MediaWiki

Notifications/Functional Requirements

< Notifications

Functional Requirements

edit

Since this feature is comprehensive, requirements have been broken out into distinct sections. The "Full Monty" version of this feature requires significant back-end work involving multiple databases, and may be only of use to systems like Wikimedia Foundation wikis.

Cross-Wiki Notification

edit

In order to facilitate easy handling of notifications in installations with multiple wikis, there must be a method for publishers in individual wikis to notify other wikis of local notifications to that the user can be informed. A comprehensive solution would involve creating a centralized notification server or designating one wiki as the central wiki. From there all notifications would be sent to the central server rather than kept and polled on each individual wiki.

Then, individual clients (a user on a specific wiki) will ask the server for all notifications on all wikis. Thus, one need only log into a single wiki (say, meta) and then be informed of activity they are interested in on the English Wikipedia, the German Wikipedia, MediaWiki.org, and any other connected system. Furthermore, links would be provided to the user to view and act upon these external notifications.

Notification Bundling

edit

To avoid clutter, notifications from a single wiki of the same type may be "bundled" and collapsed.

For example, if four people edit a talk page, each edit will fire a notification. However, with bundling, instead of the user being shown four notifications, thus:

  • Brion edited your talk page
  • Jorm edited your talk page
  • Eloquence edited your talk page
  • Kaldari edited your talk page

They would instead be shown something like this:

  • Brion, Jorm, Eloquence and 1 other edited your talk page

or even this:

  • 4 users edited your talk page

There are a number of interesting variations of how these things can be displayed.

Event Preferences

edit

In the Echo notification system, there exists a variety of event types and a variety of event vectors. Furthermore, each event type may be delivered to the user through any number of the possible vectors. Which notifications a user receives and through which vectors he/she receives them must be a user preference that can be customized.

Users will be given the ability to decide which events they receive notifications for and through which means they receive them. For example, a user may wish to get Notifications when someone edits their talk page and when someone responds to a Feedback Dashboard comment, but not when a page on their watchlist is edited, but when someone reverts their edits. Further, users may choose to receive talk page notifications over both phone and email, but only receive edit reversions through in-wiki notification.

Pluggable Backends

edit

This section concerns itself with Notification delivery - where do Notifications appear and how can they be retrieved?

Email

edit

Some things can trigger email notifications, including the things that will trigger user-talk notifications today; but also other events may trigger emails such as Extension:CodeReview's followup notifications.

These should be brought into the common notification system so they're available over non-email channels, and so that the email channels include relevant information (such as the content of a message!)

  • bugzilla:32285 Email backend for notifications to supplement/consolidate enotif with common notification infrastructure

Web UI

edit

The existing new messages links in the dynamically-generated web UI of MediaWiki will need to be updated to read from the Central Service.

API

edit

An API interface to poll for new messages would be useful for extending the front-end web UI so that you still see notifications even if you're on a page for a long time (say you're editing long text, or using an AJAX-y interface for page patrolling). This would also be a first step for mobile apps and other tools to hook into the same interface.

(Possible API? Notification triggers a remote HTTP POST?)

Further enhancement could be done with WebSockets or long-polling techniques, but may require server-side support for long-running connections.

Mobile push notifications

edit

Various mobile operating systems like Apple's iOS and Google's Android have message proxying systems that allow an application to register to efficiently listen for notifications sent through an intermediary service, even when the application has been closed to save memory & power.

Backends to set up the device subscriptions and send pings through the proxy will be a benefit here.

XMPP

edit

Notification systems could be pushed onto users via instant message on various networks (i.e. Jabber). Similar thing could be echoed on proprietary messaging networks, and by bots on channels on chat networks since the service mechanisms (like eJabberd) have pluggable features for relaying messages to transport gateways.

Note that XMPP is of interest also for XMPP recent changes, so common infrastructure for "firehose" and smaller notifications may be useful.

Existing Notifications

edit

The general approach will be to first reach feature parity with the existing notifications systems. Here is a list of the currently known notifications. The project team will need to evaluate these notifications to see which ones should be incorporated into the scope of Echo:

  • Email when (assuming email is provided):
  • Page on my watchlist has changed
  • My user talk page is changed
  • Someone writes me an email through the Email this user feature
  • email another user through the Email this user feature
  • When a page is created (e.g. if you watch Foo, you also get an e-mail when Talk:Foo is created).
  • You get a "my user page" e-mail if you watch it (with a very confusing edit summary talking about creation) when a manual user rights change happens (+sysop or +rollbacker etc.).
  • Show Yellow bar when:
  • My user talk page has changed
  • Other notifications
  • CentralNotice, sitenotice, geonotices, etc. as describe on here.

Infrastructure

edit

As stated in the rationale, this new notifications system must also address ease-of-development issues for both core and extensions developers when changing or adding event types or vectors.

The new notification system must provide an easy method, using some sort of hook or method, to register new message types. Extension developers then may simply register their type with the notifications system, and MediaWiki will automatically set up user preferences for the notification and automatically deliver those notifications as required. The extension itself will only be responsible for actually triggering and publishing the notification.

The system must also provide a method of registering new vectors, or methods of notifying the user of an event. Existing examples are email and in-wiki UI notifications, but an extension developer may want to implement a custom vector, e.g., sending out notifications to an external service for integration purposes.

Retrieved from "https://www.mediawiki.org/w/index.php?title=Notifications/Functional_Requirements&oldid=6025975"