Community Wishlist Survey 2022/Watchlists

Watchlists
10 proposals, 148 contributors, 287 support votes
The survey has closed. Thanks for your participation :)



Hide reverted edits

Clicking on "2 changes" shows an empty diff.
  • Proposed solution: Add an option to hide sets of edits that collectively produce an empty diff. Such a set commonly includes one or more edits by a vandal and a rollback edit.
  • Who would benefit: Editors with many pages on their watchlists. My watchlist contains over 700 pages so hiding the edits that don't require my attention would be a huge help.
  • More comments: As a workaround, I configured my browser to run following JavaScript snippet every time I open my watchlist:
[...document.querySelectorAll(".mw-tag-mw-reverted .mw-plusminus-null")].forEach(
  (el) => { el.parentNode.parentNode.parentNode.parentNode.style.display = "none" }
)
This serves me well but is brittle and clearly not a solution for everyone.

Discussion

  • I have seen changes of 0 text that were meaningful. You will need to pin down the criteria under which you think this hiding should be made. --Izno (talk) 19:02, 17 January 2022 (UTC)
    I mean completely empty diffs, not 0-byte changes. The class mw-plusminus-null is just used as a heuristic in my workaround. Dexxor (talk) 21:42, 17 January 2022 (UTC)
    Ah. Yeah, I am not sure this is a good idea even still, because you get permissions-farmers who will make -1 +1 edits that don't change the source for every pair of edits (not that I've seen this too often on watchable pages, but there have been some). Izno (talk) 19:51, 18 January 2022 (UTC)
    A reverted edits is searched using the tag "reverted" Thingofme (talk) 17:03, 22 January 2022 (UTC)
  • How do you even get the "2 changes" layout option? I just get the last edit to a watched page or if you select "Expand watchlist to show all changes" ever edit is separate. Having "x changes" looks useful (and familiar.. like something I used to have...) KylieTastic (talk) 20:17, 28 January 2022 (UTC)
    @KylieTastic: Enable "Group changes by page in recent changes and watchlist" in Preferences § Recent Changes. Dexxor (talk) 15:47, 29 January 2022 (UTC)
  • I would love to hide (better: mark in some way: grey out?) pairs (or larger sets) of consecutive edits which result in no overall change. This includes some but not all zero-byte changes. If someone changes "Trump" to "Biden" I care, even though the size is unchanged. If they change "Trump" to "poop" and it's reverted, I don't care; someone already dealt with that. Certes (talk) 01:55, 29 January 2022 (UTC)
    @Certes: This is exactly what this proposal is about. Don't forget to vote! Dexxor (talk) 15:52, 29 January 2022 (UTC)
  • I'd click disaprove were it an option. I anti-support this item BradVesp (talk) 13:22, 29 January 2022 (UTC)
    @BradVesp: Why is that? Did you carefully read the proposal? Dexxor (talk) 15:56, 29 January 2022 (UTC)
  • Edits reverted in bot mode get hidden. --Tgr (talk) 00:29, 30 January 2022 (UTC)
  • Similar: Community Wishlist Survey 2022/Search/Enable negation for tag filters --Wargo (talk) 23:33, 1 February 2022 (UTC)
  • I use a personal-stylesheet with -- .mw-tag-mw-undo, .mw-tag-mw-rollback, .mw-tag-mw-reverted {opacity: 0.2;} -- It seems to work well. (screenshot). Quiddity (talk) 09:13, 10 February 2022 (UTC)
  • Related task: phab:T190021. Hope that helps! Quiddity (talk) 09:13, 10 February 2022 (UTC)

