Last modified: 2014-11-07 22:09:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T38316, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36316 - Set "Add pages I edit to my watchlist" and "Add pages I create to my watchlist" to true by default on Wikimedia wikis (only for new users)
Set "Add pages I edit to my watchlist" and "Add pages I create to my watchlis...
Status: NEW
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
Depends on: 52777
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-28 08:24 UTC by Nemo
Modified: 2014-11-07 22:09 UTC (History)
16 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nemo 2012-04-28 08:24:36 UTC
That is, add to common settings:

$wgDefaultUserOptions['watchdefault'] = 1;

At least on Wikimedia projects, I think it makes sense to assume that a new user who registers and edits a page wants to follow subsequent edits to that page, rather than to create a bunch of new pages and follow only those: most of our new users make only an edit o two. If the user knows how the watchlist works and don't want it, they'll just uncheck the box when editing, but as it is they'll most likely lose sight of any following edit.

This will be particularly useful when bug 28026 is completely fixed.
Comment 1 Steven Walling 2012-04-30 23:37:05 UTC
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.
Comment 2 Sam Reed (reedy) 2012-05-03 19:20:56 UTC
Done
Comment 3 Jarry1250 2012-05-03 23:19:22 UTC
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.
Comment 4 Sam Reed (reedy) 2012-05-03 23:27:30 UTC
Reverted for now
Comment 5 Nemo 2012-05-03 23:29:55 UTC
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.
Comment 6 Jarry1250 2012-05-03 23:32:08 UTC
(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.
Comment 7 Steven Walling 2012-05-03 23:44:49 UTC
> 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.
Comment 8 Nemo 2012-05-03 23:45:38 UTC
(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.
Comment 9 Beau 2012-05-04 09:12:42 UTC
This can be very bad for bots, as they will grow huge watchlists.
Comment 10 Jarry1250 2012-05-04 12:35:50 UTC
(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.
Comment 11 Mark A. Hershberger 2012-05-08 16:47:49 UTC
(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?
Comment 12 Beau 2012-05-08 16:52:49 UTC
(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.
Comment 13 Nemo 2012-05-08 17:15:29 UTC
(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.
Comment 14 Beau 2012-05-08 18:31:26 UTC
(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.
Comment 15 Steven Walling 2012-08-28 23:04:59 UTC
(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?
Comment 16 Ryan Kaldari 2013-02-14 22:26:21 UTC
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.
Comment 17 Ryan Kaldari 2013-04-02 22:50:07 UTC
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?
Comment 18 p858snake 2013-04-02 23:04:20 UTC
Has this change been discussed anywhere?
Comment 19 Ryan Kaldari 2013-04-02 23:52:39 UTC
I'm combining bug 45020 with this bug so that it's less confusing and the discussion isn't fragmented.
Comment 20 Ryan Kaldari 2013-04-02 23:53:27 UTC
*** Bug 45020 has been marked as a duplicate of this bug. ***
Comment 21 Ryan Kaldari 2013-04-03 00:00:55 UTC
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.
Comment 22 Steven Walling 2013-04-03 00:03:52 UTC
(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.
Comment 23 MZMcBride 2013-04-03 01:35:49 UTC
(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.
Comment 24 Jarry1250 2013-04-03 12:06:18 UTC
(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.
Comment 25 Ryan Kaldari 2013-06-12 21:49:29 UTC
> 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.
Comment 26 Steven Walling 2013-06-12 22:11:28 UTC
(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.
Comment 27 Ryan Kaldari 2013-06-12 22:14:37 UTC
Looks like Benny was thinking the same thing: https://gerrit.wikimedia.org/r/#/c/68297/
Comment 28 Nemo 2013-06-13 05:22:21 UTC
(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.
Comment 29 Bartosz Dziewoński 2013-10-12 18:58:03 UTC
Adding bug 52777 as a blocker per Tim's comments
on https://gerrit.wikimedia.org/r/#/c/68297/.
Comment 30 Bartosz Dziewoński 2013-11-02 13:43:57 UTC
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).
Comment 31 Bartosz Dziewoński 2013-12-08 16:34:14 UTC
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.
Comment 32 Nemo 2014-11-07 22:09:23 UTC
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".

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links