Watch edits which add or remove pages from a category
OpenPublic

Description

As a Wikipedia editor I want to be notified if a new article was added to or deleted from a certain category in order to quickly address improper additions and deletions.

See https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_W%C3%BCnsche/Top_20#M.C3.B6glichkeit.2C_eine_Kategorie_auf_neue_Artikel_hin_zu_beobachten (in German).

Further details:
Details were discussed in an RFC.

Effort: ..

Needs to be discussed with: ..

This is part of the Top 20 wishes of the German community.

Related tasks:
T3710: Ability to watch all articles in a category which is about watching *all* edits to category entries.

bzimport added a project: MediaWiki-Watchlist.Via ConduitNov 21 2014, 9:24 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz7148.
BD2412 created this task.Via LegacyAug 28 2006, 3:48 PM
bzimport added a comment.Via ConduitAug 28 2006, 4:02 PM

robchur wrote:

This is going to be practically impossible to implement unless we start
versioning category links.

brion added a comment.Via ConduitAug 29 2006, 12:00 PM
  • This bug has been marked as a duplicate of 4605 ***
bzimport added a comment.Via ConduitAug 29 2006, 4:45 PM

ayg wrote:

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).

BD2412 added a comment.Via ConduitAug 31 2006, 1:38 AM

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.

bzimport added a comment.Via ConduitAug 31 2006, 1:57 AM

ayg wrote:

This isn't a duplicate, irrespective of possible (hopefully not) WONTFIX, so I'm
reopening.

bzimport added a comment.Via ConduitAug 31 2006, 2:21 PM

robchur wrote:

Comment 1 still stands.

BD2412 added a comment.Via ConduitAug 31 2006, 5:05 PM

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.

bzimport added a comment.Via ConduitAug 31 2006, 5:16 PM

robchur wrote:

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.

brion added a comment.Via ConduitJun 12 2007, 8:29 PM
  • Bug 10225 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitJun 12 2007, 8:33 PM

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).

bzimport added a comment.Via ConduitAug 18 2007, 9:45 PM

bugs wrote:

Should work with a javascript tool http://en.wikipedia.org/wiki/User:Ais523/catwatch.js currently used on the English Wikipedia.

bzimport added a comment.Via ConduitAug 19 2007, 1:17 AM

ayg wrote:

"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.

bzimport added a comment.Via ConduitAug 19 2007, 1:22 AM

bugs wrote:

I thought someone might do that. :)

bzimport added a comment.Via ConduitAug 20 2007, 3:34 PM

ais523 wrote:

(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.)

bzimport added a comment.Via ConduitAug 20 2007, 5:33 PM

ayg wrote:

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.

bzimport added a comment.Via ConduitJun 22 2008, 6:30 PM

ian.woollard wrote:

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.

bzimport added a comment.Via ConduitJun 22 2008, 6:44 PM

ayg wrote:

(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.

bzimport added a comment.Via ConduitJun 22 2008, 7:59 PM

ian.woollard wrote:

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.

bzimport added a comment.Via ConduitJun 22 2008, 8:03 PM

Bryan.TongMinh wrote:

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.

bzimport added a comment.Via ConduitJun 22 2008, 8:24 PM

ian.woollard wrote:

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.

siebrand added a comment.Via ConduitFeb 2 2009, 11:42 AM

Changing component to "Watchlist"

MZMcBride added a comment.Via ConduitApr 2 2011, 11:09 PM
  • Bug 28396 has been marked as a duplicate of this bug. ***
Subfader added a comment.Via ConduitApr 2 2011, 11:12 PM

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)

demon added a comment.Via ConduitNov 9 2012, 7:41 PM
  • Bug 41014 has been marked as a duplicate of this bug. ***
Jidanni added a comment.Via ConduitNov 9 2012, 11:11 PM

