Community Wishlist Survey 2019/Admins and patrollers

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Admins and patrollers
15 proposals, 220 contributors, 320 support votes

Go-previous.svg Wiktionary  •  Anti-harassment Go-next.svg


Open diffs in new tab

Support Edit proposal/discussion

  • Problem: Sometimes when reviewing edits, we open the contributions list of an user and have to click on each diff link to check if there is anything wrong with the edits. For those that do it many times a day, it may be boring and time consuming to individually click on each of them.
  • Who would benefit: Reviewers in general, admins, stewards, oversighters, checkusers.
  • Proposed solution: It would be easier to have a button to open each diff in a new tab. Even if a limit is defined. Just like we have Smart rollback to rollback all the edits on a list, it will make our work easier and we will tend to be more thorough when looking for edits of a vandal, sockpuppet, or anything alike.
  • More comments:
  • Phabricator tickets:
  • Proposer: —Teles «Talk to me ˱C L @ S˲» 21:13, 6 November 2018 (UTC)

Discussion

  • You can middle click on diff links to achieve the same effect. MER-C (talk) 21:32, 6 November 2018 (UTC)
    That works for desktop! I give you that! However, the proposed would help a lot when doing it on mobile.—Teles «Talk to me ˱C L @ S˲» 21:41, 6 November 2018 (UTC)
    But that doesn't work on a laptop ....--1233 | Questions?| This message is left by him at 08:47, 7 November 2018 (UTC)
    Works on my laptop, with Firefox 63. It may depend on your browser. You might also be able to right-click and choose "Open in a new tab" from the context menu. Anomie (talk) 13:38, 7 November 2018 (UTC)
    @1233: On mobile you can usually do a long press on the link and choose "open in new tab" in the contextual menu —TheDJ (talkcontribs) 09:11, 8 November 2018 (UTC)
    Ctrl+click also works. MER-C (talk) 20:51, 7 November 2018 (UTC)
    @1233: ping for above replies. Also: on some laptops' trackpads you can "3-finger-tap" to simulate a mouse middle-click. Quiddity (WMF) (talk) 01:45, 8 November 2018 (UTC)
    If you're using a browser, you can click and hold which will generally open a series of options, one of which is usually open in new tab. (No comment on the apps.) --Izno (talk) 00:46, 7 November 2018 (UTC)
  • I note this sounds more suited as a user script or gadget than as a change to MediaWiki itself. Helping develop gadgets is stated to be within the Community Tech team's scope. Anomie (talk) 13:38, 7 November 2018 (UTC)
  • I don't think that's necessary. Click the middle button on your mouse or right-click on the link and "open in a new tab" just works. --Super Wang on zhwiki (Share your opinions) 23:46, 16 November 2018 (UTC)
    • @MER-C and Super Wang: It opens one link at once. If I understand the proposal, it needs one link to open in new tabs all changes on some list (contribs). Similar gadgets I can find on plwiki for opening multiple unreviewed (FlaggedRevs) edits. --Wargo (talk) 19:59, 18 November 2018 (UTC)

Voting

Allow De-Privileged logons to webui

Support Edit proposal/discussion

  • Problem: Currently privileged users must maintain multiple user accounts when wanting to log on with lesser access.
  • Who would benefit: Any privileged user, especially highly privileged users such as admins, interface editors, stewards
  • Proposed solution: Allow users to create sub-identities similar to Special:BotPasswords with different access grants, that allow interactive logon.
  • More comments: This will allow users that want to log on with less access (for example from mobile devices, from less trusted devices, or just to test things) to do so without having to maintain multiple accounts, with possibility of not requiring 2FA if otherwise enabled for sub-identities.
  • Phabricator tickets: T153454
  • Proposer: — xaosflux Talk 14:59, 8 November 2018 (UTC)

Discussion

I think having two accounts with different privileges is a much easier concept to explain and understand than one account that has different privileges depending on which password you put in. Multiple accounts seems like a much simpler solution to the problem and it's also a solution that already exists. I don't think this wish is a bad idea per se, but personally I'd rather see Community Tech focus their limited resources on problems that do not have fairly workable solutions already. --Deskana (talk) 16:28, 9 November 2018 (UTC)

Single accounts already do get different privileges depending on the credentials used with BotPassword and OAuth, however they are limited to the API instead of the WebUI. Keep in mind, this would not prevent the existing method of creating all the accounts someone wants. — xaosflux Talk 20:24, 9 November 2018 (UTC)
Noted, but I believe my general point about prioritisation stands. --Deskana (talk) 21:53, 9 November 2018 (UTC)

FYI, I added some implementation notes for the Community Tech team to consider to the talk page. BJorsch (WMF) (talk) 15:20, 17 November 2018 (UTC)

  • Nice idea, but I wonder if the admins will use it. I sort of doubt it. — Jeblad 08:54, 18 November 2018 (UTC)

Voting

Partial "Pending Changes" Reviewing

Support Edit proposal/discussion

  • Problem: Pending Changes protection becomes increasingly unwieldly once more than one editor's changes are pending. If both (at least) one desired post and one undesired post are pending it requires vastly more effort to ensure the article only gains the desired content. This discourages reviewers from handling it, which allows for an even larger edit queue to build up - causing a vicious cycle
  • Who would benefit: Any Pending Changes reviewer, and editors altering a PC-protected article
  • Proposed solution: Provide the ability to individually accept or decline non-clashing pending edits.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nosebagbear (talk) 20:13, 7 November 2018 (UTC)

Discussion

  • This dovetails really quick into the discussion for T113004. --Izno (talk) 20:52, 7 November 2018 (UTC)

Voting

  • Support Support PC is increasingly used on moderate and high activity pages and this would make it far more viable in this enviroment - reducing the need for semi-protect Nosebagbear (talk) 19:47, 16 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 03:35, 17 November 2018 (UTC)
  • Support Support Wugapodes (talk) 05:47, 17 November 2018 (UTC)
  • Support Support Kpgjhpjm (talk) 07:35, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:07, 17 November 2018 (UTC)
  • Support Support --Hadibe (talk) 22:05, 17 November 2018 (UTC)
  • Support Support Keith D (talk) 23:20, 17 November 2018 (UTC)
  • Support Support Ciao • Bestoernesto 06:55, 18 November 2018 (UTC)
  • Support Support — Newslinger talk 07:55, 18 November 2018 (UTC)
  • Support Support Absolutely — multiple pending changes that should have different statuses is a hugely confusing barrier to action. ~ Amory (utc) 11:34, 18 November 2018 (UTC)
  • Support Support Bruce1ee (talk) 18:11, 18 November 2018 (UTC)

Monitoring of new external links

