Investigate whether notifications should be throttled (one notification per user/per day)
Open, Needs TriagePublic

Description

Automatic topic subscriptions have potential for good and harm. The risk of harm is partly because:

  • because notifications are nearly instant,
  • because they appear without warning (e.g., when you're trying to focus on something else, or not ready to engage in a difficult discussion),
  • because rapid-fire discussions can be less thoughtful, and
  • because rapid discussions offer less opportunity for other contributors to join the discussion.

Slowing down notifications could reduce the risk of harm by making notifications less instant. This leaves more time for thoughtfulness and for others to join the discussion.

One suggested approach is to limit the number of notifications per user/per day.

Event Timeline

I've been thinking about this. Obviously, you'd still see everything (and more) in your watchlist, so it wouldn't be terrible. However, it might be unexpected, and I specifically don't think that one notification per user/per day would be the perfect setting.

In a discussion like this:

* I need help. –A
** What kind of help? –B
*** I need help uploading an image. –A
****Click here. –C
*****Thanks. –A

"A" would get notifications immediately from both B and C; B would get notified only about the middle comment from A and the comment from C (today; B would see more later); C would get notified only about the last comment from A.

However, in a discussion like this:

* I need help. –A
** What kind of help? –B
*** I need help uploading an image. –A
****Click here. –B
*****Thanks. –A

"A" would get notified immediately about the first reply by B, and see the second reply – the one that contains the answer – later.

It's possible that some throttling would be helpful (you don't really want your notifications flooded with a hundred comments from one person), but the setting should probably be higher than one notification per user/per day.

I wonder if a solution to the consistency would be to have a digested view. This way it's one notification that includes a lot of love.

In any case, there must be high demand for receiving notifications right when the comments are left, not after a delay. Topic subscription is a great innovation that makes Wikimedia projects closer to the original meaning of the "wiki" part of their name by eliminating the pain of constantly refreshing the watchlist (or even visit different watchlists if you're active on different wikis as long as MediaWiki-extensions-GlobalWatchlist is not in its best shape).

A delay would transform the meaning of the topic subscription functionality from "There is an update in a topic you are subscribed to" to "Haven't you forgot about that discussion? It's still active". A funny thing about the last is that currently the notifications don't take into account whether I have visited that discussion (on my own, not by means of a notification) or not (AFAIK). Notifications are often viewed when the event they notify about has already been examined. So a notification arriving after a delay might be, in fact, incorrect.

And note that new notifications are already grouped by topic. So the meaning of "flooded" is mostly that the "Notices" badge often becomes blue, not that you become disoriented amid lots and lots of items (although that might happen as well if you're subscribed to many active discussions).

Perhaps an approach that would make more sense is to delay new notifications after some amount of them was read and no action was taken in connection with them. But that could still interfere with users' need to, e.g., spot a comment from some specific user they await and contradict the principle of least astonishment. To unsubscribe from a topic is a more obvious action in case of being irritated by notifications.

Another alternative is to follow the path of various messengers that allow muting notifications from some user (in our case, topic) for a specified period of time.