Community Wishlist Survey 2019/Watchlists

From Meta, a Wikimedia project coordination wiki
Watchlists
12 proposals, 221 contributors, 391 support votes
The survey has closed. Thanks for your participation :)



Editable Page Link Notifications watchlist

  • Problem: In one's preferences, under 'Notifications', one has the option of turning on or off 'Page link' notifications. This will notify one when someone links to a page they created from another page. However, this option is all or nothing. Currently one cannot change the list to remove pages they do not wish to monitor or add pages one did not create. Editors who move pages are especially affected.
  • Who would benefit: Most editors
  • Proposed solution: The list of pages that prompt notifications should be editable like the standard watchlist. Users would still be able to turn off all page link notifications as they do now as well.
  • More comments:

Discussion

@NessieVL: Is this phab:T46787? --AKlapper (WMF) (talk) 03:42, 1 November 2018 (UTC)[reply]

@AKlapper (WMF): I think phab:T66090 is closer to my idea. Looks like there are a few ways to get there. phab:T70060#2166931 is also a good way. I just asssumed there is a reason link notices are divorced from the main watchlist.

Voting

Watchlists based on Wikidata statements

Discussion

But I agree it would be nice to be able to get lists of changes across all Wikipedias. Jheald (talk) 15:48, 9 November 2018 (UTC)[reply]

Voting

Automatically add subpages in the watchlist

  • Problem: On several wiki, the archives of community discussions are structured as "Commons:Village pump/ArchiveYYYY/MM" (this is an example with Commons but this is the same idea on other projects and languages). Not talking about archives, some community discussions are stuctured this way: "Wiktionnaire:Questions_techniques/MM_YYYY" which means there is a new page to watch each month. This leads to the creation of such list.
  • Who would benefit: every contributor who watch community discussion pages that use subpages. It will allow to see a change in an archived discussion.
  • Proposed solution: Mediawiki should offer a new button next to the "Watch this page" button. This new button would be "Watch this page and all subpages". Clicking on such button, if a contributor chooses to watch Wiki:XXX, then all subpages are automatically added to the watchlist Wiki:XXXX/aaa, Wiki:XXXX/bbb, Wiki:XXXX/cccc, ... When one subpage is created, it is automatically added to the watchlist of user who watch this main page.
  • More comments: I think one should allow users to be able to remove subpages individually from their watchlists. For exemple, if one watches Wiki:XXXX, then Wiki:XXXX/aaa and Wiki:XXXX/bbbb are automatically added to the watchlist. Yet, one should be able to remove manually Wiki:XXXX/aaa.
  • Phabricator tickets:

Discussion

Voting