Support Edit proposal/discussion

  • Problem: Right now, lots of new website links are being added to Wikipedia every day, lots of them are spam, lots of them are sneaky spam. Keeping track of them is hard.
  • Who would benefit: Patrollers
  • Proposed solution: There should be a special page that I can see recent new external links that are being added but it will be flooded with lots of trusted websites (like bbc.co.uk that's been used often). So it should have a whitelist of trusted sources to remove them for review list.
  • More comments:
  • Phabricator tickets:
  • Proposer: Amir (talk) 23:21, 1 November 2018 (UTC)

Discussion

So this would sort of work like AbuseFilter? Admins would have access to editing the whitelist?

(Would we want a central whitelist (sr.se might be more common to link to on Swedish Wikipedia than on German Wikipedia, but it's equally unlikely to be spam in both cases) or a per-wiki whitelist? But that's a discussion for later, maybe.) /Johan (WMF) (talk) 11:34, 2 November 2018 (UTC)

This already exists: #wikipedia-en-spamconnect and #wikimedia-external-linksconnect. MER-C (talk) 17:35, 2 November 2018 (UTC)
We're also planning a more thorough/direct solution as part of the Knowledge Integrity program. See T199189. Samwalton9 (WMF) (talk) 10:42, 6 November 2018 (UTC)
@Ladsgroup: Do the above solutions work for you? MusikAnimal (WMF) (talk) 17:23, 13 November 2018 (UTC)
I doubt, that would target tool developers but I want something for patrollers. Amir (talk) 18:49, 17 November 2018 (UTC)
I caution that this, if implemented, could quickly become just as problematic as any other automated "filter" system. It can easily become abused, and eventually do more harm than good. Filters are a very steep and very slippery slope towards censorship. Lostinlodos (talk) 01:40, 19 November 2018 (UTC)

Voting

Mark multiple revisions in a diff as patrolled

Support Edit proposal/discussion

  • Problem: Simplify and speedup patrolling activities
  • Who would benefit: Patroller
  • Proposed solution: Once compared the selected versions, should appear a button to verify all the changes at the same time with just one click
  • More comments:
  • Phabricator tickets: phab:T10697
  • Proposer: Andyrom75 (talk) 21:16, 7 November 2018 (UTC)

Discussion

@Andyrom75: Is this phab:T10697, or do I misunderstand? --AKlapper (WMF) (talk) 02:48, 8 November 2018 (UTC)

@AKlapper (WMF): correct, thanks. I've updated the template. --Andyrom75 (talk) 12:55, 8 November 2018 (UTC)

Voting

Make undeletion page ID sensitive

Support Edit proposal/discussion

  • Problem: The practice of selecting revisions on Special:Undelete to be restored is an outdated practice that is problematic nowadays for various reasons.

    The first thing one might have noticed in MediaWiki 1.31 is that parent IDs are now preserved on undeletions. But this still has some problems. The first problem, and the most serious one, is that it can cause page histories to be very confusing. For example, when viewing the history of Draft:Marques Monroe on Wikipedia, you will see that many size differences do not look "right". Allowing rev_parent_id to point to a revision in another page's history would just make things worse (in particular, if a revision from page A had rev_parent_id pointing to a revision from page B and B is deleted, the parent ID would become broken). Another problem is that if one selects a revision without selecting the previous revision, undeletion might result in a revision with a broken parent ID (T193211). For example, on this wiki, revision 18325584 has rev_parent_id 18325581, which is a deleted revision ID. Yet another problem is that there are already many revisions, e.g. on Wikipedia, where rev_parent_id either incorrectly points to a later revision (T38976; particularly imported revisions, such as the oldest 7 revisions in the history of the "2002" article) or is incorrectly set to zero (e.g. the revisions from June 2005 in the history of the "2006 in video gaming" article), and forcing parent IDs to be preserved on undeletions would make it impossible to solve such problems. Finally, one more problem is that for revisions deleted in MediaWiki 1.18 or earlier, which did not have the ar_parent_id field filled in, the pre-1.31 behavior of using the "getPreviousRevisionId" function would still be followed, which is inconsistent with the behavior for revisions deleted in newer MediaWiki versions.

    Setting the parent ID issues aside, there are still a few more issues with the current undeletion schema. One problem is that Special:Undelete lists all deleted revisions for a given title without indicating which deleted page ID they originally belonged to. It also allows two unrelated page histories to be "mixed" or "merged" too easily, which would cause confusion regardless of what happens with the parent IDs. Another problem is that timestamps, not revision IDs, are used to identify deleted revisions, meaning that two revisions with the same timestamp could not be separated (T39465). Finally, one more problem is that for pages with thousands of deleted revisions, Special:Undelete would list too many revisions all on one page.

  • Who would benefit: Administrators, particularly those who do history merges or imports
  • Proposed solution: See the tasks below for more details. We would then have a "pagearchive" table with columns named "pa_id", "pa_namespace", "pa_title", "pa_page_id", and "pa_rev_count", and the archive table would have a new column named "ar_pa_id". Also, a script that migrates the "ar_namespace", "ar_title", and "ar_page_id" columns to the new table would then be created. Then another script would be created that would de-duplicate page IDs in the "pagearchive" table, and also de-duplicate those that duplicate the ID of existing pages or an existing rev_page field. Finally, one more script would be created that would populate missing pa_page_id fields that previously corresponded to missing ar_page_id fields.

    Special:Undelete would not list deleted revisions anymore. Instead, it would list deleted page IDs from the "pagearchive" table as radio buttons, and deleted revisions, their diffs, and deleted page histories could be viewed directly by using the "oldid" and "curid" parameters in the URL. It would also allow the page to be automatically moved to another title of the user's choice after restoration, and this would be mandatory when the title of the page one is trying to restore already exists. In the latter case, the existing page would be temporarily deleted to allow for the restoration of the selected page ID. Also, Special:DeletedContributions would be fixed to look more like Special:Contributions, by displaying size differences and, for deleted revisions where the ar_parent_id is zero, the "new page" mark.

    Importing revisions to an existing page title would be allowed only when they are either all later than the page's latest revision, all earlier than the page's oldest revision, or all fit between two consecutive revisions in the page's history. In the latter two cases, the rev_parent_id field for the first revision following the imported revisions would automatically be changed to the ID of the latest imported revision.

    Special:MergeHistory would still exist, but would also have another restriction, namely that it could not be used when all of the revisions from the source page's history would become part of the target page's history. Also, the first revisions following the merged revisions in both pages' histories would automatically have their parent IDs swapped, so that n and 0 would become 0 and n.

    Two new special pages named "Special:SplitHistory" and "Special:MergeAndMove" would be created. For the former, a "SplitHistory" class would be created that would contain a function that splits the history of a deleted page ID by changing the ar_parent_id field for a single deleted revision to zero and assigning a new page ID to that deleted revision and all later ones. For an existing page, "Special:SplitHistory" would ask you to choose a cut-off point, which title some revisions should be moved to, and whether the earlier or the later revisions should be moved there. For the latter, a "MergeAndMove" class would be created that would contain a function that first changes the rev_parent_id field for the oldest revision in the target page's (henceforth called "B") history to coincide with the page_latest field for the source page (henceforth called "A"), then changes the rev_page field for all of B's revisions to A's page ID, deletes B from the page table, and finally moves A to B to complete a history merge.

    The "populateParentId" script would be modified so that it could not only populate rev_parent_id fields, but also ar_parent_id fields. And it would also generate a new parent ID for all existing and deleted revisions that already had one to fix many parent ID problems.

    Finally, a clean-up script would be created that would permanently delete some revisions from the revision and archive tables. When duplicated revisions (those with the same rev_page or ar_pa_id, same timestamp, same comment, same minority status, and same SHA1) occur, the script would keep the smallest rev_id or ar_rev_id only, and would automatically remove the RevisionDelete status from that revision if the text, edit summary, and username or IP address are all hidden. An example of where the latter would occur is the history of the "Cecilia Skingsley" article on Wikipedia. For revisions by IP addresses, the script would also delete the revisions from the "ip_changes" table.

Discussion

I note that T20493 may be relevant, in that it contemplates changing how deletion works in a much less overcomplicated manner. Anomie (talk) 12:07, 1 November 2018 (UTC)

Hi GeoffreyT2000, I left a message for you and MER-C on Community Wishlist Survey 2019/Admins and stewards/Feature parity for tools dealing with deleted revisions. -- DannyH (WMF) (talk) 01:29, 14 November 2018 (UTC)

Voting

Prevent DDoS-style attacks

Support Edit proposal/discussion

  • Problem: Currently at en.wikipedia, there is a troll that has been running a DDOS-style attack on the various pages that unregistered users frequently go for help (Ref Desks, Teahouse, Help Desk, and related talk pages). Currently the only blunt object we have to stop them is semi-protecting those pages, which is making it VERY difficult for IP-based users (or newly registered users who are not autoconfirmed) to find places to ask for help. The attack consists of spamming vile attacks against registered Wikipedia users, or grotesquely racist comments, or other attacks, hammering the page with edits as fast as every second or two, and jumping from open proxy to open proxy to evade blocking. The attacks start within minutes of the old protection expiring, and continue unabated until protection is returned. It is making the Wikipedia help system essentially unusable.
  • Who would benefit: Admins would have a finer-grade tool to protect pages, by allowing good-faith users to edit while stopping this highly disruptive sort of attack. IP and newly registered users would not be caught up in sanctions not intended for them.
  • Proposed solution: If there was a way to throttle edits to a page in some way, so that the same IP address and/or account would be prevented from multiple, repeat edits it could slow down this virulent attack. They would still be able to jump from open proxy to open proxy, but that takes them a little longer, and it would reduce the speed of the attack to something that hopefully we could manage with blocks and RevDel rather than page protection. What I am looking for here is a way to throttle protection so that the same IP address would have to wait for a non-bot intervening edit before being able to edit again. It wouldn't be needed often, but would come in VERY handy when it is needed.
  • More comments:
  • Phabricator tickets:

Discussion

  • Does {{helpme}} not help with this sort of thing? New contributors could use it quite well until they become autoconfirmed or whatever. Gryllida 22:15, 30 October 2018 (UTC)
  • Throttle edits to a page in some way, so that the same IP address and/or account would be prevented from multiple, repeat edits This can be accomplished with mw:AbuseFilter. It does not allow you to wait for a non-bot intervening edit before being able to edit again, but I'm confused why that would help. Could you elaborate? MusikAnimal (WMF) (talk) 22:31, 30 October 2018 (UTC)
    The problem is that someone has found a way to attack Wikipedia and shut down any page they wish using a DDOS-style attack. Currently, they are restricting themselves to areas where IP editors seek help (Help Desk, Teahouse, Ref Desk, ANI occasionally). They also tend to attack the user talk pages of the admins who try to stop them, or other users at will. If you have oversighter or admin privileges, you can pull up the history of this and see a sample of the problem here. If anyone has any idea on a technical fix that would stop this, it would be great. Right now, anyone who does this is able to shut down any page at will, and we really have no defense to it. It's exposed a vulnerability to the entire software, and it would only take one person with the will to do it to, say, expand their scope from a predictable set of project-space pages to instead just start spamming random articles across Wikipedia for hours on end, and they would soak up huge amounts of resources chasing them around, and really, we have no tools to stop them as yet. I'm not really tied to any solution, I made the proposal to get the ball rolling on a discussion, but in the end, it's stopping the problem and not this solution I think we should care about. Maybe I'm over reacting, but I would not want to see this go worst-case scenario, and have the Foundation get caught with their metaphorical pants down. We've got this contained to 1 troll now who is doing it in a limited fashion. This is the sort of thing that, if a bunch of people got bored or had an axe to grind at Wikipedia, could do a lot of damage. If y'all don't see this as a problem, that's fine. It's been annoying as heck at en.wikipedia to deal with on a daily basis, and I don't want to see this trend growing. If anyone has other ideas on technical fixes for this, beyond "end IP-based editing", I'd love to see them. --Jayron32 (talk) 11:50, 31 October 2018 (UTC)
    @Jayron32: w:Special:AbuseFilter/796? We should not discuss this filter publicly, but it seems to do what you are suggesting. MusikAnimal (WMF) (talk) 16:34, 3 November 2018 (UTC)
    There are currently 3 abuse filters set to stop this one person. They don't really work, because abuse filters are only set to recognize specific text strings. He's been doing this for years, and knows enough to vary his text strings just enough to make the abuse filters useless. --Jayron32 (talk) 15:06, 5 November 2018 (UTC)
Maybe adding to abusefilter an option to trigger a captcha, might be helpful? Assuming that attack is bot-based? BWolff (WMF) (talk) 01:51, 5 November 2018 (UTC)
It may or may not be bot based. I suspect he may be just rapidly doing the edits manually, but it COULD be bot-based as well. Having a CAPTCHA option sounds brilliant, actually. If admins had the ability to set a "CAPTCHA protection" for certain pages, that may slow him down enough for us to minimize damage. It's a small inconvenience for making one edit, but it would slow down the rapid, repeated attacks so we could deal with them. --Jayron32 (talk) 15:06, 5 November 2018 (UTC)
I would be very interested to see if CAPTCHA protection would solve this problem. I highly doubt this is done manually. They come in more quickly than I can even hit the rollback button, and I have a hard time imagining something that would take less manual time than a single click. GMGtalk 13:25, 7 November 2018 (UTC)
Adding something like $wgCaptchaTriggersOnProtection['captchaProtection']['edit'] = true; to Extension:ConfirmEdit might be an option. I would actually be interested in the effect of enabling CAPTCHA on pending-changes protected pages more generally. TheDragonFire (talk) 13:36, 7 November 2018 (UTC)

Even though a Captcha might be an interesting solution, I don't see how a reasonable rate-limit would do anything but slow down those attacks considerably, while being far less invasive for human editors. It would make sense to base this option not only on IPs, which, as already pointed out, could be rotated as a countermeasure, but also on the attacked pagese themselves. As this option does not seem to exist, from what I read here, that might be a worthwhile extension to prevent a predictable serious threat. --Eloquenzministerium (talk) 14:38, 8 November 2018 (UTC)

  • Alright, so per this comment looks like the edits are definitely automated, which makes me inclined to think a captcha would be the way to go. Also it would be super if we could escalate this in terms of importance given the level of disruption, rather than winding through the whole community wishlist process so we can get something implemented ~sometimes over the next year or so. GMGtalk 14:59, 9 November 2018 (UTC)
  • Just an update on the need for this; our friend has decided to expand his reach to any random article/talk page/etc. See [1]. Having a solution to stop him beyond "semiprotecting the entire encyclopedia" would be great. --Jayron32 (talk) 15:56, 9 November 2018 (UTC)
    @Jayron32: Are we asking to impose a CAPTCHA via AbuseFilter? Or is the proposal still centered around a new form of page protection that would throttle edits from the specified user groups? Maybe impose a CAPTCHA once said throttle has been hit? The voting phase goes live this Friday, and I want to make sure we know what we're voting on. Obviously we want to put a stop to the current vandalism spree, but it's worth noting the wishlist defines projects we'll take on in the next calendar year, and not so much for urgent solutions. That said whatever comes out of this will be useful for future vandalism sprees, I'm sure. MusikAnimal (WMF) (talk) 04:32, 14 November 2018 (UTC)
    On second thought, I think the problem statement is clear. We don't need to worry about the solution just yet. However we might consider is renaming the proposal to something like "Prevent DDoS-style attacks". This will make it more clear what we're voting on, and might increase the chances of getting a lot of support. If I don't hear back about this soon, I'll take the liberty of renaming the proposal. If you later disagree, just ping me :) Ideally we'll have this sorted out before voting starts tomorrow. MusikAnimal (WMF) (talk) 19:29, 15 November 2018 (UTC)
    I have performed the rename. Hope this is okay! MusikAnimal (WMF) (talk) 16:16, 16 November 2018 (UTC)
  • Throttling similar edits over several pages are possible. I wrote about it a few years back, but nobody has picked up the idea. Could be because it involves math. — Jeblad 08:50, 18 November 2018 (UTC)

Shouldn't this proposal be in anti-harrassment category? --Dvorapa (talk) 16:59, 18 November 2018 (UTC)

Voting

Feature parity for tools dealing with deleted revisions

Support Edit proposal/discussion

  • Who would benefit:
  • Proposed solution:
  • Phabricator tickets:
  • Proposer: MER-C (talk) 11:49, 30 October 2018 (UTC)

Discussion

I note that T20493 may be relevant, in that it contemplates changing how deletion works which might make many of the things complained about here obsolete. Also, the action API's alldeletedrevisions will probably never work like usercontribs; instead we'd create a "deletedusercontribs" module. Anomie (talk) 14:16, 30 October 2018 (UTC)

MER-C and GeoffreyT2000: Is there any way to reconcile this proposal, and Make undeletion page ID sensitive? These are both very long, detailed solutions for a problem that basically boils down to "Special:Undelete is clunky/outdated". Our team is having a hard time figuring out what to make of these two mutually exclusive proposals, and I imagine that people voting in the survey will also be confused about which to vote for. Is it possible to merge these, or simplify them? -- DannyH (WMF) (talk) 01:28, 14 November 2018 (UTC)
The proposals have a lot of commonality:
Paging for Special:Undelete, so that long lists of deleted revisions don't take ages to load.
Add date cutoff filters to Special:Undelete and sizediffs
I want to be able to compare non-adjacent deleted edits on the same page.
deleted revisions, their diffs, and deleted page histories could be viewed directly by using the "oldid" and "curid" parameters in the URL.
The proposals are equivalent as long as the deleted page history page is presented identically to a live page history - with pagination, date filters and radio buttons to select revisions for diffing.
And again, except for deleted title search.
Special:Undelete would not list deleted revisions anymore. Instead, it would list deleted page IDs from the "pagearchive" table as radio buttons
Adding a search box and prefixindex box to this listing of pages, and making the listing/search results pageable means the two proposals are equivalent.
I want to compare deleted content to live revisions under the same title, or live/deleted revisions for a different title. This is especially useful to check whether a page has been substantially reposted. I could do this via Special:Diff or the API... but deleted revision links should use "rev_id" not "page/timestamp". Not being able to easily discover the revid is a damn nuisance.
See point immediately above. Special:Diff should admit deleted and non-deleted revids and function as expected when I have the rights.
but deleted revision links should use "rev_id" not "page/timestamp". Not being able to easily discover the revid is a damn nuisance.
deleted revisions, their diffs, and deleted page histories could be viewed directly by using the "oldid" and "curid" parameters in the URL.
Is this not the same thing?
Also, Special:DeletedContributions would be fixed to look more like Special:Contributions, by displaying size differences and, for deleted revisions where the ar_parent_id is zero, the "new page" mark.
I also want this.
I don't care what happens regarding back end development. I just want to be able to perform all the same actions with the GUI and API and make equivalent API calls to get the same information as I can currently can with live page histories. (I disagree with the force a different title restriction - sometimes an undeletion for the same title is useful). MER-C (talk) 12:38, 14 November 2018 (UTC)
I think we can combine the proposals, but I want GeoffreyT2000's consent first. MER-C (talk) 11:50, 15 November 2018 (UTC)

Voting

Page Curation and New Pages Feed improvements

Support Edit proposal/discussion

  • Problem: New Page Review is a key process on Wikipedia, and the only firewall that prevents inappropriate new pages being added to the Encyclopedia. However, there are many longstanding issues with the Page Curation tools and the New Pages feed which inhibit efficiency and cause problems to be overlooked. Aside from a few additions made when the Growth Team added Articles for Creation (AfC) drafts to the New Page Feed last year, the tools haven't been supported for many years and the list of proposed developments is long. These include bugs, features never implemented, and suggested improvements which have been left unaddressed. While a few requests for improvement of the tools used by New Page Reviewers can be addressed by on-wiki customisation by volunteers, most others are part of the Mediawiki software and require the intervention of the WMF developers.

    We have been repeatedly informed that the Community Tech Team does not have the resources to provide ongoing support for the tools they developed (or even to fix bugs that have popped up) and that this wishlist is the only venue for us to come to for technical assistance. While some of the tasks below are almost trivially easy, others may require a significant time investment.

  • Who would benefit: While New Page Reviewers and admins are the only users with access to the Page Curation tools, ultimately the entire wiki benefits from the work that we do. AfC drafts were recently added to the New Page Feed, and many of the suggested improvements here would also benefit the AfC team. The English wiki is also not the only one that could benefit, as these tools are not only relegated to EN Wikipedia but were originally designed to be available for use on other wikis as well (I am not currently aware of how many wikis the PC tools are configured on, but they certainly could be in the future).
  • Proposed solution: The requested improvements come in a few categories:
    • Bugs that should have been fixed a long time ago,
    • Additional sorting options and additional 'potential issues' flagging in the PC tools and New Pages Feed, which would help to flag problems for reviewers to follow up on,
    • Resources dedicated to other suggested improvements supported by the New Page Reviewer community to make them more user-friendly and improve efficiency.
  • More comments: While there were several dozen good suggested improvements, we have listed only the highest priority items below by their Phabricator tickets, in the hope that at least some of our most pressing concerns will be addressed.

Discussion

Insertcleverphrasehere: Just a heads up, if you didn't notice -- we've moved this proposal from "Miscellaneous" to "Admins and patrollers". -- DannyH (WMF) (talk) 18:52, 15 November 2018 (UTC)

  • T207452 in particular would be a really helpful bit. Hopefully the reduction in mooted ideas will help some focus without completely limiting where the benefit gets focused to. Nosebagbear (talk) 21:07, 16 November 2018 (UTC)
  • Question: Apart from English Wikipedia, is there any other WMF project that uses NewPagesFeed? 4nn1l2 (talk) 05:02, 17 November 2018 (UTC)
Possibly not at this moment in time, because it is still not perfect until the wished for upgrades are carried out. The English Wikipedia is however by far the most important project and being synonymous with the word Wikipedia is the source for all the undesirable pages masquerading as encyclopedia articles. As a MediaWiki extension, it could probably be ported to other WikiMedia projects (and even other non-Foundation projects who want to use it). It should be borne in mind however that without a well performing New Page vetting system, the English Wikipedia will cease to exist as we know it. Kudpung (talk) 06:16, 18 November 2018 (UTC)

Voting

  • Support SupportInsertcleverphrasehere (or here) 18:10, 16 November 2018 (UTC)
  • Support Support - Atsme📞📧 18:17, 16 November 2018 (UTC)
  • Support Support - Wholeheartedly. Onel5969 TT me 18:34, 16 November 2018 (UTC)
  • Support Support James Martindale (talk) 18:34, 16 November 2018 (UTC)
  • Support Support Rosguill (talk) 18:38, 16 November 2018 (UTC)
  • Support Support Alucard 16 (talk) 18:39, 16 November 2018 (UTC)
  • Support Support definitely.--SkyGazer 512 (talk) 18:40, 16 November 2018 (UTC)
  • Support Support Regards, — Moe Epsilon 18:40, 16 November 2018 (UTC)
  • Symbol strong support vote.svg Strong support I have been using this tool for some time now and the required updates will make it easier to contribute. --Satdeep Gill (talk) 18:40, 16 November 2018 (UTC)
  • Support Support.Flooded with them hundreds (talk) 18:41, 16 November 2018 (UTC)
  • Support Support Kb03 (talk) 18:41, 16 November 2018 (UTC)
  • Support Support --Kges1901 (talk) 18:42, 16 November 2018 (UTC)
  • Support Support Drm310 (talk) 18:44, 16 November 2018 (UTC)
  • Support Support Galobtter (talk) 18:45, 16 November 2018 (UTC)
  • Symbol strong support vote.svg Strong support — Would only better the—in my opinion—already good new page reviewing process at the English Wikipedia. SshibumXZ (talk) 18:47, 16 November 2018 (UTC)
  • Support Support Theroadislong (talk) 18:47, 16 November 2018 (UTC)
  • Support Support Pkbwcgs (talk) 18:48, 16 November 2018 (UTC)
  • Support Support Saederup92 (talk) 18:49, 16 November 2018 (UTC)
  • Support Support Shellwood (talk) 18:52, 16 November 2018 (UTC)
  • Support Support Wumbolo (talk) 18:54, 16 November 2018 (UTC)
  • Support Support Mark the train (talk) 18:55, 16 November 2018 (UTC)
  • Support Support MER-C (talk) 18:57, 16 November 2018 (UTC)
  • Support Support Anaxial (talk) 18:58, 16 November 2018 (UTC)
  • Support Support Pichpich (talk) 19:00, 16 November 2018 (UTC)
  • Support Support Redalert2fan (talk) 19:01, 16 November 2018 (UTC)
  • Support Support — Newslinger talk 19:02, 16 November 2018 (UTC)
  • Support Support MrX (talk) 19:08, 16 November 2018 (UTC)
  • Support Support Staszek Lem (talk) 19:10, 16 November 2018 (UTC)
  • Support Support SEMMENDINGER (talk) 19:12, 16 November 2018 (UTC)
  • Support Support StudiesWorld (talk) 19:21, 16 November 2018 (UTC)
  • Support Support --Seacactus 13 (talk) 19:22, 16 November 2018 (UTC)
  • Support Support Agtx (talk) 19:23, 16 November 2018 (UTC)
  • Support Support Zchrykng (talk) 19:24, 16 November 2018 (UTC)
  • Support Support Argento Surfer (talk) 19:26, 16 November 2018 (UTC)
  • Support Support Kosack (talk) 19:28, 16 November 2018 (UTC)
  • Support Support Ive done some Page curation, and will do more if the function gets developed Dan Koehl (talk) 19:37, 16 November 2018 (UTC)
  • Support Support strongly, this is a vital tool Atlantic306 (talk) 19:41, 16 November 2018 (UTC)
  • Support Support please also try to bring it to other language Wikipedias. Thanks much Cohaf (talk) 19:42, 16 November 2018 (UTC)
    • I knew this will be passed nevertheless, and ICPH and the team (Inc kudpung as I read the Phab tickets) had done a hell load of good work which should be recognized so I don't see the point of opposing. However, I would like to register my strong dislike of Kudpung comments above. Yes, English Wikipedia is important but not until the fact that all other projects seems to be in a totally dependent state. I simply doesn't buy it. --Cohaf (talk) 19:24, 18 November 2018 (UTC)
  • Support Support - very strongly, particularly with the increasing merging of NPP and AfC Nosebagbear (talk) 19:45, 16 November 2018 (UTC)
  • Support Support The WMF needs to commit to ongoing support for the page curation tools. If they cannot do that, they should instead create and limit themselves to supporting an API that enables community development. It is an outrage that this ticket, by necessity, includes request for bug fixes. Until then, this wish list is, apparently, the only way that new page reviewers can get the development support they need. Vexations (talk) 19:46, 16 November 2018 (UTC)
  • Support Support = paul2520 (talk) 19:50, 16 November 2018 (UTC)
  • Support Support FitIndia Talk 19:55, 16 November 2018 (UTC)
  • Support Support L293D ( • ) 19:57, 16 November 2018 (UTC)
  • Support Support CoolSkittle (talk) 20:07, 16 November 2018 (UTC)
  • Support Support Bradv (talk) 20:10, 16 November 2018 (UTC)
  • Support Support My name is not dave (talk) 20:19, 16 November 2018 (UTC)
  • Support Support with the hope for continued and/or increased development and maintenance effort in this regard. --Elmidae (talk) 20:21, 16 November 2018 (UTC)
  • Support Support as a specific item, it would be good if the New Pages Tool could spot check for already existing tags and checkmarks; as I've been burned for doing regular tagging that was redundant with some somewhat hidden tags. AngusWOOF (talk) 20:22, 16 November 2018 (UTC)
  • Support Support Geoff Who, me? 20:30, 16 November 2018 (UTC)
  • Support Support Dodger67 (talk) 20:35, 16 November 2018 (UTC)
  • Support Support Vermont (talk) 21:31, 16 November 2018 (UTC)
  • Symbol strong support vote.svg Strong support (disclosure: I get the NPP newsletter) — pythoncoder (talk | contribs) 22:08, 16 November 2018 (UTC)
  • Support Support NPP is an important safeguard to retaining Wikipedia's reputation. Hopefully its tools could also be brought to other projects. Barkeep49 (talk) 22:13, 16 November 2018 (UTC)
  • Support Support--Ozzie10aaaa (talk) 22:29, 16 November 2018 (UTC)
  • Support Support Araratic (talk) 22:32, 16 November 2018 (UTC)
  • Support Support John Broughton (talk) 23:27, 16 November 2018 (UTC)
  • Support Support A well-thought-through set of requests which would improve the effectiveness of the dedicated volunteers who defend the encyclopedia from an oncoming tide of rubbish. PamD (talk) 23:47, 16 November 2018 (UTC)
  • Support Support ToThAc (talk) 23:51, 16 November 2018 (UTC)
  • Support Support — JJMC89(T·C) 00:15, 17 November 2018 (UTC)
  • Support Support Gehenna1510 (talk) 00:20, 17 November 2018 (UTC)
  • Support Supportnumbermaniac 00:37, 17 November 2018 (UTC)
  • Support Support Anarchyte (work | talk) 00:41, 17 November 2018 (UTC)
  • Support Support- Dcheagle (talk) 01:17, 17 November 2018 (UTC)
  • Support Support-CASSIOPEIA (talk) 01:26, 17 November 2018 (UTC)
  • Support Support AmericanAir88 (talk) 01:29, 17 November 2018 (UTC)
  • Support SupportAkhiljaxxn (talk) 01:35, 17 November 2018 (UTC)
  • Support Support Natureium (talk) 02:16, 17 November 2018 (UTC)
  • Support Support MRD2014 (talk) 03:09, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 03:35, 17 November 2018 (UTC)
  • Support Support Winged Blades of Godric (talk) 04:37, 17 November 2018 (UTC)
  • Support Support JTP (talkcontribs) 04:46, 17 November 2018 (UTC)
  • Support Support Abzeronow (talk) 04:52, 17 November 2018 (UTC)
  • Support Support Ehime«» 05:46, 17 November 2018 (UTC)
  • Support Support about time Kudpung (talk) 07:17, 17 November 2018 (UTC)
  • Support Support Kpgjhpjm (talk) 07:33, 17 November 2018 (UTC)
  • Support Support Domdeparis (talk) 07:37, 17 November 2018 (UTC)
  • Support Support this is essential for maintaining the integrity of wikipedia. Polyamorph (talk) 08:56, 17 November 2018 (UTC)
  • Support Support good. 333-blue 09:49, 17 November 2018 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose I know there are no Opposes but this would not benefit most of the users. --FF-11 (talk) 09:56, 17 November 2018 (UTC)
  • Oppose Oppose I am minded to agree that this would not help most users, and in general I find the heavy proceduralization of new page patrol to be a problem. Jo-Jo Eumerus (talk, contributions) 10:03, 17 November 2018 (UTC)
    Comment Comment: FF-11 & Jo-Jo Eumerus, We were not that keen to take up a slot in the community wishlist either (although the wishlist is not just for proposals that help 'all users', this is the 'Admins and Patrollers' section after all). We have been forced to come here as a last resort as we have been told in no-uncertain-terms that they won't even do bug fixes to the existing tools unless we come here. It's a crappy situation, but we don't have an alternative. As for a potential for over-proceduralization of NPP, I'd be keen to discuss in more detail elsewhere (please contact me on my talk page). Cheers, — Insertcleverphrasehere (or here) 16:28, 17 November 2018 (UTC)
    Comment Comment, FF-11 & Jo-Jo Eumerus, as can be seen, many of the various wish list requests do not address all users. However, the impact of New Page Patrolling/Reviewing affects all new users who wish to create new articles. The current level of 'proceduralization' has never changed since NPP was introduced at the very beginning of the Wikipedia. These requsts do not over-proceduralize the process, nor do they even add any more layers of bureaucracy to it. They simply improve the work flow for the users who do this thankless task and who are unable to keep up with the flood of junk that will fill the encyclopedia if they don't. Kudpung (talk) 06:38, 18 November 2018 (UTC)
  • Support Support PratyushSinha101 (talk) 10:13, 17 November 2018 (UTC)
  • Support Support Patriccck (talk) 10:35, 17 November 2018 (UTC)
  • Support Support Jc86035 (talk) 10:56, 17 November 2018 (UTC)
  • Support Support ‐‐1997kB (talk) 11:03, 17 November 2018 (UTC)
  • Support Support AlexLeeCN (talk) 11:44, 17 November 2018 (UTC)
  • Support Support Much needed for the project Cahk (talk) 11:46, 17 November 2018 (UTC)
  • Support Support Jcc (talk) 12:12, 17 November 2018 (UTC)
  • Support Support Like tears in rain (talk) 12:23, 17 November 2018 (UTC)
  • Support Support This seems reasonable. I have seen canvassing.GreyGreenWhy (talk) 15:07, 17 November 2018 (UTC)
    Comment Comment GreyGreenWhy, Note that canvassing is allowed (and even encouraged) by the rules of the Community Wishlist. See talk page for more info. I don't want anyone to think we have done anything untoward by spreading the word about this proposal. — Insertcleverphrasehere (or here) 16:32, 17 November 2018 (UTC)
  • Support Support Though bug fixes such as T169441 should really not be having to come through this Wishlist route AllyD (talk) 20:20, 17 November 2018 (UTC)
  • Support Support Mmitchell10 (talk) 20:51, 17 November 2018 (UTC)
  • Support Support Far and away the most important proposal on the Community Wishlist Survey this year. Kind of absurd that we have to vote in bug fixes for what is essentially core functionality at this point. Snuge purveyor (talk) 22:30, 17 November 2018 (UTC)
  • Support Support support completely! :) Megalibrarygirl (talk) 02:26, 18 November 2018 (UTC)
  • Support Support Catrìona (talk) 06:04, 18 November 2018 (UTC)
  • Support Support Curb Safe Charmer (talk) 09:49, 18 November 2018 (UTC)
  • Support Support Sdkb (talk) 11:01, 18 November 2018 (UTC)
  • Support Support Abelmoschus Esculentus (talk) 11:59, 18 November 2018 (UTC)
  • Support Support Eddie891 (talk) 12:26, 18 November 2018 (UTC)
  • Support Support Sebastian Wallroth (talk) 13:13, 18 November 2018 (UTC)
  • Support Support enL3X1 ¡‹delayed reaction›¡ 14:41, 18 November 2018 (UTC) #94
  • Support Support SilverTiger12 (talk) 15:20, 18 November 2018 (UTC)
  • Support Support --AntanO 15:58, 18 November 2018 (UTC)
  • Support Support Schwede66 (talk) 17:40, 18 November 2018 (UTC)
  • Support Support · · · Peter (Southwood) (talk): 18:09, 18 November 2018 (UTC)
  • Support Support ProgrammingGeek talktome 19:57, 18 November 2018 (UTC)
  • Support Support Ajpolino (talk) 20:42, 18 November 2018 (UTC)
  • Support Support Crystallizedcarbon (talk) 20:44, 18 November 2018 (UTC)
  • Support Support Esquivalience (talk) 23:58, 18 November 2018 (UTC)
  • Support Support Barbara (WVS) (talk) 00:46, 19 November 2018 (UTC)

