Wikimedia Meta-Wiki

Community Wishlist Survey 2023/Notifications, Watchlists and Talk Pages

< Community Wishlist Survey 2023
Community Wishlist Survey 2023
Notifications, Watchlists and Talk Pages
15 proposals, 224 contributors, 465 support votes
The survey has closed. Thanks for your participation :)



Allow posting new sections to top of Talk pages

Discussion

Voting

Change information about the number of watchers on a page

  • Problem: When accessing Wikipedia: Tools > Page information, the "number of page watchers" contains data that represents a large number of inactive users, that is, who no longer edit on Wikipedia. In addition, "Number of watchers who visited recent edits" it does not define the period that these users were active in the project. The idea would be to come up with a solution that reflects the number of watchers that are active on Wikipedia based on two changes.
  • Proposed solution: Change on Page information (Basic information): "Number of page watchers" and "Number of page watchers who visited recent edits" to "Number of watchers who visited recent edits in the last 90 days" and "Number of watchers who visited recent edits in the last 30 days", respectively.
  • Who would benefit: Everyone who edits on Wikipedia would benefit, as the proposed changes would value active watchers on Wikipedia, preventing these pages from being vandalized due to the fact that they do not have inactive watchers. Therefore, when changing the first to last 90 days, we will only have number of watchers who edited Wikipedia in this period, while those who edited in the last 30 days will also be those who edited in this period. Inactive users would be in the number of watched pages (last 90 days or 30 days) when they come back to edit again.
  • More comments: With the approval of this proposal, it will be implemented in all global Wikipedias.
  • Phabricator tickets:
  • Proposer: WikiFer msg 14:19, 2 February 2023 (UTC)Reply[reply]

Discussion

  • @WikiFer: Thank you for your proposal! Could you elaborate more on how this would prevent from vandalism? We would like to understand better! KSiebert (WMF) (talk) 20:31, 2 February 2023 (UTC)Reply[reply]
@KSiebert (WMF): On this proposal, the community would know which articles have active users in the last 90 days and 30 days, which would give the articles more security in the fight against vandalism (if these users are active, they can reverse vandalism, as they will be following your watchlist). WikiFer msg 21:33, 2 February 2023 (UTC)Reply[reply]
  • "Watchers who visited recent edits" is people who have either seen the current revision of the page (whenever) or have visited the page less than $wgWatchersMaxAge time before it was last edited (180 day on Wikimedia wikis). IMO not really useful because 1) 180 days is a long time, 2) if the page was last edited three years ago, knowing that there were people who saw it some time within that three years is useful for assessing how much we should trust the current revision, but not at all useful for telling how much we should expect watchlists to help if the page gets vandalised now. There is also the issue that page information isn't a very useful place for this - you'd want to see which pages are not watched, not to take a specific page and see how many watch it.
So I think there are several feature requests here:
  • Make pageinfo tell clearly what this number means (and specify the time range) - trivial
  • Decrease it to maybe something like 30 days - trivial
  • See if there is a way to produce a number more relevant for vandalism (e.g. limit number to users who have been active in the last N days) - might be tricky because of performance implications
and while that wasn't requested, IMO it would be nice to see if there is a more useful place for surfacing this information (that's T313581, also probably hard because of performance). --Tgr (talk) 07:37, 3 February 2023 (UTC)Reply[reply]
  • @WikiFer: Would you like to adjust the proposal to some of Tgr's suggestions one more time and make more specific? KSiebert (WMF) (talk) 10:10, 3 February 2023 (UTC)Reply[reply]