(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."

Qgil added a comment.Via ConduitMar 26 2013, 5:50 PM

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

Bawolff added a comment.Via ConduitMar 26 2013, 10:15 PM

(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.

bzimport added a comment.Via ConduitSep 17 2013, 2:57 PM

andy wrote:

Question: Would it be easier to resolve this by using notifications, instead of watchlists?

Ijon added a comment.Via ConduitSep 17 2013, 4:51 PM

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.)

Subfader added a comment.Via ConduitMar 2 2014, 11:43 AM

I hacked me around this by using favorites and filtering new pages by faved categories.
Favorites is another thing MW misses...

He7d3r awarded a token.Via WebNov 24 2014, 12:04 PM
Gryllida added a subscriber: Gryllida.Via WebDec 8 2014, 3:41 AM
Nemo_bis changed the title from "Requesting watchlist for changes to category content." to "Watch edits which add or remove pages from a category".Via WebJan 16 2015, 9:35 PM
Nemo_bis edited the task description. (Show Details)
Nemo_bis set Security to None.
Subfader edited the task description. (Show Details)Via WebJan 18 2015, 6:56 PM
Patrick87 added a subscriber: Patrick87.Via WebMar 24 2015, 5:01 PM

Since it isn't mentioned anywhere explicitly:
The implementation should probably be generic enough to catch all kinds of pages (articles, files, templates, etc.)

Not that we end up with only a partial implementation that catches only changes to article categorization...

Nemo_bis added a project: Epic.Via WebMar 31 2015, 1:50 PM
Ricordisamoa added a subscriber: Ricordisamoa.Via WebMar 31 2015, 3:25 PM
Ltrlg added a subscriber: Ltrlg.Via WebApr 1 2015, 12:30 PM
Mattflaschen added a subscriber: Mattflaschen.Via WebApr 24 2015, 3:08 AM
Liuxinyu970226 removed a subscriber: Liuxinyu970226.Via WebApr 24 2015, 7:49 AM
kai.nissen added a comment.Via WebApr 28 2015, 10:18 AM

RFC updated

kai.nissen added a comment.Via WebApr 28 2015, 10:21 AM

Since it isn't mentioned anywhere explicitly:
The implementation should probably be generic enough to catch all kinds of pages (articles, files, templates, etc.)

Not that we end up with only a partial implementation that catches only changes to article categorization...

It will be.

Mattflaschen added a comment.Via WebApr 29 2015, 1:39 AM

Since it isn't mentioned anywhere explicitly:
The implementation should probably be generic enough to catch all kinds of pages (articles, files, templates, etc.)

Not that we end up with only a partial implementation that catches only changes to article categorization...

It will be.

The only current proposed limitation in the RFC is that changes in templates will not be recorded separately for the articles transcluding it (but if I understand correctly, there will be a total number of affected pages in the main entry).

Aschroet added a subscriber: Aschroet.Via WebSun, May 3, 7:12 PM
Glaisher added a subscriber: Glaisher.Via WebMon, May 4, 12:12 PM
MGChecker added a subscriber: MGChecker.Via WebWed, May 6, 4:41 PM
gerritbot added a subscriber: gerritbot.Via ConduitSun, May 17, 5:22 PM

Change 211526 had a related patch set uploaded (by Kai Nissen (WMDE)):
T9148: implementation for enabling users to watch category membership changes

https://gerrit.wikimedia.org/r/211526

gerritbot added a project: Patch-For-Review.Via ConduitSun, May 17, 5:22 PM
Glaisher added a project: user-notice.Via WebSun, May 17, 5:32 PM
Man77 added a subscriber: Man77.Via WebSun, May 17, 9:28 PM
gerritbot added a comment.Via ConduitMon, May 18, 7:56 AM

Change 211526 had a related patch set uploaded (by Siebrand):
Enable users to watch category membership changes

https://gerrit.wikimedia.org/r/211526

gpaumier moved this task to Not ready to announce on the user-notice workboard.Via WebThu, May 21, 5:15 PM
Tobi_WMDE_SW moved this task to Backlog on the German-Community-Wishlist workboard.
Tobi_WMDE_SW assigned this task to KasiaWMDE.Via WebWed, May 27, 1:08 PM
Tobi_WMDE_SW raised the priority of this task from "Low" to "Normal".
Tobi_WMDE_SW edited the task description. (Show Details)
Tobi_WMDE_SW moved this task to Sprint Ready on the German-Community-Wishlist workboard.Via WebWed, May 27, 1:14 PM
Tobi_WMDE_SW moved this task to Work in progress on the German-Community-Wishlist workboard.
KasiaWMDE removed a blocking task: T15588: Track link changes.Via WebWed, May 27, 2:19 PM
Sitic added a subscriber: Sitic.Via WebWed, May 27, 7:42 PM
Tbayer added a subscriber: Tbayer.Via WebWed, May 27, 10:43 PM

Add Comment