Voting

  •   Support Femke (talk) 19:40, 28 January 2022 (UTC)
  •   Support — Draceane talkcontrib. 22:18, 28 January 2022 (UTC)
  •   Support SVcode (talk) 00:31, 29 January 2022 (UTC)
  •   Support Javiermes (talk) 15:07, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:22, 29 January 2022 (UTC)
  •   Support Ainali talkcontributions 16:02, 29 January 2022 (UTC)
  •   Support KylieTastic (talk) 16:07, 29 January 2022 (UTC)
  •   Support as long as it hides only empty diffs and not changed content of equal size. Certes (talk) 19:31, 29 January 2022 (UTC)
  •   Support Often the size of my watchlist dissuades me from going through it, when in reality most of the changes are reverted. If I could filter them I'd do it without a thought. Sophivorus (talk) 23:06, 29 January 2022 (UTC)
  •   Support Fuger  (Talk) 01:28, 30 January 2022 (UTC)
  •   Support: substantial use case. I wouldn't enable it as I like to check that if added content has been reverted then none of it was usable and if removals were reverted then there's no issue with that content that does need resolution, and also whether I need to request page protection (if there's a lot of vandalism). However, I can see that clicking on reverted vandalism edits for a lot of people would just be a time sink and they do not want it as part of their workflow. — Bilorv (talk) 11:24, 30 January 2022 (UTC)
  •   Support Titore (talk) 18:55, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:53, 30 January 2022 (UTC)
  •   Support JPxG (talk) 01:03, 31 January 2022 (UTC)
  •   Support IOIOI (talk) 21:05, 31 January 2022 (UTC)
  •   Support Shooterwalker (talk) 22:15, 31 January 2022 (UTC)
  •   Support2d37 (talk) 09:46, 1 February 2022 (UTC)
  •   Support Thanks, EDG 543 (message me) 14:38, 1 February 2022 (UTC)
  •   Support Thibaut (talk) 16:11, 1 February 2022 (UTC)
  •   Support Wargo (talk) 23:33, 1 February 2022 (UTC)
  •   Support Yes, to reduce useless edits Thingofme (talk) 10:30, 2 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 06:02, 3 February 2022 (UTC)
  •   Oppose If your watchlist is filled with that many unnecessary edits, then clear it up. I don't see how this is necessary. --SHB2000 (talk | contribs) 08:54, 4 February 2022 (UTC)
  •   Support Dave Braunschweig (talk) 23:44, 4 February 2022 (UTC)
  •   Support MONUMENTA (talk) 02:54, 5 February 2022 (UTC)
  •   Oppose Perfectly good edits are sometimes reverted due to a misunderstanding, or mistrust of IP editors. Even if you are only interested in fighting vandals, you should not turn these off - I've seen vandals make reverts just to be disruptive. SpinningSpark 10:17, 5 February 2022 (UTC)
    @Spinningspark: You got a point there but I still believe an option to hide edit groups that produce an empty diff would be useful. Before I had my browser configured to hide those edit groups, I simply ignored them because checking them is a waste of time in 95% of cases. So unhiding those edit groups would not result in me noticing the good edits that you brought up. As long as there are some hardworking editors like you checking every edit I don't see a problem with my approach. For other editors, the proposed feature would increase their productivity and willingness to go through their watchlists. Dexxor (talk) 10:31, 6 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 09:11, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:14, 6 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 17:11, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:40, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 18:06, 7 February 2022 (UTC)
  •   Support Rots61 (talk) 23:32, 8 February 2022 (UTC)
  •   Support KnowledgeablePersona (talk) 23:47, 8 February 2022 (UTC)
  •   Support Prawdziwy Mikołajek (talk) 17:46, 9 February 2022 (UTC)
  •   Support ~Cybularny Speak? 23:42, 9 February 2022 (UTC)
  •   Support Quiddity (talk) 09:13, 10 February 2022 (UTC)

Temporarily unwatch a page for a set period of time

  • Problem: Occasionally pages that are rarely edited become news items and see large scale editing (e.g. due to the death of the subject). This causes the watchlist to get swamped, and means changes to other pages may get missed. A user may want to stop watching that page for a time until the page has stabilised.
  • Proposed solution: Allow individual pages to be unwatched for a selected length of time.
  • Who would benefit: Users who watch a lot of pages
  • More comments: This is the reverse of watchlist expiry that was implemented recently.
  • Phabricator tickets: phab:T299227
  • Proposer: Voice of Clam (talk) 18:45, 12 January 2022 (UTC)

Discussion

I created phab:T299227 for this. — xaosflux Talk 15:49, 14 January 2022 (UTC)

  • If you don't want to watch a page when it gets really busy, why are you watching it at all? That just doesn't make any sense to me. SpinningSpark 10:08, 5 February 2022 (UTC)
    @Spinningspark: Personal preference. I have my watchlist set to view all changes, not just the latest, so if a page receives a large number of edits, it floods my watchlist and I may miss changes to other pages. If a page is undergoing a large number of edits in a short time then any vandalism will be picked up quickly even if I'm not watching it. Voice of Clam (talk) 08:17, 8 February 2022 (UTC)
    That's how I have my watchlist set too. If a page is really busy, that means more has been written on it and I am more interested in reading it rather than less. If you are only interested in vandalism you have better options for filtering your watchlist than entirely turning it off. There are filters for likely, and very likely to have problems. Or you can highlight those categories as an option in your preferences. An article is just as likely to be vandalised while it is being actively improved/expanded as at any other time. More so in fact; the increased activity may well be because the subject has been in the news recently in which case it will be a magnet for vandals and trolls. You're concerned about missing changes, so you turn off a page with lots of changes. That's just illogical, as is relying on other editors to spot any vandalism. Those editors are not looking for vandalism, they are writing improvements. You are the one looking for vandalism but you have just shut your eyes to it. SpinningSpark 13:45, 8 February 2022 (UTC)

Voting

  •   Support I have had to do this several times when I've had to manually unwatch and rewatch a page. This would be beneficial in my book. Dolotta (talk) 19:53, 28 January 2022 (UTC)
  •   Support — Draceane talkcontrib. 22:16, 28 January 2022 (UTC)
  •   Support Izno (talk) 00:06, 29 January 2022 (UTC)
  •   Support as proposer. Voice of Clam (talk) 08:38, 29 January 2022 (UTC)
  •   Support Lone Warrior 007 (talk) 10:14, 29 January 2022 (UTC)
  •   Support Arado Ar 196 (talk) 10:44, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:21, 29 January 2022 (UTC)
  •   SupportOmnilaika02 (talk) 19:53, 29 January 2022 (UTC)
  •   Support Agus Damanik (talk) 01:49, 30 January 2022 (UTC)
  •   SupportKitrsjlhf (talk) 05:33, 30 January 2022 (UTC)
  •   Support TheInternetGnome (talk) 08:33, 30 January 2022 (UTC)
  •   Support JPxG (talk) 01:01, 31 January 2022 (UTC)
  •   Support Dreamy Jazz talk to me | enwiki 14:55, 31 January 2022 (UTC)
  •   Support IAmChaos (talk) 21:47, 31 January 2022 (UTC)
  •   Support Temporary unblock, removal of rights, etc. should be getting in Thingofme (talk) 10:27, 2 February 2022 (UTC)
  •   Support EN-Jungwon 10:37, 3 February 2022 (UTC)
  •   Oppose Not seeing the point of this. SpinningSpark 10:09, 5 February 2022 (UTC)
  •   Support I don't think I'd need or use this, but I can see how other people would. Better to make some fixed time lengths available so you don't forget to rewatch it. Daniel Case (talk) 19:38, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:48, 6 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 09:11, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:15, 6 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 17:11, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:42, 7 February 2022 (UTC)
  •   Support Agreed, I could see potential uses for this, at least occasionally. paul2520 (talk) 18:59, 7 February 2022 (UTC)
  •   Support Heanor (talk) 13:31, 8 February 2022 (UTC)
  •   SupportDaxServer (t · c) 14:59, 9 February 2022 (UTC)
  •   Support Wikiusuarios (talk) 20:22, 10 February 2022 (UTC)

View diffs in the Watchlist

  • Problem: Users have to visit the page of a diff in order to view it.
  • Proposed solution: Provide an expandable container option for a change in the watchlist that shows the changes made (the diff) inside of it.
  • Who would benefit: All editors of MediaWiki wikis
  • More comments: Also proposed for the Community Wishlist Survey 2015
  • Phabricator tickets: phab:T120775
  • Proposer: Sea Cow (talk) 18:41, 11 January 2022 (UTC)

Discussion

  • @Lectrician1, I believe that Instant Diffs gadget is exactly what are you looking for. — putnik 18:58, 11 January 2022 (UTC)
    @Putnik As the linked phabricator ticket describes, I would like to have it natively added to MediaWiki so that users immediately can have it at their disposal and do not have to install a userscript that is only available in Russian and English. Also so that users on wikis outside of Wikimedia can easily take advantage of it. Lectrician1 (talk) 19:04, 11 January 2022 (UTC)
  • There are a number of user scripts that already do this. Making it default I think would be a good idea unless there is some reason not too such as load. -- GreenC (talk) 20:00, 12 January 2022 (UTC)
  • (Advertisement) Another useful script that helps viewing diffs instantly: QuickDiff. NguoiDungKhongDinhDanh 15:38, 29 January 2022 (UTC)
    As well as, of course, navigation popups. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:19, 11 February 2022 (UTC)
  • How would this affect the marking of the diff as visited? Depending on how the editor works, this may or may not be desirable to happen. SpinningSpark 10:01, 5 February 2022 (UTC)
    @Spinningspark Well then I guess we should build in a configuration option to mark diffs as read or not when you open them from the Watchlist.
    We should also probably have a way to manually change a diff to read or not read from the Watchlist as well. Lectrician1 (talk) 15:47, 5 February 2022 (UTC)

Voting

Allow diffs to be marked as unvisited

  • Problem: On occasions, an edit is made that appears to be good faith, but I want to check it more thoroughly, either when I have more time or better access to sources. However as diffs are automatically marked as visited when I view them, it is not currently possible to keep it flagged to remind me to review it later.
  • Proposed solution: When a diff is viewed on a page that is in a watchlist, allow a method of marking the diff as unvisited/unread.
  • Who would benefit: All editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Voice of Clam (talk) 09:31, 16 January 2022 (UTC)

Discussion

  • +1, I need this! Thanks for the proposal. — Draceane talkcontrib. 16:02, 17 January 2022 (UTC)
  • I think it makes more sense just to open the diff in a new tab if you want to revisit it. --Izno (talk) 19:00, 17 January 2022 (UTC)
    • That still marks the diff as visited. Voice of Clam (talk) 19:03, 17 January 2022 (UTC)
      Why do you need to care if the diff is or is not visited if the diff to be consumed is on another tab (or window, however you want to organize things)? Izno (talk) 19:24, 17 January 2022 (UTC)
      Because it may be some time before I can properly review the diff (e.g. I'm away from home, and I don't have access to a reference book), and I don't want to fill my browser with open tabs for that period of time. No different to marking an email as unread if it needs further action later. Voice of Clam (talk) 19:47, 17 January 2022 (UTC)
      The difference is that this is a team made to resolve volunteer wishes and Outlook/Gmail are not. ;) I definitely know what my priority will be when we get to voting if it's an issue for you of "I don't want to have tabs open". Izno (talk) 06:32, 18 January 2022 (UTC)
      Yes, doing that is part of the reason I have hundreds of open tabs everywhere. ~~~~
      User:1234qwer1234qwer4 (talk)
      23:22, 11 February 2022 (UTC)
  • A decade ago I created Special:ApiHelp/setnotificationtimestamp with the idea of making a user script to do something like this. I never got around to writing the script though. Anomie (talk) 23:20, 28 January 2022 (UTC)
  • Are you talking about the watchlist's last visit timestamp feature (ie. bolding)? The browser's CSS styling for visited links? Patrolling? Something else? --Tgr (talk) 00:32, 30 January 2022 (UTC)
  • Seems reasonably helpful, though maybe less so for people using email watchlist notifications, which can be marked as unread. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:24, 11 February 2022 (UTC)