@Tgr As you said, the information about the number of watchers needs to be changed. In 180 days, it is only relevant if the page received editions in this period, but for articles without edition for more than 1 year, for example, it loses its effectiveness. As the proposal is limited to dealing with a statistic related to those who watch a page, we must establish a time range for the community to know the status of each watched page. Technically, decrease to the last 30 days would be a better solution to let the community know what to do with these pages. It would be the best option. Combating vandalism is only possible when the information on a page contains more up-to-date data on watchers. Therefore, the proposal aims, only statistically, to know which pages are still under the control of active users, it will help new active users to monitor this page if they do not have watchers in this period. WikiFer msg 12:15, 3 February 2023 (UTC)Reply[reply]
@Tgr Technically, it should change $wgWatchersMaxAge to the last 30 days. The statistics of who watched the page in this period will help other active users to watch this page. WikiFer msg 12:20, 3 February 2023 (UTC)Reply[reply]
  • FWIW FlaggedRevs' Special:PendingChanges shows how many active watchers each entry in a changes list has. Not sure how it defines "active watchers". --Tgr (talk) 07:44, 3 February 2023 (UTC)Reply[reply]
    @Tgr Special:PendingChanges it only serves to monitor new edits to articles, it has nothing to do with the users who watch the pages. Furthermore, en:Wikipedia:Pending changes it is limited to a few Wiki projects (my proposal covers Wikipedia in all languages). WikiFer msg 12:40, 3 February 2023 (UTC)Reply[reply]
    The proposal is centered on how many people who watches the page (and may have edited recently). Thingofme (talk) 02:36, 18 February 2023 (UTC)Reply[reply]
    Change to people who edited recently in the last 90 days and 30 days, respectively. WikiFer msg 14:30, 18 February 2023 (UTC)Reply[reply]
  • Question: What does it mean to "visit recent edits?" If I open my watchlist and the edit summary is somewhere on the page, does that count as a visit?
@Constant314 If you saw your watchlist, it's count as a visit already. Just be an active user in the last 90 days or 30 days. WikiFer msg 20:54, 19 February 2023 (UTC)Reply[reply]

Voting

Kiwik template - Ping projects/limited workflow

  • Problem:  
    • Editors get overloaded with communication as all messages/watchlist are addressed to individuals, when some messages would be better directed towards another article talk or a project
    • Many workflows involve manualy updating a second page. kiwik would be the first step towards a simple workflow
    • wiki is great for discussing an issue, but not necessarily great at providing a synopsis, or linking multiple conversations.
    • Userboxes can not be used to ask for expertise due to concerns abut spam
  • Proposed solution: Creating a two-way communication between any two pages (e.g. article talk <-> project talk)
    1. On the New York City Subway page, say you add a template like {{kiwik|Wikipedia talk:WikiProject Trains|help on XYZ}} to a discussion topic T
    2. A bot will notify related WikiProjects, such as WikiProject Trains and WikiProject New York City, with a kiwik pointing in the opposite direction like {{kiwik|Talk:New York City Subway|help on XYZ|Topic T}}
    3. Optional: Synch changes, handle deletions and archives, and handle fixing link rot on talk archives
    4. Optional: white list for projects to allow them to opt.
  • Who would benefit:  
    • Editors - Alternate to long watchlists, and spreading of workload
    • Projects that are inactive. Maybe a hashtag feed would give them a purpose, as people could help in their area of interest.
  • More comments:
  • Phabricator tickets:
  • Proposer: Wakelamp (talk) 13:01, 5 February 2023 (UTC)Reply[reply]

Discussion

  • You mean, hashtags in edit summaries? T323875 is a related proposal. Also there's T123529 and T123636 about hashtag support more generally. --Tgr (talk) 18:52, 6 February 2023 (UTC)Reply[reply]
I realised that using the word hashtags has confused thing. :-( Please see reword below) Wakelamp (talk) 08:49, 7 February 2023 (UTC)Reply[reply]

@Wakelamp: Thank you for your proposal but can you please carify your request a little more? Is this regarding hashtags on Wikiprojects, watching pages, edit pages, etc.? We also want to point you to an external tool to use- https://hashtags.wmcloud.org/, that may be able to help you needs. This will allow you to find edits with hastags in the edit summary. GMikesell-WMF (talk) 22:19, 6 February 2023 (UTC)Reply[reply]

Is this rewording better?
  • Suggested rename - kiwik tags - auto create links between any two talk pages (e.g article and project). (kiwik is a palindromes - so two way communication.  :-))

Scope - This proposal is to do with talk pages (main, wikipedia, meta, etc, user, project, essays, guidelines etc)

Problem - There is no low friction/low spam way to ask for help from a group, or to get subject matter expertise, or to consolidate links to do with the same problem

Communication issues-

  • Some pings/processes ask individuals to solve problem/be informed, that should rather than adding to a group queue. For instance, watchlists are individual, so multiple interested parties may do the same review.
  • No easy timely process to escalate poor behaviour. A normal forum self-moderates because there are multiple watchers enforcing group norms, or reporting major issues.
  • Wikipedia discussions on low volume articles, or user talk are effectively private chat rooms.
  • Not enough interlinking to encourage resilience and retention - There are few permanent communication hubs (village pump, admin related, NPP, and a few active projects). Using kiwik links to creating a feed on projects might encourage more activity on projects
  • No easy way to ask for subject matter expertise.
  • Consolidation of discussions – the wiki process encourages exploration of ideas, but there is no easy way to consolidate/summarise suggestions or link ideas to problems,
  • No easy way to ask for help from a project, and few incentives for projects to exist.

