Topic on Talk:Notifications/Flow

See also bugzilla:35306.

I don't understand why notifications are bucketed only by wiki. Notifications should be bucketed by importance/priority/topic. While one could think that users want to work on a single wiki at a time so that wiki is their current priority, this idea seems quite outdated with a centralised notification system, which should help reducing barriers between wikis. I want to see all the user talk messages I received on any wiki together, before anything else; I may then want to check whether any edit of mine has been reverted on any wiki and still requires my attention; etc. Then I want to review the mass of notifications (e.g. all the other discussions, if they're many) by topic, so probably by wiki. If the bucketing by wiki is not replaced, at least some things should be taken out of it (maybe configurable), like the talk edits.

There are two differing concepts here, and we don't have a great set of agreed upon terms for them, but for the purpose of my response I'm going to use "bucketing" and "stacking".

"Bucketing" is a "by-wiki" collection: all notifications from a specific wiki go into the same bucket.

"Stacking" is a "by-type" collection: all notifications of the same type go into the same stack.

The current design (as shown) operates on a bucket-primary, stacking-secondary process. That is, notifications are bucketed first, and then stacked within those buckets.

If I understand you correctly, you are asking for a "stack first, then bucket" ordering. There's some merit to that idea; I like it a lot for the use case you're discussing. I'm not advocating a change, however, since the reason we chose "bucket, then stack" is a technical one. It is going to be significantly faster and more accurate to bucket and then stack, because each "bucket" is actually going to be a single api call, which can be loaded and stacked independently. To do a stack-then-bucket process, we'll have to do multiple API calls to multiple wikis before we sort and stack the notifications (which will have to be done client side, in this instance).

I should point out that we are in the very earliest of stages for this feature, and we are still doing research as to the best design we can create. So it may be we do a stack-then-bucket, or that such a thing will be configurable (though probably not: I'm adverse to adding preferences for changing interface behavior).

Thank you for the answer: yes, you understood correctly. I hope there will be room for at least some "stack first, then bucket" (for user talk edits for instance), but I understand the performance constraints.

Revisiting this old thread: Our API framework may need an upgrade here. The idea of single wikis living in a vacuum was very simple, and specifically ignored the common cases -- more common now -- of clusters of related wikis. However, most wikis come in clusters:

• Some are groups of wikis that are really about the same content (but arbitrarily split into multiple 'different wikis' by language[1]).
• Others are groups of wikis on related topics, used by the same group of people. Here often a 'new wiki' rather than a 'new namespace' was chosen to make it easier to have different main pages, or different policies per topic. None of this technically requires a separate wiki; these clusters of wikis often share 90% of their templates, policies, categories.

The difference between a namespace and a new wiki, for a cluster with shared userpool, is only semantic. And we should offer APIs that let developers ignore that semantic difference. Wikimedia isn't the only group with a cluster of many wikis; most organizations I know that use wikis have a cluster of at least 2 or 3. And all of them need cross-wiki tools, notification, change-tracking.

Bump: Can we unbucket notifications now?