Community Wishlist Survey 2016/Categories/Moderation tools

Community Wishlist Survey 2016

Moderation tools

13 proposals, 163 contributors, 264 support votes

Mobile and apps  •  Multimedia

Shortcut for patrollers to last changes list

• Problem: At least at noWP, patrolling is slowed down since there are too many clicks to get from "Successfully patrolled" and back to the "Last changes"-list. Recent changes for patrollers marks changes done by newbies, IP's and other non-autopatrolled contributors with a sign. noWP has a red exclamation mark: !. Clicking the "diff" shows changes on blue background. If changes are OK, there is a button named "Mark patrolled". Clicking this, one gets a pop-up telling if patrolling was done or in rare cases: "Try once more". Then the snag is to get back to "Recent changes" ASAP. I found that the best way to do so goes via the back-arrow on the browser or the two-finger dropdown function (in my case: Safari on a Mac-laptop). But that releases a need for more steps backwards than I appreciate. If the patrolling also involves editing, it often calls for still more steps (clicks) to get back to the list of recent changes. Short-cuts ought not to add too much to the logs.

• Who would benefit: Patrollers and others with patrolling-rights

• Proposed solution: Short-cut past the "Edit" and then the actual page before getting to next unpatrolled entry. I therefore believe that an extra button: "Back to Recent changes", (Norwegian: "Tilbake til siste endringer") may be useful.

• Phabricator tickets:

• Proposer: Bjørn som tegner (talk) 15:20, 14 November 2016 (UTC)

• Translations: none yet

Community discussion

• @Bjørn som tegner: Please could you add links and details above, to any examples that would be helpful for editors who want to understand (but who are unfamiliar with the patrol process - many wikis have different/unique configurations in that area, and not all editors use that workflow regularly even when it is available). E.g. Are you talking about starting from a specific Special: page? E.g. Can you link to each page that is encountered during your usual process of patrolling (including action=edit type pages). Thanks. Quiddity (WMF) (talk) 23:37, 14 November 2016 (UTC)

I'll try: Recent changes for patrollers marks changes done by newbies, IP's and other non-autopatrolled contributors with a sign. noWP has a red exclamation mark: !. Clicking the "diff" shows changes on blue background. If changes are OK, there is a button named "Mark patrolled". Clicking this, one gets a pop-up telling if patrolling was done or in rare cases: "Try once more". Then the snag is to get back to "Recent changes" ASAP. I found that the best way to do so goes via the back-arrow on the browser or the two-finger dropdown function (in my case: Safari on a Mac-laptop). But that releases a need for more steps backwards than I appreciate.

If the patrolling also involves editing, it often calls for still more steps (clicks) to get back to the list of recent changes.

All in all, I therefore believe that an extra button: "Back to Recent changes", (Norwegian: "Tilbake til siste endringer") may be useful.--Bjørn som tegner (talk) 10:26, 15 November 2016 (UTC) PS: If this should be moved to the Problem-description, please feel free to do so. Bst.

Hi Bjørn som tegner, I moved your answer into the proposal. Please feel free to edit it, and smooth out any mistakes that I might have made. :) -- DannyH (WMF) (talk) 18:09, 22 November 2016 (UTC)

Thanks – looks OK. --Bjørn som tegner (talk) 18:12, 22 November 2016 (UTC)

Voting - Shortcut for patrollers to last changes list

1.  Support FoCuSandLeArN (talk) 17:29, 29 November 2016 (UTC)
2.  Support —— DePlusJean (from FR)
3.  Support The current system at no-wiki sounds untenable. It needs fixed. Chris Troutman (talk) 07:06, 11 December 2016 (UTC)
4. Neutral - I can a benefit for this, but I get around this and similar issues by always opening pages I'm reviewing (from any of the lists) in new tabs. KylieTastic (talk) 12:16, 11 December 2016 (UTC)
5.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)

Adjust number of entries and days at Last unpatrolled

• Problem: Need for a simpler way to adjust the number of entries and number of days at "Last changes" and "Last unpatrolled"

• Who would benefit: Patrollers at Wikis with long backlogs going back at least 30 days. Specially difficult for new patrollers. "As is" tends to give back-of -backlog- disappearances.

• Proposed solution: Some kind of shortcut

• Phabricator tickets:

• Proposer: Bjørn som tegner (talk) 15:27, 14 November 2016 (UTC)

• Translations: none yet

Community discussion

• @Bjørn som tegner: I'm afraid we don't really understand your proposal. Are you asking for Special:RecentChanges to include more than 30 days of changes and more than 500 changes? It's already simple to "adjust the number of entries and number of days", so I'm not sure what you mean. Could you elaborate? Ryan Kaldari (WMF) (talk) 18:17, 22 November 2016 (UTC)
• Yeah, I wish I could give input, but I do not quite understand exactly what it is you are proposing. Could you please give a little more clarification? CLCStudent (talk) 15:51, 8 December 2016 (UTC)

Voting - Adjust number of entries and days at Last unpatrolled

1.  Support FoCuSandLeArN (talk) 17:29, 29 November 2016 (UTC)
2.  Support --Newbiepedian (talk) 02:20, 8 December 2016 (UTC)

All edits from hardblocked IP mark as unreviewed

• Problem: Many times, abused IPs get blocked long term (6-months and longer) from all edits—including logged in editors. Many of these are public access IPs at libraries, coffee shops and restaurants, just to name a few.

• Who would benefit: everyone

• Proposed solution: 1. Allow an in-between block parameter that would CAPTcha and delay each edit to slow down abuse. 2. Mark all edits from the blocked IP as unreviewed, subject to approval from an editor with the "reviewer" flag.

• More comments: I hope this is seen as beneficial and not some loophole for spammers as I really have little patience for people who have nothing better to do than post junk on the wiki.

• Phabricator tickets:

• Proposer: VegasCasinoKid (talk) 08:00, 11 November 2016 (UTC)

• Translations: none yet

Community discussion

• From the point of view of an adminstrator who frequently blocks IPs, I think this would be very useful. It might also help to reduce the need for extended blocks on IPs that belong to schools and universities which are often the source of much vandalism, but also the source of useful content and are venues for editathons. --Kudpung (talk) 11:36, 13 November 2016 (UTC)
• w:Wikipedia:Deferred changes is half of this proposal. The other half can be achieved with the abuse filter. Come to think about it, this kind of targeted degradation of service may be a more powerful deterrent mechanism than normal IP blocks with less collateral damage and should be considered for core software. Slapping a range with a one action per five minutes throttle would lead to IP hopping vandals getting bored quickly, yet allows casual contributions through. @MusikAnimal: any chance of this getting shoehorned into Community Tech's current project of improving blocking tools? (It's a pity that our CAPTCHA is currently useless, but that should be fixed shortly.) MER-C (talk) 08:20, 14 November 2016 (UTC)
• @VegasCasinoKid: Is there a reason part 1 and part 2 need to be bundled together into 1 proposal? They seem to be separate ideas that could be implemented independently. Are you suggesting that the unreviewing feature would only apply to the new "semi-blocked" block type? Also, I think it would help voters if you had a clearer explanation of how the proposal solutions would address the problem you describe. Ryan Kaldari (WMF) (talk) 18:01, 22 November 2016 (UTC)

Voting - All edits from hardblocked IP mark as unreviewed

1.  Support FoCuSandLeArN (talk) 17:29, 29 November 2016 (UTC)
2. Neutral A solution appears to be available already per MER-C, but I'll reconsider supporting if there's any technical aspect the WMF would need to get behind. Stevie is the man! ^{Talk • Work} 20:18, 4 December 2016 (UTC)
3.  Oppose There are good reasons why people should not be allowed to edit from hardblocked ranges, such as sockpuppets and oversightable material. It would sometimes also require further suppressions on yet another page.-- Amanda (aka DQ) 21:15, 6 December 2016 (UTC)
4.  Oppose Let it be known at schools and coffeeshops alike that abuse of Wikipedia will lead to an inability to edit. Relieving this pressure only helps the vandals. Chris Troutman (talk) 06:58, 11 December 2016 (UTC)
5.  Oppose I believe that edits by non registered users should be discouraged, though this may be a major policy change. IP blocking may drive to more users being registered. DPdH (talk) 12:02, 11 December 2016 (UTC)
6.  Support (noting that this may already be a solution per MER-C above) - Adding extra restrictions to IP editors between blocks sound like a much needed feature. Too many vandals continue straight after the block ends, or range ip hoppers. KylieTastic (talk) 12:27, 11 December 2016 (UTC)

Allow per-article edit limits

• Problem: Sometimes a user tends to edit particular pages too many times, such as to periodically remove phrases and hollow an article using "death by a 100 cuts" thereby slanting the text by omission of alternate views. Also, an IP-address user pool might target a few pages, and an edit-limit, as perhaps one-per-week, might deter hack edits without blocking that IP pool from all pages. Also some users can prolong edit-conflicts by saving "87 quick edits" to a page during a multi-hour standoff.

• Who would benefit: All users faced with another editor's numerous edits.

• Proposed solution: Allow some pages to track specific user edits, perhaps nominated by concerned editors, and stop the nominated editors from editing a page beyond their per-article edit-count limit. Note how all other editors would not be limited to an edit-count on that page, only the nominated users.

Algorithm: Perhaps the following steps could show feasibility of edit-limits:

1. Check if user has any edit-limits, if not then edit page.
2. Check if user has limit for current page, if not then edit page.
3. Check if user has limit=0 for current page, if so then View source only.
4. Else count prior edits in Contributions of past week (7 days), and if the user's numedits at/above limit, then View source.

