Community Wishlist Survey 2022/Notifications

Notifications
6 proposals, 138 contributors, 216 support votes
The survey has closed. Thanks for your participation :)



Allow multiple people to subscribe to "article creator" specific notifications

  • Problem: Currently the only way to get notified if someone added Example wikilink to another article is to have created Example themselves. Similarly, automatic notifications for deletions/redirections of an article are only sent to the creator, despite multiple people having vested interests. This is the current behaviour on English Wikipedia and possibly other wikis too.
  • Proposed solution: The simplest solution would be a bundled "co-creator/virtual creator" flag that someone can watch to, akin to "watching".
  • Who would benefit: Anyone deeply interested in specific articles on a similar if not greater level as the initial article creator
  • More comments:
  • Phabricator tickets: phab:T66090, phab:T70060
  • Proposer: Shushugah (talk) 21:52, 10 January 2022 (UTC)

Discussion

  • This could be very useful for detecting bad new wikilinks. For example, on enwp, new wikilinks to Model are almost always about the role of Model (person), rather than building plans etc., and need to be changed as they appear. Certes (talk) 18:24, 11 January 2022 (UTC)
  • I think articles are expanded on many people, not only just the article creator. Two users can collaborate on each other, or they would expand an existing article. So article creators can have no rules over the page. Thingofme (talk) 12:41, 19 January 2022 (UTC)
    This proposal would not allow article creators (or others) to control articles, it would merely improve their ability to monitor these articles. – Teratix 11:03, 29 January 2022 (UTC)
    @Thingofme completely agreed, and yet right now the article creator even if just a stub DOES have a technical advantage over other users in terms of tracking an article's progress/usage. This should be democratised so to speak. Shushugah (talk) 21:11, 2 February 2022 (UTC)
    This is like handling vandalism and AFDs Thingofme (talk) 01:47, 3 February 2022 (UTC)
  • Exellent idea. There are a few articles that I have rewritten from a not-even-a-proper-stub state to a proper article and I consider them "mine" and would like to tend for them beyond just the "watch" star. --SSneg (talk) 20:48, 29 January 2022 (UTC)
  • "Similarly, automatic notifications for deletions/redirections of an article are only sent to the creator" - I'm not sure I follow this point. By "automatic", do we mean messages sent either by bot or by a semi-automated tool like Twinkle? If so, this is a matter for individual wikis, bot operators and tool developers, not the Wishlist team. Or do you get a Notification/Echo if a page you created is redirected or deleted? — Bilorv (talk) 19:56, 4 February 2022 (UTC)

