Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Watchlists

< Community Wishlist Survey 2016
Watchlists
24 proposals, 189 contributors, 344 support votes


Search  •  Wikidata


Add a watchlist to watch on article linking

  • Problem: Many internal links are created with redirects that have misleading titles (for whatever reason; for instance, in esWiki, the lack of tilde). These cases can only be tracked when the article or redirect have been created by oneself. The rest remains a while until someone notices the error and corrects it. It would be nice to have a watchlist to speed up the correction.
  • Who would benefit: Acount Users
  • Proposed solution: A new option in Preferences
  • Phabricator tickets:

Community discussion

Voting – Add a watchlist to watch on article linking

  1.   Support I've always thought I should be able to manually turn these notifications on, regardless of whether I create a particular page. Samwalton9 (talk) 09:36, 28 November 2016 (UTC)[reply]
  2.   Support. Some editors like to specialize--this should be supported by the standard tools. David spector (talk) 00:36, 1 December 2016 (UTC)[reply]
  3.   Support Libcub (talk) 02:58, 2 December 2016 (UTC)[reply]
  4.   Support It should be part of watching a page by default. Aracali (talk) 14:44, 2 December 2016 (UTC)[reply]
  5.   Support, why is it just possible to get this if one created the page? --Fixuture (talk) 20:07, 2 December 2016 (UTC)[reply]
  6.   Support --Fixer88 (talk) 20:47, 2 December 2016 (UTC)[reply]
  7.   Comment On... and off. It would be nice having the possibility of turning off linking-notifications from an item/article you created you are not interested anymore in. Strakhov (talk) 16:08, 3 December 2016 (UTC)[reply]
  8.   Support Sounds useful. Stevie is the man! Talk • Work 14:12, 5 December 2016 (UTC)[reply]
  9.   Support --Romulanus (talk) 09:32, 10 December 2016 (UTC)[reply]
  10.   Support Either option to be notified when anything from watchlist is linked, or ability to mark separate pages. Also both options would be appreciated too. --Similartothissimilartothat 18:42, 11 December 2016 (UTC)[reply]
  11.   Support - DPdH (talk) 20:57, 11 December 2016 (UTC)[reply]

Allow watchlisting just the page or just the talkpage

  • Problem: Watchlists are both for the main page of an entry and for the discussion. There is no option to watch a page or a discussion.
  • Who would benefit: editors
  • Proposed solution: Create an option "watch discussion page".
  • Phabricator tickets:

Community discussion

@Mattes: Hi, I've changed the title of this section to "Allow watchlisting just the page or just the talkpage", please change it if that's not accurate. Also, please could you add more details to the "Problem" section? Perhaps give 2 examples (one for each new option) and explain how it would benefit editors to have these options widely available. Thanks! Quiddity (WMF) (talk) 19:03, 11 November 2016 (UTC)[reply]

I would like to express support (not vote, still) for this proposal because some pages with enormous 'traffic' on their talk pages – really do clug up watchlist. Examples are w:Hillary Clinton or w:Donald Trump i.e. their talk pages that some editors who update their articles on other Wikis have in their watchlists on English Wiki along with the main page (article), because it is not possible currently to watchlist only main page without talk page. Such editors do not want to see in the watchlist those talk pages because discussions are not what they want to track in watchlists but only updates for main article. Edits of talk pages reach up to 50 or more per day on only one article what makes problem when tracking changes using the watchlist (user must visit that talk page in order for all bolded instances of it get non-bolded in watchlist, or navigate through each edit of talk page separately). --Obsuser (talk) 19:20, 11 November 2016 (UTC)[reply]

This sounds useful although I would keep it at a low priority. After all, we can ignore an entry in the watchlist. Also, if we have a "mark as visited" script, we can just tick it off without reviewing it. I'm also a bit concerned how this would be implemented in a paradigm as straightforward as watch/unwatch is now. Stevie is the man! Talk • Work 18:17, 13 November 2016 (UTC)[reply]

I have a similar `wish` to be able to watch/unwatch sections. Do I need to make a separate section or maybe talk about this here too?--Dixtosa (talk) 18:22, 13 November 2016 (UTC)[reply]
  • Short note: I think it would be a bad idea to make it an option on the edit page, the watchlist-star or in the user options as the article a user watches is supposed to also have its associated talk page watchlisted so that a user gets notified / involved in talk page discussions (which are essential info for article changes etc). Instead I think it should only be possible to unwatch specific talk pages via an option on the actual talk page.
@Dixtosa: Please also see: phab:T2738.
--Fixuture (talk) 20:54, 16 November 2016 (UTC)[reply]
  • @Quiddity: Example 1: I would like to follow a shortly started discussion (what's happening there recently) at Talk:List of knots. Currently the article is shown in the watchlist as recent changes, because of an edit on the article. I'm not interested in the article change of List of knots so it's a waste of time & effort looking at my watchlist if a article change has been performed recently (my watchlist contains 12,300 entities). Example 2: One wants just to watch the article changes but does not care about the discussion edits, resulting in the same waste of time & effort for this watchlist user. Ho it would benefit editors to have these options widely available: More effective work, less waste of time & effort. It can help to make work more attractive and leads to less (minor) frustration / discomfort. Thanks for edit the section text > perfect! --Mattes (talk) 21:16, 21 November 2016 (UTC)[reply]

Voting – Allow watchlisting just the page or just the talkpage

  1.   Support. Or both. We should see what we want to see. David spector (talk) 00:39, 1 December 2016 (UTC)[reply]
  2.   Neutral per my comments above. I don't see the priority for WMF development in the next year, and this breaks the longstanding watch/unwatch paradigm. Stevie is the man! Talk • Work 03:13, 1 December 2016 (UTC)[reply]
  3.   Support --Kenny McFly (talk) 19:09, 1 December 2016 (UTC)[reply]
  4.   Support Libcub (talk) 02:59, 2 December 2016 (UTC)[reply]
  5.   Oppose, for the reasons stated in my comment above. However I'd   Support adding a way to unwatch a specific talk page via an option on that talk page (useful for pages with much discussion). --Fixuture (talk) 20:14, 2 December 2016 (UTC)[reply]
  6.   Support This must happen. --Fixer88 (talk) 20:47, 2 December 2016 (UTC)[reply]
  7.   Support --Gnom (talk) Let's make Wikipedia green! 13:30, 6 December 2016 (UTC)[reply]
  8.   Oppose It seems to me that anyone would watch both or neither, and if not, it's not a big enough deal to justify the development effort. You should not be editing a page if you are ignoring discussions about the page. --Tryptofish (talk) 00:36, 6 December 2016 (UTC)[reply]
  9.   Oppose As much as at first sounded a good idea to me, for stuff like WikiProject talkpages which I don't need to watch the page itself, I can see (as mentioned above) people using it to not watch discussion pages, which is problematic if you're an editor of a page. Bringing up a discussion on a talk page should show up on all active editors of the page (who are prob watching it), and if this change would happen, then every discussion will start with users pinging all the active editors of the page, so not much gained. --SuperJew (talk) 19:20, 6 December 2016 (UTC)[reply]
  10.   Support FoCuSandLeArN (talk) 22:59, 11 December 2016 (UTC)[reply]

Dismissible watching of created and edited pages

  • Problem: Sometimes an editor wishes to see a list or notification of pages they created (or they edited, or both) that have been edited by others since, and then later dismiss (update, touch) that list or notification. Currently, neither the Watchlist nor the Contributions special pages fill this role. Both of these special pages show all entries with no "dismissal" functionality, so the lists grow to be very long and not ordered helpfully. Macros or other tools to perform this task undoubtedly exist, owned by certain experienced editors, but are not easily discoverable by most editors. A related and higher-level problem is to use such a list or notification of changed pages to monitor one's watched created and edited pages in an easy way to guard them against vandalism, or to respond quickly to an ongoing discussion on a Talk page. The current Alerts and Notices help, but are somewhat clumsy, do not directly address these problems, and cannot currently be customized by editors to do so.
  • Who would benefit: Wikimedian editors of all levels of experience.
  • Proposed solution: Create an extension to either the Watchlist (preferably) or the Contributions special page software that solves the problem, possibly using elements from both of these special pages. A single new special page, with separate and dismissible sections for created pages and for other edits might work well, but an extension to the Watchlist or Contributions page with similar functionality would also work. Additional useful features thought up by the developer or suggested by the community (such as other categories of pages to be watched, or choosing the method of notification) would be welcomed.
  • More comments: I proposed something like this several years ago and got strong support, but also a statement that no one who could make such a tool had any time to do so. Perhaps this has changed with this new initiative to receive proposals from the community.
  • Phabricator tickets:

Community discussion

@David spector: As you write that you "proposed something like this several years ago and got strong support", do you remember where? Any links? :) --AKlapper (WMF) (talk) 13:43, 16 November 2016 (UTC)[reply]
It was in a discussion page, like the Village Pump. I have searched my User Contributions page and cannot find it. But it was not very much different from what I've posted here (maybe I omitted the idea of dismissal, is all). It was made several years ago, and probably was archived a long time ago. Sorry. Would you like to help by posting your approve or oppose thoughts? David spector (talk) 19:38, 16 November 2016 (UTC)[reply]
@David spector: The bad news, is this will take a while to complete. The good news, is that these ideas are all being worked on!
For multiple watchlists, there is ongoing work at the deeper code levels, to make this possible (phab:T3492 is the tip of the iceberg, and should lead to a lot of new potential features, such as different notification settings depending on the watchlist).
For "just show pages which I created", that's the kind of thing that should be possible with the new interface that the Collaboration team is working on, at mw:Edit Review Improvements. See for example, the (incomplete) prototype and click inside the "Filter recent changes" box at the top, then scroll down in that dropdown menu to see some of the new filter ideas. (Feedback appreciated, on the mediawiki talkpage).
As you say, it is definitely better for everyone (in the long-run) if we build these enhancements to work with the existing Special pages, rather than creating new ones. There's a related proposal at .../Miscellaneous#Editor-focused central editing dashboard. Hope that helps. Quiddity (WMF) (talk) 01:04, 18 November 2016 (UTC)[reply]

Voting – Dismissible watching of created and edited pages

Filter watchlist to allow better visibility of category membership changes

  • Problem: A recent change to watchlists has allowed editors to see changes to category membership, but some categories are so busy that only an hour or two of changes are shown when "view category changes" is enabled. We need to be able to see more than a couple of hours of changes.
  • Who would benefit: People who watch a lot of maintenance categories.
  • Proposed solution: Enable an easy way for editors to view the recent membership changes to a subset of Category pages on the editor's watchlist.
  • More comments: In theory, one could work around this limitation by temporarily removing all but one or two Category pages from one's watchlist, but that is a hideous kludge.
  • Related: It would be nice if some category pages could be watched only for changes to the Category page text itself, ignoring membership changes.
  • Phabricator tickets:

Community discussion

Voting – Filter watchlist to allow better visibility of category membership changes

  1.   Support Libcub (talk) 03:00, 2 December 2016 (UTC)[reply]
  2.   Support, as I basically suggested the same. --Fixuture (talk) 20:08, 2 December 2016 (UTC)[reply]
  3.   Support -- Aspiriniks (talk) 09:49, 4 December 2016 (UTC)[reply]
  4.   Neutral I think #Watchlist priorities or Multiple watchlists (actually, the multiple watchlists part) is a great solution for this concern. Stevie is the man! Talk • Work 14:19, 5 December 2016 (UTC)[reply]

