Requests for comment/Need to merge Notifications and Watchlist or lack thereof

Request for comment (RFC)
Need to merge Notifications and Watchlist or lack thereof
Component General
Creation date
Author(s) Gryllida
Document status in draft
See Phabricator.


MediaWiki had included a Watchlist page for years. It is documented at Help:Watchlist.

The Echo extension introduced a new special page, Special:Notifications. This special page is normally invisible to end users, but when JavaScript is disabled, it's the only place where people can receive notifications.

The functionality of Special:Notifications is similar to a watchlist in principle. The differences include:

  • Watchlist is only about publicly visible edits, while Notifications may also include extra things like "your edit was reverted" (a public action but the 'reverted your edit specifically' is a personal event), "you were mentioned", "your user rights changed", "someone thanked you".
  • Watchlist only notifies by showing fresh edits when you visit it, or by email; the only fine-graining option is whether to email about minor edits or not (Preferences#User profile, at the bottom). -- Notifications has options to also notify by e-mail and web (an icon with a number of pending notifications at the right top) (Preferences#Notifications).

We should also keep in mind that:

  • Most contributors start by participating in only 1-2 discussions at a time. Role of Echo in onboarding these is an interesting question.
  • As people become more involved, they usually participate in more content and talk discussions work. Whatever notifications or watchlist system exists, it needs to scale.


There are a number of problems that prompted the creation of Notifications, and a number of problems I can see with its own design. For instance, Notifications was designed to know of things instantly, while nothing on-wiki needs an urgent reaction. Such lack of problem to address is worrying.

  1. Both of these systems do not scale (Special:Notifications and Special:Watchlist both get overloaded when I have over a hundred or over 20 notifications to view).
    • Notifications tries to address this problem by shoving the notifications into me gradually as day goes.
    • Notifications makes the problem worse by showing the number of new Notifications items in an icon. It's uninformative on its own. It is distracting during contributors' work on just ...reading the wiki.
  2. Watchlist is not real-time. People are unaware that someone replied to them until they check back the page or a watchlist manually.
    Is this even a problem? It is, in my personal view, perfectly normal to figure that new Things happened by visiting a watchlist.
  3. Due to the above, Notifications drags people back into communicating and editing activities. This is annoying.
  4. Notifications suggests that people spend time figuring out who thanked them. This may seem encourage more participation, but subtly misses the real problem — lack of personal communication at talk pages — and imposes a waste of time (with my slow Internet, tens of hours this year and counting until yesterday, when I disabled this feature everywhere entirely).
  5. It's not possible to get web-nagging-echo-style-notifications or email notifications about Watchlist items. This is inconsistent.


I would like to suggest merging these two pages functionality into one.

  • It should show items pertaining to both public events (edits) and personal events (thanks).
  • It would also have a settings pane, similar to what Notifications currently has, except
    • a 'watchlist' column would be added to indicate whether I'd like to get these events piped to my watchlist, and
    • a 'watchlist edits' row would be added so that they could be mailed or "nagged on the web" for me.
      • Obviously, by default, watchlist edits notifications should be off. They are a lot of information. Usually people don't need them.

I believe this would simplify things, and encourage a rework of the Watchlist page whose usability lags behind; i.e.

  • Filtering Watchlist like people can filter a Recent Changes list when it's got too many items;
  • Adding and removing pages to watchlist;
  • Filtering a watchlist by namespace;
  • ...

Simplicity is a path to success.

I personally see a carefully designed (initially passive like it is now, but, if extended, configurable for email or web-echo-nagging modes) watchlist a better solution than saying "it sucks, let's invent a second better list".