Voting

  •   Support --Nachtbold (talk) 18:31, 28 January 2022 (UTC)
  •   Support * Pppery * it has begun 18:50, 28 January 2022 (UTC)
  •   Support. This looks like the opposite of "Muted pages for page link notifications" in the Notifications preference pane. Jonesey95 (talk) 22:42, 28 January 2022 (UTC)
  •   Support Certes (talk) 01:34, 29 January 2022 (UTC)
  •   Support Would save my life. Lectrician1 (talk) 05:43, 29 January 2022 (UTC)
  •   Support Respublik (talk) 09:01, 29 January 2022 (UTC)
  •   Support Nw520 (talk) 10:55, 29 January 2022 (UTC)
  •   Support per Certes – Teratix 10:56, 29 January 2022 (UTC)
  •   Support --Hemantha (talk) 12:40, 29 January 2022 (UTC)
  •   Support -sasha- (talk) 13:51, 29 January 2022 (UTC)
  •   SupportSHEIKH (Talk) 14:26, 29 January 2022 (UTC)
  •   SupportBruce1eetalk 14:35, 29 January 2022 (UTC)
  •   Support Aca (talk) 14:58, 29 January 2022 (UTC)
  •   Support --SSneg (talk) 20:47, 29 January 2022 (UTC)
  •   Support Pelagic (talk) 23:41, 29 January 2022 (UTC)
  •   Support Wostr (talk) 00:06, 30 January 2022 (UTC)
  •   Support«« Man77 »» [de] 13:45, 30 January 2022 (UTC)
  •   Support daSupremo   22:31, 30 January 2022 (UTC)
  •   Support JPxG (talk) 00:56, 31 January 2022 (UTC)
  •   Support Good idea, but also opposite (do not notify on certain created articles) would be useful too. JAn Dudík (talk) 11:49, 31 January 2022 (UTC)
  •   Support Uanfala (talk) 13:58, 31 January 2022 (UTC)
  •   Support Mbkv717 (talk) 20:11, 31 January 2022 (UTC)
  •   Support I think we should notify some of the suspicious changes in articles, or AFD. Thingofme (talk) 13:09, 1 February 2022 (UTC)
  •   Support KingAntenor (talk) 06:44, 2 February 2022 (UTC)
  •   Support ~ Amory (utc) 20:48, 2 February 2022 (UTC)
  •   Support DanCherek (talk) 16:32, 3 February 2022 (UTC)
  •   Support - Darwin Ahoy! 19:30, 4 February 2022 (UTC)
  •   Support ·addshore· talk to me! 22:47, 4 February 2022 (UTC)
  •   SupportKPFC💬 11:18, 5 February 2022 (UTC)
  •   Support Hanif Al Husaini (talk) 12:12, 5 February 2022 (UTC)
  •   Support HHill (talk) 14:18, 5 February 2022 (UTC)
  •   Support I really like this idea! paul2520 (talk) 19:50, 5 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 07:41, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:35, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 00:05, 7 February 2022 (UTC)
  •   Support Toadspike (talk) 01:37, 7 February 2022 (UTC)
  •   Support Matthew T Rader (talk) 20:58, 7 February 2022 (UTC)
  •   SupportDaxServer (t · c) 20:25, 8 February 2022 (UTC)
  •   Support · · · Peter (Southwood) (talk): 13:04, 9 February 2022 (UTC)
  •   Support Gaurav (talk) 03:56, 11 February 2022 (UTC)

Desktop Push Notifications

  • Problem: Currently you only receive notifications when you are logged into a browser, or depending on your preferences per Email. When you write someone a message, you often don't get an answer for a long time because the recipient doesn't notice. Newbies who have logged out often disappear entirely without realizing that someone has written them a message on their talk page. Communication falls by the wayside, and unfortunately so does the workflow. That has to be changed!
  • Proposed solution: The solution is pretty much the same as last year, except last year I didn't notice that many don't use Safari. A solution for Safari might look like this: developer.apple.com/notifications. But there are a lot of great other solutions for other browsers, like for developer.mozilla.org/push-api Mozilla Firefox, Google Chrome and Microsoft Edge. No matter what browser you use, together we can make our communication system better.
  • Who would benefit: Everyone. Long-time editors whose communication is improving, as are new editors who are more involved. It just makes a lot of things easier.
  • More comments:
  • Phabricator tickets:
  • Proposer: -Killarnee (CTU) 00:30, 14 January 2022 (UTC)

Discussion