Wish-

  • A new kiwik tag. It would create a low friction way to create cross links between project talk pages which could be watched. Some user boxes could be set up as projects, to allow for technical expertise to be requested.
  • Ideally a project could decide to use statuses (open, closed, reviewed),
  • watching a project page would be visible and would replace the project membership list

Use case-

  1. On Origin talk – Add a comment tag {kiwik |link to destination talk page|priority}
  2. Bot goes to destination talk page
    • looks for an existing topic non-archived topic with origin page and section heading
    • otherwise creates create a link and copy comment
  3. Adds Calculate # of comments, # of reverts, # of editors is updated. Priority
The ping command doesn't seem to be working for me in your format - I get red linked Wakelamp (talk) 08:49, 7 February 2023 (UTC)Reply[reply]
@Wakelamp Ah, I think I may finally grasp what you're saying. You basically want a way to ping a community of editors. Let's say you're at w:Talk:New York City Subway. You want expertise from those who know about New York City. You write your comment, and add something like {{kiwik|Talk:New York City Subway|high}} and a bot would post the comment with its priority at w:Wikipedia talk:WikiProject New York City. Does that sound about right? My issue here is the editor still needs to know about the kiwik template, so the system may not have but so much success, especially for new users.
Unfortunately we are running out of time. Voting starts Friday, so please respond as soon as you can. Thanks and regards, MusikAnimal (WMF) (talk) 22:41, 8 February 2023 (UTC)Reply[reply]

Exactly right. I have updated the proposal section and solution sections using your example. It is best that kiwik is not easily visible initially - because its usage will depend on early adopters and projects deciding to use it, how hackable it is and its slow incorporation into processes. Think MVP rather than creating a good UX or automation. My observation is that the Wikipedia changes that seem to cause the least issues are in line with Open Source/ASD culture - either small in scope and deep in detail (think emacs), or broadly applicable with few constraints and optional and hackable (linux 3 or 4 letter programs piped together - a cool name like YACC helps ). The biggest concern will be cross posting to create spam, but even usenet allowed limited cross posting.

Unless there are any objections, in a few hours I am going to delete the sections that I have struck through, change the wording to kiwik from kiwik in everyones comments and rename the proposal. Wakelamp (talk)

@Wakelamp: I've rewritten your proposal to match my understanding of your wish. Let me know if it looks good, and if so I will go ahead and approve it. But we need to hear back soon. Voting starts tomorrow! Thanks, MusikAnimal (WMF) (talk) 20:46, 9 February 2023 (UTC)Reply[reply]
@Musikanimal: Excellent - Thank-you for your help. I have renamed the proposal as well Wakelamp (talk) 21:51, 9 February 2023 (UTC)Reply[reply]

Voting

Enabling subscribe action for lower headers for specific pages (prefix)

  • Problem: Subscribe action only works for level 2 headers
  • Proposed solution: I would suggest enabling subscriptions for lower section levels for specific subpages. That is, for example, by defining some prefixes in the Mediawiki namespace that are an exception to the global rule. In such cases, the subscription would be possible, for example, only for the third level. Or all levels up to 3rd (whatever is easier to do).
  • Who would benefit: I think most large wikis would. With Meta:Srg, you could only subscribe to your request, not the whole thing. Another use case is RfC on en.wiki, where now you can only subscribe to the main discussion section, and you would like to subscribe to only one subsection, but you can't. The same goes for many polls on pl.wiki (e.g. sysop rights vote (PUA)) which can go even deeper.
  • More comments: I know one could migrate some pages up a level (make level 2, level 1 and so on). But this brakes some bots and gadgets and in other cases is not feasible at all (you would have to have 0-level heading).
  • Phabricator tickets: T275943
  • Proposer: Nux (talk) 21:35, 24 January 2023 (UTC)Reply[reply]

