| • bzimport | |
| Feb 19 2008, 4:39 AM |
| F4626: SpecialRecentchanges.php.patch | |
| Nov 21 2014, 10:02 PM |
Author: ruhrfisch
Description:
On the English Wikipedia, Special:Unwatchedpages is nearly useless because it only shows the first 1000 articles. User:Random832's suggestion is to make a page for recent changes in unwatched articles, i.e. Special:Recentchangeslinked/Special:Unwatchedpages - at this point, to actually _watch_ them, you'd have to either add all the pages to your watchlist, or make a page with links to all of them (which would disclose the list).
See also:
jlerner wrote:
Extend RC to support hiding articles that at least one user is already watching
Tested briefly against 1.14-svn, seems to work. Not sure what the clearest label would be (in [[MediaWiki:Rchidewatched]]).
Attached:
jlerner wrote:
(In reply to comment #2)
will this be implemented in a "live" version?
If we can convince the powers-that-be.
cragos wrote:
I understand this might be a separate bug request - I'd be happy to break it out if you like, but it seems related enough that it would get flagged as a DUPLICATE and ignored on several other bug trackers.
Is it possible to only check the watchlists of active users when limiting Special:RecentChanges? It doesn't mean a whole hell of a lot if an article created and untouched since 2006 was created and watched by a new editor that disappeared at the same time. The ratio of users:active users in Special:Statistics on the en wiki is mind-boggling, and though likely higher than in smaller wikis, still indicative of the overall level of editor loss that wikis experience over time.
Here's some math to sell this, if it's possible to do:
en wiki total to inactive user ratio: 51:1
de wiki total: 26:1
en wiktionary: 93:1 !
(Tried to pull stats on an off-project wiki (WikiTravel), but they must be using an obsolete version of the stats page.)
It seems readily apparent that, on a site like Wiktionary or the en Wiki where we have over 50x more inactive than active users that we don't want to risk looking at the inactive user's watchlists.
Barring any deep familiarity with MediaWiki's code, it seems to me that the tradeoff of having to separate active users from inactive users would be more offset by the number of watchlists you don't have to parse to generate the content mentioned here.
(In reply to comment #4)
I know cases when users have second account used only for watchlist and such watchlist is much larger than watchlist on their regular account. If the "active user" was measured not by number of edits but by, say, last login, it could make a sense then.
(In reply to comment #6)
> *** Bug 24891 has been marked as a duplicate of this bug. ***
Yes, it is a duplicate. This seems to be an easy implement, let's do it already. Cheers!
sumanah wrote:
I am so sorry that it has taken so long for anyone to review this patch. Right now it does not cleanly apply to trunk. Joshua, do you have time and interest in updating it? Or perhaps another commenter would like to?
This patch has a few deficiencies:
(In reply to comment #8)
Joshua, do you have time and interest in updating the patch?
Unfortunately no answer, hence resetting assignee to default.
This would be helpful at English wiktionary to reduce the number of entries that someone would have to scan to find those in their language that were possibly problematic and generally to focus attention on the most neglected entries. ~~~~
(In reply to comment #4)
Is it possible to only check the watchlists of active users when limiting
Special:RecentChanges? It doesn't mean a whole hell of a lot if an article
created and untouched since 2006 was created and watched by a new editor that
disappeared at the same time. The ratio of users:active users in
Special:Statistics on the en wiki is mind-boggling, and though likely higher
than in smaller wikis, still indicative of the overall level of editor loss
that wikis experience over time.
Interesting idea. Perhaps a join on user_touched. However I imagine that would be too expensive for wikipedia (by expensive I mean has speed issues).
However, for the original idea of Special:UnwatchedChanges. I can't imagine that would be any more expensive than Special:Recentchangeslinked.
Change 76238 had a related patch set uploaded by Brian Wolff:
Add Special:UnwatchedChanges page.
(In reply to comment #13)
Change 76238 had a related patch set uploaded by Brian Wolff:
Add Special:UnwatchedChanges page.
I thought I'd have a go at this. However I should note, the patch I made for this I'm a bit unsure about. I think it would have similar performance characteristics to Special:Recentchangeslinked with a large category.
All priority decesions are arbitrary to some extent and while every feature request is important to someone, if everything was rated high, it would defeat the point.
This one is probably rated low as it only affects a small number of users and that while it is nice, we could live without it. (Keep in mind priorities are mostly ignored so it really doesnt affect anything) see https://mediawiki.org/wiki/Phabricator/Project_management#Priority_levels
How would we know it was a small number of users? A small number of contributors perhaps. It only effects what we estimate to be the more than a million unwatched pages at English Wiktionary. If we could do some kind of retrospective review of unwatched pages that have been changed since the first few minutes after their creation run at least once we would know for a fact whether it should be low priority as a continuing matter,