Fix the crosswatch tool

  • Problem: Multi-Wiki Watchlist
  • Who would benefit: Multi-Wiki contributors
  • Proposed solution: Fix the current tool, crosswatch
  • More comments: It was really easy to use and very effective.But it's somehow broken.

Community discussion

@AddisWang: But it's somehow broken. This is not useful, please be more specific. If it's a simple bug, I don't think it needs to get attention from this survey. Matěj Suchánek (talk) 21:40, 10 November 2016 (UTC)[reply]

@Matěj Suchánek: Server failure: No watchlist could be retrieved. This is an internal server error, please open a bug report if the problem persists.--AddisWang (talk) 21:56, 10 November 2016 (UTC)[reply]
Why don't you open a bug report, then? Matěj Suchánek (talk) 13:15, 11 November 2016 (UTC)[reply]
@AddisWang and Matěj Suchánek:, phabricator link added to the proposal. -- Bodhisattwa (talk) 19:50, 11 November 2016 (UTC)[reply]
@Bodhisattwa: Thanks!--AddisWang (talk) 15:46, 12 November 2016 (UTC)[reply]
@AddisWang, Matěj Suchánek, and Bodhisattwa: Letting you know this proposal has been moved here from the "Bots and gadgets" category. Thanks for participating! MusikAnimal (WMF) (talk) 18:17, 14 November 2016 (UTC)[reply]
Good idea -- Кадош (talk) 16:03, 15 November 2016 (UTC)[reply]

The Community Tech team is actually already working on a cross-wiki watchlist, which was one of the top ten wishes in last year's survey. Is there any functionality that isn't covered by the work already being done there? /Johan (WMF) (talk) 17:35, 17 November 2016 (UTC)[reply]

Hi AddisWang, as Johan says above, the Community Tech team is working on a cross-wiki watchlist. Is there anything that isn't covered by that project? -- DannyH (WMF) (talk) 22:20, 22 November 2016 (UTC)[reply]

Voting – Fix the crosswatch tool

  1.   Support. If a tool is worth creating, it is worth maintaining. David spector (talk) 00:41, 1 December 2016 (UTC)[reply]
  2.   Support I imagine this is more symbolic support if a separate tool is in production. Crosswatch was a nice proof of concept but it's sad to see the site go to waste without maintenance. I still have quite a few bugs and feature requests open at its Phabricator page if you're looking for ideas. czar 01:16, 2 December 2016 (UTC)[reply]
  3.   Support Please, its a very useful tool. Iazyges (talk) 05:02, 7 December 2016 (UTC)[reply]
  4.   Support --Arnd (talk) 13:48, 9 December 2016 (UTC)[reply]
  5.   Support I have been wating for this feature during 2 last years. Кадош (talk) 16:45, 12 December 2016 (UTC)[reply]

"Hide trusted users" checkbox option on watchlists and related/recent changes (RC) pages

  • Problem: I trust a number of editors/bots as much as I trust myself (maybe even more in some cases), but their edits cannot be filtered out of watchlists and RC pages like I can filter out my own. This makes my watchlists and RC pages considerably more burdensome to work through than seems reasonable at times.
  • Who would benefit: Anyone who maintains a sizable watchlist or uses RC pages; RC patrollers; Vandalism hunters.
  • Proposed solution: Allow users to 'trust' other users by clicking a "Trust/Remove trust" link on user pages. (This could be represented by a graphic in some skins.) This will build a non-public "trusted users" list for the user that they can edit (add/remove) similarly to a watchlist. Then, on watchlists and RC pages, a user can check "Hide trusted" similarly to how they can check "Hide my edits", thus reducing the number of watchlist/RC items to check in many cases.
  • More comments:
    • Some additional aspects that could be added as part of this include:
      1. "Page information" on user pages could show "Number of trusters" (e.g., <30 or actual number that is 30 or above).
      2. Statistics on who are the most trusted editors could be assembled. (This could be a new data point for RfAs.)
    • Regarding trusted bots, you might wonder why someone wouldn't just hide all bots. Well, there are some bots I trust with everything they do, and some I don't.
    • Implementing this proposal would help in vandalism hunting because it would make it more convenient to zero in on bad edits and more comfortable for users to maintain larger watchlists, thus having an ability to catch more vandalism than before.
    • This proposal should work very well in concert with other proposals, e.g. Watchlist priorities or Multiple watchlists, to help us keep our watchlists shaped to what we should be paying most attention to.
  • Phabricator tickets: task T58719 (applies to RC pages only; closed/declined)

Community discussion

Voting – Hide trusted users on watchlists

  1.   Support as proposer. Stevie is the man! Talk • Work 01:47, 28 November 2016 (UTC)[reply]
  2.   Support JAn Dudík (talk) 22:13, 28 November 2016 (UTC)[reply]
  3.   Support and maybe this can be extended to wiki-wide basic trusted users. Which could also feed into ORES. --Izno (talk) 01:43, 29 November 2016 (UTC)[reply]
  4.   Support Nocowardsoulismine (talk) 01:50, 29 November 2016 (UTC)[reply]
  5.   Support ChristianKl (talk) 16:36, 29 November 2016 (UTC)[reply]
  6.   Support. David spector (talk) 00:42, 1 December 2016 (UTC)[reply]
  7.   Support B25es (talk) 17:51, 1 December 2016 (UTC)[reply]
  8.   Support As someone who patrols RC frequently, this would be awesome Semmendinger (talk) 19:44, 1 December 2016 (UTC)[reply]
  9.   Support I believe this will be part of ERI project but support this anyway. Matěj Suchánek (talk) 21:34, 1 December 2016 (UTC)[reply]
  10.   Support NMaia (talk) 00:33, 2 December 2016 (UTC)[reply]
  11.   Support Jmvkrecords ⚜ (Intra talk) 10:32, 2 December 2016 (UTC).[reply]
  12.   Support Draceane (talk) 10:59, 2 December 2016 (UTC)[reply]
  13.   Support --Arthur Crbz (talk) 10:48, 4 December 2016 (UTC)[reply]
  14.   Support —Jc86035 (talk) 11:20, 2 December 2016 (UTC)[reply]
  15.   Support Great idea! I'm tired of all these productive editors clogging my watchlist. Also, everyone try saying watchlist wishlist five times, fast. EEng (talk) 05:28, 4 December 2016 (UTC)[reply]
  16.   Support Pamputt (talk) 10:53, 4 December 2016 (UTC)[reply]
  17.   Support Game changer. ImperfectlyInformed (talk) 19:42, 4 December 2016 (UTC)[reply]
  18.   Support --Epìdosis 20:12, 5 December 2016 (UTC)[reply]
  19.   Support I see no downside. --Tryptofish (talk) 00:39, 6 December 2016 (UTC)[reply]
  20.   Support That would be better. Ayub407 (talk) 16:55, 6 December 2016 (UTC)[reply]
  21.   Support great concept! --SuperJew (talk) 19:10, 6 December 2016 (UTC)[reply]
  22.   Support Solves some of the same problems as my priority proposal, would be a definite plus. —Ynhockey (talk) 10:32, 7 December 2016 (UTC)[reply]
  23.   Support Yes please with sugar on top. My watchlist is sometimes completely filled up with perfectly fine mass maintenanace edits by single users, which I can't hide without hiding many others as well.--Elmidae (talk) 16:32, 7 December 2016 (UTC)[reply]
  24.   Support Mcfar54 (talk) 01:39, 8 December 2016 (UTC)[reply]
  25.   Support --Newbiepedian (talk) 02:23, 8 December 2016 (UTC)[reply]
  26.   Support --My Chemistry romantic (talk) 02:36, 8 December 2016 (UTC)[reply]
  27.   Support I don't think I can even say how many times I have wished this option existed. Gluons12 (talk) 03:37, 8 December 2016 (UTC).[reply]
  28.   Support Best idea in years. Would improve my user experience immeasurably. Rivertorch (talk) 05:39, 8 December 2016 (UTC)[reply]
  29.   Support as proposed Iadmc (talk) 05:41, 8 December 2016 (UTC)[reply]
  30.   Support Doc James (talk · contribs · email) 06:18, 8 December 2016 (UTC)[reply]
  31.   Support --Dirk Beetstra T C (en: U, T) 08:45, 8 December 2016 (UTC)[reply]
  32.   Support I like it! Garycompugeek (talk) 22:59, 8 December 2016 (UTC)[reply]
  33.   Support This is a very interesting idea. Espresso Addict (talk) 04:21, 9 December 2016 (UTC)[reply]
  34.   Support Ayack (talk) 12:07, 9 December 2016 (UTC)[reply]
  35.   Support --Alaspada (Talk) 02:06, 11 December 2016 (UTC)[reply]
  36.   Support - Useful. DPdH (talk) 21:00, 11 December 2016 (UTC)[reply]
  37.   Support This can be done even without "trust" functionality, simply allow to filter changes made by someone belonging or not to a group (e.g. changes made by not autoconfirmed users only) — NickK (talk) 23:04, 12 December 2016 (UTC)[reply]

Improve watchlist and other tracking of file changes both from local WPs and Commons files

  • Problem: If someone changes (e.g. uploads a new version of some file), a Wikipedia user might not know about that in the watchlist on local Wiki project although such change of some file affects (if file is on Commons) all usage instances of some file, on all Wikipedias and all image/audio file transclusions etc. Aside from not being informed that file has been changed, even if user is informed – watchlist item is not bolded or marked so its easily distinguished from other visited pages non-bolded pages in the watchlist (both local Wiki and Commons watchlist).
  • Who would benefit: Many editors (interwiki), especially because uploading of new versions for files is not that much frequent BUT very useful and important because of preventing vandalism-like uploads of new version and similar things.
  • Proposed solution: Make local Wikipedia users get [more] noticeably informed in their watchlists if a file (either on their Wiki or on Commons) – a file that they have previously edited at some point – has been changed by someone else (as same as for ordinary articles that appear bolded [and with green markers on en.wiki]). It should not be important if a file description was altered or a new version was uploaded (although focus should be on the latter one which is more important and more malfunctioning right now).
  • More comments: I was happy to see notifications coming when someone pings me on other language Wikipedia project, or if someone reverts my edits. This kind of interwiki (and inter-Wikimedia) linkage is good and could be applied for this "wish" for images/watchlist, at least in my opinion.
  • Phabricator tickets: no

Community discussion