Discussion

  • I'll definitely be supporting this one once voting starts. Would be a nice efficiency. There's a whole class of Wikipedia-space pages that use L3/L4 headings for their daily business. Imagine being able to subscribe to just a single section of these enwiki projectspace pages, instead of the entire page: RFD, CFD, FFD, TFD, ITN/C, or RFPP/I. –Novem Linguae (talk) 15:18, 28 January 2023 (UTC)Reply[reply]
  • Will the [subscribe] button show on projectspace pages (non-talk pages) such as w:Wikipedia:Redirects for discussion/Log/2023 February 10? Might need to add some code to allow this, to go along with this task. –Novem Linguae (talk) 07:22, 11 February 2023 (UTC)Reply[reply]
    • Hmm, there must be a mechanism for this already, since w:WP:ANI has [subscribe] buttons. I don't know what the mechanism is though. A category or magic word or something? –Novem Linguae (talk) 07:34, 11 February 2023 (UTC)Reply[reply]
      • Hi. There was a brief prior discussion in early December about that. Based on that I don't think there is a way to add subscriptions on any level now. It just happens auto-magically for level 2 headers (h2). The rfd/log you linked has h3 and h4 headers. The problem can be solved by migration of levels sometimes. But for sub-pages included in bigger pages this is hard-to-impossible. Nux (talk) 10:26, 11 February 2023 (UTC)Reply[reply]
        Based on that I don't think there is a way to add subscriptions on any level now. I agree. This wish would fix that. Above I was just wondering why certain pages get a level 2 [subscription] button and certain pages don't get any [subscription] button. I thought it was by namespace, but I have found exceptions. –Novem Linguae (talk) 05:01, 13 February 2023 (UTC)Reply[reply]
        @Novem Linguae: [subscription] button appears if there is a signature (or any markup that resembles a signature) under the said section. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 21:26, 17 February 2023 (UTC)Reply[reply]
  • Would it hurt to enable subscribing to H3, H4 on all subscribe-enabled pages? Or do we need some mechanism to choose per-page between none, H2, H3, H4? Pelagic (talk) 16:11, 13 February 2023 (UTC)Reply[reply]
    I'm thinking automatically enable all. –Novem Linguae (talk) 03:43, 17 February 2023 (UTC)Reply[reply]
  • How about customising the entire subscription feature by using a magic word? {{ALLOWSUBS|3}} will only allow h3 subscriptions; {{ALLOWSUBS|3|5}} will allow subscription of h3, h4, h5; {{ALLOWSUBS|+}} will allow subscription at all levels; {{ALLOWSUBS|-}} will not allow subscription at any level. Which of these templates to use can be selected on a case by case basis to suit all and every need. —‍(ping on reply)—CX Zoom (A/अ/অ) (let's talk|contribs) 21:33, 17 February 2023 (UTC)Reply[reply]

Voting

Button to mark a single change as read in the global watch list

  • Problem: In my global watchlist, I have entered Wikidata, and there it is often stated straight out what the change consists of in the description itself. In these cases, I find it redundant to have to click on the edit to mark it as read in the list. The number of Wikidata edits in my watchlist quickly becomes redundant and it's frustrating that I have to go through them manually or go through them all in one go and then hit "Mark as read" for all edits.
  • Proposed solution: Add a button to mark a single change as read in the global truncation list.
  • Who would benefit: Contributors who have long watchlists in their global watchlist and go through them bit by bit.
  • More comments:
  • Phabricator tickets: T334246
  • Proposer: Sabelöga (talk) 00:09, 4 February 2023 (UTC)Reply[reply]

Discussion

Voting

Wikibreak/OoO notification autoresponder

  • Problem: I get pings or email messages from people trying to inform me about things, or trying to ask me without going to my user page and/or my talk page. Sometimes, they ping/message me when I'm on a break (which they aren't necessarily aware of). They get frustrated when I'm not reacting.
  • Proposed solution: A new notification. If I do [something] (a preference? a template on my user page?) anyone who pings me or messages me will have a notification informing "the user you've just reached out to is on a break and may not respond soon".
  • Who would benefit: Volunteers responsible for maintaining things (like tools and gadgets), any Wikimedia organization staff, contractors, board members, etc. (affiliate, WMF), and broadly speaking, any functionaries
  • More comments:
  • Phabricator tickets:
  • Proposer: Tar Lócesilion (talk) 00:39, 24 January 2023 (UTC)Reply[reply]

