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.
@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
Support Yes: I once created a page for a publisher and wish I hadn't done so, I get so many messages when people link to it in references. On the other hand I do want to know about people linking to most of the articles I create. PamD (talk) 23:37, 16 November 2018 (UTC)[reply]
Problem: It is not possible to monitor every wiki for changes in a common list of articles.
Who would benefit: All editors.
Proposed solution: On Wikidata there are two properties that are used to tag items belonging either to a Wikiproject (maintained by WikiProject (P6104)) or to a Wikimedia project (on focus list of Wikimedia project (P5008)). Use that centralized information to display watchlists for any WikiProject in any language.
More comments: For instance if many pages are tagged as belonging to WikiProject Molecular and Cellular Biology (Q15884967), then it should be possible to show watchlists for any language edition of Wikipedia or even for Wikidata itself.
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.
+1. For several months, everybody is forced to copy-paste a page list from a Lua module: wikt:fr:Modèle:Communauté, on the most part of the wikis I know... That's not ergonomic at all. But the best solution would be to also provide these subpages into the same RSS flux. JackPotte (talk) 15:04, 2 November 2018 (UTC)[reply]
I would prefer a per-page option: "Watch this page" and "Watch this page and all subpages" as separate options. The latter won't be changed often, it can be a bit more hidden (like a separate list you can edit). --mfb (talk) 03:27, 4 November 2018 (UTC)[reply]
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? ThankCancel". 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.
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.
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.
Grouping the edits is wonderful. Currently on desktop it only groups edits that occur within the same UTC day. I would love to see grouping since I last looked at the article in question (for both desktop and mobile). Doc James (talk · contribs · email) 19:56, 30 October 2018 (UTC)[reply]
I would also find it useful to be able to get the mobile behavior on the desktop version, as some edits that I really want to look at are hidden by more recent ones. Enterprisey (talk) 05:07, 31 October 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]
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.
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]
Support Like the proposer I want to be able to watch a page for a short time after editing it WikiGnomishly, or indefinitely if it's a topic of interest. PamD (talk) 23:23, 16 November 2018 (UTC)[reply]
Support, though there's some design question on "do we want to warn/indicate to users that their temporary watched item will expire soon?" that might be worth answering. --Izno (talk) 00:38, 27 November 2018 (UTC)[reply]
Support Yes please. Even a simple flag in watchlist (like 'long-term' or 'short-term') with different options to purge 'short-term' should work. In the current setup I watch only pages I am interested in in long-term — NickK (talk) 16:37, 29 November 2018 (UTC)[reply]
Problem: When articles are tagged for deletion, shut the damn hell up I'm not dealing with this crap since Wikipedia is the worst crappy mad circus site on the internet for not censoring the porn on its pages, all admins are moronic idiots
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.
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]
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.
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.
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.
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).
Support Adding this with an opt/in option; to allow the system to act normally, or have the option to flag one page or the other for watching. Lostinlodos (talk) 01:09, 20 November 2018 (UTC)[reply]
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
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.
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]
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.
Support This could also be useful on Wikivoyage. The current "Show Wikidata edits in your watchlist" floods the watchlist with changes which have no impact on what is actually seen in the articles. AlasdairW (talk) 23:55, 22 November 2018 (UTC)[reply]
Support for 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? — Mar(c).15:26, 27 November 2018 (UTC)[reply]
Support for 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 Shmurak (talk) 17:37, 27 November 2018 (UTC)[reply]
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.
Merci mais bien trop difficile pour moi (qui n'écris déjà qu'en mode visuel et pas en code car je n'y comprends rien. Dommage ! - Mylenos (talk) 17:25, 23 October 2019 (UTC)[reply]
Support Yes: I once created a page for a publisher and wish I hadn't done so, I get so many messages when people link to it in references. On the other hand I do want to know about people linking to most of the articles I create. PamD (talk) 23:37, 16 November 2018 (UTC)
