Page MenuHomePhabricator

Recent changes email workflow is inefficient
Open, NormalPublic

Description

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.)
  1. Turn off email delivery (and hide the preference).

Version: 1.22.0
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=41759

Details

Reference
bz54609

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 2:15 AM
bzimport set Reference to bz54609.
bzimport added a subscriber: Unknown Object (MLST).
brion added a comment.Sep 25 2013, 6:47 PM

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
  1. preference label is misleading, since it says "when changed" and not "the first time it changes after you visit it"; or
  1. 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
  1. 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 :)

brion added a comment.Sep 25 2013, 9:22 PM

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 :)

I wish:

  • a reliable E-Mail notifications for all changes (small and normal) to selected pages (whether I visited they logged in or not)
  • an E-Mail notifications if an "own" Commons image is embedded in one of the sister projects.

Can anyone tell me, how is the status of this case and as the chances are that it comes here to improve.

see also: https://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests#Optimierung_der_Benachrichtigung_.C3.BCber_.C3.84nderungen_an_Artikeln_.28per_Mail.29

(In German: Ich wünsche mir: * eine zuverlässige eine E-Mail-Benachrichtigung für alle Änderungen (kleine und normale) von markierten Seiten (egal ob ich sie angemeldet besucht habe oder nicht); * eine E-Mail-Benachrichtigung, wenn ein "eigenes" Commons Bild in einem der Schwesterprojekte eingebunden wird. Kann mir jemand sagen, wie der Stand dieses Falles ist und wie die Chancen sind, dass es hier zu einer Verbesserung kommt.)

@Molgreen

Neither task has been worked on recently.
The first (this) one is complicated.
For the new notification idea, some upcoming documentation might make it easier for other people (e.g. WMDE, volunteers, etc) to implement this, sometime soon. T136372: Document how to create a new notification type Also, I see Lea has added T77154 to the TCB and German-wishlist projects, so that is hopeful. :-)

@Quiddity, thank you for your help

For the watchlist, I would wish me three options:

  • Page not on the watchlist
  • Page on the watchlist
  • Page permanently on the watch list (new function)