Ability to watch all articles in a category
OpenPublic

Assigned To
None
Priority
Lowest
Author
bzimport
Commits
Unknown Object (Diffusion Commit)
Subscribers
Ricordisamoa, Aklapper, Meno25 and 12 others
Projects
Tokens
"Like" token, awarded by He7d3r.
Security
None
Reference
bz1710
Description

Author: anti0918

Description:
Request: The ability to watch all of the articles within a category (not necessarily
within the subarticles, but it would also be nice). This would more easily allow
individuals with interests in specific topics to watch for vandalism and new
articles, and add content. It would also encourage such actions.

en:User:Brian0918


Version: unspecified
Severity: enhancement

bzimport added a project: MediaWiki-Watchlist.Via ConduitNov 21 2014, 8:15 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz1710.
bzimport created this task.Via LegacyMar 18 2005, 9:04 PM
bzimport added a comment.Via ConduitMar 21 2005, 6:24 PM

richholton wrote:

Conceptually, this could be done in (at least) two ways:

  1. At the time of request, all a current members of the category to the user's

watch list.

  1. Somehow add the category itself to the watch list. If new pages are added to

the category, these pages would also be watched.

1 has the advantage of being almost certainly simpler to implement. However,
it's probably less useful.

bzimport added a comment.Via ConduitSep 17 2005, 12:30 PM

zigger wrote:

*** Bug 3479 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitDec 29 2005, 6:54 AM

zigger wrote:

*** Bug 4343 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitFeb 21 2006, 12:41 PM

adinadav wrote:

This can be done now, AFAIK, by using the 'Related changes' link for a category.
shouldn't this bug be marked FIXED?

Tsor added a comment.Via ConduitFeb 21 2006, 12:58 PM

No, not yet: What about the articles in subcategories?

bzimport added a comment.Via ConduitFeb 21 2006, 1:05 PM

mathias.schindler wrote:

Using Related changes is a different concept.

Many/Most/A lot of/ people consider their own watchlist their main source of
suggestion where to work next. There is no feature yet to tell Mediawiki to add
all (current and future) articles of an existing category to my own existing
watchlist. Related Changes is a half-suitable workaround. It is not an
replacement of this feature request.

bzimport added a comment.Via ConduitFeb 26 2006, 8:38 PM

gangleri wrote:

(In reply to comment #4)

This can be done now, AFAIK, by using the 'Related changes' link for a category.
shouldn't this bug be marked FIXED?

'special:Recentchangeslinked/Category:foo' is neither a 100% substitute for
watching all 'members' of 'category:foo' nor of the members of its subcategories.

It will *neither* show if category membership is removed for some 'members'
(because the new revision is no longar a member of 'category:foo') nor if
'members' are moved (move tests where made to ilustrate the request of bug 5052).


A 'nice to have' would be a special tag for the category namespace named 'watch
membership' (or similar) which should lead to a form haveing both radio buttons
as 'watch all members', 'watch all subcategories' *and* the option to watch only
individual members using a list with checkboxes similar to the one from
'special:Watchlist/edit'.

bzimport added a comment.Via ConduitJun 22 2006, 9:26 AM

martelli wrote:

As it was said above, it would encourage experts to watch the category related
to their subject for vandalism (with all subcategories included, that would be
very nice).

bzimport added a comment.Via ConduitJun 30 2006, 1:08 PM

omniplex wrote:

Re #7, check out [[Help:DPL]] on Meta, not exactly what you want,
but close.

bzimport added a comment.Via ConduitJan 12 2008, 7:24 PM

ian wrote:

Greetings. I came upon this request in my requisite search before submitting an "Ability to watch Recent Changes" request. I also came across bug 2308, bug 12308, and this forum post: http://www.mwusers.com/forums/showthread.php?t=5579. They all seem to be asking for the ability to subscribe to a push feed of changes to existing and/or new pages of a given criteria, without having continuously seek out, and manually subscribe to, each one individually. Examples include: "all pages", "all sub pages of a parent page", "all pages in a category", "all pages with title, content, or certain metadata matching these patterns or parameters", and so on.

Would it make sense to generalize this bug, or perhaps create a meta-bug that groups this with those mentioned previously--"Selectively watch page edits and additions", or the like?

waldyrious added a comment.Via ConduitApr 19 2008, 12:16 PM

The correct link to DLP is [[m:Help:DLP]] (there's also [[m:DynamicPageList]] which should be moved to mediawiki.org sooner or later, and has in my opinion a better explanation of the extension.

Another alternative "solution" was referred in bug 7148 (geez, there are really a bunch of bugs about this issue as #10 said above, and they have slight differences so they can't be marked as dupes... a meta-bug really is something that should be done) is a user script: [[User:Ais523/catwatch.js]].

I hope this gets fixed, as it's be really useful and improve the efficiency of the editors.

bzimport added a comment.Via ConduitMay 5 2008, 1:45 AM

Wiki.Melancholie wrote:

Since some months there is an easy way to do this, see bug 5220#c21 (web feed + Mozilla Thunderbird)!

waldyrious added a comment.Via ConduitMay 5 2008, 11:57 AM

replied in bug 5220#c24.

siebrand added a comment.Via ConduitFeb 2 2009, 12:46 PM

Changed component to "Watchlist"

gpaumier added a comment.Via ConduitDec 29 2009, 5:44 PM
  • Bug 8261 has been marked as a duplicate of this bug. ***
Qgil added a comment.Via ConduitMar 26 2013, 5:51 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:36 PM

This request has a bunch of different interpretations of varrying difficulty:

*when you hit watch on a category all articles in the category are added to your watchlist. This is a one time event. If someone later removes an article from the category it does not get removed from your watchlist. Ditto for adding.

This is not that difficult and is doable in gsoc. In fact it might be too short. However one would have to be careful about big cats. Unprintworthy redirects has over a million entries. We already have problems with watchlists exploding when they get too big. Combining such a project with tools to prune your watchlist when it gets too big might makr a good project. (Someone more familar with watchlists would probably be better at saying if scope is appropriate than I could)

Possible interface might be better as a add-all-things from cat foo box on special:watchlist rather than associating with watching the category.

*the previous one+watch subcats.
If that's taken as all subcats of all subcats I cab say right now that's a wontfix. Doing just one level maybe ok, but I would still be hesitant.

*add a cat to watchlist all things in cat are in watchlist. If something is added to cat it gets added to your watchlist

Its unclear how to do this (in a good fashion). I would not reccomend this to a student. However if a student is particularly interested tell them to post a detailed implementation plan on this bug so we could judge its feasibility.

*previous point + noting removals and additions to the category.

Probably what is truley wanted, but even more difficult than previous point. Noting category additions/removals is rather independant issue and essentialy bug 7148

bzimport added a comment.Via ConduitMar 27 2013, 10:41 AM

dotmaudot wrote:

as for me, watching subcats is not an issue (I could subscribe to subcats too), but at least additions to the category would be useful.

waldyrious added a comment.Via ConduitMar 29 2013, 2:33 PM

(In reply to comment #18)

*add a cat to watchlist all things in cat are in watchlist. If something is
added to cat it gets added to your watchlist

*previous point + noting removals and additions to the category.

So, just to be clear, the last point only differs from the preceding one by allowing removals to be tracked (not only additions)? If so, what exactly makes tracking removals so much harder than tracking additions?

*the previous one+watch subcats.
If that's taken as all subcats of all subcats I cab say right now that's a
wontfix. Doing just one level maybe ok, but I would still be hesitant.

One level would cover too narrow a subset of use cases, imo. Perhaps for this kind of need, the best would be a separate feature, to watch all pages linked from a specific page (e.g. a list).

waldyrious added a comment.Via ConduitMar 29 2013, 2:36 PM

(In reply to comment #20)

what exactly makes tracking removals so much harder than tracking additions?

bug 13588 comment 0 explains it:

Currently the only link that is timesstamped is cl_timestamp. With this it is
only possible to track additions to categories.

Bawolff added a comment.Via ConduitMar 29 2013, 3:36 PM

(In reply to comment #20)

(In reply to comment #18)
> *add a cat to watchlist all things in cat are in watchlist. If something is
> added to cat it gets added to your watchlist
>
> *previous point + noting removals and additions to the category.

So, just to be clear, the last point only differs from the preceding one by
allowing removals to be tracked (not only additions)? If so, what exactly
makes
tracking removals so much harder than tracking additions?

Additions are kind of hard to track. Cl_timestamp isnt really sufficient.

Basically the hard part is attributing arthurship to the category change, especially when templates change. Categories can also change on events not associated with an edit action. See bug 7148

If we don't care who changed which category something is in, things become a lot easier.

waldyrious added a comment.Via ConduitMar 29 2013, 5:06 PM

(In reply to comment #22)

If we don't care who changed which category something is in, things become a
lot easier.

Maybe an ideal implementation would have to be planned from scratch to take authorship in consideration, but for the purposes of this specific request, I don't think *who* performed a given change is that relevant; as long as the relevant pages are being kept in the watchlist, the goal would be achieved.

Qgil added a comment.Via ConduitApr 1 2014, 8:32 PM

Open since 2005, inactive in the past 12 months... If we want to reflect the current plans, this should be "lowest".

He7d3r awarded a token.Via WebNov 24 2014, 12:06 PM
greg added a subscriber: greg.Via WebNov 26 2014, 10:12 PM
Nemo_bis added a project: Epic.Via WebJan 2 2015, 7:01 PM
Nemo_bis set Security to None.
epriestley closed this task as "Resolved" by committing Unknown Object (Diffusion Commit).Via DaemonsMar 4 2015, 8:22 AM
Qgil reopened this task as "Open".Via WebMar 4 2015, 8:39 AM

Accidental clash. Known issue. Reverting status.

Ricordisamoa added a subscriber: Ricordisamoa.Via WebFri, Aug 21, 6:56 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldFri, Aug 21, 6:56 AM

Add Comment