Voting

More specificity on the last edit indicated

  • Problem: Currently watchlists show only the very last edit made on an article. Without going to look at the history, there is no way of knowing whether this was an isolated edit or the last in a series of edits by the same user (i.e., major changes or expansion), or the latest salvo in an edit war you had no idea was happening.
  • Proposed solution: Change "Expand watchlist to show all changes" to include an optional indicator that this was the last edit of X by User:ABC and allow a dropdown click to review all the edits made in that sequence (i.e., byte counts and edit summaries). It could also be highlighted, by user preference, if the edit is part of a sequence of reverts of an edit that is the same or substantially the same, i.e. as a possible edit war. And there are other possibilities.
  • Who would benefit: Users who work to keep articles stable and at a certain level of quality. And by extension the whole community
  • More comments: I think this would be of overall benefit to the community by making it easier to respond more quickly to vandalism and disruptive editing, and perhaps minimize the drama that breaks out when one user has just made major changes to the article that another had some time before spent a great deal of time developing.
  • Phabricator tickets:
  • Proposer: Daniel Case (talk) 05:57, 11 January 2022 (UTC)

Discussion

Just enable "Expand watchlist to show all changes, not just the most recent" in the preferences. Jon Harald Søby (talk) 09:46, 11 January 2022 (UTC)

