Last modified: 2014-11-18 13:14:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7148 - Requesting watchlist for changes to category content.
Requesting watchlist for changes to category content.
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Watchlist (Other open bugs)
unspecified
All All
: Low enhancement with 27 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
:
: 10225 28396 41014 (view as bug list)
Depends on: 13588
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-28 15:48 UTC by BD2412
Modified: 2014-11-18 13:14 UTC (History)
17 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description BD2412 2006-08-28 15:48:17 UTC
Per generally favorable discussion at 
[http://en.wikipedia.org/wiki/Wikipedia_talk:Enforce_inclusion_of_categorie
s], we would like a function to permit users to watch for additions to or 
deletions from categories, in order to quickly address improper additions 
and deletions.
Comment 1 Rob Church 2006-08-28 16:02:05 UTC
This is going to be practically impossible to implement unless we start
versioning category links.
Comment 2 Brion Vibber 2006-08-29 12:00:03 UTC

*** This bug has been marked as a duplicate of 4605 ***
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-29 16:45:05 UTC
Okay, this has been marked of a duplicate of a duplicate of a duplicate of a
FIXED, so something went wrong here.  Special:Recentchangeslinked is *not* a
substitute for category watchlist, because a) it doesn't show articles' removal
from the categories and b) it provides vastly more noise than signal (probably
95% of changes are going to be unrelated to the category itself).
Comment 4 BD2412 2006-08-31 01:38:20 UTC
The issue that has been resolved is different from the request. Earlier 
requests appear to have sought a "related changes" list emanating from a 
category. We would like a watchlist type function (only the most recent 
change would need to be shown) so that a group of categories can be watched 
simultaneously, and an entry will appear on the list when an addition (or 
subtraction) is made to any of those categories. Changes to the content of 
the articles in the category are unimportant; what matters is the ability to 
see when an article is added or removed.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-31 01:57:15 UTC
This isn't a duplicate, irrespective of possible (hopefully not) WONTFIX, so I'm
reopening.
Comment 6 Rob Church 2006-08-31 14:21:17 UTC
Comment 1 still stands.
Comment 7 BD2412 2006-08-31 17:05:10 UTC
How hard can it possibly be? When I add a category to an article, some kind 
of information transfer must occur to let the category know the article has 
been added to it. Same thing with category removal. Catch those signals and 
make 'em light up a watchlist.
Comment 8 Rob Church 2006-08-31 17:16:36 UTC
The problem is that "lighting up a watchlist" requires storing the information
somewhere. Watchlists aren't generated from a big list, but from a SELECT which
looks at who's watching what, and what changed recently.
Comment 9 Brion Vibber 2007-06-12 20:29:17 UTC
*** Bug 10225 has been marked as a duplicate of this bug. ***
Comment 10 Brion Vibber 2007-06-12 20:33:07 UTC
An additional complication is that membership may be conferred or removed indirectly through changes to templates -- or even conditional statements using time-sensitive variables.

Since there isn't necessarily an editing action with which to associate such a change, it might be a little tricky to work out how to stuff it in there... But something's probably possible.

