Community Wishlist Survey 2023/Notifications, Watchlists and Talk Pages

Add links
From Meta, a Wikimedia project coordination wiki
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]

Discussion

@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]
  • "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]
@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]
@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]
@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]

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]

Discussion

I realised that using the word hashtags has confused thing. :-( Please see reword below) Wakelamp (talk) 08:49, 7 February 2023 (UTC)[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]

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]
@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]

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]
@Musikanimal: Excellent - Thank-you for your help. I have renamed the proposal as well Wakelamp (talk) 21:51, 9 February 2023 (UTC)[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]

Discussion

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]

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]

Discussion

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]

Discussion

Voting

Watchlist edit - "check all" checkbox

Discussion

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]

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]

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]
  • 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]
    Some mildly relevant CentralNotice tasks which might be easier to fix: T138572, T52865 --Tgr (talk) 06:40, 30 January 2023 (UTC)[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]
  • @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]
  • 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]

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]

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]

Discussion

Voting

Highlight edits that are likely to have problems on page history

  • Problem: I cannot see what bad edits have been made to a page on its history page or the degree of how bad edits are ("likely to have problems", "very likely to have problems", the different colors) like you can see with changes on your Watchlist.
  • Proposed solution: The revision history page should have an option for highlighting edits that are "Likely to have problems", and "Very likely to have problems".
  • Who would benefit: Patrollers
  • More comments:
  • Phabricator tickets: phab:T318372
  • Proposer: Lectrician1 (talk) 06:51, 25 January 2023 (UTC)[reply]

Discussion

What criteria would be used to assess the problematicity of edits? Daniel Case (talk) 05:27, 22 February 2023 (UTC)[reply]

Voting

On-wiki notifications for the Watchlist or subscriptions per page

  • Problem: I forget that watchlist exists, I think notifications informing about changes in pages would be useful. I get e-mail notifications but I don't see any reasons not to move them to Wikimedia.
  • Proposed solution: Adding option to enable notifications for the watchlist or a separate "subscribe" button for each page in Wikimedia projects.
  • Who would benefit: All people viewing the Recent Changes, pending change reviewers, members of WikiProjects and sysops. The function would make tracking WikiProject discussion pages or articles, that are often edited or vandalized, easier.
  • More comments: This should be optional and configurable for individual projects. That is, in the same way that watchlist email notifications are optional. For example, I might only want enable notifications for meta.wikimedia, but not for en.wikipedia.
  • Phabricator tickets: T309855 (watchlist notifications), T263821 (new topic notifications), T284795 (subscribe to all topics on a page)
  • Proposer: SkrzydlatyMuflon (talk) 15:42, 29 January 2023 (UTC)[reply]

Discussion

Voting

Community-level notifications

  • Problem: Communities are thriving: they organize contests, they open large discussions, they gather and much more. These events are often gathered on a dedicated page for events that target the whole wiki, and at WikiProject pages for more specific events. Some other solutions are available; such as Watchlist notifications, or on-wiki newsletters; when a big project has to be announced, banners can be displayed.

    However, the vast majority of users don't get the information: check on community consultations, where the ratio of active users versus participating users is pretty low.

    Communication could be improved, using Echo notifications.

  • Proposed solution: ** Create a notifications board for the community (that could replace pages listed at d:Q79790), and one -personal- for the user (on special:Notifications)
    • Provide configurations so that Notifications can be submitted, reviewed, and delivered to each targeted user, given the topics, locations, interests, etc they've defined in their profile preferences.
    • Provide settings so that a user can select which notifications to opt-in, opt-out or configure.
    • Notifications should be tailored for each user profile, for instance:
      • A user who can't participate in a community-bread consultation shouldn't be notified. But a Notification informing them of the fact that they now have the right to participate should be sent.
      • Local in-person events should target users who opt-in for a given area.
  • Who would benefit: Anyone involved in the community, wishing to be more involved in the community. Newcomers could also get these notifications at Special:Homepage where available.
  • More comments:
  • Phabricator tickets:
  • Proposer: Trizek from FR 16:00, 6 February 2023 (UTC)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Notifications,_Watchlists_and_Talk_Pages&oldid=24623526"