Oooh, thanks for that tip, I've been wondering about that for a long time! ArthurPSmith (talk) 19:32, 11 January 2022 (UTC)
Only problem is that that function displays the edits in a random order unless you expand each line, so you can't see if, for example, the vanalism-reverting bot had the last word or not. -- Ahecht (TALK
PAGE
) 23:26, 11 January 2022 (UTC)
Having just tried it, I would refine my suggestion to be that it be made smarter: i.e., tell you if a series of edits since the last one have added/removed a lot, tell you if there's an ongoing edit war/AV bot reversions, and keep the watchlist readable by allowing you to expand the edits for individual articles if you'd like to see what they were. Daniel Case (talk) 03:02, 12 January 2022‎ (UTC)
@Daniel Case Hello there and hope you are well :) Focusing on the problem, not solution: it sounds like on your Watchlist, you want to be able to easily see how many changes there were to a page, by how many users, and if the end result was the same (meaning some sort of edit war or back-and-forth). Is that correct? This would be with the "Expand watchlist to show all changes" preference on. We have a little more room to work with there. I could envision say, an icon (defined in the legend at the top-right) next to the number of changes, indicating no content changes were made in that group of edits (and thus, there was an edit war). Something like that? MusikAnimal (WMF) (talk) 04:57, 22 January 2022 (UTC)
@MusikAnimal (WMF): Yes, something like that, with maybe an indicator of whether there were any reverts in the series, or whether any large amount of bytes was involved. Daniel Case (talk) 05:00, 22 January 2022 (UTC)
Sounds good! I think we're on the same page now :) Feel free to update the proposal to focus on adding these features to the "Expand watchlist to show all changes" feature. I'll be back in a few days and can help clean it up more if needed. Thanks and warm regards, MusikAnimal (WMF) (talk) 05:04, 22 January 2022 (UTC)
  Done Daniel Case (talk) 20:26, 27 January 2022 (UTC)
  • I understand this problem, and support doing work on it, but I think a much more straightforward system would be to group watchlist results by page edited. The latest edit to the page would be fairly self-evident without special marking. It's not possible to tell what the owner of the watchlist is looking for so grouping/marking by editor, size of edit, etc may not be useful to a particular editor and may actually be counterproductive. I would like the group containing the oldest edit to be listed last so that the oldest edit did not continually get bumped to the top of the list by new edits. SpinningSpark 09:55, 5 February 2022 (UTC)
  • It seems that the proposed way of displaying changes is the one currently used at Special:GlobalWatchlist. ~~~~
    User:1234qwer1234qwer4 (talk)
    22:37, 11 February 2022 (UTC)