I guess I would not want to use cross-wiki watchlist because then everything would really get mixed up (particularly, for me it would be sr.wiki and en.wiki watchilst combined where I edit; it would be worse for editors who edit more than two Wikipedias). It is really not hard to go to en.wiki and check en.wiki watchilst there.
For second question (which I don't see directly connected to the first one), if I edit a code of some file page or upload a new version of that file (or upload a file "from scratch") – it should be automatically added to the watchlist and appear bolded if changed anyhow (as same as ordinary articles). This is my request, basically.
For second part of second question – no. Many users have edited thousands of articles with tens of thousands of files and it would be hard to keep eye on ALL of those files in watchlist if they would automatically get added on it (if only one edit of ansome article would trigger that). This would be useful but only if there is an option to hide such automatically added files from watchlist (as same as an editor can hide his/her own edits or bot edits from watchlist / recent edits). --Obsuser (talk) 20:32, 23 November 2016 (UTC)[reply]

Voting – Improve watchlist and other tracking of file changes

  1.   Support Sadads (talk) 15:15, 28 November 2016 (UTC)[reply]
  2.   Support. Files and articles are linked IRL, but not currently when watching. David spector (talk) 00:44, 1 December 2016 (UTC)[reply]
  3.   Support Interestingly, many people complain about not being able to watch Wikidata changes but there are no voices regarding files (which have been here for a longer time). Matěj Suchánek (talk) 21:37, 1 December 2016 (UTC)[reply]
  4.   Support Pamputt (talk) 10:55, 4 December 2016 (UTC)[reply]
  5.   Support Can't believe I didn't think of this last year. Would immediately bring many more eyes (and quicker response) to cases where Commons images are vandalized with the intention of harming articles. Risker (talk) 03:29, 9 December 2016 (UTC)[reply]
  6.   Support Miniapolis 20:58, 9 December 2016 (UTC)[reply]
  7.   Support Кадош (talk) 16:48, 12 December 2016 (UTC)[reply]

Make hiding work correctly

  • Problem: When hiding a type of edit (minor, say, or bots), you currently also hide all edits previous to that edit. That is, if I want to be malicious, I can make a large change followed by a minor change and not only will nobody be able to see the large change on their watchlist, those hiding minor changes won't be aware the article was touched at all. Similarly, if a bot edits an article to (say) put a date on a cn tag, it permanently hides whatever edit introduced the cn tag for those people hiding bot edits. This, again, could be exploited to escape scrutiny. That is, currently, if the last edit of an article on your watchlist does not fit the search criteria, the article gets knocked off the watchlist completely. As though you never watched it at all. In a nutshell, other editors or unregistered bots can knock articles off your watchlist by making or triggering edits that don't fit your search criteria.
  • Proposed solution: (Option 1) For each article on the watchlist, display the last edit that does fit the search criteria. (and/or Option 2) For all minor and bot edits, display alongside it (child element style, perhaps) the last major and/or human/unregistered bot edit, as applicable.
  • More comments: I believe it needs to be a development priority to make this basic feature work correctly before attempting to implement more advanced ideas.
  • Who would benefit: Editors in the short term, everyone in the long term.

Community discussion

Voting – Make hiding work correctly

  1.   Support For watchlist hides to make sense, this must be addressed. Stevie is the man! Talk • Work 01:49, 28 November 2016 (UTC)[reply]
  2.   Support ChristianKl (talk) 16:37, 29 November 2016 (UTC)[reply]
  3.   Support StevenJ81 (talk) 18:18, 29 November 2016 (UTC)[reply]
  4.   Support Guycn2 · ☎ 19:17, 29 November 2016 (UTC)[reply]
  5.   Support. I've always worried by the major change followed by minor change flaw. David spector (talk) 00:46, 1 December 2016
  6.   Support. It is really unforgivable that the WMF still has not fixed this, after many, many calls to do so, an nearly 10 (!!) years (Noted.) Huldra (talk) 20:10, 1 December 2016 (UTC)[reply]
  7.   Support It should finally be decided on. And if it's a bug, it should get fixed. Matěj Suchánek (talk) 21:38, 1 December 2016 (UTC)[reply]
  8.   Support Libcub (talk) 03:02, 2 December 2016 (UTC)[reply]
  9.   Support, should be done ASAP - this bug needs to be fixed before anything else gets done. --Fixuture (talk) 19:35, 2 December 2016 (UTC)[reply]
  10.   Support This fix is very important. Strongest support to see it fixed. Doc James (talk · contribs · email) 03:33, 3 December 2016 (UTC)[reply]
  11.   Support I use the enhanced watchlist, so hadn't even realized this was a problem. Seems like a critical feature for people with larger watchlists. Opabinia regalis (talk) 03:57, 4 December 2016 (UTC)[reply]
  12.   Support Pamputt (talk) 10:55, 4 December 2016 (UTC)[reply]
  13.   Support -- the wub "?!" 13:47, 4 December 2016 (UTC)[reply]
  14.   Support --MGChecker (talk) 14:33, 4 December 2016 (UTC)[reply]
  15.   Support I didn't even realize that it was a problem until now, but of course it really is! --Tryptofish (talk) 00:42, 6 December 2016 (UTC)[reply]
  16.   Support as nominator. Samsara (talk) 22:26, 6 December 2016 (UTC)[reply]
  17.   Support--Elmidae (talk) 16:20, 7 December 2016 (UTC)[reply]
  18.   Support This would be really useful! Mcfar54 (talk) 01:34, 8 December 2016 (UTC)[reply]
  19.   Support --Newbiepedian (talk) 02:24, 8 December 2016 (UTC)[reply]
  20.   Support TheCatalyst31 (talk) 03:33, 8 December 2016 (UTC)[reply]
  21.   Support Iadmc (talk) 05:29, 8 December 2016 (UTC)[reply]
  22.   Support --Dirk Beetstra T C (en: U, T) 08:46, 8 December 2016 (UTC)[reply]
  23.   Support 4nn1l2 (talk) 00:12, 9 December 2016 (UTC)[reply]
  24.   Support Risker (talk) 03:31, 9 December 2016 (UTC)[reply]
  25.   Support --Arian Talk 10:00, 9 December 2016 (UTC)[reply]
  26.   Support Wikimostafa (talk) 19:54, 9 December 2016 (UTC)[reply]
  27.   Support This is a serious issue. The lack of this feature basically makes hiding minor edits a bad idea.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:44, 11 December 2016 (UTC)[reply]
  28.   Support - As requested. DPdH (talk) 21:01, 11 December 2016 (UTC)[reply]
  29.   Support Quiddity (talk) 09:42, 12 December 2016 (UTC)[reply]
  30.   Support Gharouni 10:50, 12 December 2016 (UTC)[reply]
  31.   Support Curiousity7919 (talk) 17:32, 12 December 2016 (UTC)[reply]
  32.   Support — NickK (talk) 23:05, 12 December 2016 (UTC)[reply]
  33.   Support SamanthaNguyen (talk) 23:56, 12 December 2016 (UTC)[reply]

Make it easy to quickly see all changes since last visit

  • Problem: As of right now my daily Wikipedia routine looks like this:
  1. going to my watchlist,
  2. scrolling down to older unchecked entries (where the green buttons are bordering the blue ones),
  3. clicking on "hist" for every entry for a day (~30 for me right now) one after another for them to open in new tabs,
  4. going through each tab and selecting the last unchecked revision (blue dot) and clicking "Compare selected revisions" to create a diff of all the changes since I last checked the page as fast as I can,
  5. going through each tab and actually check the changes since I last checked the respective article,
  6. (using my remaining time - more often than not that's none at all - for the things I'd like to contribute to Wikipedia other than checking my watchlist [new categories, article-content, links, change-suggestions etc])

→ as you can probably imagine step 1 - 5 take a lot of time even though those steps are always the same and can be easily automated. I would estimate that this takes around a third of my time for checking my watchlist which I could use for the actual constructive things I'd like to accomplish on Wikipedia.
To be honest it still confounds me how such a straight-forward thing as checking all changes since ones last visit isn't possible here as of right now. I mean isn't checking for changes since ones last visit the main point of the watchlist?

  • Who would benefit: Anybody who uses watchlists and especially the ones with many watchlisted items who contribute heavily to Wikipedia (note that measured by edit count about 1/3 of Wikipedia is written by its top 10.000 editors so Wikipedia really depends on its most active users)
  • Proposed solution: I suggest an additional button next to diff | hist (e.g. chan for changes) for the watchlist entries which opens a diff of all the changes since one last checked the respective article.
Alternatively (or more technically precise?) the EnhancedRC 'x since last visit' feature could be built into the default watchlist, grouping its results across days across days could be allowed and the maximum number of changes to show in expanded watchlist-setting could be set from 1,000 to something above 10,000 (at least for relevant users).
  • More comments: Note that there might also be alternative solutions to this such as an option in the settings or even a watchlist-check mode that goes through each entry from the bottom up and shows its changes since ones last visit allowing one to skim to the next via a button on the right of the window - but this one would probably harder to implement and if anything a further extension of the above proposed solution.
Also note that I have many suggestions for new features and improvements and have read many of said and think that this would be the most useful of all since it would save most time than any other suggestion I know of.
Further sidenote: the suggestion "Hyperlink from "updated since my last visit" to the diff" in the "Miscellaneous" category is related to my proposal as it's basically the same with the difference that it's for the version history.
  • Phabricator tickets: I might create one later if there is none so far | phab:T10681 for the alternative solution's issue #1 & phab:T151165 for #2

Community discussion

  • Hi @Fixuture: This is partially already available as a preference-combination. If you go to w:en:Special:Preferences#mw-prefsection-watchlist and enable "Expand watchlist to show all changes, not just the most recent"; Then go to w:en:Special:Preferences#mw-prefsection-rc and enable "Group changes by page in recent changes and watchlist"; Then open your watchlist, and you'll have entries like this. This configuration has (A) an "x since last visit" link in the first line (top of screenshot), plus (B) links to all the diffs, with the timestamps for those which are new in bold text (e.g. the 22:24 at left). If you like that setup, there is also a userscript to auto-expand each of the collapsed entries (see the top 2 lines in my global.js - add those to your own global.js or your enwiki common.js). The only problem I encounter with this, is Villagepumps and similar busy pages.
  • Does that satisfy your needs? (If "no", could you update your proposal above to take those features into account? E.g. perhaps you might want to convert this proposal into "Add the EnhancedRC 'x since last visit' feature into the default watchlist", or something.) Thanks. :-) Quiddity (WMF) (talk) 23:38, 17 November 2016 (UTC)[reply]
  • @Quiddity (WMF): Alright, thanks for that tip, it's helpful! However this doesn't resolve the above problem for two reasons: 1) people can't be expected to find such a strange preference-combination to achieve the above - it should be a single setting that describes what its use is 2) it only works for a maximum of 1000 changes. The Maximum number of changes to show in expanded watchlist-setting in w:en:Special:Preferences#mw-prefsection-watchlist has 1000 as maximum. To make it usable the maximum should be at least 10.000. So no - it does not satisfy my needs and it practically does not fix the problem which really is all that matters here. How would you suggest that I change my proposal now? Adding "setting the maximum of changes to at least 10.000" as an alternative solution? Btw. showing such high numbers of recent changes could be coupled with some user-rights or alike if it causes too heavy server load (which I don't think it should - if anything the requests could be changed so that e.g. it doesn't list all the recent editors of the watchlist-entry).