Ability to remove/mute page when viewing watchlist without permanently removing from watchlist

  • Problem: Sometimes a particular page (or related pages) will have a high number of edits and overwhelm the revisions shown on the watchlist page. In some cases, it's because I've edited an article that is related to a current event. In some cases, it's a talk page that is getting a lot of edits to a proposed policy, which I can just view the page in a new tab and read the entire discussion (no need to view every edit). This is really annoying. Currently, I work around this issue by opening the page in a new tab, clicking the star to remove the page from my watchlist and then when I'm done browsing my watchlist, click the star to re-add the page. I haven't been very active on Wikipedia for the past 12-18 months, but regularly log in to view my watchlist (which has 1776 pages). I have the maximum 500 edits and 30 days selected, but at the time of writing this, it only goes back 72 hours (almost to the minute). w:Lion Air Flight 610 (a plane that crashed a week ago with 189 on board) and its talk page appear 101 times, a talk page with a lengthy proposal discussion appears 41 times, and a couple pages that were subject to vandalism edits & revert appear 17 & 18 times...together that's over 1/3 of my watchlist page consisting of edits to 5 pages! If a page has been edited numerous times, I can just go to the edit history and compare revisions. It would be nice if there was a way to remove pages from appearing in watchlist edits (the page you get by clicking "watchlist" in the upper right and shows edits to watchlist pages) without permanently removing them from the watchlist (the list of articles that are checked for recent edits). I'll refer to this as "muting" a page in the watchlist.
  • Who would benefit: Editors with watchlists that contain a lot of guideline/policy talk pages that can be subject to a lot of editing over a short period (usually related to a proposal) or contain pages related to topics that are in the news. It would also benefit editors with large watchlists who don't log in every day and would like to see more edits appear on the watchlist page.
  • Proposed solution: Have an unobtrusive button—like how "(diff|hist)" links appear on the watchlist or the "thank" button appears on the diff page—that would allow the page to be muted. After that button is clicked, you would be presented with options on how long you'd like to mute the page: just while currently browsing the watchlist (labeled "just once"), while logged in, 12 hours, 24 hours, 48 hours, a week (would be useful length for pages in the news...you'd know what they are and can visit them without going through the watchlist). This would work like the give thanks button on the diff page, where "(thank)" expands to "Publicly send thanks? Thank Cancel". In this case "(mute)" would be added to each line would expand to "Mute [just once] [while logged in] [12h] [24h] [1 week]" (I used brackets to indicate separate buttons). After selecting your choice, it the entire line for the edit entry would be replaced with "You have muted [Page name] for [duration]. Change?", which gives editors an easy way to change the duration if they accidentally clicked the wrong duration. A specific duration could be set in preferences to be applied every time, possibly with a button or prompt after clicking to allow you to change the length once.
Here's how that would look:
  • (diff | hist) . . Lion Air Flight 610; 23:35 . . (-324) . . 125.165.174.88 (talk) (→Passengers and crew) (Tag: references removed)(mute)
  • (diff | hist) . . Lion Air Flight 610; 23:35 . . (-324) . . 125.165.174.88 (talk) (→Passengers and crew) (Tag: references removed) (Mute [just once] [while logged in] [12h] [24h] [1 week])
After selecting the duration, the line entry where you have selected the mute will be replaced with the following line and other edits to that same page will disappear from the watchlist page you are viewing:
  • You have muted the page Lion Air Flight 610 for one week. Change?
If you really wanted to be fancy, you could have "custom" at the end of the options that would create a popup (not as in a separate window in you browser, but just graphically overlaid on the page) with a dropdown for numbers or a box to enter digits and a dropdown with "hours", "days", "weeks", and "months". A reasonable maximum (2 months?) should be added to prevent unintended muting for long periods. Also, a reminder should be added to the top of the watchlist page when you subsequently visit it: "X pages in your watchlist are currently muted. View list" Clicking on it would reveal a list of pages and durations with a button "end" to end the muting.
  • More comments: I think I've come across a discussion about this before (not this exact proposal, but temporarily removing pages from a watchlist), probably on the Wikipedia village pump.
  • Phabricator tickets:
  • Proposer: AHeneen (talk) 07:54, 6 November 2018 (UTC)[reply]

Discussion

Note: There must be somewhere list of my muted pages, where I can manually unmute them. Maybe as new section on Special:EditWatchlist. JAn Dudík (talk) 13:28, 6 November 2018 (UTC)[reply]

Voting

Mobile web watchlist should only show latest revision of each page

  • Problem: When we click on watchlist in mobile web view, the watchlist shows every single edit of every watched page, rather than the latest edit of each watched page (default behaviour of desktop watchlist). So, pages with frequent edits drown out the rest of the watchlist.
  • Who would benefit: Everybody who uses mobile web view
  • Proposed solution: Implement the same default behaviour as desktop watchlist: only show the latest edit of each watched page.

Discussion