Voting

  •   Support * Pppery * it has begun 18:55, 28 January 2022 (UTC)
  •   Support KylieTastic (talk) 19:57, 28 January 2022 (UTC)
  •   Support Liaskian (talk) 20:47, 28 January 2022 (UTC)
  •   Support — Draceane talkcontrib. 22:15, 28 January 2022 (UTC)
  •   Support Betseg (talk) 02:23, 29 January 2022 (UTC)
  •   Support BSMIsEditing (talk) 15:19, 29 January 2022 (UTC)
  •   Support Piensaimnieks (talk) 15:20, 29 January 2022 (UTC)
  •   Support Edits being missed because only the most recent ones get shown is a massive problem (e.g. someone does something disruptive but no-one notices because an hour later someone else came and fixed a typo, or a new talk page thread gets missed because posting it triggered the bot that does the archiving, etc). I support making "Expand watchlist to show all changes" the default option for everyone. Now, there are some existing functionalities that are really helpful in certain situations (like the "Reverted" tag), but the proposed new features will be a lot more universally useful. Uanfala (talk) 01:06, 30 January 2022 (UTC)
  •   Support Agus Damanik (talk) 01:51, 30 January 2022 (UTC)
  •   Support JPxG (talk) 01:02, 31 January 2022 (UTC)
  •   Support -- Ahecht (TALK
    PAGE
    ) 18:37, 31 January 2022 (UTC)
  •   Support Shooterwalker (talk) 22:15, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 10:30, 2 February 2022 (UTC)
  •   Support Pi.1415926535 (talk) 22:13, 4 February 2022 (UTC)
  •   Support Neriahtalk • 20:41, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:47, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:10, 6 February 2022 (UTC)
  •   Support Nabla (talk) 19:32, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:43, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 18:08, 7 February 2022 (UTC)
  •   Support KnowledgeablePersona (talk) 23:46, 8 February 2022 (UTC)

Grouping watched pages

  • Problem: Everyone watches different pages for different reasons – some are noticeboards, some are projects to do, and some are watched for vandalism or sockpuppetry, however people with large watchlists can often forget why they watch a page. To use myself as an example, I primarily work countering spam, and many recurring sockmasters edit a large number of pages (which I watch), making it difficult to remember why I have a certain page watched, and for which sockmaster.
  • Proposed solution: Create a method of allowing the user to create and name watchlist groups (very similar to how filters can be created at Special:RecentChanges.) When a page is watched, there could be an option to add it to a watchlist group, similar to how you can select the duration of time to watch a page. Ideally, the user should also be able to filter their watchlist by group, and possibly assign different groups colors.
  • Who would benefit: Most Wikimedia users, especially anyone with a large watchlist.
  • More comments: I'm not massively familiar with MediaWiki, but I imagine it would involve re-purposing a lot of code from RecentChanges, especially bits surrounding the filter mechanisms.
  • Phabricator tickets:
  • Proposer: Giraffer (talk) 23:11, 14 January 2022 (UTC)

