Last modified: 2014-10-09 01:41:41 UTC
My email inbox suggests that, between Sep. 4 and Sep. 9, I received 36 emails about changes to meta Talk:Privacy_Policy. That's carefully separating multiple emails that end up in the same gmail conversation view, which is not common but happens. I've checked spam filters as well. Based on the revision history page, during the same time period (specifically, counting from the revision I received the first notification on the 4th to the last revision I received a notification about on the 9th) there were 170 edits to the page. That's a 79% failure rate. This is consistent with the results I get from other pages in meta. Similarly, casual conversation around the office suggests I'm not the only person with this problem, and that email notifications are widely treated as unreliable. Proposed solutions: 1. Make email delivery reliable. I think this is the preferred solution, as I'm a big believer that a key time management and stress reduction method is to reduce the number of inboxes [http://lifehacker.com/5364596/], and email notification is the only way to do this with a Mediawiki workflow (especially in the WMF context, with 1,000 different wikis to follow, meaning 1,000 watchlists to follow.) 2. Turn off email delivery (and hide the preference).
Hmm, just to check -- the way the watchlist emails work is that they don't send you another notification mail until you've gone to visit the page, at which point you're assumed to have seen everything up to the present time. You'll then get a single notification mail on the next edit, which'll be the last one you receive until you visit the page again. So for instance, if the page is edited three times before you next visit it, you'll only get a single email.
Related: bug 41759 and its patch (for unexpected behavior when viewing non-latest revisions and diffs). That said, and apart from that, I have been experiencing unreliable notifications for quite some time myself, especially on often-edited pages like [[WP:VPT]]. I really can't tell if this is caused by the aforementioned behavior or if there's actually a bug here.
Brion: that's... interesting. So maybe the bug is: 1. doesn't work like any other notification system; or 2. preference label is misleading, since it says "when changed" and not "the first time it changes after you visit it"; or 3. the email's statement about this is completely unclear/not a good place to try to explain to a user that #1 is true ('There will be no other notifications in case of further activity unless you visit this page'); or 4. the email's other attempt to clarify this (link to "all changes since your last email") should be the *first* link, not the second, because that link is the one that actually contains the accurate/complete information that you should want to see. To focus on #1 for a second: if your goal is to reduce the # of inboxes you have to check, then you have to get *all* the notifications, not just some of them. Because likely the most common action will be: 1. Get the notification of a change. 2. Read, and decide the correct action in response to the change is "do nothing". 3. File/archive/mark read/delete as appropriate for how you handle your inbox. 4. Go back to #1. That keeps you entirely within your email for the most common use case - most efficient for anyone who has to/wants to read and process a lot of notifications. With this system, you add Step 2.5: leave your email by clicking on "all changes since your last visit" to make sure nothing else has changed, because you have no way of knowing whether or not something has happened without breaking out of your mail handling workflow. So for inexperienced Mediawiki users, it breaks expectations from every other notification system they've ever worked with; and for experienced mail handlers, it completely breaks workflow and forces you to swap back and forth between tools. If this is all by design, I suppose this is really just venting/WONTFIX, given everyone's change aversion and the work necessary to fix it. In the meantime, I'll chalk it up as yet another systemic inefficiency that makes me wonder how this thing ever got built :) And wait patiently for Flow. :/
(Or set up rss2email :)
Oh yeah there's some, shall we say, "user experience issues" here that need work. :)
Worth filing any of them, and/or leaving this bug open? The overarching bug that I've described is obviously a huge one, but the text/string changes could be worth filing, I suppose? With the caveat that I have no idea how painful/non-painful our l10n/i18n story is, or what other process strings have to go through to get changed, I'm even happy to provide patches for at least those.
(In reply to comment #3) > With this system, you add Step 2.5: leave your email by clicking on "all > changes since your last visit" to make sure nothing else has changed, because > you have no way of knowing whether or not something has happened without > breaking out of your mail handling workflow. I hate to admit it, but that's exactly what I end up doing quite often (specific change does not interest me, but I want to get notified of the next change which might interest me).
Right, and that's horribly inefficient :)
Bug 41759 is fixed now, which should make it a lot harder to accidentally mark revisions as "read" when you haven't actually seen them. Let's see if it makes the situation better.
I don't really think that solves the core problem, but maybe that is in part because the core problem is not well-described here. At least I'll change the bug name to reflect the underlying reality :)
