Community Wishlist Survey 2019/Notifications

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Notifications
4 proposals, 164 contributors

Go-previous.svg Multimedia and Commons  •  Programs and events Go-next.svg

The survey has closed. Thanks for your participation :)
Here are the Community Wishlist Survey 2019 results!


Notify users when their revision has been approved or rejected

Edit proposal/discussion

  • 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)

Discussion

  • Comment 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)
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)

Voting

Article reminders

Edit proposal/discussion

  • 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).

Discussion

  • 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)
  • Check w:User:MusikAnimal/customWatchlists.js? Gryllida 22:19, 30 October 2018 (UTC)
  • There was one (or more?) MediaWiki extensions to add this sort of thing, but they never made it onto the Wikimedia servers for some reason (probably because they weren't finished or tested or something). It should definitely be possible to fix one of them up. Enterprisey (talk) 04:41, 31 October 2018 (UTC)
  • Mw:Extension:Reminder does something like this. Its not been vetted for WMF usage (security/scaling) yet. It's also heavily reliant on javascript if I remember correctly, which our community tends to frown upon at times. —TheDJ (talkcontribs) 09:01, 31 October 2018 (UTC)
  • I absolutely support pursuing this. Here is the verbatim text of a wishlist item I have been keeping track of for some time: "Ability to set a calendar for alerts (for yourself and other users?) for future edits that need to be made. So that, for instance, we don't have to be a year and a half late for things like this." Thanks to all of you for the work that you do on WP. KConWiki (talk) 00:54, 4 November 2018 (UTC)
  • For lvwiki I created a tool for adding a reminder to do something. Later bot adds notification on some talk page (where user requested it). It's very far from perfect and isn't much used, but as a proof of concept... I know that Enterprisey did (or wanted to do) something on enwiki, right? Edgars2007 (talk) 07:25, 4 November 2018 (UTC)
    Correct - I did write "RemindMeBot" on enwiki but it was never completed. It wasn't actually that hard, I just had other things I was working on. If this doesn't get chosen I could probably revisit it, but I think the mediawiki extension route is what we should be going for here. Enterprisey (talk) 21:15, 4 November 2018 (UTC)
  • This doesn't relate to adding a feature, but just FYI, you can keep reminders in a sandbox page. The "sandbox" link is always in the upper right corner when viewing Wikipedia (between "talk" and "preferences"), so it is always easy to get to. Just edit your sandbox page with a description of when/what you want to be reminded of. This will just be a page, so no notifications, but if you remember to check it like you do with your watchlist, it can be a decent interim solution for you. AHeneen (talk) 08:07, 6 November 2018 (UTC)
  • As creator I welcome everyone to improve description/language of this proposal, so that it does not stop from being successful. --Papuass (talk) 08:33, 6 November 2018 (UTC)
  • As someone who updates sports team season pages this would be very helpful to remember to update after games. Swimmer33 (talk) 13:48, 8 November 2018 (UTC)
  • Yes, please. I often propose changes on talk pages, of the form "<Detail of change.> In the absence of any objection, I propose making this change in about a week/month/etc." See also T88781. Feline Hymnic (talk) 13:07, 11 November 2018 (UTC)
  • Please. en:Special:Diff/868948727. Bellezzasolo (talk) 15:19, 15 November 2018 (UTC)
  • I like this proposal, I'd like to know how public, or private the reminder would invariably be? Thank you.--John Cline (talk) 00:45, 17 November 2018 (UTC)
  • I think this might be of use to Wikivoyage, which is prone to slap big red warningboxes on destinations during major disasters. There is already a "lastedit" field to flag (for example) that "{{warningbox|All good Anglo-Saxons are warned of an imminent Norman invasion...|lastedit=1066-01-01}} should be discarded once the invading rabble have been chased back to the Continent, but some of these warnings, like {{warningbox|Hurricane! Incoming! Run!}} tend to be very time-sensitive and a note to remove or update the notice after landfall would be valuable. K7L (talk) 07:52, 26 November 2018 (UTC)

Voting

Update Echo Notifications in real time without page reloads

Edit proposal/discussion

  • 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:

Discussion

  • 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)

Voting

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

Edit proposal/discussion

  • 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:

Discussion

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

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)
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)
  • 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)

Voting