Community Wishlist Survey 2019/Notifications

4 proposals, 164 contributors, 235 support votes
The survey has closed. Thanks for your participation :)

Notify users when their revision has been approved or rejected

  • Problem: On wikis with Flagged Revisions enabled, new and inexperienced users who don't yet have achieved the required user status have to wait for an established editor to review and approve their edits to go live in the default version of an article. This can take many hours, days or even weeks.
  • Who would benefit: Directly: New and inexperienced users who are logged in, by receiving either positive reinforcement or guidance on how to avoid rejection of their edits. Indirectly: all editors and readers, by integrating new contributors quicker and aligning them better with policies and quality standards via closer feedback loops
  • Proposed solution: Create a new notice type in Notifications (for logged-in users), see also phab:T54510.
  • More comments: See also the more in-depth rationale by Atlasowa here
  • Phabricator tickets: phab:T54510
  • Proposer: HaeB (talk) 17:58, 11 November 2018 (UTC)[reply]


  •   Comment I'm not actively opposing this, but I can see it causing problems in that notifying editors that their edit hasn't been accepted will act as a reminder to vandals, spammers and POV-pushers that they need to try again, so may lead to a significant increase in problematic edits. Iridescent (talk) 10:26, 20 November 2018 (UTC)[reply]
I think this is unlikely to be a concern, considering that vandals and other users whose edit gets reverted outright normally already receive a notification about that, see documentation. (In fact the implementation of the "rejected" notification probably needs to take this into account, it may end up being largely redundant to the existing "reverted" notification.) Regards, HaeB (talk) 20:10, 20 November 2018 (UTC)[reply]


Article reminders

  • Problem: There are articles you want to update from time to time but it is not easy to keep track of them.
  • Who would benefit: Dedicated editors, power users on every project.
  • Proposed solution: Use existing notification system to show reminders. A new screen could be created under "more" menu. You should be able to pick either specific date or number of days in the future.
  • More comments: It would be useful to set a reminder to update a certain article after 6 months (end of sporting season) or on June 27 (a certain president assumes office).


  • Perhaps more general reminders would be more useful. Rather than just scheduling "remind me about article X", you might also want reminders about talk page sections or other discussions. Anomie (talk) 14:20, 30 October 2018 (UTC)[reply]


Update Echo Notifications in real time without page reloads

  • Problem: at the moment, if you are on a page and stay there, you don't know if you've received new notifications.

    This is particularly true when you are on your watchlist and use the "show me new changes" link: it reloads the content of your watchlist, but doesn't update the whole page. Since the watchlist is a gateway for a lot of users (AFAIK), you can stay a lot of time on that page without getting any notifications if you don't open a new page.

    It can also help you when you edit a page and someone leaves you a message about that page (cross-replies on talk pages, a new mention on a talk page you're editing, warn a new user about things to fix on a page they currently edit, etc.

  • Who would benefit: Everyone.
  • Proposed solution: Update Echo Notifications in real time without page reloads. Provide a way to opt-out if you don't want to be disturbed, temporarily (have a way to set when to refresh?) or anytime.
  • More comments:


  • Even though I get very few notifications, I have been in the situation described where I was pinged during an edit and I would have prefered to read the entry where I was pinged before completing the edit. Wholeheartedly support. — The preceding unsigned comment was added by PopularOutcast (talk)


Notifications should be able to display all cross-wiki notifications, whatever their status

  • Problem: I can't seem to see my cross-wiki notifications unless I have unread notifications on that wiki. So I wind up keeping unread notifications around to avoid losing the ability to refer to the notifications I have already read.

    Example: I get lots of en-wiki notifications, but rarely anything from the nl-wiki. Someone notifies me from nl, and I read it but have no time to respond. A day later I go to my notifications list and cannot find any way to access that read nl-wiki notification. If I get a second nl-wiki notification, I can go to that, select "all" or "unread", and see my first nl-wiki notification, but I'd better remember to leave at least one of the messages flagged as unread if I don't want to lose access again. If I remember that the vanished notification was on nl-wiki, I could go to the nl-wiki, then check my notifications there, but with half-a-dozen possible wikis, this can quickly become tedious.

    Because I am active on a fair number of wikis, and keep unread notifications around, my "Recent Activity" list stretches well off the bottom of the screen. As I often deal with new notifications at the top of the page without scrolling down and clicking on and checking through eight or nine wikis, I've managed to miss seeing cross-wiki notifications for months, which is careless and unkind of me when someone is awaiting a reply. I suspect I would be more active across wikis if this were easier.

  • Who would benefit: Anyone active across wikis who does not always deal with all of their notifications immediately.
  • Proposed solution: Some sort of access to cross-wiki read notifications in the interface, not mandatory but configurable by individual editors (clarified 20:10, 17 November).
  • More comments:


I like the idea. Gryllida 22:22, 30 October 2018 (UTC)[reply]

I like the idea, but at the same time I feel that it may pile up a lot of notifications. It may be wanted by some, but also annoying for others at the same time. So I suggest that the feature to be developed, and the choice is left to individual users according their "Preferences". Another option is to create a "Special:" page which displays all the notifications/messages from all the Wikis, with an option to select the time-frame, include/exclude projects etc. The user who wishes to check, will use the Special page. KCVelaga (talk) 11:09, 31 October 2018 (UTC)[reply]
I'm very happy with the idea of user control. I'd favour leaning towards "I don't want to miss anything" by default, with configuration to move it towards "I don't want clutter", as new users will get few notifications and are less familiar with configuration. If the config is in the GUI this is less of a problem. There are lots of ways to implement this, and an "Other wikis" link would suffice to give access to wikis with no unread notifications, so it certainly could be done without significant clutter. Only the last 200 notifications are kept; configuration of expiry dates etc. as suggested might be preferable. HLHJ (talk) 06:36, 8 November 2018 (UTC)[reply]
  • Thank you, 1997kB, I wasn't aware of that script. Despite the "This is a quick and dirty script — it's not ready for reuse!" this is really useful technical information. I agree configurability is a must, and as it has now come up twice, have made a small underlined mod to the proposal for clarification. I'd welcome comments on whether people would prefer an opt-in or an opt-out, and what form they would like it to take. I'd personally prefer a GUI-button opt-out, for reasons given above, but a self-customized Special page as suggested by KCVelaga might also be a good option. We might want one configuration method for newbies, and another for power users. HLHJ (talk) 20:11, 17 November 2018 (UTC)[reply]