That algorithm would allow a new edit-limit to recount recent Contributions (of 7 days) and decide if now must View source. -Wikid77 (talk) 09:09, 24 November 2016 (UTC)

• Phabricator tickets:

• Proposer: Wikid77 (talk) 14:09, 18 November 2016 (UTC)

• Translations: none yet

Community discussion

@Wikid77: Hmm, are you sure the proposed solution to have "per-article edit limits" sufficiently helps solving the underlying problem? How common is this problem compared to other forms of "unwanted edits" or even vandalism? I for myself prefer performing small atomic edits on pages and providing an edit summary, so others could discuss (and potentially revert) specific changes of mine instead of 'one big change' that might have some good parts in it... --AKlapper (WMF) (talk) 16:56, 18 November 2016 (UTC)

I think other types of troublesome edits can be handled by reverts, or en:wp:edit filters. The use of per-article edit-limits would stop a person who sees, "The Big Bad Wolf huffed and puffed and blew the house down" (plus source) and edits 30x times, removing "Bad" & "Big" & "huffed and puffed" (etc.) until it reads, "A witness said a dog-like character passed by the neighborhood of the domicile". Perhaps if a noticeboard could actually track those hundreds of edits and convince several users to read the hundreds of edits and detect a pattern of slanting..., but meanwhile in the real world where many users do not want to check a user's hundred edits for a pattern, then just limit a nominated user to a few edits per week (or month). Plus, for an IP pool, then limiting the IP pool to a few edits (3?) per week, on specific pages, could deter people wanting to re-hack the key pages about a particular topic, but allow other users of those same rotating IP addresses to edit other pages without blocking all users of the IP pool. -Wikid77 (talk) 22:23, 18 November 2016 (UTC)

This doesn't seem like an approach that deals with the underlying problem and simultaneously could harm good faith editing. I think many will view this as a non-starter. Stevie is the man! ^{Talk • Work} 14:53, 19 November 2016 (UTC)

The edit-limit could be perhaps 5-per-week on specific pages, but allow IP pool to edit other pages with no limit, rather than block IP range as really harming numerous good-faith edits to other pages. -Wikid77 (talk) 09:09, 24 November 2016 (UTC)

Hi Wikid77: There was a proposal last year for Per-user, per-article protection, which got to #14 in the votes. I think that proposal and yours are both solving a similar problem—a particular user editing a particular article too much, especially after a warning or a block.

But your proposal is, in my opinion, needlessly complicated. Custom-setting an edit limit for a particular user on a particular page would need its own interface, nomination process, history log and discussion page, where people determine how many edits is too many for that user on that page. I think what you really want is the per-user per-article block, and we've already got a proposal that 52 people voted for. Would you mind if I replaced your proposal with that one? -- DannyH (WMF) (talk) 00:08, 24 November 2016 (UTC)

Oh no, that 2015 proposal ("Per-user, per-article protection") looks like "edit-limit zero" per specific page, rather than edit-limit by count prior Contributions (of 7 days). The problem to stop is user edits 25x per week to reword/remove phrases until month later, page is hollow where other editors could not offset 100x partial-cut edits per month (semi-blanking content as "death by 100 cuts"). The only required proof of trouble is to count Contributions to show too-many-edits per week and thus nominate those users for edit-limit (8 per week?); otherwise it is too difficult at en:wp:ANI to ask judgment about pattern of slanting in 500 edit-diffs because few people have time to read 500 diffs to confirm the slanting by reading the page sources[!]. That is why per-article edit-limits seem to be the only practical method to stop "slant by 100 edits" which is very difficult to have other users judge. Meanwhile, any topic bans could be assisted as "edit-limit=0" but an IP pool needs like "edit-limit=5" with a troublemaker rotating the IP address numbers, allowing others a chance among those 5 edits each week. -Wikid77 (talk) 09:09, 24 November 2016 (UTC)

When I decide to cleanup a large article I tend to go problem by problem, and section (or sometimes paragraph) by section. I tend to cleanup anything that is misrendering first, section by section, then I fix references that are broken, then I improve references or remove unreferenceable content, and finally I reorganize if needed. I can easily do 30-100 edits on a single page, while ensuring NPOV and improving the article. If a user is vandalising or breaking NPOV they should be dealt with, if not then there is no reason to restrict them at all. Jerodlycett (talk) 13:23, 2 December 2016 (UTC)

Okay, if you re-read above, a user breaking NPOV could hide changes among 100 edits, as requiring users to judge 100 diffs to spot the NPOV slant, which is extremely tedious to prove at wp:ANI, because sources also must be checked for facts. Instead, the proposed edit-limits would only apply to nominated users (known to re-edit many times per week), only on specific pages, and only per-week limits, not lifetime limits, so could even edit more next week. The major goal is to limit IP-range edits, but not block all mobile-phone users on all wikis, as currently done via IP-range global blocks. -Wikid77 (talk) 00:30, 6 December 2016 (UTC)

Voting - Allow per-article edit limits

1.  Support FoCuSandLeArN (talk) 17:29, 29 November 2016 (UTC)
2.  Oppose Jerodlycett (talk) 13:23, 2 December 2016 (UTC)
3.  Oppose per Jerodlycett and my earlier comments. This generally feels un-wiki. Stevie is the man! ^{Talk • Work} 20:24, 4 December 2016 (UTC)

   Well, this wishlist section is "Moderation Tools" which can limit actions as "un-wiki". If not supporting per-article edit-limits, how else do we control IP ranges which target specific articles? I think the current blocking of entire rotating IP-range users (on all wikis) due to one troublemaker needs to be loosened as per-article counts of edits, whether by IP or others. -Wikid77 (talk) 00:30, 6 December 2016 (UTC)

4.  Support as proposer. -Wikid77 (talk) 00:33, 6 December 2016 (UTC)
5.  Oppose--Ranjithsiji (talk) 11:16, 6 December 2016 (UTC)
6.  Oppose Tiggerjay (talk) 21:15, 6 December 2016 (UTC)
7.  Oppose MohammadtheEditor (talk) 03:01, 7 December 2016 (UTC)
8.  Oppose – there is a soft limit called 3RR on Wikipedia, and it's one of the oldest limits on editing. It was reached by consensus and is easy to enforce because violations are not that common in practice, and edits are easy to track. If you get consensus for this edit limit in the community, it will be as easy to enforce as 3RR, without additional tools. Maybe better tracking tools (easy to implement) would be helpful, but not until there is clear consensus in the other (non-technical) forums that such a limit should be created. —Ynhockey (talk) 12:10, 7 December 2016 (UTC)
9.  Oppose – In my opinion it can be helpful for less confident editors to break the changes into smaller chunks rather than trying to get the whole article right in one go. Restricting that might put people off. Just my opinion... TheLordJagged (talk) 09:09, 8 December 2016 (UTC)
10.  Oppose - Some users in places with unstable internet might fear they would lose what they have written; consequently, they save their edits a lot. Unless that problem can be solved, I oppose this measure. Ueutyi (talk) 07:44, 11 December 2016 (UTC)
11.  Oppose - number of edits is not a clear indicator of vandslism; unless there is a way to differentiate from legit micro-edits this is the wrong solution. DPdH (talk) 11:42, 11 December 2016 (UTC)
12. Neutral This is too unspecific to support or oppose. Some idea of this sort is needed, but there are potential devils in the details.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:18, 11 December 2016 (UTC)
13.  Oppose, this is quite useless as a feature available by default given that many good-faith editors prefer doing multiple edits over a single edit (e.g. adding one paragraph at a time). While I don't share these views, this is not necessarily abusive. If there is a specific need to put such edits in place, this can be done using AbuseFilter — NickK (talk) 13:26, 12 December 2016 (UTC)
14.  Oppose --Mikheil ^Talk 21:14, 12 December 2016 (UTC)

IDN support for Special:Linksearch