I would also love this! I don't know why it is not implemented yet. The division by UTC day seems really arbitrary. --Ita140188 (talk) 22:20, 30 October 2018 (UTC)[reply]
The mw:Reading/Web/Advanced_mobile_contributions project could fullfil this wish, provided enough users give feedback that fixing this is important. Jdlrobson (talk) 23:06, 1 November 2018 (UTC)[reply]
  • The wording of proposal is confusing: it's not so much "should only show last revision of each page", rather "should group together all the day's edits for each page". PamD (talk) 23:30, 16 November 2018 (UTC)[reply]

Voting

Watchlist item expiration

  • Problem: My watchlist combines a few pages which I want to watch permanently with thousands of entries which I only wanted to monitor for a few days after a one-off edit. The two types are mixed together with no distinction. Removing pages which were of temporary interest is tedious and error-prone.
  • Who would benefit: Editors who want to monitor revisions to a page in the near future, without it cluttering up the watchlist permanently. This especially benefits "gnomes" who make minor changes to many pages.
  • Proposed solution: Introduce an optional expiry date on watchlist entries. Remove expired entries from watchlists before displaying them. Make the default expiry date "forever", so the change only affects editors who opt in.
  • More comments: The edit dialogue could have a "watch for a day/week/month" option. Allow editors to make this their default on an opt-in basis.
  • Phabricator tickets: T124752, T100508, T8964
  • Proposer: Certes (talk) 13:59, 7 November 2018 (UTC)[reply]

Discussion

  • This is a variation on the Watchlist Expiry idea, which has been much discussed and debated over the years. See T124752 T100508 T8964. It was a 2016 project of the German wishlist team, and it looks like they made progress in terms of adding required fields to the back-end Watchlist data table. But I'm not sure what the progress was after that, or why the process stalled if it did. I'm pinging Birgit Müller (WMDE) and Lea Voget (WMDE), who should be able to fill us in on where this effort stands and what the level of difficulty going forward would be. —JMatazzoni (WMF) (talk) 19:00, 7 November 2018 (UTC)[reply]
    • So we did take the biggest hurdles, which was refactoring all the necessary code and adding the required fields to the database table. What is left to do is implementing the actual feature. This should not be hard in itself, the complexity comes more from making this work with other ideas for the watchlist (although I am not sure if there are currently any other plans). Currently,no work on this wish is scheduled. The reason why we stopped our work was that it took over a year for the database fields to be added, and we had thus many more things on our TODO-list when they were finally there. --Lea Voget (WMDE) (talk) 12:36, 9 November 2018 (UTC)[reply]
  • When working on this problem for the 2013 German wishlist, an alternative was proposed: we could allow watchlist entries to be listed by the date they were added, and give users a way to remove old entries by selecting them from the filtered view. There is a recent RFC that proposes a similar feature, see phab:T209773. -- DKinzler (WMF) (talk) 21:48, 29 November 2018 (UTC)[reply]

Voting

AfD/prod flags in Wikipedia watchlist

  • Problem: When articles are tagged for deletion, it is not always obvious to interested editors simply by looking at their watchlist. There may have been subsequent edits, so the latest edit summary doesn't mention deletion, or the nominator may not have indicated the AfD/prod/CSD in their edit summary. It is also difficult for editors nominating articles for deletion to determine all interested editors and to notify them.
  • Who would benefit: All interested editors.
  • Proposed solution: Add flags in the Wikipedia watchlist so that any articles that currently have AfD, prod, or CSD tag on them are highlighted/labelled so that interested editors can easily spot these and take any action that they might wish to (e.g. contesting speedy deletion, deproding, or participating in an AfD discussion).
  • More comments: One of the current proposals at the Village Pump is to require notification of editors when an article is PRODded. This is a more practical and useful solution.
  • Phabricator tickets:
  • Proposer: Michig (talk) 10:44, 4 November 2018 (UTC)[reply]

