Talk:Requests for comment/Watch Categorylinks

Watchlist

This seems slightly to be mixing watchlist and notices ui. If a user watches a category, shouldnt they find out about removals and additions in the watchlist, not in echo?

Do you plan to support showing who added/removed the category (i think thats impossible to do, at least in all cases, and i dont think it should be a requirement, but if you have a solution for that, that would be awesome). Bawolff (talk) 16:24, 30 March 2015 (UTC)

Hi Bawolff, since a WikiPage object is passed to the event handler, determining and displaying the corresponding author shouldn't be a problem. We need to make sure to keep the notification simple and respect the recommendation of having not more than two links in the notification (see: Echo_(Notifications)/Developer_guide#Defining_a_notification). Kai Nissen (WMDE) (talk) 13:00, 31 March 2015 (UTC)

not all category change events are directly associated with an edit. Bawolff (talk) 13:22, 31 March 2015 (UTC)

The terminology was unclear, so I made it consistent. The linked page clearly asks for watchlisting (Beobachten). Notifications (enotifwatchlist) are given "for free" by the watchlist. --Nemo 14:03, 31 March 2015 (UTC)

How will watching category membership changes integrate with Special:Watchlist? I'm not sure about using Echo/notifications for this. --MZMcBride (talk) 03:33, 15 April 2015 (UTC)

Setting

Pro But please make sure the default setting (notification via Web/Mail on/off) can be configured so that if a comunity wants to change it, it can be done without editing in the source-code. -- MichaelSchoenitzer (talk) 11:09, 31 March 2015 (UTC)

Since it sounds like this will be an Echo notification, that would be a simple case of altering your $wgDefaultUserOptions. --Krenair ^{(talk • contribs)} 11:16, 31 March 2015 (UTC)

Finally something useful

Congratulations to WMDE for trying to work on the most crucial piece of our wikis after action=edit, the RecentChanges/Watchlist mechanism. This is the heart of wikis, where all the collaboration and activity lives. --Nemo 14:03, 31 March 2015 (UTC)

Does this need to be its own extension?

Given the Echo features that you want to use (bundling is a good one, for instance), this probably can't be in MW core, but is there a reason why this should be in its own extension, rather than being part of the Echo extension? --Roan Kattouw (WMF) (talk) 20:43, 1 April 2015 (UTC)

I'm not sure if it's a good idea to stuff all notification types into it. Echo provides ways to easily define events and create notifications. If we start to add all types of notifications in Echo itself, wouldn't we bloat it? Kai Nissen (WMDE) (talk) 09:43, 2 April 2015 (UTC)

Well, Echo already takes over some watchlisting features of core, namely enotiftalk. --Nemo 09:47, 2 April 2015 (UTC)

Feature thoughts

Having recently implemented a category membership watchlist tool on labs, some thoughts:

• Allow to monitor additions only, removals only, or both for a given category.
• Allow to match partial category names.
• If a given category is added and removed from the same page the same number of times, suppress it. ie. reverts
• Provide an atom feed if this is not integrated with current page watchlists. --Bamyers99 (talk) 23:41, 6 April 2015 (UTC)

@Bamyers99: Could you make that tool to work on other wikis as well? Helder 14:20, 15 April 2015 (UTC)

Meeting outcome

Thanks Matt for the update on the meeting outcome. I'm not sure about point 1 (template changes), but on 2 I think it's fine to require a specific watchlist table setting to watch category members changes. The new field might contain serialised parameters à la log_params to be future-proof: later, this would allow to add an UI to customise category watching experience as well as to add more "smart watchlisting" features in other cases. I don't think it's necessary to provide a user-facing option to not watch category member changes from the very first iteration. --Nemo 06:13, 18 April 2015 (UTC)