Voting

  •   Support MrMeAndMrMeLet's talk 22:13, 28 January 2022 (UTC)
  •   Support Shizhao (talk) 03:59, 29 January 2022 (UTC)
  •   Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:11, 29 January 2022 (UTC)
  •   Support Aca (talk) 14:56, 29 January 2022 (UTC)
  •   Support — Jules* Talk 18:34, 29 January 2022 (UTC)
  •   Support But noting that some may find the browser permission prompt “do you want to allow push notifications for this site” to be off-putting. Pelagic (talk) 23:40, 29 January 2022 (UTC)
    I think it should be possible to only show this prompt after the corresponding setting is changed in the preferences. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:20, 11 February 2022 (UTC)
  •   Support Ali Imran Awan (talk) 07:16, 30 January 2022 (UTC)
  •   Support OwenBlacker (Talk) 11:00, 30 January 2022 (UTC)
  •   Support 🌸 Sakura emad 💖 (talk) 07:57, 31 January 2022 (UTC)
  •   Support Dreamy Jazz talk to me | enwiki 14:53, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 13:08, 1 February 2022 (UTC)
  •   Support Thibaut (talk) 16:16, 1 February 2022 (UTC)
  •   Support --Cameron11598 (talk) 04:17, 2 February 2022 (UTC)
  •   Oppose Not necessary KingAntenor (talk) 06:46, 2 February 2022 (UTC)
  •   Support WikiAviator (talk) 16:12, 3 February 2022 (UTC)
  •   Support - Darwin Ahoy! 01:47, 5 February 2022 (UTC)
  •   Support Sir Proxima Centauri (talk) 11:58, 5 February 2022 (UTC)
  •   Support Exilexi (talk) 17:36, 5 February 2022 (UTC)
  •   Support ideally, this could be disabled in preferences (though I think most/all modern browsers have the option to block such notifications) paul2520 (talk) 19:49, 5 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 21:49, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:21, 6 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 07:40, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:29, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 09:58, 6 February 2022 (UTC)
  •   Support Tgr (talk) 21:56, 6 February 2022 (UTC)
  •   SupportTheDJ (talkcontribs) 17:27, 7 February 2022 (UTC)
  •   Support ChhTJ096 (talk) 19:45, 8 February 2022 (UTC)
  •   Support only as an opt-in in perferences; as said by Pelagic above: some (me) find the browser permission prompt annoying (and I personally prejudice the website with a negative opinion) — DaxServer (t · c) 20:32, 8 February 2022 (UTC)
  •   Support Veracious (talk) 06:48, 9 February 2022 (UTC)
  •   Support · · · Peter (Southwood) (talk): 13:06, 9 February 2022 (UTC)
  •   Support --evrifaessa (talk) 16:19, 11 February 2022 (UTC)

Notify users when their revision has been approved or rejected

  • Problem: On wikis that have 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, and there is no easy way to find out about it (apart from keeping to reload the page or its revision history/logs, and knowing where to look).
  • Proposed solution: Create a new notice type in Notifications (for logged-in users) similar to the existing one for Thanks. There are already some design mockups and patches from past years by e.g. ProcrastinatingReader and Pginer-WMF at phab:T54510 (a ticket which has its priority set to "high" ever since Phabricator was set up over seven years ago, and is tagged "good first task" currently).
  • 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. (It should be noted that rejections are very often combined with reverts, which already generate a notification by themselves currently. In other words, it appears likely that the new feature would increase the amount of positive feedback much more than the amount of negative feedback.)
    • Indirectly: all editors and readers, by integrating new contributors quicker, hopefully increasing the retention of productive newbies and encouraging them to contribute more, and aligning them better with community policies and quality standards via tighter feedback loops.
  • More comments: See also the more in-depth rationale by Atlasowa here (2013) and the 2019 wishlist version of this proposal
  • Phabricator tickets: phab:T54510
  • Proposer: HaeB (talk) 04:18, 23 January 2022 (UTC)

Discussion

  • While this would be valuable, I think the far bigger issue is that FlaggedRevs doesn't tell editors that their edits are under review. There should be something like a guided tour the first time they make an edit. --Tgr (talk) 22:07, 23 January 2022 (UTC)
    Perhaps, yes. But at the current velocity of user-facing improvements in this area, that would seem unlikely to become implemented before the middle of the 21st century. So it should not hold up this particular piece of progress. (I understand that while the Flagged Revisions extension is deployed on many Wikimedia wikis and can be expected to remain so for the foreseeable future, it has essentially been orphaned - i.e. without code maintenance responsibilities assigned - for many years now.) Regards, HaeB (talk) 01:07, 28 January 2022 (UTC)

Voting

Enable Thanks Button by default in Watchlists and Recent Changes

  • Problem: The Thanks button is only available on individual Page Histories, which very few people interact with on a regular basis -- especially more experienced editors. The number of newbies looking at individual history pages, is miniscule.
  • Proposed solution: There is a user script on English Wikipedia that implements a thanks feature in other feeds ( see en:User:Evad37/Thanky.js ) but this is a super hidden feature -- and for most wikis, having to configure a script is too high of a technical threshold for most users, especially the ones we want to interact with other users: newbies. I recommend either enabling this by default across all the wikis, or building directly into the Thank feature, that way its something that other mediawiki wikis could handle.
  • Who would benefit: We have a lot of scholarly evidence that the Thank feature improves the general social dynamic on our Wikis, for example, this recent paper, summarized here. However, the thanks button right now in the default interface is living only in the history page of articles, not in many of the places where experienced editors interact with diffs (watchlists, recent changes feeds, etc).
  • More comments:
  • Phabricator tickets: phab:T51541, phab:T90404
  • Proposer: Sadads (talk) 12:10, 11 January 2022 (UTC)