Edit: oh and it also doesn't work: I found many watchlist-entries which only have the diff | hist buttons and no x changes button even though there have been multiple changes since my last visit (multiple green buttons when I go to the respective history page)...
--Fixuture (talk) 20:47, 19 November 2016 (UTC)[reply]
@Fixuture: Ah, good point, IIUC that's because of the split into "per-day" results. I.e. if you haven't visited the page at all since midnight, then all changes will be considered new (hence the "since last visit" link would be identical). -- phab:T10681 ("Group changes across days in enhanced rc") asks for this to be changed. You could focus this proposal on that item, or something similar. E.g. title: "Make it easy to see all changes since last visit". E.g. Suggested solution: "Add the EnhancedRC 'x since last visit' feature into the default watchlist, and group results across days". Plus tweaks to the problem description to shorten that. (There are 260+ proposals, and they need to be as clear and concise as possible so that hundreds of editors can easily read/understand them all and vote, next week!) Hope that helps. Quiddity (WMF) (talk) 20:25, 20 November 2016 (UTC)[reply]
@Quiddity (WMF): Thanks for your help here so far! I still prefer my suggested solution though but added this as an alternative solution so that the developers may decide what would have the better time-cost/use relation (some new development or keeping on with the current approach and fixing its problems). With "enhanced rc" I guess you're referring to the watchlist with these 2 settings turned on and that it still requires 10000+ changes as maximum in the settings? --Fixuture (talk) 21:10, 20 November 2016 (UTC)[reply]
@Fixuture: That sounds good, for the alternative proposed solution. I was just using the "enhanced rc" keywords so that people understand which feature you want to replicate. (There's 'expanded' which shows multiple entries, and 'enhanced' which groups the changes per-page - The keywords are confusing, naming things is hard!) However, the adjustment for "10,000 changes" might not be a required-component of that, so I'd suggest removing that, or splitting it out into a comment (note, I filed phab:T151165 to investigate the feasibility of that idea, but if this were a change to the default watchlist (without the "expanded"/"enhanced" preferences) then it might not encounter this problem). Out of curiosity, what is your usual preference for "n days" to display, and roughly how many changes does that show? (e.g. If I set my watchlist to use 10 days, then I get "Below are the last 1,098 changes in the last 240 hours".) Thanks again. Quiddity (WMF) (talk) 21:21, 21 November 2016 (UTC)[reply]
@Quiddity (WMF): I'm not sure why upping the 1,000 maximum changes limit wouldn't be a required component of it as the limit also goes for the enhanced watchlist. I recently set the days to display-setting to 12 - I always try to clear my watchlist up until 5 days behind the current day but there have been days in which I was always lagging ~30 days behind and even had to use screenshots of my watchlist sometimes to work it out a few days later. The 12 days limit currently shows 545 changes for me (I exclude bots, my edits, page categorization and Wikidata).
Btw. I found a similar suggestion in the Miscellaneous category which I linked above.
--Fixuture (talk) 12:15, 26 November 2016 (UTC)[reply]
  • @Stevietheman: Oh wow, very cool! Trying it out today these days - it seems to have implemented what I suggested here. I think it should be added to the preferences along with his rater gadget. --Fixuture (talk) 21:34, 30 November 2016 (UTC)[reply]
  • @Stevietheman: Well, I've tried it out now and sadly it doesn't appear to be working: it shows me the since last seen-link for just about 5 articles somewhere at the top of my watchlist (not even the first 5, I could take a screenshot). Does it work for you? Maybe there's some API-request-limitation or so that keeps it from working? --Fixuture (talk) 21:02, 2 December 2016 (UTC)[reply]

Voting – Make it easy to quickly see all changes since last visit

  1.   Support --Izno (talk) 01:45, 29 November 2016 (UTC)[reply]
  2.   Support --Yair rand (talk) 07:04, 29 November 2016 (UTC)[reply]
  3.   Oppose Partially available, the details depend on each person's workflow. It would be very difficult to make a tool that accommodates all the different workflows out there.--Strainu (talk) 09:46, 30 November 2016 (UTC)[reply]
    @Strainu: Well I think at the very least that gadget (the partial solution) should be added to the preferences. However I don't think that is an issue of peculiar workflows - imo that's the most intuitive and common-sense way of using the watchlist - why would anybody want to just view the latest change to an article on ones watchlist instead of all changes since one has last visited the page? --Fixuture (talk) 21:32, 30 November 2016 (UTC)[reply]
  4.   Support. This was my main motivation for my Dismissible Notifications proposal above. It is currently too hard to see changes that were made a week or more ago, especially to see if our edits were reverted. Also, I don't trust "it can already be done" followed by a long list of instructions. Make any useful feature into a tool, a preference, or support it on a Special Page if the feature is worth having at all. David spector (talk) 00:55, 1 December 2016 (UTC)[reply]
  5.   Support Should be made default and embedded in Mediawiki. To see just the last edit should become an option. --Una giornata uggiosa '94 · So, what do you want to talk about? 01:15, 1 December 2016 (UTC)[reply]
  6.   Support This would be one of the most useful changes of all. --Chris Howard (talk) 18:18, 1 December 2016 (UTC)[reply]
  7.   Support - Better visibility = less time wasted. DPdH (talk) 21:02, 11 December 2016 (UTC)[reply]
  8.   Neutral Actually, this is the only way I use watchlist. But AFAIK this is only relevant for the "old-style" watchlist (ie. not the enhanced one). Matěj Suchánek (talk) 21:41, 1 December 2016 (UTC)[reply]
  9.   Support Libcub (talk) 03:03, 2 December 2016 (UTC)[reply]
  10.   Support SamanthaNguyen (talk) 22:16, 2 December 2016 (UTC)[reply]
  11.   Support --Continua Evoluzione (talk) 10:23, 5 December 2016 (UTC)[reply]
  12.   Support Stevie is the man! Talk • Work 14:58, 5 December 2016 (UTC)[reply]
  13.   Neutral I'm having trouble seeing how this would improve on looking at the edit history, where one can quickly see all new edits since last visiting the page. --Tryptofish (talk) 00:44, 6 December 2016 (UTC)[reply]
    @Tryptofish: I explained this in the problem-description: when you got a lot of articles on your watchlist / check it frequently it takes a lot of time to do that for each of them (steps 1-5). --Fixuture (talk) 18:44, 6 December 2016 (UTC)[reply]
    Yes, thanks. I was commenting on how I felt about that difference. --Tryptofish (talk) 20:16, 6 December 2016 (UTC)[reply]
  14.   Support I've wanted this since forever. Neither Watchlist nor Contributions really gets close to the expected behaviour: "show me things that have happened to pages I care about". Stevage (talk) 06:22, 7 December 2016 (UTC)[reply]
  15.   Support This will be very useful. Arthistorian1977 (talk) 07:57, 8 December 2016 (UTC)[reply]
  16.   Support Whats new? (talk) 22:51, 8 December 2016 (UTC)[reply]
  17.   Oppose See above; several current tools already provide most of this functionality, so devs have better things to do than focus on this.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:48, 11 December 2016 (UTC)[reply]
  18.   Support —The preceding unsigned comment was added by Quiddity (talk)

Make it possible to set single entries from watchlist un-visited (and visited)

  • Problem: Sometimes there's something to do but now you don't have time to. Everything else is fine so you wanna hit the »mark all pages visited« button. But this will also set visited the article you want to care about later.
  • Who would benefit: People who can't/won't spend much time; People.
  • Proposed solution: Via a new link-action (i.e.; unvisit; index.php?title=…&action=unvisit) a visit should be undone. (Great would be an Ajax-watchlist.)
  • Phabricator tickets:

Community discussion

Voting – Make it possible to set single entries from watchlist un-visited

  1.   Support This (and setting single entries as visited) should be built into MediaWiki. I use the script I mention above (for setting single entries as visited) and it has already worked wonders for my watchlist processing. Stevie is the man! Talk • Work 02:41, 28 November 2016 (UTC)[reply]
  2.   Support · · · Peter (Southwood) (talk): 11:01, 29 November 2016 (UTC)[reply]
  3.   Support Guycn2 · ☎ 19:18, 29 November 2016 (UTC)[reply]
  4.   Support --Una giornata uggiosa '94 · So, what do you want to talk about? 01:04, 1 December 2016 (UTC)[reply]
  5.   Support --Thgoiter (talk) 12:47, 2 December 2016 (UTC)[reply]
  6.   Support --MGChecker (talk) 14:33, 4 December 2016 (UTC)[reply]
  7.   Support --Gnom (talk) Let's make Wikipedia green! 16:41, 5 December 2016 (UTC)[reply]
  8.   Support An interesting idea. --Tryptofish (talk) 00:46, 6 December 2016 (UTC)[reply]
  9.   Support and also setting single entries as visited. --SuperJew (talk) 19:12, 6 December 2016 (UTC)[reply]
  10.   Support Iadmc (talk) 05:31, 8 December 2016 (UTC)[reply]
  11.   Support --Dirk Beetstra T C (en: U, T) 08:43, 8 December 2016 (UTC)[reply]
  12.   Support Jmatazzoni (talk) 22:57, 9 December 2016 (UTC)[reply]
  13.   Support - DPdH (talk) 21:08, 11 December 2016 (UTC)[reply]
  14.   Support — NickK (talk) 23:06, 12 December 2016 (UTC)[reply]
  15.   Support SamanthaNguyen (talk) 23:55, 12 December 2016 (UTC)[reply]

Only watchlist certain categories for membership changes

  • Problem: People might watchlist many categories but are only interested in membership changes in some particular ones of those. This could be for any reason including highly active categories which get many new additions every day or people only being interested in new additions to categories they created themselves or that often get false additions. (Personally I'd like to use the category-membership-changes-watchlist-feature but am not able to because I watchlisted too many categories with too many changes.)
  • Who would benefit: Everyone who would like to make use of the category-watching.
  • Proposed solution: There are many possible solutions to this. For instance when clicking the watchlist-star on categories a drop-down could show that says "Monitor membership changes" with two radio buttons yes & no with the default one which can be set in the settings being already selected (one can change it and save it).
  • Phabricator tickets:

Community discussion

Voting – Only watchlist certain categories for membership changes

  1.   Support Sadads (talk) 15:19, 28 November 2016 (UTC)[reply]
  2.   Neutral I think "watching category membership changes" works with Special:Recentchangeslinked. --Izno (talk) 01:47, 29 November 2016 (UTC)[reply]
  3.   Support IKhitron (talk) 12:21, 29 November 2016 (UTC)[reply]
  4.   Neutral I think #Watchlist priorities or Multiple watchlists (actually, the multiple watchlists part) is a great solution for this concern. Stevie is the man! Talk • Work 15:08, 5 December 2016 (UTC)[reply]

Options to select and remove redirects and non-existing pages from watchlist

  • Problem: Many users have a lot of pages in their watchlist and with time passing some pages may be deleted and/or renamed (this causes to have one more page in watchlist: source and target page after rename), and it may be difficult for them to find, select and remove such pages from watchlist.
  • Who would benefit: Users with huge watchlists
  • Proposed solution: Add options in Special:EditWatchlist for easy selecting of redirects and non-existing pages, to make easier proccess of their removal from user's watchlist.

Community discussion

  • @XXN: Hmm, is there a reason/pattern that someone is editing redirects a lot, which is causing them to appear in your watchlist frequently?
It would be ideal to address that kind of root problem (which might help hundreds of editors), instead of trying to silence the symptoms of the problem (1 editor at a time).
Or, are you just trying to reduce the size of your watchlist, for other reasons?
Generally: I strongly encourage keeping redirects in our watchlists, so that we can detect vandalism or page-forks or distinct new article creations. These are good things for humans to notice! Quiddity (WMF) (talk) 23:56, 17 November 2016 (UTC)[reply]
When pages are moved, redirects to them are updated by bots and thus they appear in users watchlists. There was an issue with watching too many pages. XXN (talk) 10:12, 18 November 2016 (UTC)[reply]
@XXN: But there is no longer a problem with watching too many pages, and it is possible to hide bot-edits in our watchlist. Perhaps instead what you want is #Hide trusted users on watchlists and related/recent changes (RC) pages (below)? Quiddity (WMF) (talk) 22:37, 22 November 2016 (UTC)[reply]
Quiddity (WMF), let me try to respond to your original question from my POV: yes, there are cases when redirects show up in the followed pages, such as when robots solve double redirects. There are also one-time bot runs that can cause this to a much larger scale (when spelling changes for a language, for instance). But the main reason why I find this proposal useful is that it takes too much to find pages in the list if you don't know the exact name and the list is filled with redirects. Actually, the way I see this implemented is having options for each group of pages that can be identified from the database: redirect, disambig, red links, by namespace etc.--Strainu (talk) 09:57, 30 November 2016 (UTC)[reply]

Voting – Options to select and remove redirects and non-existing pages

  1.   Support--Shizhao (talk) 03:15, 28 November 2016 (UTC)[reply]
  2.   Support - Gareth (talk) 07:24, 28 November 2016 (UTC)[reply]
  3.   Support - Nocowardsoulismine (talk) 01:54, 29 November 2016 (UTC)[reply]
  4.   Support Guycn2 · ☎ 19:19, 29 November 2016 (UTC)[reply]
  5.   Support --Strainu (talk) 09:47, 30 November 2016 (UTC)[reply]
  6.   Support Libcub (talk) 03:04, 2 December 2016 (UTC)[reply]
  7.   Neutral, instead I'd support a filter for the watchlist-entries-view that can also be used to restrict its shown entries to these types of pages which can then be manually removed from ones watchlist. --Fixuture (talk) 19:44, 2 December 2016 (UTC)[reply]
  8.   Neutral Speaking from my uses, I actually watch some redirects and nonexistent pages for pretty good reasons, so I think wiping out all of either feels a little too dangerous. What I think works better is color-coding the links. Nonexistent pages are already red. You can use en:User:Anomie/linkclassifier to color-code the redirects. Then you can go through and click all the ones you want to delete, and delete all of those together. Fixuture's filter idea may also be workable. Stevie is the man! Talk • Work 15:14, 5 December 2016 (UTC)[reply]
  9.   Support --Epìdosis 20:13, 5 December 2016 (UTC)[reply]
  10.   Support Because it would help us a bit. Gary "Roach" Sanderson (talk) 00:02, 9 December 2016 (UTC)[reply]
  11.   Support --Superchunk22 (talk) 08:40, 9 December 2016 (UTC)[reply]
  12.   Support-ish. Need this functionality, but agree that watchlist-entries-view filter is a better approach.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:49, 11 December 2016 (UTC)[reply]
  13.   Support - DPdH (talk) 21:10, 11 December 2016 (UTC)[reply]

Watch all items in a category

  • Problem: It would be helpful, if I could watchlist all items in a category by adding only the name of the cat to the watchlist (in some way).
  • Who would benefit: All users (except IPs)
  • Proposed solution:
  • Phabricator tickets: T3710

Community discussion

Voting – Watch all items in a category

  1.   Support --Betterknower (talk) 21:23, 1 December 2016 (UTC)[reply]
  2.   Neutral This is possible via Special:RecentChangesLinked. It could be integrated into watchlist via many times mentioned "multiple watchlists". Matěj Suchánek (talk) 21:43, 1 December 2016 (UTC)[reply]
  3.   Support Libcub (talk) 03:05, 2 December 2016 (UTC)[reply]
  4.   Support --Epìdosis 20:14, 5 December 2016 (UTC)[reply]
  5.   Support Not possible everywhere yet TheDragonhunter (talk) 03:47, 8 December 2016 (UTC)[reply]
  6.   Support --Dirk Beetstra T C (en: U, T) 08:44, 8 December 2016 (UTC)[reply]
  7.   Support Jmatazzoni (talk) 21:24, 9 December 2016 (UTC)[reply]
  8.   Support and should include subcategories Solstag (talk) 12:34, 11 December 2016 (UTC)[reply]
  9.   Support Also would be useful if «added to Category» and «subtracted from Category» had their own <span> or other elements with different classes, so they can be easily coloured with CSS. --Similartothissimilartothat 18:58, 11 December 2016 (UTC)[reply]
  10.   Support FoCuSandLeArN (talk) 23:00, 11 December 2016 (UTC)[reply]
  11.   Support SamanthaNguyen (talk) 23:55, 12 December 2016 (UTC)[reply]

RecentChangesLinked & new articles

Machine translation from Russian to English, please improve! -- Служебная:Связанные правки & новые статьи

  • Problem: Today, there are bots that generate lists of new articles on dozens of WikiProjects, increasing the load. Using RecentChangesLinked and a simple filter "new" it would be possible not to use bots.
Сейчас списки новых статей формируются ботами на десятках страниц проектов, делая по правке в день, что не рационально и увеличивает нагрузку на движок.
  • Who would benefit: Everyone. Participants from a narrow thematic projects, portals.
Все.
  • Proposed solution: Add an "only new" option for Special:RecentChangeLinked.
Предлагает добавить к инструменту опцию «только новые», как это сделано, скажем, для патрулирования в русскоязычном разделе.
  • Phabricator tickets:

Community discussion

Voting – RecentChangesLinked & new articles

RecentChangesLinked should search associated pages

  • Problem: RecentChangesLinked doesn't allow you to follow talk pages (associated namespace 1) through categories and lists in which only articles (namespace 0). As a result, the popular (but not rational) solution is to create empty talk pages for the categories.

In Recent changes, there is a checkbox "Associated namespace", but it only works if there is a link on the page and on the discussion (tool can filter, but can't search). Situation 1: there are project templates -> category of talk pages, but the project member can't use the Recent changes tool to watch the associated pages of article pages having a list only of talk pages. The current solution - bot will copy a list from the category, cut off "talk" from the name and saves as a new list. Situation 2: there is a list of articles, but the Recent changes tool can't look associated discussion. The current solution is an additional adding links to talk page of those articles, this increases the size of the list, and makes to create additional lists if a main list somewhere used. For added talk pages have to do red links to see the future creation of these pages. It's uncomfortable and you need to restart the bot to update additional lists.

  • Who would benefit: Everyone. Wiki-projects participants, participants observe specific thematic lists.
  • Proposed solution: Сheckbox for displaying together with the associated pages, only associated pages (the association will be located automatically)
  • Phabricator tickets: T117122 (focused on WikiProject needs)

Community discussion

Note: Larger projects (WP:Medicine) have 15000+ pages to track, and their rollover time is short (these 15000×2 pages can have 1500 edits/24h, and you only see 500, so even on a daily check one would miss 1000 edits. Possible solution: split the list).
Note: as User:Сунприат points out above, a similar RCL is useful to track What Links Here lists (subject+talkpages). IOW, follow RCL for all pages that have Template:Foo transcluded.
Does the proposal include namespace selection? -DePiep (talk) 12:32, 10 December 2016 (UTC)[reply]

Voting – RecentChangesLinked should search associated pages

  1.   Support. This is needed for WikiProject change patrol, as there's a need for members to watch changes to all included pages (both content and talk pages). Currently, on WikiProjects I work in, I have to periodically generate link pages for this purpose. I would love for this task to become obsoleted by the implementation of this proposal. Stevie is the man! Talk • Work 02:49, 28 November 2016 (UTC)[reply]
  2.   Support, and see phabricator:T42882--Shizhao (talk) 03:37, 29 November 2016 (UTC)[reply]
  3.   Support --Yair rand (talk) 07:04, 29 November 2016 (UTC)[reply]
  4.   Support. David spector (talk) 00:28, 1 December 2016 (UTC)[reply]
  5.   Support. -DePiep (talk) 12:32, 10 December 2016 (UTC)[reply]

Remember last used namespace

  • Problem: Loading a large watchlist takes time; if you want to focus on a namespace other than "all", you have to wait again.
  • Proposed solution: This is a trivial change that could have significant impact. (Option 1) Remember the last used namespace and apply it the next time the watchlist is accessed. (Option 2) Allow users to configure a preferred default namespace.
  • Who would benefit: Anyone who regularly selects namespaces other than "all" on their watchlists. Helps particularly those times you want to check for vandalism (namespace: article).
  • Phabricator tickets:

Community discussion

none

Voting – Remember last used namespace

  1.   Support. Useful when editing in non-article namespaces. David spector (talk) 00:29, 1 December 2016 (UTC)[reply]
  2.   Oppose--Dixtosa (talk) 15:30, 4 December 2016 (UTC)[reply]
  3.   Support as nominator. Samsara (talk) 22:01, 5 December 2016 (UTC)[reply]
  4.   Oppose -- Amanda (aka DQ) 21:23, 6 December 2016 (UTC)[reply]
  5.   Support SamanthaNguyen (talk) 23:55, 12 December 2016 (UTC)[reply]

Using watchlists to surface new articles on topics of interest

  • Problem: Discovery of new articles on subjects related to your editing interests is often clunky and requires some manual intervention. The result is that new articles may not be seen by people knowledgeable about their topic before being tagged for "cleanup" (which discourages new editors) or nominated for deletion. Articles already on a user's watchlist could be used to surface new articles on related subjects.
  • Who would benefit: Established editors whose interests focus on topic areas rather than processes; productive new editors whose early contributions are new articles.
  • Proposed solution: Currently the English Wikipedia has several tools for discovery of new articles on particular topics; however, they usually require manual intervention - either configuration of search terms and categories, or manual addition of WikiProject templates to article talk pages. This proposal is to use the articles already on a user's watchlist to surface new articles on related topics, possibly by making use of the Related Pages beta feature. New articles could be shown highlighted in the watchlist for users who opt in to this feature, or could be displayed on a separate Special page. This allows established editors to review new content across multiple areas of topic interest on a single page.
  • More comments: The purpose of this proposal is to facilitate review of new articles by editors who are knowledgeable about the topic of the article, using the articles on their watchlist as a proxy. Currently, on the English Wikipedia, new articles are often reviewed by editors who conceive of their task as "patrolling" new pages in the aggregate. This sometimes results in deletion nominations by editors who are unfamiliar with the article topic, and more frequently results in adding numerous "cleanup" tags to new articles - a behavior which is known to be discouraging to new editors (and which is currently encouraged by the tags' integration into the Page Curation tool). This proposal is a component of disaggregating the new-page patrol task, so that "patrolling" necessitates only review for simple issues requiring prompt deletion (e.g. vandalism or spam) and a larger pool of editors with topic-area focus can perform content-directed review with less urgency.

    A secondary consequence of this process change is that authors of new articles are more likely to receive feedback from editors knowledgeable about their topic, rather than editors simply monitoring the influx of new articles. Interaction with a topic-oriented organized group (such as a WikiProject) helps integrate new or less experienced editors into the community.

  • Phabricator tickets:

Community discussion

  • Once again, you and I - and I think a surprising number of others - agree completely on the subject of taggery. I just had a quick play with RelatedPages. Choosing three starting articles (one species, one historic individual, one scientific phenomenon) and browsing a further three articles via the suggestions (we're now looking at 18 suggestions) as well as a number of randomly selected newly created articles, I made three findings, only two of which are relevant here. I came away feeling one would have to watch very specific pages; the tool's goal is, as I understand, not to produce an exhaustive set, but rather, a small number of related items. The same applies to SuggestBot, another possible starting point (although only "some" of its source code is public - one wonders which parts are missing). On the positive side, RelatedPages generates meaningful results even for articles that contain no links or categories and are orphaned, but my sample article did contain references with correctly used templated formatting and links. My impression, although my sample was not perfect, is that text analysis is used to determine related pages - and, within the caveats stated above, this works (I saw that there are links for more details on the algorithm, but my bed has a backlog I must attend to). It also came to my attention a while ago that the German Wikipedia makes good use of lists of new articles by category, which I imagine relies on having a well-maintained strict hierarchy of categories, and on making it a priority to assign categories to new articles - which you've alluded to. Shouldn't we perhaps replace that tagging button on the page curation tool with a catting button? Also, if you're aware of any other comparisons of SuggestBot and RelatedPages, I'd be interested. Cheers, Samsara (talk) 05:24, 21 November 2016 (UTC)[reply]
    • It's funny, I hardly ever see anyone say they like tags and think they're useful, yet we've build this whole system around applying them. I never knew why they weren't banished to the talk pages ages ago. I've had related pages turned on for a while, and I noticed that it often seems to run out of specific similar pages and gives something very general (a stub about an animal virus gives "virus", that sort of thing), but maybe it's not really the best way to do this (as below). Opabinia regalis (talk) 06:36, 24 November 2016 (UTC)[reply]
  • I understand the desire, but am a bit concerned that the currently defined scope would be difficult to impossible to build a solution for that actually scales to a community the size of enwiki. From the computer science-y point of view what you are asking for is to select some number of nodes (e.g. your watchlist) in a graph (i.e. the set of all pages on enwiki) and then get notifications when any arbitrarily connected nodes (e.g. pages that are similar in topical content) in that same graph are created or modified. The biggest challenge here is the arbitrary connection between pages. This isn't just pages that transclude a common element or are in the same category (which is already challenging). The RelatedPages beta feature uses Elasticsearch to find pages that are similar in content based on word similarity rankings. For this to work in your case, the system would have to watch for each edit, use the edited page as the seed for a new related search, collect the resulting set of related pages, and then search through the watchlist of each user to see if a page in the related set is watched. The existing related search is not guaranteed to be exhaustive either; in fact is it deliberately limited to halt after a small number of matches are found. For a reliable notification feature the RelatedPages search would need to exhaustively compare all of the pages on the wiki for similarity following each edit. --BDavis (WMF) (talk) 23:09, 22 November 2016 (UTC)[reply]
    • I confess, I only thought of this while writing up this other proposal, and thought I was squeezing it in at the last minute before this survey closed, so I, uh, haven't thought through the implementation too well :) As you can guess from the other proposal, the genesis of this was interest in discovery of new articles on a topic basis, so it's not purely a second-degree-of-separation watchlist (though that would be cool!). So I think your description sounds maybe a little overengineered compared to what I had in mind - though I did assume that answering "what pages are RelatedPages to 'virus'?" or the like would be simple. I don't think it needs to update for every modification, only provide a list of new articles for which a given watchlisted page is related. Now that I think of it, I suppose it would have to just be its own Special page, since the watchlist is just a selection of recent changes.

      Anyway, the core idea behind this suggestion is to use articles you've watchlisted to suggest new pages on related subjects that you might want to review. We've already got bots that provide lists of new pages matching predefined criteria, and en:User:SuggestBot as Samsara mentioned above, but I think people would be more willing to review new articles and provide support to their authors if the articles were more organically discoverable. Opabinia regalis (talk) 06:36, 24 November 2016 (UTC)[reply]

      • +1 on the over-engineering, particularly: the system would have to watch for each edit. There is already processing that happens on each edit. The question is how much this new mechanism would add. As I understand it, only the first edit (page creation) would trigger the processing, and only if it's larger than some predefined threshold that allows good predictive accuracy; if it's been processed, you set a flag against the page (not the rev). If it hasn't been processed, you keep checking on subsequent edits whether it has gotten over the threshold (or check size before flag, whichever is computationally cheaper; for most articles, flag check is more likely to fail). Optionally, once it's been seen (or edited, if a seeing criterion is not available) by more than e editors, you never run the search. I'm also not sure that the search needs to be exhaustive - I think a sane default would be running the search until at least a dozen active users' watchlists have been hit (or whatever this equates to in terms of users whose activity status is not known - I note that an activity criterion seems to be available in the "watched by" stats). Samsara (talk) 05:25, 26 November 2016 (UTC)[reply]
        • Yes, this sounds more like it. Possibly more than a dozen editors, to get one who will notice and care to review, but yes, it would probably be a better experience from the perspective of the watchlist-owner too if they only get a subset of the possible new pages presented to them. (I could be overgeneralizing from my own experience, but I'd be a lot more likely to work on my SuggestBot suggestions if they came in batches of 5, not 30. And if they didn't come with a huge table of which tags were on them....) Opabinia regalis (talk) 03:58, 27 November 2016 (UTC)[reply]
  • I think I know why this isn't getting much vote attention -- it's too complicated as presented. Since watchlists are about watching edits to pages, let's keep it in that paradigm, but perhaps add a checkbox for watching edits to related pages (pages related to pages you're watching) as determined by the Related Pages beta. Also, these related pages edits should probably be formatted differently in the list. Stevie is the man! Talk • Work 15:51, 5 December 2016 (UTC)[reply]

Voting – Using watchlists to surface new articles on topics of interest

  1.   Support, ones watchlist-entries should be built into a system of article-suggestions. Please also see my relevant suggestion "Suggestions for WikiProjects to join". --Fixuture (talk) 20:00, 2 December 2016 (UTC)[reply]
  2.   Support as proposer. Opabinia regalis (talk) 03:52, 4 December 2016 (UTC)[reply]
  3.   Support Samsara (talk) 21:59, 5 December 2016 (UTC)[reply]
  4.   Support Being a fairly niche editor (classical music) this would be useful Iadmc (talk) 05:33, 8 December 2016 (UTC)[reply]
  5.   Support Solstag (talk) 12:34, 11 December 2016 (UTC)[reply]
  6.   Support It would be nice if it included possibility of setting list of regex strings, and if page that has stuff that matched any of those expressions have been created, then show it in watchlist (or notify user) --Similartothissimilartothat 21:45, 11 December 2016 (UTC)[reply]
  7.   Neutral I am somewhat worried about using watchlists for some further research. They are a great source of data indeed, but they are not supposed to be public, period — NickK (talk) 23:09, 12 December 2016 (UTC)[reply]

Watch only a section

  • Problem: If you are only interested in one section, for example, in user discussions, you must always watch the whole page. Especially when that is a well-used page, it is hard to find the changes that you really want to observe.
  • Who would benefit: All users (except IPs)
  • Proposed solution: Section watching

Community discussion

Already asked for in phab:T2738. Jo-Jo Eumerus (talk, contributions) 09:43, 19 November 2016 (UTC)[reply]

Voting – Watch only a section

  1.   Support Three words: Administrators' Noticeboard/Incidents. — Gestrid (talk) 01:03, 28 November 2016 (UTC)[reply]
  2.   Support. This would be highly useful. Stevie is the man! Talk • Work 02:51, 28 November 2016 (UTC)[reply]
  3.   Support Samwalton9 (talk) 09:33, 28 November 2016 (UTC)[reply]
  4.   Support --Micru (talk) 16:06, 28 November 2016 (UTC)[reply]
  5.   Comment I won't oppose this suggestion (since it doesn't count anyway), but I think wikis which have rejected Flow (for whatever reason) for the predominant use case (talk pages) really have just shot themselves in the foot on the matter. --Izno (talk) 01:50, 29 November 2016 (UTC)[reply]
  6.   Support שי אבידן (talk) 13:32, 29 November 2016 (UTC)[reply]
  7.   Support KPFC 💬 14:30, 29 November 2016 (UTC)[reply]
  8.   Comment Izno is right. --YMS (talk) 16:31, 29 November 2016 (UTC)[reply]
  9.   Oppose per Izno. Matěj Suchánek (talk) 16:59, 29 November 2016 (UTC)[reply]
  10.   Oppose, Flow or bust. Max Semenik (talk) 18:54, 29 November 2016 (UTC)[reply]
  11.   Support – While it is possible using Flow, the vast majority of pages don't use Flow (yet). Guycn2 · ☎ 19:21, 29 November 2016 (UTC)[reply]
  12.   Support I don't care about flow. Alexei Kopylov (talk) 08:07, 30 November 2016 (UTC)[reply]
  13.   Support --Fixuture (talk) 21:17, 30 November 2016 (UTC)[reply]
  14.   Support --CorrectHorseBatteryStaple (talk) 23:42, 30 November 2016 (UTC)[reply]
  15.   Support. David spector (talk) 00:32, 1 December 2016 (UTC)[reply]
  16.   Support iff the solution is not Flow. Strong   Oppose otherwise. MER-C (talk) 05:18, 1 December 2016 (UTC)[reply]
  17.   Oppose Not useful. Flow can be the solution. Lot of things are more more useful. --Nouill (talk) 14:40, 1 December 2016 (UTC)[reply]
  18.   Support Libcub (talk) 02:54, 2 December 2016 (UTC)[reply]
  19.   Support Dalba 04:54, 2 December 2016 (UTC)[reply]
  20.   Support SamanthaNguyen (talk) 05:12, 2 December 2016 (UTC)[reply]
  21.   Comment I suggest using Flow. -Geraki TL 07:14, 2 December 2016 (UTC)[reply]
  22.   Support Flow was a good idea in principle, but just didn't prove a good fit for most needs. The problems that Flow might have solved are still problems, though, and this is a major one. Opabinia regalis (talk) 03:53, 4 December 2016 (UTC)[reply]
  23.   Support until flow flows in--Dixtosa (talk) 15:31, 4 December 2016 (UTC)[reply]
  24.   Support --Gnom (talk) Let's make Wikipedia green! 16:42, 5 December 2016 (UTC)[reply]
  25.   Support Strong support, and Flow is unlikely to be the solution. I considered proposing this myself. --Tryptofish (talk) 00:49, 6 December 2016 (UTC)[reply]
  26.   Comment What those pushing Flow should note is that we might want to watch sections of large, frequently edited content pages (articles) too, and Flow isn't used for those. Stevie is the man! Talk • Work 12:06, 6 December 2016 (UTC)[reply]
  27.   Support very useful for mass talkpages (such as ANI and Ask the Expert pages), and also for heavily edited pages which might have a section which one is interested in. --SuperJew (talk) 19:15, 6 December 2016 (UTC)[reply]
  28.   Support AN/I. Nuff said.--Elmidae (talk) 16:25, 7 December 2016 (UTC)[reply]
  29.   Support until Flow is fully functional. –Tommy Kronkvist (talk), 07:33, 8 December 2016 (UTC).[reply]
  30.   Support Lack of this is a show-stopper for me for active participation in forums. Required companion features are the ability to quickly unsubscribe from a topic and handling new topics in one of the few ways: either ignore, of subscribe automatically, or get just the leading messages so that I can decide whether I'm interested. Preferrably, this should be possible from some push notification system like the RSS feed. See http://softwarerecs.stackexchange.com/q/37335/27685 - according to the result (or rather, lack thereof), currently, there are no solutions to this problem at all! Ivan Pozdeev (talk) 11:53, 8 December 2016 (UTC)[reply]
  31.   Support — Rhododendrites talk \\ 14:56, 8 December 2016 (UTC)[reply]
  32.   Support Whats new? (talk) 22:49, 8 December 2016 (UTC)[reply]
  33.   Support No Flow 4nn1l2 (talk) 23:50, 8 December 2016 (UTC)[reply]
  34.   Support Flow was never going to be a good fit for being able to watch sections anywhere other than talk pages, and there are a lot of use cases outside of those narrow limits. Risker (talk) 03:20, 9 December 2016 (UTC)[reply]
  35.   Support If the solution is not Flow. --Alaspada (Talk) 01:58, 11 December 2016 (UTC)[reply]
  36.   Support Yes, please - much needed for ANI, Village Pumps, etc. PamD (talk) 09:31, 11 December 2016 (UTC)[reply]
  37.   Support SamanthaNguyen (talk) 16:06, 11 December 2016 (UTC)[reply]
  38.   Support Flow is bletcherous, and not a solution to anything. And it has nothing to do with article text; there are quite a few articles I would want to watchlist sections of.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:51, 11 December 2016 (UTC)[reply]
  39.   Support - DPdH (talk) 21:14, 11 December 2016 (UTC)[reply]
  40.   Support FoCuSandLeArN (talk) 23:00, 11 December 2016 (UTC)[reply]
  41.   Support. I also want to use this not only for talk pages but for articles as well (e.g. I may want to be interested in watching only en:List of conflicts in Europe#21st century but not the entire article — NickK (talk) 23:11, 12 December 2016 (UTC)[reply]

Watchlist drop-down options with less restrictive defaults

Machine translated from German -- please help improve! Variables Drop-Down-Menü mit weniger einschränkenden Vorgaben

  • Problem: The drop-down menu has only certain options to choose from. I would like a free selection field, where I can also set about 8 hours, 2 days, 100 days or 30 minutes. In addition, the restriction is limited to 1000 posts and 30 days - unnecessary.
Das Drop-Sown-Menü hat nur bestimmte Abstände zur Auswahl. Ich möchte hier ein freies Auswahlfeld, wo ich etwa auch 8 Stunden, 2 Tage, 100 Tage oder 30 Minuten einstellen kann. Zudem ist die Einschränkung auf 1000 Beiträge und 30 Tage beschränkt - unnötig.
  • Who would benefit: A more useable watchlist for active contributors
besser nutzbare Beobachtungsliste für aktive Autoren
  • Proposed solution: Free input field, and termination of the restrictions.
Freies Eingabefeld und Beendigung der Restriktionen
  • Phabricator tickets:

Community discussion

@Marcus Cyron: It is possible to type our own limits into the URL bar, e.g. ~8 hours = https://meta.wikimedia.org/w/index.php?title=Special%3AWatchlist&days=0.34
Re: free selection field - this would be a lot more complicated because it would need to understand "days" "hours" "minutes" in 280+ languages and a few numeral systems. It would also require more explanatory text in the Preferences page. It is easier technically (at all levels of code) to give pre-defined options, and translate those. It is easier for the majority of users to use pre-defined settings, or use the setting 1-level above what they want. Advanced users can just alter the URL, as above.
Re: the 1,000 page limit, I've filed phab:T151165. Re: the 30 day limit, the watchlist is based on the Recent Changes database, so that cannot easily be changed.
Hope that helps, and apologies for replying in English. Quiddity (WMF) (talk) 21:10, 20 November 2016 (UTC)[reply]
@Marcus Cyron: However, there is related work in phab:T120733 to add a dropdown datepicker to the Special:Contributions page. Would that be an acceptable solution for watchlists? If so perhaps you could update your proposal above? Thanks. Quiddity (WMF) (talk) 22:48, 22 November 2016 (UTC)[reply]

Voting – Watchlist drop-down options with less restrictive defaults

  1.   Support, for abolishing the 1000 this one is relevant: phab:T151165. --Fixuture (talk) 21:19, 30 November 2016 (UTC)[reply]
  2.   Support -- Marcus Cyron (talk) 12:08, 4 December 2016 (UTC)[reply]
  3.   Support per Fixuture. Stevie is the man! Talk • Work 14:34, 5 December 2016 (UTC)[reply]
  4.   Support I might be away from Wikipedia for two months but I still want to watch my articles when I am back. 4nn1l2 (talk) 23:53, 8 December 2016 (UTC)[reply]
  5.   Support SamanthaNguyen (talk) 15:38, 11 December 2016 (UTC)[reply]

Watchlist "Mark all visited" synchronization

  • Problem: When an user clicks on "Mark all visited" button on the watchlist page, all pages edited at that time are marked as visited, even if they are not displayed. For example the pages that were edited after the watchlist page was loaded are marked as visited, even if the user did have a chance to see them. Because of this, it is easy to miss an edit.
  • Who would benefit: Anyone who uses watchlist (i.e. everybody), especially editors that have large watchlists.
  • Proposed solution: Mark pages as visited only if they are currently displayed. That is, do not mark
    • pages that were edited after the page was loaded
    • pages that are currently hidden from the watchlist (e.g. when the user watch only edits in a particular namespace or hide - say - minor edits)
    • pages that are not shown because there are too many pages to show

Community discussion

  • I definitely agree with the thrust of this proposal, especially with regards to "pages that were edited after the [watchlist] page was loaded". I get caught on these frequently. The other aspects may be hairier to implement or make easily apparent to the user. Stevie is the man! Talk • Work 17:36, 13 November 2016 (UTC)[reply]

Voting – Watchlist "Mark all visited" synchronization

  1.   Support for "pages that were edited after the [watchlist] page was loaded". I'm still undecided on the other scenarios. I would like to see more discussion on those. Stevie is the man! Talk • Work 02:54, 28 November 2016 (UTC)[reply]
  2.   Support Alexei Kopylov (talk) 07:57, 30 November 2016 (UTC)[reply]
  3.   Support Like Stevie is the man --β16 - (talk) 11:46, 5 December 2016 (UTC)[reply]
  4.   Support Always believed its already true. --Dalka (talk) 10:36, 9 December 2016 (UTC)[reply]
  5.   Support SamanthaNguyen (talk) 15:38, 11 December 2016 (UTC)[reply]
  6.   Support - DPdH (talk) 19:56, 11 December 2016 (UTC)[reply]

Watchlist priorities or Multiple watchlists

  • Problem: Long-time editors have very large watchlists (in the four or five digits), and can be overwhelmed by the load, especially if they become less active. Watchlists are somewhat hard to navigate, and currently only organized by namespace.
  • Who would benefit: All editors, administrators, etc. but especially veteran editors
  • Proposed solution: Introduce the ability to set priorities for each article on the watchlist, and the ability to sort by priority, auto-include self-made articles in the high priority list, etc.

Watchlists should have a function for "labels/folders" to act more naturally like bookmarks in a web browser. This would have multiple uses for many people, such as creating a collection of educational resources; For marking what articles to edit, such as a folder named "United States 50,000 Challenge" which would contain articles to edit.; For creating a collection of templates that an editor uses a lot; For articles to read later (similar to how YouTube has a "Watch Later function")

Some other things that would also assist with more natural bookmark management, would be the ability to customize label colors, and move labels around.

(and merged details from a duplicate by SamanthaNguyen (talk) 02:54, 15 November 2016 (UTC))[reply]

Community discussion

Its very logical and helpful thing. -Nizil Shah (talk) 02:10, 11 November 2016 (UTC)[reply]

Voting – Watchlist priorities or Multiple watchlists

  1.   Support Multiple watchlists separated by named folders/tabs. I oppose priorities because they are too hard to keep track of compared to having a name that reminds me of why a watched page is in a particular folder/tab. Heck, you could name a folder/tab "High priority", and if you wanted folders numerically sortable, you can begin the names with a number. Also, I suppose watchlist entries would start off in a default folder before being re-assigned to a named one. I'm open to how this would be designed, but it should be as breezy to use as possible. Last, this would work great in concert with #"Hide trusted users" checkbox option on watchlists and related/recent changes (RC) pages for helping to keep our watchlist service work to a minimum. Stevie is the man! Talk • Work 03:08, 28 November 2016 (UTC)[reply]
  2.   Support Agree that categories should be namable so that you could name them after priorities if you wanted, and not if you don't. Samwalton9 (talk) 09:34, 28 November 2016 (UTC)[reply]
  3.   Support Sadads (talk) 15:21, 28 November 2016 (UTC)[reply]
  4.   Support MichaelMaggs (talk) 20:26, 28 November 2016 (UTC)[reply]
  5.   Support {{Nihiltres |talk |edits}} 21:44, 28 November 2016 (UTC)[reply]
  6.   Support --Jack Phoenix (Contact) 22:46, 28 November 2016 (UTC)[reply]
  7.   Support SamanthaNguyen (talk) 23:12, 28 November 2016 (UTC)[reply]
  8.   Comment This can be worked around using Special:Recentchangeslinked. --Izno (talk) 01:52, 29 November 2016 (UTC)[reply]
    But it requires manually maintaining pages of links, and isn't integrated with watch/unwatch and other potential watchlist features. Stevie is the man! Talk • Work 22:12, 29 November 2016 (UTC)[reply]
  9.   Support Nocowardsoulismine (talk) 02:01, 29 November 2016 (UTC)[reply]
  10.   Support Alexei Kopylov (talk) 07:59, 30 November 2016 (UTC)[reply]
  11.   Support MER-C (talk) 05:18, 1 December 2016 (UTC)[reply]
  12.   Support Ermahgerd9 (talk) 19:05, 1 December 2016 (UTC)[reply]
  13.   Support Jmvkrecords ⚜ (Intra talk) 10:28, 2 December 2016 (UTC). For the moment, if I want a different watchlist, I need to create a sockpuppet.[reply]
  14.   Support // Martin Kraft (talk) 23:42, 2 December 2016 (UTC)[reply]
  15.   Support Opabinia regalis (talk) 03:58, 4 December 2016 (UTC)[reply]
  16.   Support -- Aspiriniks (talk) 09:43, 4 December 2016 (UTC)[reply]
  17.   Support Pamputt (talk) 10:51, 4 December 2016 (UTC)[reply]
  18.   Support -- Marcus Cyron (talk) 12:04, 4 December 2016 (UTC)[reply]
  19.   Support -- the wub "?!" 13:52, 4 December 2016 (UTC)[reply]
  20.   Support --Anika (talk) 14:09, 4 December 2016 (UTC)[reply]
  21.   Support --By erdo can (talk) 14:11, 4 December 2016 (UTC)[reply]
  22.   Support --MGChecker (talk) 14:33, 4 December 2016 (UTC)[reply]
  23.   Support --Santga (talk) 23:10, 4 December 2016 (UTC)[reply]
  24.   Support -<(kmk)>- (talk) 01:38, 5 December 2016 (UTC) yes, please![reply]
  25.   Support --Continua Evoluzione (talk) 10:24, 5 December 2016 (UTC)[reply]
  26.   Support --Andropov (talk) 17:20, 5 December 2016 (UTC)[reply]
  27.   Support This is an excellent idea. I love the idea of having folders within a watchlist. Strong support. --Tryptofish (talk) 00:52, 6 December 2016 (UTC)[reply]
  28.   Support -- Amanda (aka DQ) 21:25, 6 December 2016 (UTC)[reply]
  29.   Support Ks0stm (T•C•G) 21:26, 6 December 2016 (UTC)[reply]
  30.   Support Antiqueight (talk) 13:59, 7 December 2016 (UTC)[reply]
  31.   Support--Elmidae (talk) 16:26, 7 December 2016 (UTC)[reply]
  32.   Support — Rhododendrites talk \\ 14:57, 8 December 2016 (UTC)[reply]
  33.   Support Whats new? (talk) 22:50, 8 December 2016 (UTC)[reply]
  34.   Support Risker (talk) 03:21, 9 December 2016 (UTC)[reply]
  35.   Support Magalia (talk) 07:26, 9 December 2016 (UTC)[reply]
  36.   Support Ayack (talk) 12:06, 9 December 2016 (UTC)[reply]
  37.   Support Smalljim (talk) 15:32, 9 December 2016 (UTC)[reply]
  38.   Support Elekhh (talk) 23:37, 9 December 2016 (UTC)[reply]
  39.   Support --OrsolyaVirág (talk) 13:23, 10 December 2016 (UTC)[reply]
  40.   Support Great idea. We also need the Global watchlist! Reguyla (talk) 18:39, 10 December 2016 (UTC)[reply]
  41.   Support --Alaspada (Talk) 02:01, 11 December 2016 (UTC)[reply]
  42.   Support Doug Weller (talk) 18:04, 11 December 2016 (UTC)[reply]
  43.   Support So much want this. I've actually stopped using my watchlist almost entirely because it's just too monolithic to be useful.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:35, 11 December 2016 (UTC)[reply]
  44.   Support --Plagiat (talk) 19:10, 11 December 2016 (UTC)[reply]
  45.   Support - Very useful. DPdH (talk) 19:58, 11 December 2016 (UTC)[reply]
  46.   Support – Uanfala (talk) 01:34, 12 December 2016 (UTC)[reply]
  47.   Support in whatever format, main reason why I don't want to keep all articles I want on my watchlist — NickK (talk) 23:12, 12 December 2016 (UTC)[reply]
  48.   Support Samat (talk) 00:00, 13 December 2016 (UTC)[reply]

Watchlist SMS text notifications

  • Problem: Most of us follow a lot of pages, but there are a few we monitor regularly. It would be nice if a "check-box" could be put on those pages we follow a lot, that would allow an SMS to be sent to a specific email address to notify the watcher of changes and modifications.
  • Who would benefit: All users.
  • Proposed solution: Add a checkbox to all pages in the users watch list, to allow a user to tag that page for SMS notifications.
  • More comments: This would eliminate scrolling through hundreds of pages in the "Watchlist" View.
  • Phabricator tickets:

Community discussion

@Mikepellerin: This would be a potential feature once "multiple watchlists" are available. That work is slowly progressing at the deeper levels, in the tasks linked from phab:T3492. AFAIK it isn't practical to implement this kind of feature, until that backend work is complete. Quiddity (WMF) (talk) 21:15, 20 November 2016 (UTC)[reply]

The problem states "allow an SMS to be sent to a specific email address" which seems redundant since you already can get notifications by email. If one really wants SMS, it could be done through the external service w:IFTTT today. Ainali (talk) 10:23, 1 December 2016 (UTC)[reply]

Voting – Watchlist SMS text notifications

  1.   Oppose This will just encourage editwarring. "Hold on, I gotta call you back; someone edited my article, dammit." No thanks.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:36, 11 December 2016 (UTC)[reply]
  2.   Oppose, no SMS notifications in general please, I don't want some American editor wake my up in the middle of European night — NickK (talk) 23:13, 12 December 2016 (UTC)[reply]

Watchlist sorted or coded to show page-traffic surges

  • Problem: It would be nice to be able to see what articles on one's watchlist are having a surge in viewership. It might indicate that the article has been linked to from a discussion group, website or is the topic of some current event. This could let me give more importance where more eyes are going and make it possible to react by improving the article or being more alert.
  • Who would benefit: All watchlisters. This would help put in more importance to pages that are currently experiencing increased traffic - either by being in the news or being linked via high-traffic sites.
  • Proposed solution: spike factor = (float)(number of page-views yesterday)/(average page views in the previous window of 5-10 days) - the window size could be a preference setting (and of course handle division by zero etc.). This factor is used to color-code or sort watchlist entries.
  • Phabricator tickets:

Community discussion

Voting – Watchlist sorted or coded to show page-traffic surges

no votes for this proposal

Add a button in the watchlist to remove pages

  • Problem: Watchlist can be too long
  • Who would benefit: All users
  • Proposed solution: Add a "remove from watchlist" button next to each item that displays

Community discussion

@LT910001: Please edit your proposal by filling in a title of your proposal, and by describing the actual problem that is created because the watchlist is too long, so it becomes possible to discuss whether your proposed solution is actually the best solution for the (currently still undefined) problem. Thanks! --AKlapper (WMF) (talk) 10:33, 8 November 2016 (UTC)[reply]

Check out en:User:PerfektesChaos/js/listPageOptions. It provides this feature. Stevie is the man! Talk • Work 14:46, 8 November 2016 (UTC)[reply]

Voting – Add a button in the watchlist to remove pages

  1.   Support if this can expedite development. This would be very nice to have. Stevie is the man! Talk • Work 03:12, 28 November 2016 (UTC)[reply]
  2.   Support - Gareth (talk) 07:30, 28 November 2016 (UTC)[reply]
  3.   Support Samwalton9 (talk) 09:35, 28 November 2016 (UTC)[reply]
  4.   Support I thought we had this feature once, and then it disappeared. Kudpung (talk) 14:54, 28 November 2016 (UTC)[reply]
  5.   Support --Micru (talk) 16:06, 28 November 2016 (UTC)[reply]
  6.   Support MichaelMaggs (talk) 20:27, 28 November 2016 (UTC)[reply]
  7.   Support JAn Dudík (talk) 22:16, 28 November 2016 (UTC)[reply]
  8.   Support Nocowardsoulismine (talk) 02:02, 29 November 2016 (UTC)[reply]
  9.   Support Arian Talk 13:27, 29 November 2016 (UTC)[reply]
  10.   Support KPFC 💬 14:31, 29 November 2016 (UTC)[reply]
  11.   Support Spinster (talk) 15:32, 29 November 2016 (UTC)[reply]
  12.   Support – While some gadgets do it perfectly, I'd like to have it built-in on MediaWiki core. Guycn2 · ☎ 19:23, 29 November 2016 (UTC)[reply]
  13.   Support --Jarekt (talk) 03:38, 30 November 2016 (UTC)[reply]
  14.   Support Sadads (talk) 15:01, 30 November 2016 (UTC)[reply]
  15.   Support Trizek from FR 19:56, 30 November 2016 (UTC)[reply]
  16.   Support. David spector (talk) 00:34, 1 December 2016 (UTC)[reply]
  17.   Support MER-C (talk) 10:51, 1 December 2016 (UTC)[reply]
  18.   Support — Pajz (talk) 12:31, 1 December 2016 (UTC)[reply]
  19.   Support --Nouill (talk) 14:38, 1 December 2016 (UTC)[reply]
  20.   Support --Chris Howard (talk) 18:24, 1 December 2016 (UTC)[reply]
  21.   Support --Grabado (talk) 18:50, 1 December 2016 (UTC)[reply]
  22.   Support Long overdue. --Vachovec1 (talk) 20:45, 1 December 2016 (UTC)[reply]
  23.   Support Would be nice --Horsegeek (talk) 23:52, 1 December 2016 (UTC)Horsegeek[reply]
  24.   Support NMaia (talk) 00:31, 2 December 2016 (UTC)[reply]
  25.   Support --XXN (talk) 01:12, 2 December 2016 (UTC)[reply]
  26.   Support Libcub (talk) 02:57, 2 December 2016 (UTC)[reply]
  27.   Support This would save a of click and reduce the need to load article page as well as the short wait. - Shiftchange (talk) 04:37, 2 December 2016 (UTC)[reply]
  28.   Support --Geraki TL 08:11, 2 December 2016 (UTC)[reply]
  29.   Support Jmvkrecords ⚜ (Intra talk) 10:30, 2 December 2016 (UTC).[reply]
  30.   Support Draceane (talk) 10:58, 2 December 2016 (UTC)[reply]
  31.   Support —Jc86035 (talk) 11:20, 2 December 2016 (UTC)[reply]
  32.   Support // Martin Kraft (talk) 23:42, 2 December 2016 (UTC)[reply]
  33.   Support Should be simple to do and would be nice. Doc James (talk · contribs · email) 03:59, 3 December 2016 (UTC)[reply]
  34.   Support Pamputt (talk) 10:52, 4 December 2016 (UTC)[reply]
  35.   Support -- the wub "?!" 13:43, 4 December 2016 (UTC)[reply]
  36.   Support --By erdo can (talk) 14:10, 4 December 2016 (UTC)[reply]
  37.   Support This would be a big help to users with large watchlists (like me). Kaldari (talk) 21:09, 4 December 2016 (UTC)[reply]
  38.   Support --Santga (talk) 23:00, 4 December 2016 (UTC)[reply]
  39.   Support Studmult (talk) 07:57, 5 December 2016 (UTC)[reply]
  40.   Support --Yeza (talk) 10:06, 5 December 2016 (UTC)[reply]
  41.   Support --Continua Evoluzione (talk) 10:21, 5 December 2016 (UTC)[reply]
  42.   Support ·addshore· talk to me! 10:49, 5 December 2016 (UTC)[reply]
  43.   Support but not high priority. Just a nice convenience. --Tryptofish (talk) 00:53, 6 December 2016 (UTC)[reply]
  44.   Neutral it's a nice convenience, but I think there are higher priority proposals. --SuperJew (talk) 19:17, 6 December 2016 (UTC)[reply]
  45.   Support -- Amanda (aka DQ) 21:25, 6 December 2016 (UTC)[reply]
  46.   Support --Rschen7754 07:05, 7 December 2016 (UTC)[reply]
  47.   Support SamanthaNguyen (talk) 23:56, 7 December 2016 (UTC)[reply]
  48.   Support Mcfar54 (talk) 01:37, 8 December 2016 (UTC)[reply]
  49.   Neutral Handy shortcut, but this one would be more useful for managing big watchlists. Rivertorch (talk) 05:42, 8 December 2016 (UTC)[reply]
  50.   Support --Dirk Beetstra T C (en: U, T) 08:45, 8 December 2016 (UTC)[reply]
  51.   Support Useful. Jianhui67 talk★contribs 10:59, 8 December 2016 (UTC)[reply]
  52.   Support Risker (talk) 03:22, 9 December 2016 (UTC)[reply]
  53.   Support Sydney Poore/FloNight (talk) 04:03, 9 December 2016 (UTC)[reply]
  54.   Support This would definitely save time. Espresso Addict (talk) 04:23, 9 December 2016 (UTC)[reply]
  55.   Support--Shizhao (talk) 06:47, 9 December 2016 (UTC)[reply]
  56.   Support Ayack (talk) 12:06, 9 December 2016 (UTC)[reply]
  57.   Support Miniapolis 20:55, 9 December 2016 (UTC)[reply]
  58.   Support Elekhh (talk) 23:38, 9 December 2016 (UTC)[reply]
  59.   Support --OrsolyaVirág (talk) 13:23, 10 December 2016 (UTC)[reply]
  60.   Support Great idea Reguyla (talk) 18:40, 10 December 2016 (UTC)[reply]
  61.   Support --Alaspada (Talk) 02:05, 11 December 2016 (UTC)[reply]
  62.   Support helpful to those of us with bloated Watchlists. PamD (talk) 09:33, 11 December 2016 (UTC)[reply]
  63.   Support This would be very helpful. SarahSV talk 15:58, 11 December 2016 (UTC)[reply]
  64.   Support YES!  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:36, 11 December 2016 (UTC)[reply]
  65.   Support --Similartothissimilartothat 18:45, 11 December 2016 (UTC)[reply]
  66.   Support - Very useful. DPdH (talk) 20:03, 11 December 2016 (UTC)[reply]
  67.   Support Tdslk (talk) 20:11, 11 December 2016 (UTC)[reply]
  68.   Support Although this functionality is provided by some gadgets (like en:Wikipedia:Tools/Navigation popups), it definitely needs to be built-in. – Uanfala (talk) 01:38, 12 December 2016 (UTC)[reply]
  69.   Support --Yann (talk) 23:49, 12 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Watchlists&oldid=24950213"