Discussion

  • Tar Lócesilion, the Growth team offers this option for mentors. Mentors can set themwelves as away and, during they away time, newcomers who ask them questions are redirected to another mentor, with a responder message. I don't know how easy it is to offer this option to anyone, but it could be an inspiration. Trizek (WMF) (talk) 20:07, 1 February 2023 (UTC)Reply[reply]
    Thanks for info, @Trizek (WMF). I hope that it'd be clear for the voters that I'm asking for something different. This could perhaps be some inspiration at most. Tar Lócesilion (talk) 19:58, 17 February 2023 (UTC)Reply[reply]
  • @KHarlan (WMF): Any thoughts? Do you think it would be possible to make it available for other users? KSiebert (WMF) (talk) 19:43, 2 February 2023 (UTC)Reply[reply]
    @KSiebert (WMF) yes, we could explore making our "I am away" functionality for mentors something that is available to all users, via Special:Preferences. I'll file a subtask of T327655 about that. I'm not sure about the autoresponder side of it, but we could allow it to modify the appearance of a user's signature, perhaps. KHarlan (WMF) (talk) 13:52, 7 February 2023 (UTC)Reply[reply]
    Filed as T329052 KHarlan (WMF) (talk) 13:55, 7 February 2023 (UTC)Reply[reply]
  • People should also be aware that this is a platform run by volunteers, being in different time zones all over the world, who cannot and will not be standby 24/7. So it might take some time before you get an answer, sometimes several days. --JopkeB (talk) 10:40, 11 February 2023 (UTC)Reply[reply]
  • Just going to mention that when it comes to the messages (i.e. someone writing you on the talk page), you can set up (or ask admins to) an edit notice, and if you have it transclude either a labeled section or just a plain old subpage in your user space you will have control over it without the need to poke admins every time. I have such a set up on my ukwiki user talk page so that I can warn people of a wikibreak. As I am currently not at wikibreak at ukwiki, you can see a PoC on testwiki:User talk:Base (try creating a new topic). Now when it comes to pings this will not work of course. --Base (talk) 21:00, 17 February 2023 (UTC)Reply[reply]
    Thanks @Base. Tacsipacsi mentioned this in the sandbox. My answer was: "That would be a poor ersatz, though. I mostly mean notifications and pings outside of the user talk page namespace. It's more about Admins' noticeboards, WikiProject talk pages, Village Pumps, anywhere where template/gadget maintainers get chased - spaces where someone may ping you specifically and never ask themselves if you're active at a given moment." Best, Tar Lócesilion (talk) 23:01, 17 February 2023 (UTC)Reply[reply]

Voting

Discussion pages should not use HTML lists

  • Problem: Due to an accident of history, we have used HTML lists for discussions, including using : for indentation. Using : for indentation is an accessibility problem for users as it indicates a definition list, yet it is used to indicate a reply.
  • Proposed solution: Change the meaning of : when used on talk pages, when they are not preceded by ; (the definition) to generate simply indentation, and include a backlabel for screenreaders to find the comment to which it is a reply to.
  • Who would benefit: Screenreader users, but also keyboard navigation warriors
  • More comments: There has been some discussion about introducing new syntax for this purpose, but i don't think that this is required. More importantly, I don't think new syntax is DESIRED by the editors. Yet it is still a problem we should solve. This might also help us solve the problem of endless indentation on talk pages, which is problematic for editors without a 24+ inch screen. Discussion Tools have shown that we can do many things to solve problems like this if we really want to.
  • Phabricator tickets: T6521
  • Proposer: —TheDJ (talk • contribs) 16:30, 5 February 2023 (UTC)Reply[reply]

Discussion

Voting

Watchlist edit - "check all" checkbox

  • Problem: When removing pages from Special:EditWatchlist you must manually check every page, even if you want to remove all (or almost).
  • Proposed solution: Add checkbox "Check all" above list of pages for every space.
  • Who would benefit: Everyone.
  • More comments:
  • Phabricator tickets: phab:T334252
  • Proposer: IOIOI (talk) 10:34, 6 February 2023 (UTC)Reply[reply]

Discussion

  • Note, it is possible to shift click the checkboxes, to select an entire range. —TheDJ (talk • contribs) 13:12, 6 February 2023 (UTC)Reply[reply]
  • It seems to be a toggle action. Clicking a checked box – either with or without Shift pressed – will reverse the state of the box or boxes. — Smyru (talk) 10:35, 9 February 2023 (UTC)Reply[reply]
  • It is also possible to highlight and delete everything by editing the raw watchlist, but this is perhaps a little unintuitive. Snowmanonahoe (talk) 19:25, 18 February 2023 (UTC)Reply[reply]

Voting