Discussion

A similar proposal to Community Wishlist Survey 2021/Watchlists#Large watchlist access 2A00:23C4:E845:5B00:24AF:C351:D079:6898 01:19, 15 January 2022 (UTC)

Thanks for sharing, I hadn't seen that. I'm not proposing splitting up a watchlist or creating numerous ones, but adding the ability to "categorize" pages within it and sort by them. Giraffer (talk) 10:34, 15 January 2022 (UTC)
  • This should be much simpler to deal with than previous requests; the work is to be done by the user themselves, putting things in the categoriesa thewy want. The basic operation of the watchlists can go on the usual way. -- if I understand this correctlyDGG (talk) 05:40, 16 January 2022 (UTC)
  • Special:RecentChangesLinked continues to exist for this use case. --Izno (talk) 19:01, 17 January 2022 (UTC)
Maybe even more similar to Community Wishlist Survey 2021/Watchlists/Multiple watchlists. ~~~~
User:1234qwer1234qwer4 (talk)
12:05, 30 January 2022 (UTC)

Voting

Expiring temporary watchlist

  • Problem: When using the watchlist expiry feature, pages are removed from your watchlist automatically without notification.
  • Proposed solution: Create an optional watchlist notification when the page is being removed from the watchlist
  • Who would benefit: Editors who have expiring pages on their watchlists
  • More comments: Sometimes you misjudge just how long you need to be watching a page and it be removed from your watchlist without you realizing. An option to see when the time has expired would let editors know this has happened and be able to make a decision (do nothing or visit the page and watch it again).
  • Phabricator tickets:
  • Proposer: Barkeep49 (talk) 18:21, 13 January 2022 (UTC)

Discussion

  • I'd like to comment that the lack of a notification was by design. But the popularity of this proposal can change that ;) In case you weren't aware, there are a few ways to see the expiry: Expiring watchlist items are listed first at Special:EditWatchlist and show the expiry time. You can also hover over the half-star (or watchlist link) on a page, and that will say how many days are left. The same is true with the clock icon shown next to temporarily watched pages at Special:Watchlist. Finally, it's displayed on the edit screen next to the "Watch this page" checkbox. I kind of worry about using Echo notifications as you suggest, as depending on your workflow (i.e. Twinkle settings), you could have MANY and it would quickly become too spammy. Better I suppose would be for you to opt into notifications only for specific pages, but that complicates the UX. Anyway, your problem statement is clear, and that's the important part. We can figure out the solution later :) MusikAnimal (WMF) (talk) 19:02, 13 January 2022 (UTC)
    All of your suggestions require checking the watchlist or specific pages, which will only help if the page has not been automatically unwatched yet. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:26, 11 February 2022 (UTC)
  • Good suggestion; the lack of notifications is probably why I have not used watchlist expiries so far. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:27, 11 February 2022 (UTC)
  • Support if it's optional and selectable on a per-page basis, otherwise an hour of Twinkle work could get you >50 notifications that same hour the following week. Giraffer (talk) 18:01, 11 February 2022 (UTC)

Voting

  •   Support I never temporarily watch a page for I fear that I might want to continue watching the page later than what I have selected and I will forget about extending the watch period. This leads me to not watch many pages in the first place to keep down the size of my watchlist. Having a notification for when an expiry occurs can help me temporarily watch something and evaluate whether I need to continue watching it after a period of time. Lectrician1 (talk) 01:01, 29 January 2022 (UTC)
  •   Support Curios7ty (talk) 08:57, 29 January 2022 (UTC)
  •   SupportBilorv (talk) 11:29, 30 January 2022 (UTC)
  •   Support IAmChaos (talk) 21:46, 31 January 2022 (UTC)
  •   Support Shooterwalker (talk) 22:15, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 10:29, 2 February 2022 (UTC)
  •   Support Vega (talk) 18:35, 3 February 2022 (UTC)
  •   Support ·addshore· talk to me! 23:02, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 00:24, 5 February 2022 (UTC)
  •   Support MONUMENTA (talk) 02:54, 5 February 2022 (UTC)
  •   Support I would like this. Daniel Case (talk) 19:37, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:46, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:15, 6 February 2022 (UTC)
  •   SupportThanks for the fish! talkcontrib (he/him) 17:11, 6 February 2022 (UTC)
  •   Support Nabla (talk) 19:36, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:45, 7 February 2022 (UTC)
  •   Support //Lollipoplollipoplollipop::talk 11:33, 7 February 2022 (UTC)
  •   Support Nave do Conhecimento (talk) 12:03, 7 February 2022 (UTC)
  •   Support Prawdziwy Mikołajek (talk) 17:47, 9 February 2022 (UTC)
  •   Support Barkeep49 (talk) 20:55, 10 February 2022 (UTC)