• Problem: Special:Linksearch treats the encoded and decoded strings for internationalized domain names as separate domains (e.g. a search for http://københavn.eu does not find links to http://xn--kbenhfavn-54a.eu and vice versa).

• Who would benefit: Anyone who fights spam, particularly on wikis involving non-ASCII characters.

• More comments: This is a rather embarrassing bit of software rot that constitutes a vulnerability and needs to be fixed.

• Phabricator tickets: phab:T130482

• Proposer: MER-C (talk) 08:10, 7 November 2016 (UTC)

• Translations: none yet

Community discussion

This should be fairly easy to implement using PHP's idn_to_ascii() function. Kaldari (talk) 23:09, 9 November 2016 (UTC)

• I commented on the bug and submitted gerrit:320721. Legoktm (talk) 05:08, 10 November 2016 (UTC)

Voting - IDN support for Special:Linksearch

1.  Support BethNaught (talk) 08:08, 28 November 2016 (UTC)
2.  Support FoCuSandLeArN (talk) 17:30, 29 November 2016 (UTC)
3.  Support as proposer. MER-C (talk) 05:22, 1 December 2016 (UTC)
4.  Support Doc James (talk · contribs · email) 04:06, 3 December 2016 (UTC)
5.  Support localization 4nn1l2 (talk) 18:20, 5 December 2016 (UTC)
6.  Support--Ranjithsiji (talk) 11:16, 6 December 2016 (UTC)
7.  Support Katie^talk 20:18, 6 December 2016 (UTC)
8.  Support. - Mailer Diablo (talk) 06:57, 7 December 2016 (UTC)
9.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:49, 8 December 2016 (UTC)
10.  Support Daniel kenneth (talk) 08:41, 11 December 2016 (UTC)
11.  Support KylieTastic (talk) 11:53, 11 December 2016 (UTC)
12.  Support JustAGuyOnWikipedia (talk) 16:46, 11 December 2016 (UTC)
13.  Support Yep. We can't have spammer exploits laying around.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:05, 11 December 2016 (UTC)
14.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
15.  Support Atsme^📞📧 19:27, 11 December 2016 (UTC)
16.  Support — NickK (talk) 13:27, 12 December 2016 (UTC)

IDN support for Spam blacklist

• Problem: The spam blacklist treats the encoded and decoded strings for internationalized domain names as separate domains (e.g. a regex entry for http://københavn.eu does not prevent addition of links to http://xn--kbenhavn-54a.eu and vice versa).

• Who would benefit: Anyone who fights spam, particularly on wikis involving non-ASCII characters.

• More comments: This is a rather embarrassing bit of software rot that constitutes a vulnerability and needs to be fixed.

• Phabricator tickets: phab:T130483

• Proposer: MER-C (talk) 08:13, 7 November 2016 (UTC)

• Translations: none yet

Community discussion

none

Voting - IDN support for Spam blacklist

1.  Support BethNaught (talk) 08:08, 28 November 2016 (UTC)
2.  Support --Izno (talk) 01:36, 29 November 2016 (UTC)
3.  Support FoCuSandLeArN (talk) 17:30, 29 November 2016 (UTC)
4.  Support as proposer. (This may be fixed soon.) MER-C (talk) 05:22, 1 December 2016 (UTC)
5.  Support --TerraCodes (talk) 03:37, 4 December 2016 (UTC)
6.  Support localization 4nn1l2 (talk) 18:21, 5 December 2016 (UTC)
7.  Support. - Mailer Diablo (talk) 06:57, 7 December 2016 (UTC)
8.  Support KylieTastic (talk) 11:53, 11 December 2016 (UTC)
9.  Support Don't even see why this is a separate proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:06, 11 December 2016 (UTC)
10.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
11.  Support All for making things work better! Atsme^📞📧 19:28, 11 December 2016 (UTC)
12.  Support — NickK (talk) 13:27, 12 December 2016 (UTC)

Make link to user contributions more accessible on user pages

• Problem: I look at people's user contributions pretty often when I'm editing, and when I go to a user page, I have to scan down the list of links on the left side to find the contribs link. I think on a user page, people are much more likely to want to see someone's contributions than they are to want What links here or Related changes, but the User contributions link is buried under those.

• Who would benefit: People who do moderation or review

• Proposed solution: Make the link to User contributions easier to find—maybe somewhere near the top of the page. We could have a community discussion to figure out the best place for it.

• More comments: Note: I'm User:DannyH (WMF), a WMF staff member on the Community Tech team, and I'm posting this proposal under my volunteer account. I won't participate in the voting, but I'm posting this proposal to see if other people are annoyed by this problem and want to fix it.

• Phabricator tickets:

• Proposer: Toughpigs (talk) 15:59, 15 November 2016 (UTC)

• Translations: none yet

Community discussion

• I can see the point of making it the first link in the Tools list, at the very least. Beyond that, I'm not sure. Stevie is the man! ^{Talk • Work} 14:43, 19 November 2016 (UTC)
• I can't say this bothers me personally. Seems like the time could be better spent. BethNaught (talk) 08:08, 28 November 2016 (UTC)
• If we're just talking about the order in the Tools list, I'm wondering if this is really a technical project but instead a site decision + minor tweak. Stevie is the man! ^{Talk • Work} 19:13, 28 November 2016 (UTC)

No, reordering the Tools list wouldn't help. I'm proposing finding a place for it near the top of the page. I don't have a specific design in mind; that can be figured out later. -- Toughpigs (talk) 20:10, 28 November 2016 (UTC)

Encourage the use of en:User:MusikAnimal/MoreMenu for that. It's a gadget on en. If it's not already a widely used gadget, I can see a case for WMF involvement. But I would oppose developing something new when we already have this gadget that works beautifully for this purpose. Stevie is the man! ^{Talk • Work} 20:20, 28 November 2016 (UTC)

• You could probably get significant benefits from Navigation popups. Just by hovering over a user's link, you get a popup with the basic information, and if you hover over "user" and then "contributions", you see the list of their contributions, with clickable diffs. --Slashme (talk) 08:11, 12 December 2016 (UTC)

Voting - Make link to user contributions more accessible on user pages

1.  Support Small change, but very useful: a more accessible link woul be great. Jules78120 (talk) 13:07, 28 November 2016 (UTC)
2.  Support This would make navigation easier. -Nocowardsoulismine (talk) 18:45, 28 November 2016 (UTC)
3. {{neutral}} Per my latest discussion comment, I think this is probably best left as a site decision. It just seems too light for consideration in this survey. Stevie is the man! ^{Talk • Work} 19:13, 28 November 2016 (UTC)

    Support only making the MoreMenu gadget available on other wikis as it completely handles the problem of not having a link at the top (and then some), and leaving the Tools list link placement as a site decision + tweak. Stevie is the man! ^{Talk • Work} 14:58, 29 November 2016 (UTC)

4.  Support Anthonyhcole (talk) 09:30, 29 November 2016 (UTC)
5.  Support FoCuSandLeArN (talk) 17:30, 29 November 2016 (UTC)
6.  Support That has been done for the mobile version of the site already. Also I'd prefer if instead of making the link to the contributions more visible a handful (10-60) of contributions should be embedded directly on the userpage (with previous&next&500 buttons to show more). This would be especially useful to newcomers who don't know of the contributions page or where to find it. --Fixuture (talk) 21:03, 30 November 2016 (UTC)
7.  Support Easy change, can't be bad. The left menu have to be clean up... --Nouill (talk) 13:44, 1 December 2016 (UTC)
8.  Support Draceane (talk) 10:19, 2 December 2016 (UTC)
9.  Support -- the wub "?!" 15:14, 4 December 2016 (UTC)

    Oppose as triviality. Already, when viewing a userpage, the option "User contributions" appears halfway down left margin in Vector-skin, as 2nd option under "Tools" and similar in Monobook-skin. Ain't broke, don't fix. -Wikid77 (talk) 23:52, 5 December 2016 (UTC)

10.  Support--Elmidae (talk) 16:40, 7 December 2016 (UTC)
11.  Support - Yes, while it does appear in the menu, it's not exactly in a noticeable spot; I have been editing Wikipedia for more than eight years and I completely forgot until this discussion that this was the case. Narutolovehinata5 (talk) 08:19, 11 December 2016 (UTC)
12.  Support - DPdH (talk) 11:44, 11 December 2016 (UTC)
13.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
14.  Support If we have the volunteers with the time and resources, why not? Looks like a good plan to me because it would save time. Atsme^📞📧 19:30, 11 December 2016 (UTC)
15.  Support - I think it is much needed. WannaBeEditor (talk) 02:23, 12 December 2016 (UTC)
16.  Support I use and appreciate the w:en:User:PleaseStand/User info userscript which does this and more. I'd like to see that as a global gadget with default-on. Quiddity (talk) 09:06, 12 December 2016 (UTC)
17.  Support This has already been done for the mobile view, as mentioned above, and that is one of the few places where it is superior to the desktop version.— Godsy (talk • contribs) 09:11, 12 December 2016 (UTC)
18.  Oppose, this is not a Community Tech project. Pretty much all links to user pages (recent changes, page history, watchlist) have links to user contributions as well. If you really need to have these links accessible from a user page, borrow a gadget from Turkish Wikipedia, you can check how it works, for instance, by looking at my user page in Turkish Wikipedia: tr:Kullanıcı:NickK. @Toughpigs: Is this what you are interested in? If yes, perhaps you can simply adapt this gadget? — NickK (talk) 10:39, 12 December 2016 (UTC)
19.  Support A small change but a good idea. Paste (talk) 14:30, 12 December 2016 (UTC)

Multi-protocol support for Special:Linksearch

• Problem: Currently, I have to do two separate link searches to find links to cover both secure and non-secure links e.g. Special:Linksearch/*.example.com and Special:Linksearch/https://*.example.com.

• Who would benefit: Anyone who fights spam.

• Proposed solution: At the very least, linksearch should return results for HTTP and HTTPS combined when no protocol is specified.

• More comments: Google now (rightfully so) boosts rankings for HTTPS sites. This, too, is a rather embarrassing bit of software rot that constitutes a vulnerability and needs to be fixed. Unlike the two IDN proposals, this one has already been (unintentionally?) exploited by spammers.

• Phabricator tickets: phab:T14810

• Proposer: MER-C (talk) 08:23, 7 November 2016 (UTC)

• Translations: none yet

Community discussion

• super useful for a lot of applications, Sadads (talk) 12:33, 10 November 2016 (UTC)
• This would be super useful. I looked at it a long time ago, and it shouldn't be really hard. Splitting the protocol (and possibly all the URL parts like domain and path) would make for much more useful querying. ^demon (talk) 22:49, 25 November 2016 (UTC)

Voting - Multi-protocol support for Special:Linksearch

1.  Support BethNaught (talk) 08:08, 28 November 2016 (UTC)
2.  Support LinkSearch just doesn't work as expected right now; a wildcard should act like a true wildcard, not assume you want http. Samwalton9 (talk) 09:26, 28 November 2016 (UTC)
3.  Support --Izno (talk) 01:36, 29 November 2016 (UTC)
4.  Support FoCuSandLeArN (talk) 17:27, 29 November 2016 (UTC)
5.  Support as proposer. MER-C (talk) 05:22, 1 December 2016 (UTC)
6.  Support This is the expected functionality. czar 01:11, 2 December 2016 (UTC)
7.  Support Libcub (talk) 02:37, 2 December 2016 (UTC)
8.  Support can we also get Linksearch to filter after the .com/ too? For example, http://www.sports-reference.com/olympics/ has just been taken offline, but http://www.sports-reference.com/cfb/ is still online. How many links do we have to /olympics/*? Linksearch currently can't tell us. The-Pope (talk) 15:24, 2 December 2016 (UTC)
9.  Support Doc James (talk · contribs · email) 04:07, 3 December 2016 (UTC)
10.  Support Nikkimaria (talk) 23:12, 3 December 2016 (UTC)
11.  Support Stevie is the man! ^{Talk • Work} 20:35, 4 December 2016 (UTC)
12.  Support --β₁₆ - (talk) 11:09, 5 December 2016 (UTC)
13.  Support 4nn1l2 (talk) 18:24, 5 December 2016 (UTC)
14.  Support Wikid77 (talk) 23:55, 5 December 2016 (UTC)
15.  Support Elkan76 (talk) 03:46, 8 December 2016 (UTC)
16.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:47, 8 December 2016 (UTC)
17.  Support Sadads (talk) 22:26, 9 December 2016 (UTC)
18.  Support It's just silly that this require separate searches.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:08, 11 December 2016 (UTC)
19.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
20.  Support Quiddity (talk) 09:07, 12 December 2016 (UTC)
21.  Support — NickK (talk) 13:13, 12 December 2016 (UTC)

New pages Feed/Page Curation

• Problem: (essential cross-Wiki application, core software extension). en.Wiki receives around 850 or more new pages every 24 hours directly published in mainspace. Currently there is a backlog of around 14,000 unreviewed new pages of which up to half are not suitable for publication. Page Curation is is the only firewall against undesirable new pages. These days, most of these are cleverly contrived corporate spam (by rings of multiple accounts -w:Orangemoody) or non notable autobiographies, while some are in fact from good faith first-time creators who need a simple nudge on the right track to avoid their work being deleted.

• Who would benefit:

1. The encyclopedia from being better policed and kept free of spam, hoaxes, and attack pages.
2. Good faith new users who have created pages that are not ready for immediate publication.
3. The improvements listed below would attract more users of the right calibre to the task of reviewing new pages and using the New Pages Feed and the Curation Toolbar.

• Proposed solution: Develop and implement the following requested short list of improvements, many of which were intended, but 'forgotten' during initial development. We were recently asked by the WMF for a shortlist from the list of 20 or so requested updates. Thee details are not exhaustive but this update to the New Page Review tools should be addressed as one project/one request. Most of the template texts have already been written along with details of the required functions. WMF implementaion is required.

Curation toolbar

1. Tool for moving pages to draft and notify creator
2. Notify creator whenever an article is patrolled but tagged for maintenance
3. Tool for declining a CSD placed by another reviewer, and for notifying patroller of wrongly applied tags
4. Removing the 250 character limit for messages to creator
5. Add the accept and decline features of the AfC Helper Script templates so that submitted drafts can also be reviewed by either New Page reviewers or AfC reviewers from the New Pages Feed.
6. Add the CSD criteria that are listed in Twinkle but not in Page Curation (already listed at Phabricator but apparently closed as 'Resolved' because no one understood what was wanted. This is also one of the reasons why people won't use Page Curation.

New Pages Feed

1. Change the green 'patroll' blob to other icons for all pages that have been CSD?PROD/BLPPROD/AfD so that patrolling admins know what's going on. There should also be an indication of the type of deletion nomination (rather than a generic trash can).
2. Auto refresh. The feed should auto refresh every 5 seconds like the other one does. This is the other main reason why so many patrollers won't move over to Page Curation. Anyone opening the New Pages Feed finds that up to 60% of all pages, especially the low hanging fruit, have already been tagged - sometimes incorrectly.
3. Inform with an icon if a page has previously been deleted.
4. Pages that have been tagged for maintenance issues (but not for deletion) and are otherwise just acceptable for inclusion, should be shown not with the green 'checked' icon, but with an orange blob that contains a capital T (for 'Tagged'). It should be obvious that this would enable admins who are patrolling the quality of the patrollers themselves rather than new pages, can immediately revert any tags that have been inappropriately or erroneously applied, and replace them with correct ones or use the 'unreview button' which should then send the 'unreviewed' message automatically to the patroler, using a dropdown list of canned reasons.
5. Display in the Feed entry, in red alongside the 'no citations' alert, a 'Naked URL' alert. This should enable a patroler to send a canned message to to the creator on the lines of: Thank you for creating X. I notice you left naked URLs in the references section. Please consider returning to the article and addressing this and any other tagged issues. For more information about correctly formatting sources and external links, please see WP:CITE.

• Phabricator tickets:

• Proposer: Kudpung (talk) 18:47, 15 November 2016 (UTC)

• Translations: none yet

Community discussion

• I suspect this falls under the same problem that my proposal (above) ran into in that it is a broad and multi-faceted problem/solution, whereas this wishlist survey seems to be asking for more specific improvements. FWIW I think posts like this should be allowed and encouraged next year. Not every community wish is a single issue or Phab task. Samwalton9 (talk) 20:39, 15 November 2016 (UTC)

  It doesn't have to be separated task by task, but it needs to be specific enough to !vote on. Someone may want to support some of the features of a proposal, but the other features they oppose. Then we end up with "partial support" votes, etc. We'll try to help separate things out as needed MusikAnimal (WMF) (talk) 00:19, 16 November 2016 (UTC)

  I agree this a bit too complicated for a single proposal. If someone agrees with some of these ideas, but not others, it will be tricky for them to express that in a vote. At the very least it should be split into two proposals: 1 for improving the Curation Toolbar and 1 for improving the New Pages Feed. Kaldari (talk) 00:21, 16 November 2016 (UTC)

  @Kudpung: What do you think about splitting this into 2 requests? Kaldari (talk) 22:18, 17 November 2016 (UTC)

  THe instructions for making these wish list proposals are vague - or should I perhaps say 'broad', so it was not easy to know what to say or how detailed to make it. The two things are as inseperable as the gearbox and the engine of a car or the propeller and the wings of an airplane - one can't work without the other, even if separate teams work on the blueprints. From the point of view of those who actually use the software, and the goal its use is intended to achieve, I therefore personally see this as one request. It was obviously developed by Brandoon as one project, and if it were to be split there would be the risk that some parts will be ready sooner than others so the devs on the completed bits will be redeployed and it will be hard to get them back together when needed for any final tweaks. Lets not forget that half a year has already passed since thee issues reached critical discussion stage and so far, there has been no progress at all.

• Also, at this stage the community now has 4 years experience of use, so its probably best to be guided by what they have said they now require, label this as a New Page Review software upgrade and just get on with addressing the individual tweaks that are needed. If there is to be a lot of discussion over the fine details all over again, then nothing will ever get done. We now have a user right for the software, so we need some compelling arguments to get people to use it and address the monumental backlog of new, unreviewed pages.

• At the end of the day, this shouldn't be a wishlist project at all. It's a necessary core extension as much as an editing window is, and is therefore a high priority. Most likely, if it were a community accessible code, like Twinkle for example, these features would have been addressed long ago and without any fuss. Software like this needs regular version releases, not waiting for votes on what non users and developers think the stake holders need. Kudpung (talk) 00:30, 18 November 2016 (UTC)

• The Page Curration Tool is a workflow tool and as such a force multiplier compared to manual reviewing of new articles. The less often a reviewer needs to exit the workflow the more efficiently they can work. The more information it can present to a reviewer to allow them to partition their work - the orange notice for pages with tags but not merged reviewed, what has been deletion tagged, which articles have been previously deleted etc - the better a reviewer can work. They can select specific tasks; looking over tagged articles, paying special attention to articles with prior deletions or finding articles with specific deficiencies that may indicate problems. Every process which requires dropping out of the tool (which intrinsically includes Special:NewPagesFeed) hurts efficiency and increases the chance for error.

If the Foundation has a real desire to support minimum content standards and rapid identification of inappropriate content they need to dedicate the resources required to give the people who volunteer to do those tasks the appropriate tools to perform them. I am a bit horrified that so much development time is spent on "cool" stuff like AI article scoring or "glitzy" things no one wants like Flow or that abomination Gather while unglamorous, workmanlike tools required for efficient maintinance tasks must go through a community begging process. This is a complex tool that fills a mission critical need and the Foundation and its paid developers need to dedicate the time and resources to support it as such. Jbh^Talk 15:42, 25 November 2016 (UTC)

Voting - New pages Feed/Page Curation

1.  Support--Shizhao (talk) 03:02, 28 November 2016 (UTC)
2.  Support as proposer. --Kudpung (talk) 12:26, 28 November 2016 (UTC)
3.  Support, at the risk of sounding like a doomsayer, unchecked new article spam could become an existential threat to the project and these are all very sensible, basic changes needed to patch up our neglected 'firewall' Joe Roe (talk) 17:32, 28 November 2016 (UTC)
4.  Support Anthonyhcole (talk) 09:34, 29 November 2016 (UTC)
5.  Support FoCuSandLeArN (talk) 17:27, 29 November 2016 (UTC)
6.  Support MER-C (talk) 05:23, 1 December 2016 (UTC)
7.  Support our most critical current need to maintain quality. DGG (talk) 04:59, 4 December 2016 (UTC)
8.  Support -- the wub "?!" 15:17, 4 December 2016 (UTC)
9.  Support Some constituent proposals seem stronger than others, but I support the general thrust of improving these tools. Stevie is the man! ^{Talk • Work} 20:51, 4 December 2016 (UTC)
10.  Oppose Why don't you use toollabs:pageviews? That's already enough for me. --Liuxinyu970226 (talk) 10:28, 5 December 2016 (UTC)

    Liuxinyu970226, I don't see the pageviews tool having anything whatsoever to do with this topic. Are you sure you are in the right thread? Kudpung (talk) 01:33, 6 December 2016 (UTC)

    Liuxinyu970226, please consider removing this 'Oppose' vote, as it seems to be mistakenly placed. Stevie is the man! ^{Talk • Work} 15:08, 6 December 2016 (UTC)

    Stevietheman, Oppose votes are important for discussion, but only Support votes are counted in the final tally. Liuxinyu970226's vote won't hurt this proposal's chance of success. -- DannyH (WMF) (talk) 19:46, 7 December 2016 (UTC)

    Acknowledged and understood. Just concerned about the inadvertent plonking effect. :) Stevie is the man! ^{Talk • Work} 20:01, 7 December 2016 (UTC)

11.  Support both parts, as interrelated tasks. -Wikid77 (talk) 23:59, 5 December 2016 (UTC)
12.  Support Aye. Lovkal (talk) 08:25, 8 December 2016 (UTC)
13.  Support we really need that perfect Page curation tool! 333-blue 09:05, 9 December 2016 (UTC)
14.  Support Miniapolis 20:07, 9 December 2016 (UTC)
15. Neutral, leaning Weak oppose - The suggested changes are good. However, I've never cared for the tool, preferring Twinkle combined with other methods. Secondly, as en wiki has recently restricted the use of this tool to those with a specific user right, but still allows users without it to review new pages (though they can't patrol them), I don't feel this is a priority. It is silly to disallow users from a streamlined method of doing something that they are still allowed to do the majority of.—Godsy (talk • contribs) 21:04, 9 December 2016 (UTC)
16.  Support a very useful proposal that will ultimately help NPP's and Admins (and of course genuine new page creators) Xyzspaniel (talk) 21:25, 9 December 2016 (UTC)
17.  Support --OrsolyaVirág (talk) 11:47, 10 December 2016 (UTC)
18.  Support Ramaksoud2000 (talk) 07:00, 11 December 2016 (UTC)
19.  Support The stress editors feel is real. We need these improvements. Chris Troutman (talk) 07:01, 11 December 2016 (UTC)
20.  Support Absolutely. Mz7 (talk) 07:02, 11 December 2016 (UTC)
21.  Support I'm not a New Page Reviewer, but I understand the importance of this very daunting task. Not only is it important to NPRs, it should also be important to those who deal with editor retention (like English Wikipedia's Teahouse, which I do participate in), among other groups, as well! — Gestrid (talk) 07:07, 11 December 2016 (UTC)
22.  Support --Satdeep Gill (talk) 07:20, 11 December 2016 (UTC)
23.  Support—NPP needs improvement to encourage more serious editors to spend time on this vital work.PamD (talk) 09:47, 11 December 2016 (UTC)
24.  Support Jcc (talk) 10:18, 11 December 2016 (UTC)
25.  Support - DPdH (talk) 11:47, 11 December 2016 (UTC)
26.  Support—Have only recently become more active in this activity, and while I support more of the above changes than others, I don't see an issue with those which I personally see as less of a priority. On the whole, I think the changes will be a rather large net positive, and assist with the burgeoning backlog. Onel5969 ^{TT me} 12:43, 11 December 2016 (UTC)
27.  Support KGirlTrucker81 (talk) 12:54, 11 December 2016 (UTC)
28.  Support TonyBallioni (talk) 13:40, 11 December 2016 (UTC)
29.  Support Anything that helps new pages patrollers edit more efficiently is a huge plus in my view. These seem crucial not just to make patrolling more effective but to address major disabilities with the current setup. The only one I am slightly leery of is the move to draft tool. I see a potential of its use to sweep bad pages under the rug that a patroller does not know what to do with or which are not subject to any CSD, nor PROD candidates and the user does not want to take the time to take to AfD. On balance though I don't think my suspicion of likely misuse by some is nearly a good enough reason not to implement it. If misused in this manner, it can be addressed at the individual patroller when seen.--Fuhghettaboutit (talk) 14:44, 11 December 2016 (UTC)
30.  Support - both parts of the proposal. I particularly like removing the 250 character limit on comments; at present you're left with a choice to leave a truncate, if not curt, explication for good faith editors or moving out of the work flow to engage at least minimally. The proposals seem a good, balanced approach to develop and retain capable new page reviewers, encourage good faith article contributors, and protect the integrity of the encyclopedia. - Neonorange (talk) 16:31, 11 December 2016 (UTC)
31.  Support Badly needed.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:09, 11 December 2016 (UTC)
32.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
33.  Support Dank (talk) 02:48, 12 December 2016 (UTC)
34.  Support Jbh^Talk 03:20, 12 December 2016 (UTC)
35.  Support Anything to make it easier to toss the spam and yet not bite the true newbies. Montanabw (talk) 04:59, 12 December 2016 (UTC)
36.  Support Quiddity (talk) 09:09, 12 December 2016 (UTC)
37.  Support New article spam is a huge problem and we need any help we can get in terms of more effective tools, processes, and volunteers. This is a well-thought-out proposal that deserves attention. MrX (talk) 13:17, 12 December 2016 (UTC)
38.  Support The management of the new pages feed is already an established community with a workflow proven to give great results. Now that we have some history of usage, the community is more aware of what the bottlenecks in productivity are. Whenever some technical fixes can leverage more usefulness out of the volunteer labor of an established community, then performing those fixes is logical. We need progress in this now as this process will eventually spread to all languages and projects. Blue Rasberry (talk) 15:17, 12 December 2016 (UTC)
39.  Support PGWG (talk) 15:58, 12 December 2016 (UTC)
40.  Support ONUnicorn (talk) 16:20, 12 December 2016 (UTC)

Quality scoring for new articles

• Problem: New articles are often contributed by new editors who are unfamiliar with Wikipedia and who consequently create low-quality material on undesirable topics. On the English Wikipedia, where the new-article volume is very high, managing the influx of new articles consumes a large amount of volunteer time. My experience is with enwiki, but I expect this generalizes to most large wikis, especially those that see a lot of spam.

• Who would benefit: Established editors who invest their volunteer time in managing and sorting new articles, working in deletion processes, or supporting new editors; productive new editors whose earliest contributions are new articles.

• Proposed solution: The English Wikipedia community has a large number of tools available for identifying unproductive edits. A few months ago, the ORES review tool was deployed in beta, providing a MediaWiki-integrated mechanism for highlighting edits in need of review. Additionally, the new page patrol feature allows manual curation of articles. Recently the English Wikipedia established a new user right to use the patrol feature, necessitating a significant investment of volunteer time in managing this right and reviewing the editors doing the new-page reviewing. This is an inefficient process.

The proposed solution is to use an ORES-style machine learning mechanism to score newly created articles and use the scores to stratify new pages tools' output (e.g. Page Curation, Special:NewPages, or third-party tools). This is expected to:

• 1. Provide a MediaWiki-integrated mechanism to efficiently identify new articles with a high likelihood of problem content, differentiating those that need prompt attention (e.g. obvious vandalism, likely spam) from those that merely need additional editing (e.g. a new article that lacks categories or has formatting errors). Useful features along these lines are already available through edit filters and tags.
  2. More efficiently allocate volunteer resources to supporting new editors who are making good-faith edits rather than those who have misunderstood the project's purpose. (A frequent issue is new editors believing Wikipedia is a general-purpose directory and they should submit entries for their products or businesses.) There is some evidence, older but likely still accurate, that "desirable" newly registered editors whose contributions are rejected are less likely to stick with the project. This means we should provide tools to help established editors avoid mistakenly rejecting good contributions.
  3. Allow identification of new editors who are producing good new articles. There is also evidence that editors who are productive in their earlier edits as registered editors are most likely to become long-term community members ("Wikipedians are born, not made"). Yet many of our processes aimed at new editors are essentially about providing guidance to those who are making errors, not about encouraging those who aren't.
  4. Provide effective decision support to editors managing and sorting new pages, reducing their error rate and reducing the need for monitoring and critiquing their work.

• Phabricator tickets:

• Proposer: Opabinia regalis (talk) 22:51, 19 November 2016 (UTC)

• Translations: none yet

Community discussion

This is great to see! I'm already working on a model to "identify new articles with a high likelihood of problem content, differentiating those that need prompt attention (e.g. obvious vandalism, likely spam)". See m:Research:Automated classification of draft quality for the project page. I'm currently targeting "spam" (G11), "vandalism" (G3) and "attack" pages (G10) in English Wikipedia, but if successful, we should be able to adapt similar strategies to other wikis that have a consistent way of labeling their deletion reasons. I've submitted a similar proposal about splitting these articles with immediate concerns from the rest of the pool of new article creations (see m:Grants:IdeaLab/Fast and slow new article review), so I'm generally supportive of this idea and that's why I've started working on the modeling infrastructure.

Further, I think that the current article quality model (wp10) could be used to highlight new articles that are most complete for prioritized review and support. This would probably be useful for directing support to new article drafts that are most likely to be ready to be published so that they don't languish in some backlog. --Halfak (WMF) (talk) 21:21, 22 November 2016 (UTC)

That looks like a great start! A system that's robust and effective at identifying the worst new articles and channels effort in those directions would be a real benefit to the community, both for the simple reason of controlling bad articles and for the social reason of alleviating perceived pressure on the patrollers and simplifying their tasks. Some active patrollers still feel strongly that nothing short of fully manual curation by highly experienced users will produce acceptable results, but obviously that doesn't scale well. Looking at your proposal, one relatively simple change from your original description would be to allow sorting of the new pages feed by a score or classification given to each article, rather than splitting into two separate streams - once people have had experience with the tool's output, they would likely be more comfortable with using it to split articles into different queues. It would also be pretty interesting if the article quality features identifying good new articles could then be used to provide feedback directly to the authors. (Of course, I also have serious doubts about the accuracy of most enwiki article ratings, but that's a different problem...) Opabinia regalis (talk) 06:16, 24 November 2016 (UTC)

Opabinia regalis, we need to better understand the preamble to your proposal. The new, New Page Reviewer right does not create more work for anyone. It creates an encouragement for more users to process a 14,000 page backlog with more efficiency, accuracy, and experience, and to do so, read and understand the principles that new articles are expected to follow, and provide in their triage, basic front-line advice to page creators.

This current proposal as I see it, is a solution for a solution and one that typifies the belief that automation is the cure-all for the ills affecting the mission to maintain Wikipedia as a credible and respected source of knowledge. Possible better and less cost-intensive solutions are available; Foundation time and funds, IMO, would be better allocated to developing methods of informing would-be first-time article creators what they can and cannot publish directly in mainspace. Hence this proposal is possibly a financial mallet to crack an egg, which will require extensive development and testing, whereas the more logical, and the more personal approach is the one begun by the Foundation, and whose completion is requested in this current ‘wishlist’ survey at 2016 Community Wishlist Survey/Categories/Bots and gadgets#New User Landing Page - Article Creation Workflow (probably not the best location to place the proposal, but there didn’t seem to be one that fits the bill).

Solutions to critical issues of this kind should take into account the long, in-depth empirical evidence provided by those who have actually worked intensively in those areas. This is how Page Curation and New Pages Feed were developed - a rare but effective collaboration between the WMF and a team of experienced community volunteers. Kudpung (talk) 23:12, 24 November 2016 (UTC)

On your first point, the new "right" actually removed the right from most users and instituted a new process for granting it to a very small subset of individuals, each of whom will be individually assessed: currently ~280 editors (plus ~1300 admins). That may well produce better results - it remains to be seen - but it is by definition creating more work to achieve those results.

As for cost-effective, I think the foundation's budget is its business ;) But much of the infrastructure for this already exists, and as Halfak mentions above, some of the groundwork is already been done anyway. While any new tool needs testing, it's important to keep in mind that the concepts underlying this idea are extremely well validated "in the wild" on enwiki already. Machine learning is highly effective in identifying common types of problem edits - we know that from ClueBot and more recently ORES. Semi-automated decision support systems to facilitate anti-vandalism work (like Huggle or STiki) are efficient and well integrated into the community. The proposed tool is also generalizable to other wikis - at least others where the rate of incoming new articles is high, and where there is a local system for annotating deletion reasons. That makes it a good fit for WMF development effort. Opabinia regalis (talk) 04:51, 26 November 2016 (UTC)

Actually, the assumption that the new right removed a right is in practice incorrect. While technically true, it was only from the thousands who were not using it or who had even never used it. The new right prevents the extremely low quality of reviewing while reducing the load on others who should have, but never did monitor the quality. What we now have are 280 users most of whom have now specifically asked for the right and/or who were already active patrollers during the sample period, thus providing an overview for the first time ever. Secondly, NewPagesFeed and Page Curation were already a costly WFM development. We should build on that infrastructure and encourage editors to use it. Kudpung (talk) 12:18, 26 November 2016 (UTC)

Luckily, it is likely quite straightforward to integrate the score (and sorting/filtering by score) into the existing new pages feed, as well as exposing it in the new pages list and through the API. Opabinia regalis (talk) 03:13, 27 November 2016 (UTC)

That is good news. I feel I was sounding as if I were averse to any technology that will ultimately make page triage easier for all concerned. Due to the urgency of seriously improving the triage of its massive daily intake and backlog of new articles as quickly as possible, I have been heavily involved in the immediate action of improving the tools we already have: Page Curation/New Pages Feed, and to make them more attractive to users. I am therefore not up to speed with ORES, but I certainly appreciate its potential. Kudpung (talk) 09:55, 27 November 2016 (UTC)

Opabinia regalis suggests using “an ORES-style machine learning mechanism to score newly created articles.” In the next few months, the WMF Collaboration Team will release a beta feature that, among other improvements, adds the following to Recent Changes: a Page Creations filter, which finds edits that create new pages, and a set of filters based on the ORES Damaging and Good Faith tests (the “Contribution Quality” and “User Intent” filters, respectively). You can read more about these improvements and see a demo here.

It's great that we're working on additional ORES article-quality tests. But I feel like the new RC page features just mentioned will address at least some of the issues raised here, since they'll enable users to filter a) for new pages that b) are likely to have problems. Halfak (WMF), what do you think? JMatazzoni (WMF) (talk) 00:18, 10 December 2016 (UTC)

+1 JMatazzoni. I think that, once we have the ORES edit quality models in place, applying the draft quality models to page creation edits would be pretty straightforward. Either way, we don't need to choose. We can have these ORES draft scores appear both in the new review feed your team is working on and any other interface that would benefit from the score. --Halfak (WMF) (talk) 20:38, 10 December 2016 (UTC)

Voting - Quality scoring for new articles

1.  Support--Shizhao (talk) 03:02, 28 November 2016 (UTC)
2.  Support --Kudpung (talk) 12:24, 28 November 2016 (UTC)
3.  Support MichaelMaggs (talk) 19:58, 28 November 2016 (UTC)
4.  Support FoCuSandLeArN (talk) 17:27, 29 November 2016 (UTC)
5.  Support --Telaneo (User talk page) 21:56, 29 November 2016 (UTC)
6.  Support --Anthonyhcole (talk) 06:47, 30 November 2016 (UTC)
7.  Support Noyster (talk) 00:18, 1 December 2016 (UTC)
8.  Support MER-C (talk) 05:23, 1 December 2016 (UTC)
9.  Support as proposer. Opabinia regalis (talk) 03:59, 4 December 2016 (UTC)
10.  Support I am amazed this obvious great idea doesn't have a lot more supports. Stevie is the man! ^{Talk • Work} 19:43, 4 December 2016 (UTC)
11.  Oppose Per my vote under #New pages Feed/Page Curation. --Liuxinyu970226 (talk) 10:28, 5 December 2016 (UTC)

    Liuxinyu970226, that vote appeared to have nothing to do with the subject, nor does it here. Stevie is the man! ^{Talk • Work} 15:10, 6 December 2016 (UTC)

12.  Support, per Kudpung comments above. Wikid77 (talk) 00:04, 6 December 2016 (UTC)
13.  Support--Ranjithsiji (talk) 11:17, 6 December 2016 (UTC)
14.  Support Blue Rasberry (talk) 19:26, 6 December 2016 (UTC)
15.  Support Ks0stm ^(T•C•G) 21:22, 6 December 2016 (UTC)
16.  Support I'm surprised this extremely good idea isn't getting more traction. Espresso Addict (talk) 03:53, 9 December 2016 (UTC)
17.  Support Miniapolis 20:10, 9 December 2016 (UTC)
18.  Support Long overdue Reguyla (talk) 18:45, 10 December 2016 (UTC)
19.  Support See my comments I made through my staff account above (I'm Halfak when I'm working). I don't just support this proposal. I'm already working on it! --EpochFail (talk) 20:39, 10 December 2016 (UTC)
20.  Support Best triage idea I've seen. Chris Troutman (talk) 07:03, 11 December 2016 (UTC)
21.  Support - Especially if could work with the curation proposal. DPdH (talk) 11:49, 11 December 2016 (UTC)
22.  Support - KylieTastic (talk) 12:05, 11 December 2016 (UTC)
23.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
24.  Support --Plagiat (talk) 18:33, 11 December 2016 (UTC)
25.  Support ONUnicorn (talk) 16:20, 12 December 2016 (UTC)
26.  Support--Mikheil ^Talk 21:14, 12 December 2016 (UTC)

Return and improve the AbuseFilter's resource tracking

• Problem: The AbuseFilter extension has limited computational resources available to it, and edit filter managers must be careful to ensure that no filter uses more than necessary or certain filters will fail to run. There was previously per-filter usage information (Filter X took Y ms to run and used Z conditions), which was since removed for technical reasons, the details of which I'm not sure of. It is now almost entirely unknown how resource-heavy any given filter is, and overall data is only mildly useful ("Of the last X actions, Y have reached the condition limit of 1,000"). Better information on each filter's usage and a good ability to check which filters are using the most resources would be very beneficial.

• Who would benefit: Primarily users with the user rights to manage filters; the ability to properly manage resources will greatly improve the number and quality of filters able to be created.

• Proposed solution: Re-implementing per-filter resource usage information, and providing a single location where the resource usage of each filter can be checked at a glance.

• More comments: This is probably the more important of the AbuseFilter improvements that are needed, but more general attention for the extension is definitely needed.

• Phabricator tickets: T53294

• Proposer: Samwalton9 (talk) 19:39, 7 November 2016 (UTC)

• Translations: none yet

Community discussion

• Yes please: having these stats would be very useful -- samtar ^{talk or stalk} 11:24, 16 November 2016 (UTC)

• Some extra information uncovered today: The Condition Limit stats can be reimplemented as-is, but the tracking is too resource heavy itself right now. I guess this proposal might turn into "improve the resource tracking code so it can be implemented without having to be switched off after a few weeks (T132200)". Samwalton9 (talk) 11:33, 28 November 2016 (UTC)

Voting - Return and improve the AbuseFilter's resource tracking

1.  Support BethNaught (talk) 08:08, 28 November 2016 (UTC)
2.  Support as proposer. Samwalton9 (talk) 09:27, 28 November 2016 (UTC)
3.  Support Okay so we vote here - either way, very helpful -- samtar ^{talk or stalk} 09:47, 28 November 2016 (UTC)
4.  Support — xaosflux ^Talk 14:51, 28 November 2016 (UTC)
5.  Support Matěj Suchánek (talk) 16:42, 29 November 2016 (UTC)
6.  Support FoCuSandLeArN (talk) 17:28, 29 November 2016 (UTC)
7.  Support DatGuy (talk) 18:20, 29 November 2016 (UTC)
8.  Support MER-C (talk) 05:23, 1 December 2016 (UTC)
9.  Support Ahm masum (talk) 16:51, 1 December 2016 (UTC)
10.  Support I don't have much understanding of this aspect of wikis, but as someone experienced with systems development, I can see the necessity for resource monitoring of critical processes. Stevie is the man! ^{Talk • Work} 19:51, 4 December 2016 (UTC)
11.  Support ·addshore· ^{talk to me!} 10:49, 5 December 2016 (UTC)
12.  Support A lot of improvements need and should be done to the Abusefilters besides this but this would be a great start. Reguyla (talk) 18:46, 10 December 2016 (UTC)
13.  Support Sunmist (talk) 23:18, 10 December 2016 (UTC)
14.  Support - KylieTastic (talk) 12:07, 11 December 2016 (UTC)
15.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)

Rewriting X!'s Tools

• Problem: The suite of tools developed by User:X! (I'll refer to them as "Xtools" from here on out) is currently very unstable and impossible to maintain. Xtools is a suite of tools that include the following:
  • Edit Counter: Detailed information about user's edits, including breakdown by namespace (and time if they opt in). Current version: xtools-ec
  • Article Information: Detailed information about an article, including issues and statistics. Current version: xtools-articleinfo
  • Article Blamer: Shows who is responsible for inserting given text into an article: Current version: blame
  • Adminstats: Show statistics of admin actions in a sortable table. Current version: adminstats
  • RfX Analysis: Analyze Requests for Adminship and Request for Bureaucratship pages. Current version: rfa
  • RfX : Shows how a user voted in a Request for Adminship. Current version: rfap
  • Simple Edit Counter: Shows basic group and edit count information. Current version: sc

• Who would benefit: Any project that links to Xtools (We support all WMF projects by way of meta_p on Tool Labs)

• Proposed solution: A complete rewrite of Xtools is in progress, which is nicknamed the "Rebirth". Assistance from community tech to help complete the rewrite and test it would be very helpful.

• More comments: It is worth noting that one of the goals of this rewrite is to make Xtools independent of Tool Labs. Instead, we will be installing it on Labs Instances at the end. This will increase stability.

• Phabricator tickets: None directly related to the rebirth, but any ticket located at [1] will be fixed.

• Proposer: ~ Matthewrbowker ^{Drop me a note} 22:22, 19 November 2016 (UTC)

• Translations: none yet

Community discussion

Pinging interested persons: @Cyberpower678: @MusikAnimal: @Technical 13: ~ Matthewrbowker ^{Drop me a note} 22:22, 19 November 2016 (UTC)

• Hi Matthewrbowker, could you add some examples to your proposal—specific tools that are helpful and should be rescued? This will help people who aren't familiar with Xtools to understand your proposal, and get you more support votes. -- DannyH (WMF) (talk) 23:24, 19 November 2016 (UTC)

  @DannyH (WMF): I've updated my proposal, thank you. ~ Matthewrbowker ^{Drop me a note} 04:56, 20 November 2016 (UTC)

• I'm in support of this. I've reached out to the Community Tech Team once before for this but they need official community support before they can take up such a project.—cyberpower ^Chat_Hello! 00:25, 20 November 2016 (UTC)
• I am both a member of Community Tech and the XTools team, so obvious conflict of interest, but to give perspective: XTools serves up to 185 languages and is used an estimated 200,000+ times a month [2] (I changed the endpoint [3][4] but failed to update the tracking endpoint in the xtools project until very recently). XTools is easily the most popular of the user analysis tools, and complaints of instability have been ongoing since the author of the most recent rewrite retired in Augst 2014 [5] (see reports at w:en:WP:VPT [6], their talk page on dewiki [7], and issues on GitHub). Most people are content because our ongoing efforts have provided around an 80% uptime (according to private Uptime Robot data) of the services, which is still severely lacking for such a popular suite of tools. Primary use cases include evaluating candidates for particular roles (request for adminship, various permissions, etc.), and individual interest in a user's productivity. Much attention has also been given to privacy. Multiple RfCs have resulted in data that is already public, such as aggregated stats on an user's editing activity, only be visualized unless explicitly allowed by the editor [8][9]. So in summary, a rewrite of this integral suite of tools that is more reliable, maintainable, and more compatible with the Tool Labs environment, is desperately needed. Matthewrbowker has been working very hard on the rebith [10] that lives on a dedicated Labs instance. His work will surely make it's way to a more stable service for all, but official support for this effort I believe will greatly benefit the moderation community — MusikAnimal ^talk 07:50, 20 November 2016 (UTC)
• This is such an important suite of tools that it should have been a Foundation financed project from the beginning. MusikAnimal has stressed the primary reasons for its use, and there are some extremely valuable tools that should be in it that were originally developed buy Scottywong (now retired), such as for example, the New Page Patrol analysis. Kudpung (talk) 11:30, 25 November 2016 (UTC)

Voting - Rewriting X!'s Tools

1.  Support--Kudpung (talk) 12:29, 28 November 2016 (UTC)
2.  Support -Nocowardsoulismine (talk) 18:50, 28 November 2016 (UTC)
3.  Support Yes, these valuable tools need to be supported. Stevie is the man! ^{Talk • Work} 19:24, 28 November 2016 (UTC)
4.  Support MichaelMaggs (talk) 19:59, 28 November 2016 (UTC)
5.  Support · · · Peter (Southwood) ^(talk): 09:24, 29 November 2016 (UTC)
6.  Support FoCuSandLeArN (talk) 17:28, 29 November 2016 (UTC)
7.  Support When I used it, was very useful. DatGuy (talk) 18:24, 29 November 2016 (UTC)
8.  Support --Telaneo (User talk page) 21:56, 29 November 2016 (UTC)
9.  Support --Anthonyhcole (talk) 06:49, 30 November 2016 (UTC)
10.  Support The Article Blamer is an essential tool in copyright investigation. There've been times when both it and the alternative have been out of action, so anything that improves reliability should be a priority. Thanks, Justlettersandnumbers (talk) 11:11, 30 November 2016 (UTC)
11.  Support Noyster (talk) 00:03, 1 December 2016 (UTC)
12.  Support — Pajz (talk) 12:16, 1 December 2016 (UTC)
13.  Support Ahm masum (talk) 16:51, 1 December 2016 (UTC)
14.  Support These essential tools don't work properly, too often broken. Any improvement is welcome. --Stobaios (talk) 21:41, 1 December 2016 (UTC)
15.  Support Echoing these tools as invaluable—a stable version in any form would do us all well czar 01:12, 2 December 2016 (UTC)
16.  Support Libcub (talk) 02:43, 2 December 2016 (UTC)
17.  Support Jmvkrecords ⚜ (Intra talk) 08:33, 2 December 2016 (UTC).
18.  Support Broken too often. I'm addicted to these tools. :-) Draceane (talk) 10:21, 2 December 2016 (UTC)
19.  Support —Jc86035 (talk) 11:16, 2 December 2016 (UTC)
20.  Support. Matiia (talk) 23:31, 2 December 2016 (UTC)
21.  Support --Informationswiedergutmachung (talk) 20:01, 3 December 2016 (UTC)
22.  Support --Ping08 (talk) 02:40, 4 December 2016 (UTC)
23.  Support --TerraCodes (talk) 03:35, 4 December 2016 (UTC)
24.  Support Opabinia regalis (talk) 03:59, 4 December 2016 (UTC)
25.  Support Llywrch (talk) 04:44, 4 December 2016 (UTC)
26.  Support Essential . DGG (talk) 05:00, 4 December 2016 (UTC)
27.  Support Louis Wu (talk) 11:55, 4 December 2016 (UTC)
28.  Support This tool is core. ImperfectlyInformed (talk) 19:26, 4 December 2016 (UTC)
29.  Support --Gestumblindi (talk) 02:20, 5 December 2016 (UTC)
30.  Support -- Marcus Cyron (talk) 06:02, 5 December 2016 (UTC)
31.  Support --Yeza (talk) 09:53, 5 December 2016 (UTC)
32.  Support --Hubertl (talk) 13:22, 5 December 2016 (UTC)
33.  Support --Atlasowa (talk) 13:57, 5 December 2016 (UTC)
34.  Support -<(kmk)>- (talk) 17:01, 5 December 2016 (UTC) core tools need to reside in the core software
35.  Support --Andropov (talk) 17:15, 5 December 2016 (UTC)
36.  Support 4nn1l2 (talk) 18:31, 5 December 2016 (UTC)
37.  Support Chewbacca2205 (talk) 19:49, 5 December 2016 (UTC)
38.  Support. Wikid77 (talk) 00:05, 6 December 2016 (UTC)
39.  Support --Tryptofish (talk) 00:06, 6 December 2016 (UTC)
40.  Support--Ranjithsiji (talk) 11:17, 6 December 2016 (UTC)
41.  Support Blue Rasberry (talk) 19:26, 6 December 2016 (UTC)
42.  Support Tiggerjay (talk) 21:16, 6 December 2016 (UTC)
43.  Support Ks0stm ^(T•C•G) 21:23, 6 December 2016 (UTC)
44.  Support in the strongest possible terms. Katie^talk 22:56, 6 December 2016 (UTC)
45.  Support Per my comment in the discussion section.—cyberpower ^Chat_Hello! 00:00, 7 December 2016 (UTC)
46.  Support. - Mailer Diablo (talk) 06:57, 7 December 2016 (UTC)
47.  Support —Ynhockey (talk) 12:05, 7 December 2016 (UTC)
48.  Support--Elmidae (talk) 16:57, 7 December 2016 (UTC)
49.  Support Yup. -Djsasso (talk) 18:21, 7 December 2016 (UTC)
50.  Support Pretty please. Rivertorch (talk) 05:46, 8 December 2016 (UTC)
51.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:48, 8 December 2016 (UTC)
52.  Support Whats new? (talk) 22:52, 8 December 2016 (UTC)
53.  Support I love the capability of XTools when it works correctly. It's been a little off at times since Hedonil hasn't had it. So, let's get this baby geared up to its finest capability. Maile66 (talk) 23:01, 8 December 2016 (UTC)
54.  Support many fine tools with roaring. Bishzilla (talk) 16:32, 9 December 2016 (UTC).
55.  Support Miniapolis 16:58, 9 December 2016 (UTC)
56.  Support --Nikola (talk) 18:42, 9 December 2016 (UTC)
57.  Support --OrsolyaVirág (talk) 11:49, 10 December 2016 (UTC)
58.  Support Strong support. This should have been done a long time ago. Reguyla (talk) 18:47, 10 December 2016 (UTC)
59.  Support Very useful. Felsic2 (talk) 23:35, 10 December 2016 (UTC)
60.  Support — Godsy (talk • contribs) 03:09, 11 December 2016 (UTC)
61.  Support It's overdue. Chris Troutman (talk) 07:04, 11 December 2016 (UTC)
62.  Support—useful tools which need official support.PamD (talk) 09:49, 11 December 2016 (UTC)
63.  Support --Oluwa2Chainz (talk) 11:14, 11 December 2016 (UTC)
64.  Support - DPdH (talk) 11:51, 11 December 2016 (UTC)
65.  Support - strong support, very useful tool that desperately need to be more stable. KylieTastic (talk) 12:10, 11 December 2016 (UTC)
66.  Support KGirlTrucker81 (talk) 12:57, 11 December 2016 (UTC)
67.  Support It's amazing the transfer of such things from the community to "official" versions has been sooooo slow and poor! Johnbod (talk) 13:40, 11 December 2016 (UTC)
68.  Support. No brainer. If I can put a bug in someone's ear about some useful changes while this is being done, I think it would be a great improvement in the edit counter if it would include a count of logged deletions and page moves as part of the overall edit total as well as count page moves. Doing so would make the counter sketch a far more accurate picture of what any user or admin who focuses on certain maintenance tasks, actually does with their time and in their editing.--Fuhghettaboutit (talk) 14:58, 11 December 2016 (UTC)
69.  Support Hell yes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:12, 11 December 2016 (UTC)
70.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
71.  Support Doug Weller (talk) 18:58, 11 December 2016 (UTC)
72.  Support^10! IJBall (talk) 19:04, 11 December 2016 (UTC)
73.  Support Anna Frodesiak (talk) 20:53, 11 December 2016 (UTC)
74.  Support Dank (talk) 02:52, 12 December 2016 (UTC)
75.  Support Mz7 (talk) 04:54, 12 December 2016 (UTC)
76.  Support -- numbermaniac 06:03, 12 December 2016 (UTC)
77.  Support Quiddity (talk) 09:12, 12 December 2016 (UTC)
78.  Support MrX (talk) 13:19, 12 December 2016 (UTC)
79.  Support, a very important feature, many things rely on it (e.g. eligibility for various elections) — NickK (talk) 13:21, 12 December 2016 (UTC)
80.  Support ONUnicorn (talk) 16:19, 12 December 2016 (UTC)
81.  Support - Neonorange (talk) 21:13, 12 December 2016 (UTC)
82.  Support--Mikheil ^Talk 21:14, 12 December 2016 (UTC)
83.  Support KSFT (talk) 22:12, 12 December 2016 (UTC)

Search user contributions

• Problem: There is no way to search a user's contributions to pinpoint revisions that an editor wishes to review regarding queried words or phrases.

• Who would benefit: All editors

• Proposed solution: Extend search function as described above

• Phabricator tickets:

• Proposer: VegasCasinoKid (talk) 07:52, 11 November 2016 (UTC)

• Translations: none yet

Community discussion

I could imagine this a bit like the "Search tools" filter in google's search result page. I'd like that. —TheDJ (talk • contribs) 11:30, 11 November 2016 (UTC)

• This is similar to the below proposal. I will point out that there are two community-built tools to search revision history: XTool's Article Blamer (sometimes inaccurate) and WikiBlame (accurate but slower). This does not answer the need to search through a user's contributions, however MusikAnimal (WMF) (talk) 18:10, 12 November 2016 (UTC)
• RELATED: to my knowledge there is no working way (tool is dead) to search for any user's contributions (including my own), nor has there been for at least a year. Don't give me suggestions, please take care of it if you know how. Self-puffery: I keep a log on my own page ([11]), but maintain it manually. Deisenbe (talk) 18:10, 19 November 2016 (UTC) (Don't know why my name is red.)
• @VegasCasinoKid: Kindly letting you know that I've removed the "search edit history" part of this proposal, since it is covered by the git blame proposal. Thanks for your participation! MusikAnimal (WMF) (talk) 18:04, 22 November 2016 (UTC)
• I'm not quite sure what's being proposed here. As MusikAnimal (WMF) says, we have two tools (when they're working) to search for specific changes to an article. We have (or should have) at least three tools that allow us to isolate the contributions of a specific user to that article:

• The Top Edits tool of XTools
• The User Contribution Search tool by User:Σ
• The userhist script by User:Ale jrb, which adds an "Isolate history" button to the revision history page … but as far as I know has never worked.

Of these, while the first two both do the job, the third is the most useful implementation – you can (in theory) isolate/unisolate the contributions of a single user with one click. It'd be great if it could be made to work. Justlettersandnumbers (talk) 11:52, 30 November 2016 (UTC)

Voting - Search user contributions

1.  Support Anthonyhcole (talk) 09:36, 29 November 2016 (UTC)
2.  Support FoCuSandLeArN (talk) 17:28, 29 November 2016 (UTC)
3.  Support Guycn2 · ☎ 19:01, 29 November 2016 (UTC)
4.  Support --Telaneo (User talk page) 21:56, 29 November 2016 (UTC)
5.  Support This will be useful in vandalism cases as well Semmendinger (talk) 19:42, 1 December 2016 (UTC)
6.  Support Oliv0 (talk) 22:32, 1 December 2016 (UTC)
7.  Support technically difficult --Framawiki (talk) 20:44, 2 December 2016 (UTC)
8. Neutral for pretty much the same reason as for the other blame-related proposal. Existing tools may not be perfect, but at least we have them. Asking WMF to create a maybe better alternative seems like a very low priority. Stevie is the man! ^{Talk • Work} 20:05, 4 December 2016 (UTC)
9. Neutral I can see how this could help deal with disruptive users, but I also fear that it would make it easier for disruptive users to follow and harass good editors. --Tryptofish (talk) 00:08, 6 December 2016 (UTC)
10.  Support (edit-conflict), as easy way to help find vandalism. Wikid77 (talk) 00:09, 6 December 2016 (UTC)
11.  Support. - Mailer Diablo (talk) 06:58, 7 December 2016 (UTC)
12.  Support --Dirk Beetstra ^{T C} (en: U, T) 08:49, 8 December 2016 (UTC)
13.  Support --Spencer (talk) 14:35, 9 December 2016 (UTC)
14.  Support Miniapolis 16:59, 9 December 2016 (UTC)
15.  Support - DPdH (talk) 11:52, 11 December 2016 (UTC)
16.  Support Yes, yes, more yes. A tremendous number of disputes do not get resolved in a timely fashion because of the sheer pain of diffing the evidence. Take that pain away.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:13, 11 December 2016 (UTC)
17.  Support — Music1201 ^talk 18:13, 11 December 2016 (UTC)
18.  Support – Very needed. IJBall (talk) 19:05, 11 December 2016 (UTC)
19.  Support MrX (talk) 13:22, 12 December 2016 (UTC)
20.  Support--Mikheil ^Talk 21:15, 12 December 2016 (UTC)
21.  Support KSFT (talk) 22:12, 12 December 2016 (UTC)