Allow going beyond the first page on RecentChanges/Watchlist ("older n")

  • Problem: While you can increase the number of results on recent changes and the watchlist to see older changes, this results in slower page load and you have to scroll past the new ones.
  • Proposed solution: "(newer n) (older n)" links at the end of the results, like on history, contributions, etc.
  • Who would benefit: Editors
  • More comments: The query APIs (mw:API:RecentChanges, mw:API:Watchlist) already support "continue". It is weird that it is not possible in the user-facing interface.
  • Phabricator tickets: T20228, T163429
  • Proposer: Nardog (talk) 18:15, 23 January 2023 (UTC)Reply[reply]

Discussion

Voting

Communicate local and global announcements through notifications rather than banners

  • Problem: Global and local announcements are frequent, intrusive, sometimes irrelevant to the reader, and cause layout shifts.
  • Proposed solution: Allow for local and global announcements to be communicated through the notification system where it makes sense
  • Who would benefit: Everyone using Wikipedia.
  • More comments: This proposal is to allow for communications to happen through the notification system where it makes sense and not to replace banners. Communicating announcements through notifications would allow users to read them at their own time, without interrupting other activities. Furthermore, since Wikipedia doesn't overload users with notifications, and it's the user itself who clicks the bell icon to see the notification, it's possible that announcements communicated through notifications may be read with more attention than usual, therefore increasing their effectiveness.
  • Phabricator tickets:
  • Proposer: Sophivorus (talk) 13:02, 27 January 2023 (UTC)Reply[reply]

Discussion

  • Additionally, mobile site (m.wiki) users are never shown MediaWiki:Sitenotice, and that's more than half of all users. ponor (talk) 18:26, 27 January 2023 (UTC)Reply[reply]
  • That would make those announcements a lot harder to notice and read and somewhat defeat the purpose. There is a lot to be said IMO for improved banner controls so it's easier to keep track of what banners are running and limit how often the same user sees them (and to get rid of the overlapping system of local and global notices), but notifications are not the right mechanism for that. It would also require a major rewrite of both banners (CentralNotice) and notifications (Echo) which isn't really realistic. --Tgr (talk) 04:59, 30 January 2023 (UTC)Reply[reply]
    Some mildly relevant CentralNotice tasks which might be easier to fix: T138572, T52865 --Tgr (talk) 06:40, 30 January 2023 (UTC)Reply[reply]
    Pinging the proposer @Sophivorus for their input. I agree it seems like this proposal may be focusing too much on a solution and less about the problem. There are several systems involved here, CentralNotice is one of them but some communities also use Geonotices. For a single proposal, it would be too much to ask I think to consolidate and solve them all. I also agree with Tgr that perhaps notifications aren't the best solution.
    Would you mind trimming down this proposal to something smaller, and focusing on the problem? Perhaps issues with CentralNotice, in particular (or one of the other systems if those are more important to you).
    Note we have until this coming Thursday to get this resolved. I'm sorry we're running so short on time! Another option is to leave this proposal as-is and move it to our Larger suggestions category so it can get the attention it deserves from leadership. Thanks and regards, MusikAnimal (WMF) (talk) 23:53, 6 February 2023 (UTC)Reply[reply]
  • @Sophivorus: Since we didn't hear back from you I'm slightly modifying the proposal and accepting it. DMaza (WMF) (talk) 19:39, 9 February 2023 (UTC)Reply[reply]
  • May I add that many sites and apps already communicate stuff via notifications, so it's not like we're proposing something new. Sophivorus (talk) 01:46, 12 February 2023 (UTC)Reply[reply]

Voting

Notify users when their revision has been approved or rejected

  • Problem: On wikis that have Flagged Revisions enabled, new and inexperienced users who haven't yet 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, assuming the new editor knows where to look at all).
  • 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 a patch that several people (including ProcrastinatingReader and Pginer-WMF) worked on in past years, see phab:T54510 (a ticket which has had its priority set to "high" ever since Phabricator was set up over eight years ago, and which 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 in the future. (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 2022 and 2019 versions of this wishlist proposal.
  • Phabricator tickets: phab:T54510
  • Proposer: HaeB (talk) 14:54, 5 February 2023 (UTC)Reply[reply]

Discussion

Voting

Provide links to discussions that are stable after discussions get archieved

  • Problem: When a topic of a discussion on a discussion page gets archived the links to that discussion break.
  • Proposed solution: Modify the links to be stable, so that they keep working even after discussions get archived.
  • Who would benefit: All readers of older discussions.
  • More comments:
  • Phabricator tickets: T273341
  • Proposer: ChristianKl ❪✉❫ 15:01, 30 January 2023 (UTC)Reply[reply]

Discussion

Voting