Jump to content

Community Wishlist Survey 2022/Notifications

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2022
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)[reply]

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)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
    This is like handling vandalism and AFDs Thingofme (talk) 01:47, 3 February 2022 (UTC)[reply]
  • 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)[reply]
  • "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)[reply]

Voting

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 (C•T•U) 00:30, 14 January 2022 (UTC)[reply]

Discussion

Voting

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)[reply]

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)[reply]
    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)[reply]

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)[reply]

Discussion

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    @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)[reply]
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)[reply]
@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)[reply]

Voting

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)[reply]

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)[reply]

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)[reply]
@Daniel Case: Just pinging you to find out more! KSiebert (WMF) (talk) 11:46, 26 January 2022 (UTC)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Voting

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)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2022/Notifications&oldid=22829021"