Discussion

  • The [thank] button is also available next to the [undo] button when viewing single diffs, see for example here. Sophivorus (talk) 01:04, 16 January 2022 (UTC)
  • Which is the most natural placement for it, considering that a genuine, meaningful expression of gratitude for a contribution would actually involve knowing what that contribution was, i.e. seeing the diff page of the edit. I'm not sure how much we want to encourage sending thanks in ignorance of what the thanked user actually did. Such concerns were already brought up earlier (e.g. phab:T51541#2189460, but also elsewhere about the history page design IIRC), but I don't see them addressed in this proposal. Regards, HaeB (talk) 05:21, 23 January 2022 (UTC)
  • We really liked that wish when we reviewed it as a team today and are happy to accept it! KSiebert (WMF) (talk) 19:59, 21 January 2022 (UTC)
  • Personally, as an editor, I like the Thanks feature a lot. But the claim that "We have a lot of scholarly evidence that the Thank feature improves the general social dynamic on our Wikis" seems to oversell the existing research results considerably. I agree that the mentioned preprint study was well done, it seems by far the best evaluation of the feature's effects to date (see also my review in the Wikimedia Research Newsletter). But contrary to many expectations (including mine), the thanked newbie users did not contribute more - as measured by daily labor hours - in this experiment. The biggest effect was that they ended up sending more thanks themselves. Interpreting the latter result as a significant improvement of the wiki's social dynamic requires the circular assumption that we already know that the Thanks feature has this effect. Again, I like the feature personally and try to use it often myself as an editor. But the evidence for its impact should not be exaggerated for the purposes of prioritizing this proposal. Regards, HaeB (talk) 05:10, 23 January 2022 (UTC)
  • Comment: Similar to HaeB above (05:21) I'm not sure that thanking someone without viewing the diff is good practice. (IIRC, I had raised this once before and was told that, and found their point convincing.) Perhaps we should remove thanks from the History too, to bring it into parity with WL and RC. ⁓Pelagic (talk) 23:29, 29 January 2022 (UTC)
    @HaeB @Pelagic The problem is that you can see diffs in a lot of these other places because of popups, and other tools -- especially experienced editors have ways of "seeing" the diff, without going to a diff page -- its really frustrating especially when you see, for example, someone do a revert of vandalism from a clearly vandalism account, etc., Sadads (talk) 15:58, 31 January 2022 (UTC)
The Popups tool actually already includes a "send thanks" action (as someone already pointed out in the linked Phabricator tickets). Besides, we shouldn't change the general MediaWiki interface for all users to support a use case that only fully makes sense for a small number of power users employing certain bespoke tools. Regards, HaeB (talk) 11:03, 2 February 2022 (UTC)
@HaeB However, that button needs a lot more clicks (it even loads the Special:Thanks page rather than sending it directly). I agree that this feature is not very useful for newcomers (and thus would not support this being enabled by default), but a simple preference for this seems useful. ~~~~
User:1234qwer1234qwer4 (talk)
19:37, 11 February 2022 (UTC)
  • @Sadads Might be a bit paradoxical to present this proposal as aimed at "newbies" in the description and then make an argument about "experienced editors". ~~~~
    User:1234qwer1234qwer4 (talk)
    19:27, 11 February 2022 (UTC)
    @1234qwer1234qwer4 The point, is that the technical skill is high for experienced editors and for new editors -- and in small wikis, configuring it and alongside the other features, especially when you don't necessarily need to open the history or a diff to appreciate it, is to high when compared with the value that comes from thanking folks, Sadads (talk) 23:51, 11 February 2022 (UTC)