Filter user contributions as patrolled or unpatrolled

Support Edit proposal/discussion

  • Problem: It's not possible to just see the reviewed/patrolled or unreviewed/unpatrolled edits in a list of contributions.
    Deutsch: Es ist nicht möglich, nur die gesichteten oder ungesichteten Beiträge in einer Beitragsliste anzuzeigen
  • Who would benefit: Everyone who uses these filters, for example reviewers/patrollers, who then don't have to go through all edits by a users (possibly together with the option "only
    Deutsch: Alle, die solche Filter benötigen, z. B. Sichter, die alle nicht gesichteten Beiträge eines Benutzers überprüfen möchten (eventuell zusammen mit der Option "Nur aktuelle Versionen
  • Proposed solution: Add a drop-down menu with the options "reviewed", "unreviewd" and "all", or "unchecked", "checked" and all.
    Deutsch: Eine Drop-Down-Liste mit den Einträgen "Gesichtet", "Ungesichtet" und "Alle" beziehungsweise "Ungeprüft", "Geprüft" und "Alle" hinzufügen
  • Further comments:
  • Phabricator tickets:
  • Proposer: FF-11 (talk) 20:26, 29 October 2018 (UTC)

Discussion

This was originally posted in German. I've added a rough English translation, and kept the German text below. If this feels unfamiliar to you, it's because German Wikipedia, unlike most Wikimedia wikis, uses Flagged Revisions. /Johan (WMF) (talk) 12:49, 2 November 2018 (UTC)

Voting

Overhaul spam-blacklist

Support Edit proposal/discussion

  • Problem: The current blacklist system is archaic; it does not allow for levels of blacklisting, is confusing to editors. Main problems include that the spam blacklist is indiscriminate of namespace, userstatus, material linked to, etc. The blacklist is a crude, black-and-white choice, allowing additions by only non-autoconfirmed editors, or only by admins is not possible, nor is it possible to allow links in certain namespaces. Also giving warnings is not possible (on en.wikipedia, we implemented XLinkBot, who reverts and warns - giving a warning to IPs and 'new' editors that a certain link is in violation of policies/guidelines would be a less bitey solution).
  • Who would benefit: Editors on all Wikipedia's
  • Proposed solution: Basically, replace the current mw:Extension:SpamBlacklist with a new extension with an interface similar to mw:Extension:AbuseFilter, where instead of conditions, the field contains a set of regexes that are interpreted like the current spam-blacklists, providing options (similar to the current AbuseFilter) to decide what happens when an added external link matches the regexes in the field (see more elaborate explanation in collapsed box).

    Note: technically, the current AbuseFilter is capable of doing what would be needed, except that in this form it is extremely heavyweight to use for the number of regexes that is on the blacklists, or one would need to write a large number of rather complex AbuseFilters. The suggested filter is basically a specialised form of the AbuseFilter that only matches regexes against added external links.

description of suggested implementation

description of suggested implementation

  1. Take the current AbuseFilter, create a copy of the whole extension, name it ExternalLinkFilter, take out all the code that interprets the rules ('conditions').
  2. Make 2 fields in replacement for the 'conditions' field:
    • one text field for regexes that block added external links (the blacklist). Can contain many rules (one on each line, like current spam-blacklist).
    • one text field for regexes that override the block (whitelist overriding this blacklist field; that is generally more simple, and cleaner than writing a complex regex, not everybody is a specialist on regexes).
  3. Leave all the other options:
    • Discussion field for evidence (or better, a talk-page like function)
    • Enabled/disabled/deleted (not turn it off when not needed anymore, delete when obsolete)
    • 'Flag the edit in the edit filter log' - maybe nice to be able to turn it off, to get rid of the real rubbish that doesn't need to be logged
    • Rate limiting - catch editors that start spamming an otherwise reasonably good link
    • Warn - could be a replacement for en:User:XLinkBot
    • Prevent the action - as is the current blacklist/whitelist function
    • Revoke autoconfirmed - make sure that spammers are caught and checked
    • Tagging - for certain rules to be checked by RC patrollers.
    • I would consider to add a button to auto-block editors on certain typical spambot-domains (a function currently taken by one of Anomie's bots on en.wikipedia).

This should overall be much more lightweight than the current AbuseFilter (all it does is regex-testing as the spam-blacklist does, only it has to cycle through maybe thousands of AbuseFilters). One could consider to expand it to have rules blocked or enabled on only certain pages (for heavily abused links that actually should only be used on it's own subject page). Another consideration would be to have a 'custom reply' field, pointing the editor that gets blocked by the filter as to why it was blocked.

Possible expanded features (though highly desired)
  1. create a separate userright akin AbuseFilterEditor for being able to edit spam filters (on en.wikipedia, most admins do not touch (or do not dare to touch) the blacklist, while there are non-admin editors who often help on the blacklist).
  2. Add namespace choice (checkboxes like in search; so one can choose not to blacklist something in one particular namespace, with addition of an 'all', a 'content-namespace only' and 'talk-namespace only'.
    • some links are fine in discussions but should not be used in mainspace, others are a total nono
    • some image links are fine in the file-namespace to tell where it came from, but not needed in mainspace (e.g. flickr is currently on revertlist on en.wikipedia's XLinkBot)
  3. Add user status choice (checkboxes for the different roles, or like the page-protection levels)
    • disallow IPs and new users to use a certain link (e.g. to stop spammers from creating socks, while leaving it free to most users).
    • warn IPs and new users when they use a certain link that the link often does not meet inclusion standards (e.g. twitter feeds are often discouraged as external links when other official sites of the subject exists; like the functionality of en:User:XLinkBot).
  4. block or whitelist links matching regexes on specific pages (disallow linking throughout except for on the subject page) - coding akin the title blacklist
  5. block links matching regexes when added by specific user/IP/IP-range (disallow specific users to use a domain) - coding akin the title blacklist
Downsides

We would lose a single full list of material that is blacklisted (the current blacklist is known to work as a deterrent against spamming). That list could however be independently created based on the current rules (e.g. by bot).

  • More comments:
  • Phabricator tickets: task T6459 (where I proposed this earlier)

Discussion

I 2nd this and would like to request a feature to be added: When fighting spam one always has to look up both SBL log and Abuse log. It would have saved me thousands of clicks if the SBL log could be merged (for displaying purposes only) into the Abuse log (by checkbox for example or even via a virtual abuse filter number) so that one view shows the spamming actions. --Achim (talk) 12:50, 30 October 2018 (UTC)

Just to set realistic expectations here, it is unlikely that the Community Tech team would have the time and resources to create something similar to AbuseFilter. It may be possible, however, for the team to make some improvements to the existing bare-bones implementation. Ryan Kaldari (WMF) (talk) 01:05, 14 November 2018 (UTC)

    • @Ryan Kaldari (WMF): my apologies if this comes through harsh: that is a matter of priorities, the WMF has spent an enormous amount of developing time to code that is sometimes flat out rejected by the community, code that is then stuffed down our throats in the worst cases (up to superprotect, remember). The spam blacklist is now a crude, minimalistic piece of code that, despite some hacks, is in some cases more disruptive than the spammers/abuse, and maintainers need sometimes to jump through hoops to collect evidence. Requests to upgrades exist for years now, utterly ignored. Three bots are written to fill in some of the holes, but it would be more efficient to replace on of them (which is now only protecting one wiki ..), and have a meaningful and useful extension (and replacement to a part) for the others.
    Editor retention and attracting new editors scales linearly (if not exponentially) with attracting spammers and ‘keeping’ (i.e. not getting rid of) them ... it is time to finally realise that the admin corps needs more tools to protect. —Dirk Beetstra T C (en: U, T) 03:58, 14 November 2018 (UTC)
    • @Ryan Kaldari (WMF): (<- new ping, as I am not sure if my previous ping worked). One of those hoops is currently discussed here: Talk:Spam_blacklist#more_than_3000_entries. One of our maintainers, User:Lustiger seth is now running a very long running script to collect all rules that have not been hit. From that, we have to go through other hoops to select out the ones that should, even if they do not hit, should not be removed, and then we can cleanup the current list of several thousands of entries. Editors in some cases request de-listing as 'it has not been added' (dôh), and we have to try and show that it was actually tried (which we ignore because we simply can't). The current blacklist is too crude. It needs to be replaced by something that is way more modular and has way more options. It cannot be done by the current extension, it basically needs to be re-designed from scratch. --Dirk Beetstra T C (en: U, T) 05:35, 14 November 2018 (UTC)
      • @Beetstra: Thanks for providing more context. It sounds like the current system is pretty abysmal. I think it would be appropriate for us to consider an overhaul, I just don't think it would be realistic for our team to build something as complex as AbuseFilter within the constraints that we have (and considering our very limited capacity for maintenance work afterwards). I won't disagree with any of your arguments, just want to set realistic expectations. Ryan Kaldari (WMF) (talk) 17:43, 14 November 2018 (UTC)
        • How about others in the WMF? Although that would be out of the scope of the survey. C933103 (talk) 06:14, 15 November 2018 (UTC)
        • @Ryan Kaldari (WMF): in fact, I am taking the already existing AbuseFilter, and rip out all the rule interpretation code and replace it with one (maby two) simple regex check. It is byfarnot as complex as the AbuseFilter, and the rest of the existing code is almost immediately usable without adaptation. —Dirk Beetstra T C (en: U, T) 07:10, 15 November 2018 (UTC)
          • @Beetstra: Unfortunately, the AbuseFilter extension has been mostly unmaintained for years and would need to be overhauled, even if we didn't reuse the rule interpretation code. The AbuseFilter codebase is extremely old and buggy at this point. Last time I checked it had 311 open bugs, including 23 open security bugs! The new MediaWiki Platform team has agreed to do some work on cleaning-up AbuseFilter next year, but in the meantime I don't think it would be a viable option for us. I'm confident we could come up with something that works better than the current system, however. Ryan Kaldari (WMF) (talk) 21:58, 15 November 2018 (UTC)
            • @Ryan Kaldari (WMF): so .. a nice time for a joint effort? Or are we back at my initial point regarding WMF (IMHO completely misplaced) priorities? Not only have they made the spam blacklist become outdated, also the AbuseFilter .. <sarcasm>at least now we have a nice image viewer, and a visual editor and what not ... </sarcasm> —Dirk Beetstra T C (en: U, T) 05:24, 16 November 2018 (UTC)
  • I am going to +1 this, the blacklist and edit filters are a hugely undervalued part of protecting the project against abuse and it really is long past time we put some effort into improving them. JzG (talk) 00:28, 16 November 2018 (UTC)
  • This has a hidden assumption. If the spam blacklist is veiwed as a pure spamlist, then it is a one-level list. If it is used to block questionable sites, then it is a multilevel list. Whether to give the user a warning is optional to what the list should be. A multilevel list for questionable sites is a pretty large discussion, as it must also discuss what kind of external vetting should be done. — Jeblad 08:42, 18 November 2018 (UTC)
    • @Jeblad: it is not an assumption, the current blacklist is just a one level list, attracting complaints for being so black and white. There is material that needs the possibility of other approaches (see en:User:XLinkBot as an implementation of a softer approach). There are many cases where our hands are tight, or we block all and attract numerous complaints, or play whack-a-mole eating away a lot of volunteer time. —Dirk Beetstra T C (en: U, T) 18:51, 18 November 2018 (UTC)
      • The hidden assumption is that you describe a system that is multilevel, which is quite more complex than the present. — Jeblad 20:43, 18 November 2018 (UTC)
        • @Jeblad: Not an assumption, and nothidden, we need a system that ismore complex. —Dirk Beetstra T C (en: U, T) 01:47, 19 November 2018 (UTC)

Voting

Allow partial reverts for edits

Support Edit proposal/discussion

  • Problem: There are edits of which a part should be reverted but the rest should/can be kept. In such cases you don't always want to time-consumingly edit/improve the source of the page. Instead the changes are either completely kept or completely reverted.
    Deutsch: Es gibt Bearbeitunen, bei denen ein Teil rückgänig gemacht werden sollte, der Rest aber behalten werden kann. In solchen Fällen möchte man nicht immer den Quelltext der Seite aufwändig verbessern. Stattdessen werden dann die Bearbeitungen komplett behaltden oder komplett rückgängig gemacht.
  • Who would benefit: Everybody who only wants to revert parts of an edit
    Deutsch: Jeder, der nur Teile einer Bearbeitung rückgänig machen will
  • Proposed solution: Add a link "Partially revert" next to the normal "revert", which would open a page which looks like the "new" version of Two Column Edit Conflict View. It'll show a "conflict" between the version which will be partially reverted and the previous version. The conflict resolution can then be saved normally.
    Deutsch: Einen Link (Teilweise rückgängig machen) neben den normalen (Rückgängig) - Link setzen, mit dem eine Seite, die wie die "neue" Version des "Two Column Edit Conflict View" aussieht, aufgerufen wird. Es wird ein "Konflikt" zwichen der Version, die teilweise rückgängig wird und vorherigen Version angezeigt. Die Lösung des Konflikts kann dann normal gespeichert werden.
  • Other comments:
  • Phabricator tickets:
  • Proposer: FF-11 (talk) 17:24, 5 November 2018 (UTC) (Old username: Honischboy)

Discussion

  • This would be cool, but I'm not sure how feasible it is. --Izno (talk) 19:01, 6 November 2018 (UTC)
  • I love the idea too. Needs some brainstorming to come up with a good idea to make this work well. Thanks for submitting the proposal FF-11. I will rename the proposal to English and move it to the right category. -- NKohli (WMF) (talk) 21:19, 6 November 2018 (UTC)
  • Related phabricator task at T108664. --Izno (talk) 20:54, 7 November 2018 (UTC)=
  • I could use this. It would probably improved new editor retention, especially if you could use it through some of the editing tools. HLHJ (talk) 07:11, 14 November 2018 (UTC)

Voting

Create an integrated anti-spam/vandalism tool

Support Edit proposal/discussion

  • Problem: Our current infrastructure for countering vandalism and spam at the cross-wiki level is stuck in 2004. We have a spamblacklist with poor logging done on a per-wiki basis, a global abusefilter which isn't global, and a title blacklist that doesn't log at all.
  • Who would benefit: Stewards
  • Proposed solution: Create an integrated anti-spam/vandalism tool (like Phalanx used on Wikia) that combines the functions of the spam and title blacklists, as well as limited abusefilter functionality, to better respond to ongoing spam and vandalism at the global/cross-wiki level.
  • Phabricator tickets:

Discussion

Hi Ajraddatz. I wonder if some of the needs of this proposal have been met by the recent improvements made to Recent Changes and Watchlist feeds? -- NKohli (WMF) (talk) 18:37, 30 October 2018 (UTC)

Unfortunately not - what I'm thinking of is cross-wiki in scope and blocks edits before they happen, rather than reacting to edits that have gone through. – Ajraddatz (talk) 18:40, 30 October 2018 (UTC)
  • This seems relatively minor, because the individual projects already have these tools. DGG (talk) 01:09, 4 November 2018 (UTC)
    First of all, it is absolutely worth investing in infrastructure that could work on 700 projects instead of repeating the same action 700 times. But we also have the spam and title blacklist globally. The issue is that they are both old extensions that aren't very functional - see this other proposal for more information. – Ajraddatz (talk) 03:31, 4 November 2018 (UTC)
Hi! We discussed this proposal in our team meeting today. We are not sure how much we will be able to do but we'll try to do our best. It will probably not be a big cross-wiki thing though. Doing cross-wiki projects is difficult with MediaWiki's current architecture. We will scope this project and come up with what we can do if it is in the top 10. Thanks. -- NKohli (WMF) (talk) 17:50, 13 November 2018 (UTC)
Thanks! You're in luck, because I doubt this proposal will be in the top 10. Because of the limitations in using the current extension, only a small handful of people even work with it, and this topic isn't glamorous enough to gather attention from beyond the handful of people would would be impacted by a change. That said, it's still something that is important to have eventually, so I hope this puts it on the map. – Ajraddatz (talk) 18:40, 13 November 2018 (UTC)

Voting

Collapse multiple consecutive revisions by same author

Support Edit proposal/discussion

  • Problem: Collapse consecutive edits by the same author in the revision history page
  • Who would benefit: The whole system, all Wiki users, especially moderator and peer reviewers
  • Proposed solution: Currently every update, be it even one single character, generates a new revision of the article. When the same author makes consecutive non-overlapping changes to the same page, the revisions could be collapsed into one single row. This will simplify the display and moderator review interface.
  • More comments: This will simplify moderator and peer review, and shorten the article history considerably.
  • Phabricator tickets:
  • Proposer: Geert Van Pamel (WMBE) (talk) 16:13, 4 November 2018 (UTC)

Discussion

  • I am not aware of such functionality in VisualEditor, but it surely doesn't combine revisions on the backend. Disk space is not something you should ever worry about, but I get how the small, consecutive edits is problematic for patrollers. My bold stance here is this proposal is too technically involved for us, as it would presumably require a major reworking of how revisions are saved in MediaWiki. People smarter than would be able to judge this better, though. I will point out HotCat allows you to add/remove multiple categories at once, by clicking on the "++" link. MusikAnimal (WMF) (talk) 22:58, 4 November 2018 (UTC)
  • I have trouble imagining we'd do this on the backend (It would make the way we model revisions really complicated). But from the front-end perspective, is this basically asking for "enhanced recentchanges" but for history pages? BWolff (WMF) (talk) 02:14, 5 November 2018 (UTC)
    I would take that. --Izno (talk) 01:57, 6 November 2018 (UTC)
  • In Instiki, which is used on nLab, multiple consecutive edits by the same author within a minute do get merged into a single revision. This proposal would make editing in MediaWiki act like editing in Instiki. GeoffreyT2000 (talk) 16:29, 5 November 2018 (UTC)
  • Sometimes this would be undesirable, for example when a new page is created by splitting out material from another page, I understand the new material should be copied across and saved exactly as it was on the previous page, to allow attribution. If the editor then makes changes to tidy up the new page, these would be merged into the previous edit. Perhaps a way forward would be, if someone has made another edit within a set time of their previous one, such as 30 minutes, for a box to pop up asking if they want the 2 edits to be merged. Mmitchell10 (talk) 10:32, 10 November 2018 (UTC)
  • Geertivp Thanks for submitting a proposal. Per what MusikAnimal and BWolff said above, this proposal as it stands is not workable as it asks for a massive change in how MediaWiki handles revisions. Disk space is certainly not something you should be concerned about. On the contrary, doing this change will break a huge number of MediaWiki extensions, gadgets and community-built tools. However, if you are asking for better history pages (collapse multiple consecutive revisions by same author), then we can probably try to see if we can build that. Would you like to rename and redefine the proposal to that effect? -- NKohli (WMF) (talk) 04:57, 14 November 2018 (UTC)
    Yes, please, rename to "Collapse multiple consecutive revisions by same author". Geert Van Pamel (WMBE) (talk) 10:25, 14 November 2018 (UTC)
@Geertivp: Thank you. I've renamed the proposal and revised the proposal a bit. I hope that's okay. Please do ping me if you don't agree with any of the changes. Thanks for participating in the survey. -- NKohli (WMF) (talk) 17:33, 14 November 2018 (UTC)
  • There are times when an editor makes a series of very different edits, and one might want to undo one but not the rest (as in the above request for "partial revert"). Combining all the edits would make it more cumbersome. PamD (talk) 23:52, 16 November 2018 (UTC)
  • This kind of automation is not good. There are two cases: editors, who deliberately split their changes into logically different sets, and editors, who make those smaller edits for other reasons. I'd compared this with how git works. It's possible to rebase a branch, and pick or squash commits. Maybe, something similar can apply here: After making a series of smaller commits, the author can decide to make them into one "commit" or fewer number of "commits". РоманСузи (talk) 17:39, 17 November 2018 (UTC)
  • Also squash reverted edits. Note that it should be possible to inspect squashed edits. — Jeblad 08:45, 18 November 2018 (UTC)

Voting

Smarter undo function

Support Edit proposal/discussion

  • Problem: When trying to revert vandalism or undo past edits which are problematic, there are still edits that cannot be "undone" which should be able to be undone. The software frequently refuses to use the undo function on edits that it should be able to recognize and undo.
  • Who would benefit: People reverting vandalism or undoing old, previously missed vandalism.
  • Proposed solution: I'm not very technical, but it seems to me that there should be a way to create a smarter function that recognizes better when a block of text added by an edit has no interlaced text from later edits that would conflict with removing it, without otherwise messing with the rest of the article. Currently, the "undo" function will bug out often even when the only changes to the article are to unrelated parts of the article.
  • More comments:
  • Phabricator tickets:

Discussion

  • You might want to provide examples of cases you think the software should be able to handle as an undo. As it is, this seems too vague for anyone to actually do anything about. Note that to properly evaluate cases, we'd need to know both the diff being undone and the page's current revision at the time. Anomie (talk) 19:20, 30 October 2018 (UTC)
    • @Jayron32: Ditto above and below. Please add examples if you can find any (now/soon). Thanks. Quiddity (WMF) (talk) 01:06, 8 November 2018 (UTC)
  • I believe undo is not possible when there is only one single author... Geert Van Pamel (WMBE) (talk) 09:52, 4 November 2018 (UTC)
    I think what you mean is that an edit cannot be undone if it's the first and only edit in the page. This little issue has forced me to blank talk pages created by vandals, which isn't optimal. --Felipe (talk) 10:50, 4 November 2018 (UTC)
    At least in earlier versions of MediaWiki, I could not undo my nth change of the same page as long as I was the only author... As a workaround I needed to edit the previous version, and save it again to simulate the undo. This seems to be a bug that has been solved (since longtime?). I have verified that it correctly works now on https://test.wikipedia.org/wiki/Xxxx Geert Van Pamel (WMBE) (talk) 17:38, 4 November 2018 (UTC)
  • Here is an example of what (I think) the proposal is about: Clicking the undo link for this edit currently results in the message "The edit could not be undone due to conflicting intermediate edits; if you wish to undo the change, it must be done manually." Presumably because of this subsequent change within the same paragraph. I guess this is a special case of improving the automatic edit conflict resolution. Regards, HaeB (talk) 09:53, 7 November 2018 (UTC)
    It is normal that no automatic rollback is possible in this case; the same section has been subsequently edited. Therefore only manual editing is possible. The system cannot decide about what is actually wanted. —The preceding unsigned comment was added by Geertivp (talk) 09:24, 8 November 2018 (UTC)
I already mentioned and linked that subsequent diff in my comment. The point is that the system could get a little smarter in such cases. Regards, HaeB (talk) 09:22, 9 November 2018 (UTC)

Would Community Wishlist Survey 2019/Bots and gadgets/Machine readable diffs help here? If MediaWiki can generate diffs in a format it can easily understand, then maybe it becomes easier to make a finer grained undo that looks into each paragraph. MER-C (talk) 19:25, 15 November 2018 (UTC)

Voting