Preference to set default watchlist expiry

  • Problem: I want every page I edit to be added to my watchlist for a limited time, so I can see what kinds of follow-up changes other users may make in reaction to my edit. Because my edits are generally maintenance-related in nature, I edit a wide range of pages, and have no interest in edits that are made months or years later.
  • Proposed solution: In the Watchlist page of preferences, provide an expiry dropdown next to "Add pages and files I edit to my watchlist", "Add pages and files I move to my watchlist", and each subsequent checkbox in that section, so that a default watchlist expiry time can be set. This default expiry only applies to (a) pages that are currently unwatched, and (b) pages whose watchlist expiry will expire before the default period I set in my preferences (e.g. if the page will leave my watchlist in 2 days, but my preferences stipulate a default expiry of 7 days, the page's watch expiry will be extended to 7 days).
  • Who would benefit: Wikignomes (those who mainly perform maintenance edits across a wide variety of pages)
  • More comments: The amount of development work involved is low. It probably would take an experienced MediaWiki developer 1 or 2 days (not including any design required).
  • Phabricator tickets: phab:T265716
  • Proposer: This, that and the other (talk) 04:45, 15 January 2022 (UTC)

Discussion

I came here to propose precisely this idea for the same reason. I was surprised to see that the expiration option did exist but only if set manually, not as part of the watchlist preferences. I hope this gets more attention in the near future as it would greatly help users who mostly do maintenance edits. - Klein Muçi (talk) 00:29, 20 January 2022 (UTC)

Would have supported if I had known voting ended at 18 UTC. ~~~~
User:1234qwer1234qwer4 (talk)
23:20, 11 February 2022 (UTC)
en:User:Rummskartoffel/auto-watchlist-expiry.js offers a workaround on English Wikipedia. Certes (talk) 20:15, 21 February 2022 (UTC)

Voting

Make Special:GlobalWatchlist more discoverable

Discussion

  • It's hard, and the global watchlist links can be accessed through meta-wiki. Thingofme (talk) 17:04, 22 January 2022 (UTC)
    why do you think it is hard? Special:GlobalPreferences and Special:CentralAuth can already be accessed through Special:Preferences on every wiki. Why not make the same for Special:GlobalWatchlist? Heanor (talk) 21:32, 22 January 2022 (UTC)
  • This is my provisional solution (global.js):
    if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Watchlist' ) {
    	mw.loader.using( [ 'mediawiki.util' ] ).then( function () {
    		mw.util.addPortletLink(
    			'p-views',
    			'//meta.wikimedia.org/wiki/Special:GlobalWatchlist',
    			'Global watchlist',
    			'',
    			'Global watchlist'
    		);
    	} );
    }
    
  • --Matěj Suchánek (talk) 11:38, 23 January 2022 (UTC)
    Good, works for me! But maybe not enough. But definitely should be implemented for all registered users by default. Heanor (talk) 15:12, 23 January 2022 (UTC)
  • Hi. I'm the developer of the GlobalWatchlist extension and still have some grant money to work on it, but help from Community Tech would be appreciated and I would be happy to coordinate with them if they are willing to review. I haven't work on it yet since I wasn't clear how it should appear from a design perspective though. --DannyS712 (talk) 03:12, 3 February 2022 (UTC)

Voting

Pattern matching article titles

  • Problem: There is no easy way to watchlist many similar pages at once, other than adding all of them individually to your watchlist. For example, if I want to watchlist all editions of the Eurovision Song Contest, I'd have to add all 67 of them as well as every new article when it gets created. You can watchlist categories and notice when a new page is added, but that only works if people categorise new pages the way you would expect, and you also still then have to manually add it to your watchlist.
  • Proposed solution: Introduce a new Special:BulkWatchPages which allows you to watch items by regular expression (with some sane limit), and perhaps other options such as a category. In the example above, the regular expression could be Eurovision Song Contest \d+. Or for templates with subpages, Template:Example(/.*)?. For technical reasons, this would watch every page as if you watched them individually, as opposed to grouping all these pages together as one "watched item". There could also be a Special:BulkUnwatchPages special page so you can un-watch them in bulk, however.
  • Who would benefit: All editors, especially those who often check other people's edits
  • More comments:
  • Phabricator tickets:
  • Proposer: Jochem van Hees (talk) 15:07, 11 January 2022 (UTC)