Voting

  •   Support The more visible and easy-to-use that the thanks button is, the better. It's a really nice way to acknowledge an edit! Thanks. Mike Peel (talk) 18:35, 28 January 2022 (UTC)
  •   Support Femke (talk) 19:34, 28 January 2022 (UTC)
  •   Support Thanks button should be more visible and easy to use... RJ Raawat (talk) 20:32, 28 January 2022 (UTC)
  •   Support Strainu (talk) 21:23, 28 January 2022 (UTC)
  •   Support As proposer Sadads (talk) 22:59, 28 January 2022 (UTC)
  •   Support Sea Cow (talk) 23:28, 28 January 2022 (UTC)
  •   Support Klein Muçi (talk) 00:50, 29 January 2022 (UTC)
  •   Support Also please add Undo as requested elsewhere. Certes (talk) 01:34, 29 January 2022 (UTC)
  •   Support Betseg (talk) 02:13, 29 January 2022 (UTC)
  •   Support Shizhao (talk) 03:59, 29 January 2022 (UTC)
  •   Support Lectrician1 (talk) 04:06, 29 January 2022 (UTC)
  •   Support Jake The Great 908 (talk) 06:33, 29 January 2022 (UTC)
  •   Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:04, 29 January 2022 (UTC)
  •   Support Graham11 (talk) 08:45, 29 January 2022 (UTC)
  •   Support Ainali talkcontributions 08:55, 29 January 2022 (UTC)
  •   SupportSHEIKH (Talk) 14:27, 29 January 2022 (UTC)
  •   Support Aca (talk) 14:55, 29 January 2022 (UTC)
  •   Support Mohammad ebz (talk) 18:23, 29 January 2022 (UTC)
  •   Support Waddles 🗩 🖉 21:10, 29 January 2022 (UTC)
  •   Support czar 00:09, 30 January 2022 (UTC)
  •   Support Gusfriend (talk) 00:24, 30 January 2022 (UTC)
  •   Support Agus Damanik (talk) 02:02, 30 January 2022 (UTC)
  •   Support GeoffreyT2000 (talk) 02:15, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 08:22, 30 January 2022 (UTC)
  •   Support Fano (talk) 09:11, 30 January 2022 (UTC)
  •   Support I don't use the "thank" feature because I'm too lazy to go to the page history. This would be pretty damn useful SHB2000 (talk | contribs) 10:23, 30 January 2022 (UTC)
  •   Support«« Man77 »» [de] 13:45, 30 January 2022 (UTC)
  •   Support daSupremo   22:29, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:03, 30 January 2022 (UTC)
  •   Support JAn Dudík (talk) 11:51, 31 January 2022 (UTC)
  •   Support Trizek from FR 13:44, 31 January 2022 (UTC)
  •   Support the wub "?!" 14:34, 31 January 2022 (UTC)
  •   Support Dreamy Jazz talk to me | enwiki 14:52, 31 January 2022 (UTC)
  •   Support PorkchopGMX (on the go) (talk) 18:19, 31 January 2022 (UTC)
  •   Support Mbkv717 (talk) 20:12, 31 January 2022 (UTC)
  •   Support IAmChaos (talk) 21:43, 31 January 2022 (UTC)
  •   Support Shooterwalker (talk) 22:21, 31 January 2022 (UTC)
  •   Support Trey314159 (talk) 22:52, 31 January 2022 (UTC)
  •   Support --Alaa :)..! 08:26, 1 February 2022 (UTC)
  •   Support Glerium (talk) 12:14, 1 February 2022 (UTC)
  •   Support ok Thingofme (talk) 13:11, 1 February 2022 (UTC)
  •   Support Daniel Case (talk) 02:55, 2 February 2022 (UTC)
  •   Support KingAntenor (talk) 06:44, 2 February 2022 (UTC)
  •   Support Firefangledfeathers (talk) 04:10, 3 February 2022 (UTC)
  •   Support EN-Jungwon 10:33, 3 February 2022 (UTC)
  •   Support Aladdin  talk  14:50, 3 February 2022 (UTC)
  •   Support Paucabot (talk) 15:41, 3 February 2022 (UTC)
  •   Support WikiAviator (talk) 16:12, 3 February 2022 (UTC)
  •   Support JuliánLeiva66 (talk) 18:56, 4 February 2022 (UTC)
  •   Oppose the addition of a thanks button in the default interface anywhere but the Page History and diff view (which the proposal seems to misleadingly omit). Points in the "Discussion" section have gone unaddressed by supporters. — Bilorv (talk) 19:51, 4 February 2022 (UTC)
    Proposal omits it; first comment in the discussion section mentions it. The thanks button is also visible next to the log entries displayed when opening a previously deleted page, which you seem to misleadingly omit. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:25, 11 February 2022 (UTC)
  •   Support I often want to thank people directly from viewing the change in Popups. Make this an option in Preferences, even if it's off by default. Fayenatic london (talk) 14:47, 5 February 2022 (UTC)
  •   Support - Darwin Ahoy! 14:47, 5 February 2022 (UTC)
  •   Support SD hehua (talk) 15:23, 5 February 2022 (UTC)
  •   Support Exilexi (talk) 17:36, 5 February 2022 (UTC)
  •   Oppose I agree with HaeB, Pelagic, and Bilorv that this could result in thanks being sent without actually seeing/verifying what was changed. But I'm very much in favor of encouraging more thanks to be given! = paul2520 (talk) 19:46, 5 February 2022 (UTC)
  •   Oppose --Ciao • Bestoernesto 02:20, 6 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 07:40, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:30, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 09:58, 6 February 2022 (UTC)
  •   Support Newt713 (talk) 14:10, 6 February 2022 (UTC)
  •   Support Matthew T Rader (talk) 20:58, 7 February 2022 (UTC)
  •   Support ~Cybularny Speak? 21:18, 7 February 2022 (UTC)
  •   Support only with an option to disable/opt-out on such pages; users with rollback rights already see a rollback button and adding a thank button would add more clutter to the interface. — DaxServer (t · c) 20:29, 8 February 2022 (UTC)
  •   Support Nice to have it. Thank you. Use of thanks button is important not only for existing wiki-community, but also for support of newbies.KKDAII (talk) 21:42, 10 February 2022 (UTC)
  •   Support Marcok (talk) 12:46, 11 February 2022 (UTC)

