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.

The Growth-Team would like to make this happen - we want the watchlist enabled by default during the guided edited experiences for new users that we are working on, and we also think it's an improvement for new users in general.

Eight years ago this was blocked due to database size concerns. We get about a quarter million new users per month; given the automated account creation on various wikis, that's upwards from a million new user records per month; for any property that is set to a non-default value for new users, that's an extra million user_property rows monthly. That doesn't seem to be a concern anymore - a user creation on enwiki right now results in new 12 users property rows. So I assume there's enough space today for user preference size not to be a concern, and one more row won't make a significant difference. @Ladsgroup what do you think about that?

(See T54777#7651262 for some stats.)

Thanks for bringing this to my attention. user_properties table in enwiki is at 16GB and while it could really use normalization on up_property and possibly, maybe on up_value but it's not a concern atm (to compare pagelinks is ten times bigger).

That being said, I do see some issues:

• I think these changes adding needs some offsetting. Possibly just by normalizing up_property? Or help in normalizing templatelinks (T299417)
• There might be some issues with deadlocks caused by new user creations and this table: T286521: Deadlock found when trying to get lock (UserOptionsManager::saveOptionsQuery) but it seems it's fixed now. A double check would be great.
• And the most importantly, I don't think it will cause issues directly but it will increase the size of watchlist and through that we will see issues. We recently did some clean ups and removed millions of rows from enwiki (and 90% of wikidata and some other wikis).
  • Querying watchlist won't become a reliability issue given that now it has max 30 seconds query timeout but it can slowly become unusable to users.
  • Normalizing it with linktarget (similar to templatelinks) might help but I don't know how page moves work in watchlist. Might not be suitable. It wouldn't save much either, pages don't get repeated that often there. So I advise against it unless someone can show benefit (e.g. lots of duplication).
  • Given that watchlist gets joined with rc table all the time, improving rc table would be a better way to move things forward. I have had some ideas (e.g. reducing rc max age in large wikis) but they seem a bit offtopic.

My volunteer user hat on: I personally would not like this option. I edit a lot of pages, if all gets added to my watchlist, it'll become useless :/ I'm slightly worried a user starts to have this for long time and then deciding to turn it off but the clean up of watchlist pages would become impossible. Just a thought from user xp.

In T38316#7652720, @Ladsgroup wrote:

• I think these changes adding needs some offsetting. Possibly just by normalizing up_property? Or help in normalizing templatelinks (T299417)

Are you suggesting we should work on one of those projects, or are you saying they are on someone's roadmap and this task should be on hold until they get done?

• There might be some issues with deadlocks caused by new user creations and this table: T286521: Deadlock found when trying to get lock (UserOptionsManager::saveOptionsQuery) but it seems it's fixed now. A double check would be great.

I don't think that bug was relevant in any case. Increasing the number of per-user preferences per user won't make locks any more or less likely.

• And the most importantly, I don't think it will cause issues directly but it will increase the size of watchlist and through that we will see issues. We recently did some clean ups and removed millions of rows from enwiki (and 90% of wikidata and some other wikis).

That seems likely, over a sufficiently long time. Looking at enwiki, about 40% of watchlist entries already come from users with <10 edits. If users are opted in automatically, that will probably grow further.

• Normalizing it with linktarget (similar to templatelinks) might help but I don't know how page moves work in watchlist. Might not be suitable. It wouldn't save much either, pages don't get repeated that often there. So I advise against it unless someone can show benefit (e.g. lots of duplication).

Watchlist entries are duplicated with page move. That would work with page IDs as well. People do want to watch non-existing pages though (e.g. to make sure deleted attack or vanity pages do not get recreated). So it would have to be done with a new title table, not page. (The same might be true for templatelinks as well, not sure how we handle references to non-existing templates.)

• Given that watchlist gets joined with rc table all the time, improving rc table would be a better way to move things forward. I have had some ideas (e.g. reducing rc max age in large wikis) but they seem a bit offtopic.

In terms of performance (as opposed to storage cost), I think the watchlist size shouldn't matter much because either the DB engine will walk the recentchanges table and look up watchlist rows via join condition (which is constant time in terms of watchlist size) or it walks the wl_user index, which is also constant time. A single user having an enormous watchlist could be problematic - that could be an issue for bots, I suppose, but bots with bot flags are already excepted, and unflagged bots doing huge numbers of edits should be rare (he says naively).

My volunteer user hat on: I personally would not like this option. I edit a lot of pages, if all gets added to my watchlist, it'll become useless :/ I'm slightly worried a user starts to have this for long time and then deciding to turn it off but the clean up of watchlist pages would become impossible. Just a thought from user xp.

I feel if you care about your watchlist, you'll figure out early on how you want to set this, and if you don't care about it, you can just truncate it when you decide to start caring. What's the disadvantage of an emptied watchlist over a useless watchlist?

(accidental dupe)