swalling wrote:

Adding EE team members to this and bug 36316 since it may be tackled by them as part of work on releasing Echo (which includes a watchlist notification).

Yeah, testers sometimes figure out that they have to add things to their watchlists to get updates, but generally only when prompted, which doesnt exactly bode well for the average user. Considering how especially new users are apt to care about going back to see how their edits have fared, having stuff be added to their watchlists by default would definitely help.

Moves may also make sense since moves are basically edits anyway, and even relatively new users can and do move pages from time to time, deletions... yeah. Pages admins delete they generally dont care to see on their watchlists; they can go through a crapton of pages and not give even the slightest crap if someone recreates them later. Certainly dont want to see the spam and attack titles on their watchlists later. And as you say, if they do want to see it, theyll probably know how to turn the thing on themselves.

Thanks, everyone, for recommending this important enhancement!

Our WMF editor engagement team also thinks this is a key feature for new users, who are not aware of how the watchlist works and are not likely to use it if they do not see anything relevant when they first visit it.

We hope to implement this feature in coming weeks, as part of our Echo notification project, as described in this proposal:

http://www.mediawiki.org/wiki/Echo/Feature_requirements#Add_pages_to_new_user_watchlists

Note that we are also planning to create a few more watchlist-related features at the same time:

http://www.mediawiki.org/wiki/Echo/Feature_requirements#Watchlist_notifications

Comments and suggestions welcome. Please keep in mind that we only have a few days of development time for these features in this first release, so please focus your recommendations on the most important and practical points that can be implemented relatively quickly. Thanks for your understanding :)

Isarra, I agree with you on the page moves, on the other hand there's also some power-users moving a lot of pages they don't care about just like sysops delete, so the same considerations apply IMHO.

(In reply to comment #3)

Comments and suggestions welcome. Please keep in mind that we only have a few
days of development time for these features in this first release, so please
focus your recommendations on the most important and practical points that
can
be implemented relatively quickly. Thanks for your understanding :)

Thank you Fabrice, I'll ensure to check that page again: I had not seen the section during the office hours or I didn't understand it was also about core.
Well, this is just a character to change in the config and the only cost is occupying some space in Reedy's memory so that he remembers to "save" WMF wikis when upgrading so that bug 36316 can be fixed with the additional care explained there... so it should definitely moved out of "Features under consideration" and I'm sure it will be done anyway at some point.

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

• This bug has been marked as a duplicate of bug 36316 ***

This is not a duplicate. The bug here is about desirability of the change (which is unchallenged), while bug 36316 is about WMF-only processes to deal with the change.

Related URL: https://gerrit.wikimedia.org/r/68297 (Gerrit Change I95ebe73ac65a8ac7da074b1a94962b4c175861a2)

Patch in comment 8 has received -1 in Gerrit and needs rework.

If we want to do this for the release, and we can't do this (yet) for WMF,
can't we just enable them in $wgDefaultUserOptions in DefaultSettings.php
and disable them back in WMF config? That would be two trivial two-line changes. The current patch doesn't look like it's going to be merged anytime soon.

If we don't want to do this for the release, please update the milestone and priority.

(In reply to comment #10)

If we want to do this for the release, and we can't do this (yet) for WMF,
can't we just enable them in $wgDefaultUserOptions in DefaultSettings.php
and disable them back in WMF config?

Yes please. That's the idea for this bug. WMF now has a release manager etc., they should be able to coordinate the switch of a variable during deploy.

Release manager is not needed for anything here, somebody just has to create both patches and say that they are dependent on each other. New version deployment is naturally correlated with a configuration update, so this will probably amount to two extra mouse click for the deployer (one to merge the core change before branching new wmfXX version and second to merge the config change right after).

In fact, the configuration patch here would be backwards-compatible (same config as the currently default one), so there is just about zero coordination needed. Just merge that one before the other.

This bug has been open for 8 months. I've enjoyed philosophical discussions around this in the last couple years, but I'm tired now: if you think it's that simple i.e. you are willing to merge it immediately I can submit the patch, otherwise no point in discussing.

Change 89603 had a related patch set uploaded by Bartosz Dziewoński:
Explicitly set 'watchcreations' and 'watchdefault' options to false

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

Change 89604 had a related patch set uploaded by Bartosz Dziewoński:
Set 'watchcreations' and 'watchdefault' options to true

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

Change 89603 merged by jenkins-bot:
Explicitly set 'watchcreations' and 'watchdefault' options to false

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

Change 89604 merged by jenkins-bot:
Set 'watchcreations' and 'watchdefault' options to true

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

Thanks Bartosz, Brian and Ori! This is a nice day. :)
I've added notes to [[mw:MediaWiki 1.23#Notifications]]. Now we only need bug 45022 in the same way. With some more configuration and bundling/installer tweaks, maybe with 1.23 vanilla MediaWiki will start being almost usable. ;-)

This is in some ways a workaround for the difficulties in getting bug 3525 fixed. It definitely makes it seem less urgent, I think.

Change 68297 abandoned by Bsitu:
Update watchlist preference for new users

Reason:
Wrong approach

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