Discussion

  • I proposed quite similar Community Wishlist Survey 2017/Watchlists/Automatically watch pages containing specific string in 2017, also Community Wishlist Survey 2017/Watchlists/Watchlist created on categories is from 2017. So I still agree this would be useful. Stryn (talk) 15:31, 11 January 2022 (UTC)
  • This sounds a lot like phab:T27372, declined in 2018. — xaosflux Talk 14:33, 12 January 2022 (UTC)
    A gadget could be built to do this. Izno (talk) 19:05, 17 January 2022 (UTC)
  • I think being able to add a pattern to a watchlist, as if it were itself a "watched item", is not going to scale and is a firm no. However, similar to what I brought up on the cascade-watching wish, we could offer a new special page like Special:BulkWatchPages where you can bulk watch pages (probably up to some limit) based on some parameters such as a regular expression or pattern. You would not be able to unwatch all of those page in one go, however, since there's no concept of relationships between watched items. That said, would the Special:BulkWatchPages idea still be better than nothing, Jochem van Hees? If not, I'm afraid this proposal is out of scope for Community Tech, and we can offer to put this in our Larger suggestions pile or archive it. Thanks, MusikAnimal (WMF) (talk) 22:58, 19 January 2022 (UTC)
    @MusikAnimal (WMF), you can easily bulk-watch a given list of pages from special:EditWatchlist/raw. Is your proposed special page supposed to generate such lists? Using a list generator like PetScan or Quarry and copying that over two the raw watchlist editor seems like a more efficient solution to me. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:37, 11 February 2022 (UTC)
  • @Jochem van Hees: Hello and thanks for taking the time to write this proposal. We are archiving this wish due to a lack of clarification. We needed clarification so that we could accept this wish and mark it for translation so that it could go into voting. Thanks again! Regards, DMaza (WMF) (talk) 13:49, 26 January 2022 (UTC)
    @DMaza (WMF): sorry, I should have replied sooner. Personally I'd be fine with any way this is implemented, and your Special:BulkWatchPages idea sounds to me like it could do the job, so I'd be happy to change the proposal to that. Thanks for taking the time! Jochem van Hees (talk) 17:45, 27 January 2022 (UTC)
    No worries. With your approval, I've reworded the proposal to fit what we believe is more in scope and feasible, and have unarchived the proposal. I still have some concerns about people misusing Special:BulkWatchPages tool and watching way too many pages, but we'll worry about that later :) Thanks for replying and participating in the survey! MusikAnimal (WMF) (talk) 22:03, 27 January 2022 (UTC)
  • I have the same issue as OP with Elections. SSneg (talk) 21:22, 29 January 2022 (UTC)

Voting

  •   Support Lectrician1 (talk) 23:36, 28 January 2022 (UTC)
  •   Support --SSneg (talk) 21:21, 29 January 2022 (UTC)
  •   Support: an upper limit of 200 pages or so to watch simultaneously, and a preview - "You are about to add X pages to your watchlist, as follows: [list]. Please confirm this is correct" - would massively limit the damage of accidental mistakes. Note also that you could bulk unwatch pages by the same conditions as bulk watching (without any parametised relationship between watched items). — Bilorv (talk) 11:28, 30 January 2022 (UTC)
  •   Support Stryn (talk) 17:11, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:49, 30 January 2022 (UTC)
  •   Support JPxG (talk) 01:02, 31 January 2022 (UTC)
  •   Support the wub "?!" 15:04, 31 January 2022 (UTC)
  •   Support Thingofme (talk) 10:26, 2 February 2022 (UTC)
  •   Support Jolly1253 (talk) 12:15, 2 February 2022 (UTC)
  •   Support Aimwin66166 (talk) 06:03, 3 February 2022 (UTC)
  •   Support - Darwin Ahoy! 19:38, 4 February 2022 (UTC)
  •   Support MONUMENTA (talk) 02:53, 5 February 2022 (UTC)
  •   Support. Alexcalamaro (talk) 11:55, 5 February 2022 (UTC)
  •   Support Again, something I wouldn't use at present but I do see how it might be convenient or necessary. Daniel Case (talk) 19:42, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 02:49, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:09, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:57, 7 February 2022 (UTC)
  •   Support Tom Ja (talk) 18:06, 7 February 2022 (UTC)
  •   Support Rots61 (talk) 23:27, 8 February 2022 (UTC)
  •   Support Quiddity (talk) 09:14, 10 February 2022 (UTC)