Page MenuHomePhabricator

Make preference "Email me when a page or file on my watchlist is changed" true by default
Closed, ResolvedPublic

Description

Part of the series «Have sane defaults, obviously».
Blablabla (like bug 45020), relevant report for WMF inaction bug 38796.

Implementation:

  1. set enotifwatchlistpages to 1 in $wgDefaultUserOptions in DefaultSettings.php;
  2. don't forget to note this in the release notes files (it affects also old installations upgrading, and all their existing users whatever their preferences).

Version: 1.21.x
Severity: enhancement
URL: http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/60474
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=38796

Details

Reference
bz45022

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:29 AM
bzimport set Reference to bz45022.

How would this react if the person doesn't have a proper mailing system setup?

(In reply to comment #1)

How would this react if the person doesn't have a proper mailing system
setup?

It has no effects if you're not emailconfirmed, and you can't be so if emails are not enabled; enotifusertalkpages is already set to true, so nothing new for that aspect.

Gods, no.

From a user perspective this makes no sense save for on very inactive wikis that one seldom actually visits, as otherwise such email notifications wind up nothing more than pointless spam. If we had a sane discussion system, setting email notifications as default for messages might make sense, but we dont.

From an ops standpoint, this is a very good way to overwhelm a mailserver for no good reason, and from what I recall did exactly that when previously turned on by accident.

(In reply to comment #3)

Gods, no.

From a user perspective this makes no sense save for on very inactive wikis
that one seldom actually visits, as otherwise such email notifications wind
up
nothing more than pointless spam. If we had a sane discussion system, setting
email notifications as default for messages might make sense, but we dont.

This is already covered in the other bug, there's no doubt that people installing MediaWiki want it.

From an ops standpoint, this is a very good way to overwhelm a mailserver for
no good reason, and from what I recall did exactly that when previously
turned
on by accident.

Where? MediaWiki emails are plain text, about 2 KB... The additional traffic for all such notifications when enabled on WMF cluster was not even visible in the graphs.

The notifications framework (or "framework") currently within core MediaWiki is such that it may make sense to wait on implementing this bug until Echo is better developed.

I realize, of course, that Echo is a MediaWiki extension and that this bug is talking about MediaWiki core. My concern is basically that the feature in MediaWiki core isn't wonderful (echoing comment 3) and I think most wikis would be better off waiting for a better notification system (Echo).

All that said, e-mail notifications are one of the areas I know very little about, so my comments should be taken with a large grain of salt. Copying Ryan K. for his thoughts/insight into this.

I won't iterate my previous comments; let me just point out that we're tired of waiting, bug 28026 (from which I split bug 38796, and now this) was filed two years ago: hadn't we had the obstacle of WMF being unable to manage the default change, this would have happened ages ago in core, to the point that James Forrester once wrote me on the lines of "oh I thought this had already been done years ago", probably because it was discussed many times before these bugs but nobody bothered to file it given that it's such a pain to change something in core that benefits third-party wikis.

Perhaps you are not aware of the magnitude of this - on active projects such as the english wikipedia, email notifications per EDIT to a watched page can mean hundreds or thousands of emails per user per day. Now people can turn it off before it gets to that point, but the initial turn on by default would be for pretty much everyone, and that is not viable. When it was accidentally turned on by default when the option was initially added, it really did back up the mail queue after flooding many users.

If there were a way to enable this only for new users with a clear note in the emails how they can turn it off when it is no longer useful to them, that would probably be fine, but as it is the current infrastructure does not support such fine tuning, to my knowledge.

(In reply to comment #7)

Perhaps you are not aware of the magnitude of this - on active projects such
as
the english wikipedia, email notifications per EDIT to a watched page can
mean
hundreds or thousands of emails per user per day.

Of course I do. But this is not about Wikipedia, that's bug 38796.

When it was accidentally turned
on by default when the option was initially added, it really did back up the
mail queue [...]

It didn't at all.

If there were a way to enable this only for new users with a clear note in
the
emails how they can turn it off when it is no longer useful to them, that
would
probably be fine, but as it is the current infrastructure does not support
such
fine tuning, to my knowledge.

Again, that's bug 38796, which includes such requirements (and yes, only en.wiki complained back then).
On normal wikis (which arguably includes all Wikipedia but en.wiki, apparently) not even the most active editors can have thousands of watchlisted pages edited in the course of a day before they can go to the preferences and disable this when the volume gets excessive.
The enotif_body has clear instructions sending people to the preferences; the amount of mail received is always gradual so the 99.99 % of users will receive a very small amount of emails and disable them if they wish when it gets too much because they got more active and have more watchlisted pages, or whatever.

Just because most wiki don't have channels through which to complain doesn't mean they necessarily approve, nor does that wikimedia wikis can turn this off mean that third party users will necessarily realise they have to as well - release notes apparently don't have a normal-person-readable version that I've seen anywhere. Were I not cced on this bug, I never would have known, and suppose, for example, the thing were merged and Uncyclopedia wound up with it... well, there would probably be a bit of a riot. There was outright yelling when watchlisting on deletion got turned on, after all.

And Uncyclopedians are bloody laid back compared to wikipedians, and not nearly so averse to change. These are people who saw AFTv5 and said 'WANT', for crying out loud.

Change 100958 had a related patch set uploaded by Nemo bis:
Preference "Email me when a page or file on my watchlist is changed" explicitly false

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

Change 100958 merged by jenkins-bot:
Preference "Email me when a page or file on my watchlist is changed" explicitly false

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

(In reply to comment #11)

Change 100958 merged by jenkins-bot:

Preference "Email me when a page or

file on my watchlist is changed" explicitly

false

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

This was change of mediawiki-config, setting bug back to NEW

Change 100959 had a related patch set uploaded by Bartosz Dziewoński:
Make preference "Email me when a page or file on my watchlist is changed" true by default

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

Change 100959 merged by jenkins-bot:
Make preference "Email me when a page or file on my watchlist is changed" true by default

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

Great! Added to [[mw:MediaWiki 1.23]]. That page already starts to look nice. If we manage to fix bug 35785 too, it will be a release folks will remember positively IMHO. ;-) Although the true revolution would be if we managed to fix bug 31881 and then bug 52807 of course.