Article-specific notifications based on watchlist

  • Problem: Notifications are currently driven by user-based actions: reverts of the notified user's edits, thanks, mentions and replytos or pings. If an editor wants/needs to work on one thing yet keep an eye on a particular article or set of articles (or pages), this has to be done by regularly checking a watchlist or the history pages in question.
  • Proposed solution: Notifications could be triggered by edits to pages on the user's watchlist, perhaps even keyed to edits that resemble apparent vandalism situations, or edit wars, where the user being notified might want to be able to respond more swiftly.
  • Who would benefit: Admins and vandal fighters, but I think everybody.
  • More comments: Yes, this could make some user disputes a little hotter. But I think it would be a net benefit to the community and the project.
  • Phabricator tickets:
  • Proposer: Daniel Case (talk) 04:59, 14 January 2022 (UTC)

Discussion

This can be useful when I want to watch som page on smome wiki where I am not regularry active if I can add this page between notificatinn. JAn Dudík (talk) 20:56, 17 January 2022 (UTC)

Could you elaborate on the specific pain points that justify this wish? We would like to understand it better, thanks! KSiebert (WMF) (talk) 13:16, 21 January 2022 (UTC)
@Daniel Case: Just pinging you to find out more! KSiebert (WMF) (talk) 11:46, 26 January 2022 (UTC)
  • @Daniel Case: Thank you for writing this proposal. I'm afraid I'll archive it for lack of clarification. Let me know if you have any concerns. DMaza (WMF) (talk) 16:24, 27 January 2022 (UTC)
