swalling wrote:

I think Nemo's assumption is a good one here. These days, users expect these kinds of notifications and know how to opt-out of them if they are unwanted.

Done

The update also seems to have affected old users who merely never specified a preference, rather than just new users...? That's going to annoy people who deliberately didn't set it.

Reverted for now

If they deliberately didn't set it they can change it in the preferences or when editing, and in any case they'll notice it thanks to the checkbox on page editing, so it can't be of annoyance.
On the other hand, new users need sensible defaults and they might never discover the existence of the preference.

(In reply to comment #5)

If they deliberately didn't set it they can change it in the preferences or
when editing, and in any case they'll notice it thanks to the checkbox on page
editing, so it can't be of annoyance.
On the other hand, new users need sensible defaults and they might never
discover the existence of the preference.

Changing the preferences of hundreds of editors without asking (even if they can change back) is just going to annoy them.

I suspect someone clever will come up with a good way to resolve the key issue here - the different between "default to" and "never changed" for older users - and then the same changes to default settings can be made without annoying hundreds of editors.

swalling wrote:

Changing the preferences of hundreds of editors without asking (even if they
can change back) is just going to annoy them.

I suspect someone clever will come up with a good way to resolve the key issue
here - the different between "default to" and "never changed" for older users -
and then the same changes to default settings can be made without annoying
hundreds of editors.

Agreed. It's ok if we set the expectation of watchlist emails for new editors, but futzing with the preferences of not-so-new folks without warning is probably a bad idea.

(In reply to comment #6)

Changing the preferences of hundreds of editors without asking (even if they
can change back) is just going to annoy them.

Some preferences have been removed entirely, or can't be changed back, so apparently this is not a problem. I really don't see how it could be for something which is set each time before saving.

I suspect someone clever will come up with a good way to resolve the key issue
here - the different between "default to" and "never changed" for older users -
and then the same changes to default settings can be made without annoying
hundreds of editors.

Actually not, it would need a migration script.

beau wrote:

This can be very bad for bots, as they will grow huge watchlists.

(In reply to comment #8)

Some preferences have been removed entirely, or can't be changed back, so
apparently this is not a problem. I really don't see how it could be for
something which is set each time before saving.

I don't agree. Preference removal has only been done in a small number of cases (<math> options and "minor by default" come to mind), both where a relatively small number of users were affected. Both were problematic and raised objections even though they were trailed in advance (unlike this change, which was accidental and hence untrailed). The latter is a particularly good example because again, it was something you could tick each time you edited a page. But it still caused a fuss.

I suspect someone clever will come up with a good way to resolve the key issue
here - the different between "default to" and "never changed" for older users
and then the same changes to default settings can be made without annoying
hundreds of editors.

Actually not, it would need a migration script.

That's exactly what I had in mind, yes.

(In reply to comment #9)

This can be very bad for bots, as they will grow huge watchlists.

So, use the bot flag to override it then, right?

beau wrote:

(In reply to comment #11)

So, use the bot flag to override it then, right?

Either this feature should not be available for users with bot flag or the migration script should explicitly turn off this feature.

(In reply to comment #12)

(In reply to comment #11)

So, use the bot flag to override it then, right?

Either this feature should not be available for users with bot flag or the
migration script should explicitly turn off this feature.

Why? This is only one of many options any bot owner has to adjust on a bot account, and it wouldn't create any disruption to old accounts as email notifications are disabled by default.

beau wrote:

(In reply to comment #13)

Why? This is only one of many options any bot owner has to adjust on a bot
account, and it wouldn't create any disruption to old accounts as email
notifications are disabled by default.

If you have one bot account there is no issue assumimg you can inform community about the change. There are always people who miss such notices. What is more if you are global bot operator you have to change the preferences for each local account, that's a lot of work.

swalling wrote:

(In reply to comment #7)

Changing the preferences of hundreds of editors without asking (even if they
can change back) is just going to annoy them.

I suspect someone clever will come up with a good way to resolve the key issue
here - the different between "default to" and "never changed" for older users -
and then the same changes to default settings can be made without annoying
hundreds of editors.

Agreed. It's ok if we set the expectation of watchlist emails for new editors,
but futzing with the preferences of not-so-new folks without warning is
probably a bad idea.

Okay, there's been quite a bit of discussion on this bug, but little action lately. Let me try to summarize what I see so far:

• There is consensus that this is a Good Thing (tm) for new editors to have as a default.
• There is consensus it is a bad idea to change this to on for any existing editors.
• There is consensus that this is a bad idea to change this for bots.

It sounds to me we should avoid migrating any existing user accounts at all. Can we simply turn this preference on as checked by default for newly-registered accounts from now on?

What we would probably need to do is explicitly set it to off for all existing users that don't have the preference set (possibly with userOptions.php). Then simply set the default to on. As far as I know, there isn't any way to have different default user options for different user groups (to exclude bots), but maybe someone else knows otherwise. Having it set to on for new bots wouldn't be the end of the world though.

Actually, it looks like changing the default setting in $wgDefaultUserOptions changes it for everyone regardless of whether they have explicitly set the option differently in the past. How have we dealt with this situation in the past? Do we back-up everyone's userOptions, switch the defaults and then restore everyone's userOptions from the back-up?

Has this change been discussed anywhere?

I'm combining bug 45020 with this bug so that it's less confusing and the discussion isn't fragmented.

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

If we're going to change the Wikimedia defaults, there's no reason we shouldn't change the MediaWiki defaults while we're at it (as the rationale for both is the same).

@p858snake: it's been discussed in lots of places (mailing lists, IRC, in person), but nothing on-wiki as far as I know. Maybe a discussion on meta would be useful.

swalling wrote:

(In reply to comment #18)

Has this change been discussed anywhere?

Per Kaldari's apt bug title change, it should be clear this change is only for new users. It won't change the preference of any existing account, and thus isn't a feature where we need to go ask folks on the wikis.

To expand on why I support change: it's a cardinal sin to give users a feed of things (like a watchlist) and have nothing in it when they first view it. Showing new users the list of changes to pages they have edited or created demonstrates the usefulness of the watchlist through showing them how it works, rather than hoping they might go watch some pages before seeing the feature in action.

(In reply to comment #17)

Actually, it looks like changing the default setting in $wgDefaultUserOptions
changes it for everyone regardless of whether they have explicitly set the
option differently in the past.

This doesn't make any sense. If this is accurate, there must be a dependent bug to fix this, as the behavior as described wouldn't be logical. If a user explicitly disables a user preference, why would $wgDefaultUserOptions override that?

The introductory paragraph of [[mw:Manual:$wgDefaultUserOptions]] seems to suggest that the path forward you described in comment 16 is accurate. You'd run a maintenance script on all Wikimedia wikis to set the option to explicitly false (as default user options are not stored) and then you'd switch the default behavior in CommonSettings.php, which would change the default behavior for any new account.

(In reply to comment #23)

(In reply to comment #17)

Actually, it looks like changing the default setting in $wgDefaultUserOptions
changes it for everyone regardless of whether they have explicitly set the
option differently in the past.

This doesn't make any sense. If this is accurate, there must be a dependent
bug
to fix this, as the behavior as described wouldn't be logical. If a user
explicitly disables a user preference, why would $wgDefaultUserOptions
override
that?

It would have to be a massive regression, I've been cc'ed on a few of these and it's always been a case of doing what MZM says in his second paragraph.

You'd run a maintenance script on all Wikimedia wikis to set the option to
explicitly false (as default user options are not stored) and then you'd switch
the default behavior in CommonSettings.php

That's easier said than done. We have 19 million users in the en.wiki database. To update all of them without totally locking up the table requires using low priority batched jobs, which means the maintenance script would probably take a couple days to run. During that time, anyone who saved their preferences would undo the update. At some point we may want to change how we're saving user preferences so that we can actually change defaults without switching lots of people that don't want to be switched.

swalling wrote:

(In reply to comment #25)

You'd run a maintenance script on all Wikimedia wikis to set the option to
explicitly false (as default user options are not stored) and then you'd switch
the default behavior in CommonSettings.php

That's easier said than done. We have 19 million users in the en.wiki
database.
To update all of them without totally locking up the table requires using low
priority batched jobs, which means the maintenance script would probably
take a
couple days to run. During that time, anyone who saved their preferences
would
undo the update. At some point we may want to change how we're saving user
preferences so that we can actually change defaults without switching lots of
people that don't want to be switched.

Yeah, the issue where the migration would undo the preference change for anyone who updated (newbie or not) is pretty bad.

Why do you guys do what you did for Echo, and use a hook to change the default for new users on account creation? It's not very elegant, but it causes no pain for end users.

Looks like Benny was thinking the same thing: https://gerrit.wikimedia.org/r/#/c/68297/

(In reply to comment #27)

Looks like Benny was thinking the same thing:
https://gerrit.wikimedia.org/r/#/c/68297/

Wonderful news to begin a day! Maybe we'll get this bug fixed before the 2.5 years mark from request.
On the other hand, that's a solution in core for a problem which is only WMF's. But once the WMF roadblock is removed, it will be finally easy to completely fix bug 45020 by really changing the default in core without affecting WMF i.e. this bug.

Adding bug 52777 as a blocker per Tim's comments
on https://gerrit.wikimedia.org/r/#/c/68297/.

I have just learned that 'watchcreations' is already enabled for all users on all Wikimedia wikis except Commons today (by accidentally turning it off for everyone because I'm dumb, see https://gerrit.wikimedia.org/r/93160).

Just a note that these options are now enabled by default in MediaWiki itself (per bug 45020); we still need to enabled them on Wikimedia wikis.

Sigh, so sad that I still have to teach users to manually toggle these preferences, at Wikimedia Italia workshops. Usually they jawdrop "what?! I thought it was obvious I would want to watchlist those pages".

I suspect that there may be a fair amount of new-ish users who patrol the recent changes, and wouldn't want every instance of reverted vandalism to result in another page they know nothing about added to their watchlist. Maybe the preference option can be split to not include reverts as regular edits?

To summarize: MediaWiki's preferences system is optimized to save storage space. If you select (or never change away from) the option which is also the site default, no user_properties row is stored for that setting. This means that changing the default will change the user preference for every user who had that option selected. For something with as much workflow impact as the watchlist settings, this is not feasible.

Sometimes we get around that by changing the setting for new users in a hook. Doing that for this setting was opposed in the past on the grounds of T54777: user_properties table bloat (was a long time ago, not sure if it is still relevant).

Another, smaller problem with changing on account creation: what do you do with autocreations? Either you only change on primary account creation; then a new user signs up, gets their watchdefault preference set, then they visit another wiki and the preference won't be automatically set there. Or you do change it on autocreation; then, whenever existing users visit a new wiki, they will have the preference auto-set for that wiki. Either way seems confusing.

Maybe we should allow the default option value to be some kind of registration date map? If you registered before 2022, your default is off; if you registered afterwards, your default is on. Could be done in the UserGetDefaultOptions hook, or in core - given the existence of that hook, there is already no other reliable way to get the defaults than UserOptionsManager so changing the defaults configuration doesn't seem too bad.