A special recentchanges table entry could perhaps be generated for each categorylinks change when doing differential updates (similar to the log entries, these would not be associated with any page revision record).
Comment 11 Casey Brown 2007-08-18 21:45:58 UTC
Should work with a javascript tool http://en.wikipedia.org/wiki/User:Ais523/catwatch.js currently used on the English Wikipedia.
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-08-19 01:17:57 UTC
"RESOLVED FIXED" for bugs filed under the MediaWiki product implies that the bug has been fixed in the default MediaWiki software (implying all Wikimedia sites plus all third-party sites when they respectively update).  It has not.  Furthermore, a JavaScript solution to this is not acceptable for inclusion in the core software: it has to be solved in the PHP, for reasons of efficiency, accessibility, and speed.  The first paragraph of the opening comment on the linked hack shows that the hack used has serious limitations anyway.
Comment 13 Casey Brown 2007-08-19 01:22:23 UTC
I thought someone might do that. :)
Comment 14 ais523 2007-08-20 15:34:58 UTC
(In reply to comment #11)
> Should work with a javascript tool
> http://en.wikipedia.org/wiki/User:Ais523/catwatch.js currently used on the
> English Wikipedia.
> 
That, of course, is merely a user script, not a software feature, and has several limitations (as mentioned above). If this is implemented in the software, though, it might be useful to have an option to ignore removals from a category (like the script does due to necessity, as removals can't be deduced from the categorylinks table); I use the script for watching (among other things) [[:w:en:CAT:HELP]] and [[:w:en:CAT:PER]], when in both cases an addition to the category is a much more useful thing to notice in the watchlist than a removal would be (and I suspect the same applies to other 'work-queue'-type categories.)
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-08-20 17:33:07 UTC
But for something like [[Category:Living people]], you definitely want to watch removals.  Better to give more information than less, if we aren't going to give an option.
Comment 16 Ian Woollard 2008-06-22 18:30:04 UTC
Presumably at *some* point the wiki software recalculates the category membership. That's a good place to add some behaviour.

One option would be, rather than have a change record, to have a way of dumping the category membership out in strict textual list form. With that ability, the wiki software could dump this category list into another associated article- for example [[WP:CategoryChanges/Rocketery]] would be associated with [[Category:Rocketry]]

Then the user could just do a watch on that article if they require it.

It would be desirable, but perhaps not essential that the list not be recalculated immediately so that if a template causes thousands of changes that you not get thousands of versions produced, just one, ideally by delaying it by a time period, 5 minutes or something might be desirable.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-22 18:44:37 UTC
(In reply to comment #16)
> Presumably at *some* point the wiki software recalculates the category
> membership. That's a good place to add some behaviour.

Yes, during article edits/jobs.  However, this would still take considerable effort to do, in practice: creating a new recentchanges-style table for category changes, and maybe using a covering index on a designated server the way we do for watchlists.  Or whatever.

> One option would be, rather than have a change record, to have a way of dumping
> the category membership out in strict textual list form. With that ability, the
> wiki software could dump this category list into another associated article-
> for example [[WP:CategoryChanges/Rocketery]] would be associated with
> [[Category:Rocketry]]
> 
> Then the user could just do a watch on that article if they require it.

Probably not as clean an idea as a dedicated database table.  You'd have these weird article revisions in the database that aren't actually article revisions, which would cause who knows what problems.  Plus if these are only kept around for watchlist, we don't really need to keep them forever the way we do revisions.
Comment 18 Ian Woollard 2008-06-22 19:59:33 UTC
If you're keeping old revisions of articles anyway, there's no major harm. And you can always get rid of old revisions by deleting the log article and recreating it.

Sure, it's probably not *as* clean, but it may be a lot less work.

Comment 19 Bryan Tong Minh 2008-06-22 20:03:52 UTC
It would probably not much less work. In the dirty case you want an extension to hook LinksUpdateComplete, calculate the link changes and write it to a page. In the neat case, you want a function which is called just before the LinksUpdateComplete hook, calculate the link changes and write it to a table in the database. Then you want a special page to actually view the contents of that table. So it is not very much more work. Besides any extension that uses the dirty way of doing it is definitely not going to pass the sysadmins.
Comment 20 Ian Woollard 2008-06-22 20:24:47 UTC
Or perhaps rather than build it in to the wiki, just create a bot to go around once a day or so and simply list/snapshot any selected categories in textual form and submit that to an associated log article. If they haven't changed, then the submit will be textually identical and ignored by the wiki and no watchlists will trigger, but if they have, existing watchlist mechanisms are good at detecting deltas.

Provided the bot uses archives in a sensible way I don't see that the versions are likely to be a problem, and by doing this periodically the number of versions is sharply constrained anyway.
Comment 21 Siebrand Mazeland 2009-02-02 11:42:10 UTC
Changing component to "Watchlist"
Comment 22 Dan Jacobson 2009-05-11 06:36:47 UTC
Also noting: http://www.mediawiki.org/wiki/Extension:CategoryWatch
Comment 23 MZMcBride 2011-04-02 23:09:52 UTC
*** Bug 28396 has been marked as a duplicate of this bug. ***
Comment 24 Subfader 2011-04-02 23:12:10 UTC
I want to request the same thing and would like to see some action on this. The last comments sound more promossing than the beginning :)

Here's the content of the dupe I created:

Watching:
When I "follow" a category I will be informed about new pages in that category. 
Currently there is no way stay informed about new articles on topics I'm interested in.

Informing the user:
The user could be informed about new pages in categories he follows in
different ways (maybe a user pref):

- on a special page, e.g. Special:Dashboard. Just like the Watchlist he may be
able to edit the list of followed categories here too.

- via e-mail

- via RSS. The feed should be unique so I can't guess other people's RSS feeds.

If it's live (via special page) or just by a daily script (via e-mail and RSS) wouldn't matter much to me. It'd be all better than current situation.


Scenarios to think about: What happens if

* a users starts following his first category. (His list would be empty, since
nothing was added since he started following it. Maybe the last page added
should be listed as a dummy.)

* a page in a watched category is moved (title should be updated in relevant
table)

* a page in a watched category is deleted

* a page is added to a followed category days after page creation

* a page is removed from a followed category before teh user saw it

* the user follows 100 or categories (using a max value may be possible but
should be avoided)

* the user follows a main category (such can include thousands of pages) (maybe
a blacklist of non-followable cats would help)
Comment 25 Chad H. 2012-11-09 19:41:21 UTC
*** Bug 41014 has been marked as a duplicate of this bug. ***
Comment 26 Dan Jacobson 2012-11-09 23:11:49 UTC
(In reply to comment #25)
> *** Bug 41014 has been marked as a duplicate of this bug. ***
Thanks, but I was trying to say that in the current situation, at least some warning should be given to the user that he will only be "watching" part of what he sees, in contrast to non-category pages, where "what he watches is what he gets."
Comment 27 Quim Gil 2013-03-26 17:50:58 UTC
It has been suggested at https://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_projects#List_of_project_ideas_25327 that this feature could be a project idea for Google Summer of Code 2013.

This is a reality check to know whether this feature is feasible for a students within that time-frame, whether the MediaWiki maintainers would be happy to take the changes if they meet quality requirements and (hopefully) whether someone would volunteer to mentor a student to accomplish this task.

More: https://www.mediawiki.org/wiki/Summer_of_Code_2013
Comment 28 Bawolff (Brian Wolff) 2013-03-26 22:15:22 UTC
(In reply to comment #27)
> It has been suggested at
> https://www.mediawiki.org/wiki/Talk:Mentorship_programs/
> Possible_projects#List_of_project_ideas_25327
> that this feature could be a project idea for Google Summer of Code 2013.
> 
> This is a reality check to know whether this feature is feasible for a
> students
> within that time-frame, whether the MediaWiki maintainers would be happy to
> take the changes if they meet quality requirements and (hopefully) whether
> someone would volunteer to mentor a student to accomplish this task.
> 
> More: https://www.mediawiki.org/wiki/Summer_of_Code_2013

I do not believe this is a suitable gsoc project. Doing this bug right does not appear to be straightforward and thus not something I would reccomend to someone with little experiance.

If there was a *student* who was particularly interested in doing this, I would suggest they post a detailed plan of their proposed approach on the bug so we can give feedback to the approach's feasibility. I do not think we should suggest this bug to students unless they are already interested.
Comment 29 Andy Mabbett 2013-09-17 14:57:08 UTC
Question: Would it be easier to resolve this by using notifications, instead of watchlists?
Comment 30 Asaf Bartov 2013-09-17 16:51:03 UTC
Andy, I think the difficulty is not in the getting-the-news-to-you bit, but in the defining-what-the-news-are and capturing-the-news-effectively bits.  (See Comment 10 for example.)
Comment 32 Subfader 2014-03-02 11:43:14 UTC
I hacked me around this by using favorites and filtering new pages by faved categories.
Favorites is another thing MW misses...

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links