@DMaza (WMF): I thought it was the other user from whom clarification was requested as to his "pain points", not me. Daniel Case (talk) 20:23, 27 January 2022 (UTC)
@Daniel Case It's not too late! Sorry for the confusion. I think your problem statement is fine, but perhaps even keyed to edits by certain editors, apparent vandalism situations, or edit wars might be asking too much. Getting pinged when certain users edit an article would be a huge vector for harassment and is unlikely to be implemented by the WMF, per our prior research at Community Tech/Add a user watchlist. "Apparent vandalism" is too vague and hard to quantify (maybe the ORES score would be okay), and similar for edit wars. All of those would also very much complicate the UI and watchlist system. But, if you just want an Echo notification when edits are made to specific pages, I think we can make that happen. Would you mind removing the quoted bit from your proposed solution? Then we can move this out the archives. Thank you!
See also the Favorite an article with a gold star proposal. MusikAnimal (WMF) (talk) 22:34, 27 January 2022 (UTC)
@MusikAnimal (WMF): Actually, I was thinking of IP users, or accounts with a certain degree of newness ... i.e., it could alert you if a particular sockpuppeteer might be showing up again. Perhaps it could even be indexed to a particular diff or set of diffs, like some sort of personal edit filter. Daniel Case (talk) 00:21, 28 January 2022 (UTC)
@Daniel Case Eek, the scope is increasing with each suggestion, hehe! The hardest part is the UI challenges, I think… "Watchlist" by itself is already a confusing subject for new users, then we added the expiry feature. I can't imagine adding more fields to that tiny little pop-up form that is shown. Now that I understand your use-case, I envision a Special:PageNotifications where you could add which pages you want to get notified about – completely separate from the normal watchlist. This by itself I think is a solid idea that would be of use to many editors. For instance, there's the "article creator" notifications wish. That wish would be satisfied if our new Special:PageNotifications offered an option to get pinged about page links.
Adding on the complexity of making it a counter-vandalism tool is something we could iterate on. I would say the "personal edit filter" aspect is a no-go and much too out of scope, but we could offer simple criteria for the pings such as "only edits by IPs / new accounts". I am realizing now ORES scores likely won't work because those are stored post-save, so there could be race conditions. So anyways, I suggest we keep things simple and open-ended both so that we (Community Tech) do not over promise, but also to attract voters to this general-purpose tool.
All of that said, how do you feel about leaving your proposal as-is, but just removing mentions of "watchlist", since that system wouldn't be used here? Or really, I'd just prefer to place this in the "Notifications" category. I'm guessing most voters won't care if the system is separate from the watchlist they now use. MusikAnimal (WMF) (talk) 01:17, 28 January 2022 (UTC)
I'll await your reply before moving this back into the survey. To summarize: My suggestions are to remove mention of the watchlist (we'll remove it from the proposal title when we move this page), and also remove the bit about triggering notifications about specific editors, because that is a hard "no" from Trust & Safety, I suspect. For the "Proposed solution", I suggest something like Introduce a new system to get notified about edits to pages that you selectively subscribe to, apart from the normal watchlist. There could be options to aid counter-vandalism, such as only notifying for edits by new users or reverted edits. You could also get notified about other events such as page links. Let me know how you'd like to proceed! We have until 18:00 UTC to decide. Best, MusikAnimal (WMF) (talk) 01:51, 28 January 2022 (UTC)
What I would want would be an option to get notified when someone makes a new edit to an article on my watchlist, at minimum. But your suggestion is fine with me, so I'll use it. Daniel Case (talk) 04:36, 28 January 2022 (UTC)
All items on your watchlist? For some users, that could possibly overload the system. Anyway, I admit I'm breaking our own rules and focusing too much on the solution… The problem statement is what matters, and that's crystal clear. Let's just leave your wording as-is :) I'll only remove the bit about getting notified for specific editors, because of our prior experience involving this. Thanks and I look forward to seeing how this proposal performs during voting! MusikAnimal (WMF) (talk) 05:12, 28 January 2022 (UTC)
I wrote some code to add echo watchlist notifications for a GCI task back in 2019. (phab:T203941) It still hasn't been enabled on WMF projects. * Pppery * it has begun 18:53, 28 January 2022 (UTC)

Voting

  •   Support«« Man77 »» [de] 13:45, 30 January 2022 (UTC)
  •   Support Thingofme (talk) 13:08, 1 February 2022 (UTC)
  •   Support KingAntenor (talk) 06:45, 2 February 2022 (UTC)
  •   Support paul2520 (talk) 19:38, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:18, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:31, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 09:59, 6 February 2022 (UTC)
  •   Support Tgr (talk) 21:53, 6 February 2022 (UTC)
  •   Support Toadspike (talk) 01:36, 7 February 2022 (UTC)
  •   Support Will kind of work like the notification bell for YouTube channel subscriptions ;) Lectrician1 (talk) 05:26, 6 February 2022 (UTC)
  •   Support Wikiusuarios (talk) 20:21, 10 February 2022 (UTC)