Discussion

  • This is an elegant solution to a perceived need among regular contributors. Perhaps that's implied in the proposal, but I feel the watchlist should include a filter enabling editors to quickly check if any of their watched articles are under PROD or AfD. Some people watch thousands of articles and won't see the notices in the default "recent changes first" display, but would be happy to perform a weekly check for whatever is considered for deletion this week. JFG (talk) 09:22, 5 November 2018 (UTC)[reply]
  • This can be done by the community today with an EditFilter set to tag. --Izno (talk) 00:56, 6 November 2018 (UTC)[reply]

Voting

Traffic spike notification

  • Problem: To be notified when an article has an unusual spike in page views/traffic. This usually indicates there has been an external news story or event driving traffic to Wikipedia, typically signaling the article needs updating with new information/sources.
Example Graphs
Short spikes in traffic are normal and are usually short-lived (1 day spires see example graphs) These can be safely ignored as anomalous. However when there is a sustained build-up and trailing off, looking more like a mountain than a spire, there is a probable notable external event driving traffic to the article.
  • Who would benefit: Anyone keeping an article up to date
  • Proposed solution: There are three elements. 1) A system for marking which articles to track. Possibly through the watchlist. 2) A system and algorithm for tracking those articles and monitoring for unusual traffic spikes. There might be some custom variables users can set to determine what counts as a traffic spike. 3) Finally a system for notifying users of when a spike occurs. This might be through the watchlist or some other mechanism.
  • Phabricator tickets:

Discussion

Voting

Revive Crosswatch tool

  • Problem:
    Cross-wiki watchlists are nowhere on the horizon. They were proposed in the 2015 survey and made it to the top but could not be implemented. However, a tool called Crosswatch (docs, tool, phab) was developed by a volunteer as part of an internship. The tool was pretty good at displaying watchlists from all wikis. The tool went down about two years ago (task T144083) and has not been revived since.
  • Who would benefit: All power users who use multiple wikis for their work.
  • Proposed solution: Fix the Crosswatch tool.
  • More comments: I suggest fixing the crosswatch tool rather than implementing cross-wiki watchlists in a more efficient way as it's technically easier and hopefully won't be declined.

Discussion

Some of the long history of various crosswiki watchlists (including Crosswatch) is found at :en:Wikipedia:Global, cross-wiki, integrated watchlists. --Timeshifter (talk) 23:09, 1 November 2018 (UTC)[reply]

Voting

View content page or discussion only

  • Problem: Marking a page for the watchlist automatically marks both, content page and discussion. For a limited number of pages, for example the village pump, this could mean a considerable number of changes popping up on the watchlist, and a considerable number of emails received, many of them with toxic or less interesting content. Other situations may exist, where someone wants to follow the discussion only.
  • Who would benefit: Anybody who is interested in watching a content page, but wants to avoid notification of the discussion (or the other way round).
  • Proposed solution: A button or another way to switch off the mark for an individual discussion page, while leaving it intact on the content page (or the other way round).
  • More comments:
  • Phabricator tickets:
  • Proposer: Natalie Freyaldenhoven (talk) 21:59, 30 October 2018 (UTC)[reply]

Discussion

Voting

Improve Wikipedia Watchlist Handling of Wikidata

  • Problem: We use elements from Wikidata within Wikipedia. If those elements are changed we need the ability to only see those changes. Currently if you want to look at Wikidata edits within your Wikipedia watchlists it contains elements not used within the article in question (such as changes to aliases in all languages). For example below in my watchlist you see changes to content that is not used within English Wikipedia and 90% of the Wikidata edits in my English watchlist pertain to other languages.

    Watchlist Wikidata integration issue
    Watchlist Wikidata integration issue
  • Who would benefit: The quality assurance processes at Wikidata and an increased possibility of using Wikidata within Wikipedia.
  • Proposed solution: Only show those items / properties actually used within the Wikipedia article. Nothing more.
  • More comments: User:Ladsgroup accomplished much of this work. Only a few more steps needed to finish.
  • Phabricator tickets:

Discussion