New messages popup for new users

  • Problem: Many new editors don't notice the new messages popup in the right hand corner, which leads to them not reading important feedback about their edits.
  • Proposed solution: Have a one-time popup that appears when the user gets the first user talk post so the user knows they received a new message. Also, have some sort of global opt-out available so that stewards etc. don't have to click through this over and over.
  • Who would benefit: New editors, admins
  • More comments:
  • Phabricator tickets:
  • Proposer: Rschen7754 02:12, 14 January 2022 (UTC)

Discussion

  • May need different options for desktop and mobile, for mobile a related task is phab:T240976. — xaosflux Talk 15:24, 14 January 2022 (UTC)
  • This could be an entry point for opting-in to desktop push notifications. However, I'd prefer having the gold bar of doom for everyone, not just new users and not just on Vector. See also Community Wishlist Survey 2022/Mobile and apps/Better warning display for mobile users. Could this pop-up co-exist with the gold bar (or its equivalent)? Pelagic (talk) 00:08, 30 January 2022 (UTC)
  • I'm not sure how you can miss a long bright yellow bar saying "You have new messages" without actively ignoring it, so this proposal is of doubtful effectivity for me. Mobile has obviously very different problems. ~~~~
    User:1234qwer1234qwer4 (talk)
    19:40, 11 February 2022 (UTC)

Voting

  •   Support * Pppery * it has begun 18:51, 28 January 2022 (UTC)
  •   Support I work with a lot of new editors. Messages are often overlooked, not for lack of interest, but just because there's a lot to keep track of when getting started. This would help orient new community members. Wskent (talk) 19:20, 28 January 2022 (UTC)
  •   Weak support — Draceane talkcontrib. 22:04, 28 January 2022 (UTC)
  •   Support Izno (talk) 23:53, 28 January 2022 (UTC)
  •   Support Betseg (talk) 02:13, 29 January 2022 (UTC)
  •   Support Graham11 (talk) 08:46, 29 January 2022 (UTC)
  •   SupportSHEIKH (Talk) 14:27, 29 January 2022 (UTC)
  •   Support Aca (talk) 14:56, 29 January 2022 (UTC)
  •   Support Encycloon (talk) 21:43, 29 January 2022 (UTC)
  •   Support , if it doesn't prevent the other forms of “you have new talk page messages” from being enabled more widely. Pelagic (talk) 00:11, 30 January 2022 (UTC)
  •   Support Agus Damanik (talk) 02:02, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:02, 30 January 2022 (UTC)
  •   Support Dreamy Jazz talk to me | enwiki 14:53, 31 January 2022 (UTC)
  •   Support Novak Watchmen (talk) 17:40, 31 January 2022 (UTC)
  •   Support Mbkv717 (talk) 20:12, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 13:11, 1 February 2022 (UTC)
  •   Support Daniel Case (talk) 02:53, 2 February 2022 (UTC)
  •   Oppose KingAntenor (talk) 06:43, 2 February 2022 (UTC)
  •   Support Mustafa_MVC (talk) 16:24, 2 February 2022 (UTC)
  •   Support WikiAviator (talk) 16:12, 3 February 2022 (UTC)
  •   SupportBilorv (talk) 19:52, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 02:09, 5 February 2022 (UTC)
  •   Support paul2520 (talk) 19:39, 5 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 21:49, 5 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 07:41, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 09:33, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 00:02, 7 February 2022 (UTC)
  •   Support Toadspike (talk) 01:33, 7 February 2022 (UTC)
  •   SupportTheDJ (talkcontribs) 17:27, 7 February 2022 (UTC)
  •   Support ChhTJ096 (talk) 19:49, 8 February 2022 (UTC)
  •   SupportDaxServer (t · c) 20:33, 8 February 2022 (UTC)
  •   Support Manuel Assiego (talk) 02:12, 9 February 2022 (UTC)
  •   Support Meiræ 22:09, 10 February 2022 (UTC)