Making wikidata in the watchlist work nicely as above and then setting "Show Wikidata edits in your watchlist" to default enable would greatly help monitoring of wikidata changes and vandalism detection. Galobtter (talk) 08:08, 31 October 2018 (UTC)[reply]
Tagging on to this, I think the Wikidata watchlist notifications are generally hard to decipher, as they rely too much on the P numbers and not the property names. --NessieVL (talk) 16:46, 31 October 2018 (UTC)[reply]
I agree with this last point. Lines like "Mildred Dresselhaus (Q29573) (diff | hist) . . GerardM (discuter | contributions) (Affirmation ajoutée : Property:P166: Q57647862, #quickstatements ; Qualificatif ajouté : Property:P585: 1998, #quickstatements)" are really hard to decipher. Instead of P166 and P585, the property name in the language of the user should be displayed . The same for Q57647862. Pamputt (talk) 12:44, 1 November 2018 (UTC)[reply]
I've put up Community Wishlist Survey 2019/Wikidata/Expand automatic edit summaries to deal with the decipherability issue. Jo-Jo Eumerus (talk, contributions) 09:15, 2 November 2018 (UTC)[reply]

Out of curiosity about the ideas behind this proposal and/or the work that has already been done, and to add some additional remarks/questions (and because the appropriate "mention" notifications were unchecked in my preferences earlier), I'll repeat my remark here:

  • I support the splitting the Watchlist's "Wikidata edits" filter into three types of edits: the ones that change the information in the articles themselves (as described here), the ones that change project links (language/interwiki projects, sister projects), and the rest of the edits. @Doc James and Ladsgroup: is something like this what you have in mind?

Additional remarks/questions: this proposal is in the Watchlists category of the survey, and only watchlists are mentioned in the proposal text (and the discussion and vote comments), but isn't this actually about the revision history of the articles? With, technically, a second "revision history" for the pages in the local projects, which only tracks the changes to items/properties actually used within the local article at that time (on the front/user's end probably merged into one revision history somehow), those changes wouldn't just be temporarily visible to the active users who watch their watchlists or some "related changes" list, but to anyone viewing a page's revision history, any time. From there, showing these changes on watchlists and such will be a small step. I actually hope that is the road you are planning to take, because such a thorough implementation of the ability to track these changes locally would be a huge improvement in quality assurance and thus Wikidata usage within the local projects!

The second type of Wikidata edits I mentioned (changes to project links) is in my opinion a less important one, not really necessary to store locally – also by their nature (interwiki connections) it makes perfect sense to store those changes only on the Wikidata project. But for the watchlists on the local projects, it would still be great to have them separated from the 90% of the Wikidata edits that doesn't affect the article in question.

With kind regards — Mar(c). [O] 20:48, 1 December 2018 (UTC)[reply]

User:Mar(c) yes that would do nicely. Doc James (talk · contribs · email) 22:00, 1 December 2018 (UTC)[reply]

Voting

Improve watchlist colors

Original title: Afficher des couleurs moins criardes aux différentes contributions de la liste de suivi

  • Problem: Watch list (with “Colors” gadget) displays shrill and vulgar colours which assault the eye and require more concentration to read.
    French (original): La liste de suivi (avec gadget "couleurs") affiche des couleurs criardes et vulgaires qui violentent l'oeil et lui demandent plus de concentration pour la lecture.
  • Who would benefit: Everybody
    French (original): Tout le monde
  • Proposed solution: Drop all ones by several tones in colour gamut to reach pastel colors like the blue in this page where I’m writing.
    French (original): Tout baisser de plusieurs tons dans la gamme chromatique pour arriver à des couleurs pastelles, comme le bleu de cette présente page où j'écris.
  • More comments: Thank you in advance :-)
    French (original): Merci d'avance :-)
  • Phabricator tickets:
  • Proposer: Mylenos (talk) 19:18, 5 November 2018 (UTC)[reply]

Discussion

Voting