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, 392 contributors

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

The survey has closed. Thanks for your participation :)
Here are the Community Wishlist Survey 2019 results!


Allow partial reverts for edits

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)
  • I don't get the point. Using "undo" already allows altering, and so does using "edit". So what exactly would the change be? --Vogone (talk) 00:58, 21 November 2018 (UTC)
    • When you click "Revert" you do get the chance to edit the page before saving, but if you'd like to reinsert some part of the undone edit, you'll need to go back and forth between the editor and the diff view. The idea I guess is to use the edit conflict view so that the changed text is available in the editor and it's marked up so that it's easily seen. Uanfala (talk) 20:07, 24 November 2018 (UTC)
      • Thanks. With your explanation, it now makes much more sense to me. However, I would then think that all "undo"s should come with this feature, rather than adding an additional "partial undo" link as proposed. --Vogone (talk) 21:56, 24 November 2018 (UTC)
        • AutoWikiBrowser has a feature which is interesting for this: it allows one to click on part of a diff to discard those changes. I've attempted to create a similar feature using JavaScript: UndoFromDiff.js (it is not perfect, but works for most cases, even the diffs which appear when undoing edits). Helder 12:03, 25 November 2018 (UTC)
  • I don't understand. Isn't rollback supposed to revert vandalism/spam? many wikis don't like their rollbackers to use this access to revert valid edits, which seems to be the case given in "problem". Matiia (talk) 00:59, 21 November 2018 (UTC)

Voting

Page Curation and New Pages Feed improvements

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 (There are currently some bugs stopping the rollout of the tools on other wikis, fixing these is part of this proposal as well; This would make the Page Curation tools and New Page Feed able to be enabled on other language wikis).
  • 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 and to make them non-en.wiki-specific, enabling rollout on other language wikis.
  • 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)
Excuse me, I must ask you to say that again. What a nice and vivid statement concerning the status of English Wikipedia. "English Wikipedia is by far the most important project"? "English Wikipedia is the synonym for Wikipedia"? What's the proof? --Super Wang on zhwiki (Share your opinions) 12:04, 20 November 2018 (UTC)
Super Wang on zhwiki I think that Kudpung is referring to en.wikipedia being the hardest hit by spam and promotion pages. Therefore it is more necessary to have a robust system in place to deal with these additions on the English Wikipedia than anywhere else (elsewhere a lower volume can generally be dealt with by a small dedicated team, this is difficult on en.wiki). En.wiki *is* synonymous with the word Wikipedia, and it is the first project that companies and individuals come to when looking to advertise or promote themselves; specific countries have in-country promotional issues to deal with, en.wiki has global promotion to deal with. — Insertcleverphrasehere (or here) 13:38, 20 November 2018 (UTC)
@Insertcleverphrasehere:Thank you for explanation, but sorry, that doesn't make much sense to me. You know, due to Taiwan's int'l status and the large population using Chinese language, zhwiki has also been always a target of vandalism. I acknowledge that enwiki is the first project ever, but if you think enwiki is the only source and bulletin board for companies and celebrities, I must say that thought reflects "English language-priority". --Super Wang on zhwiki (Share your opinions) 00:17, 21 November 2018 (UTC)
Besides, enwiki has a "global" promotion doesn't mean other wikis don't. Chinese is the language used by the most people (1.5 billion, 2015 consensus) on this planet. There aren't less issues than those on enwiki here on zhwiki. It's some kind of bias that someone thinks "English Wikipedia has 'global' issues to deal with". --Super Wang on zhwiki (Share your opinions) 00:24, 21 November 2018 (UTC)
@Super Wang on zhwiki: Fair enough, and fair enough. As I've said in comments below, I'm keen to push to fix remaining issues that are keeping the Page curation tools from being non-en.wiki-specific, so that they can be used on other wikis as well; the phab task is phab:T50552. If we do this right, then the work done for these improvements can be ported to other wikis such as zh.wiki. Keen to chat more about this. — Insertcleverphrasehere (or here) 00:49, 21 November 2018 (UTC)
just a note I moved the discussion below to the discussion page. --Cohaf (talk) 00:51, 21 November 2018 (UTC)
You could listen a bit more carefully to your fellow intl Wikipedians. I also wondered why this is the top wish for „a key process on Wikipedia“ but it's about the US/GB Wikipedia only. Sargoth (talk) 10:09, 23 November 2018 (UTC)
@Sargoth, Once again, we were forced to come here as a last resort by community tech, which refused to maintain or update the tools that they built many years ago unless we came here and got in the top 10. Not sure how much more carefully you want me to listen; I've added the ticket to make the tools non-en.wiki-specific to the list above, and I'm going to push for this if I can so that these tools can be made available elsewhere on other language wikis as well. — Insertcleverphrasehere (or here) 13:29, 23 November 2018 (UTC)
„as a last resort“, this sounds disillusioned. I hope you get your supports (I didn't vote here and will propably not but am quite disapointed about the oppose-votes at the gender options proposal. Best of luck :) Sargoth (talk) 14:07, 23 November 2018 (UTC)
Sargoth Somewhat disillusioned, yes. As for the gender options one, note that oppose votes don't count. Still, the premise of a voting free-for-all and top ten as a good system for identifying all the stuff that needs developing is a bit ridiculous. It tends to lead to no development for proposals that are fairly trivial to fix, but only impact a relatively small segment of the user base. A good man once said that "Democracy is two wolves and a lamb voting on what to have for lunch". We had the same problem here, in that NPP isn't particularly sexy; this proposal is going to take a fair amount of effort, and while essential, it doesn't directly help all wikipedians (you can see some people complaining about it below). Note that you can canvass to your heart's content per the wishlist rules (which is really dumb, but it is how we managed to get a decent number of votes here). I'd suggest heading over to various wikiprojects and canvassing for votes if you want that particular proposal to pass in the top 10. — Insertcleverphrasehere (or here) 16:01, 23 November 2018 (UTC)
  • Oppose per Jo-Jo Eumerus, this is a Fascistism to IP users, things that is suitable for English are not necessarily suitable for other languages. --117.14.243.161 03:21, 26 November 2018 (UTC)
    Note that each language wiki would be able to use their own tags and deletion processes by specifiying what is in each section of the toolbar via on-wiki .js pages. As for 'Fascistism' to IP users; there is a simple solution to that problem. — Insertcleverphrasehere (or here) 08:58, 26 November 2018 (UTC)
  • Comment Comment I would really love to see a wiki-agnostic page curation tool. I wish there was a way to vote for that specifically - right now it's just one of a big bag of feature requests, a significant part of which I imagine would have to be dropped to make the scope reasonable. --Tgr (talk) 04:47, 25 November 2018 (UTC)
    Comment Comment @Tgr Most of the other feature requests are things that the other language wikis will want as well. In any case, from the looks of things making the tools non-en.wiki specific only consists of a few key things that need fixing, so not hard to tack on to this proposal; value for effort, it is one of the best tasks on this list. Making the tools Wiki-agnostic (non-en.wiki-specific) was tried as a separate request a few years ago in the community wishlist, but failed to garner enough support (40-somethingth); honestly getting tacked on to this proposal is the best chance it has to be completed. — Insertcleverphrasehere (or here) 09:04, 25 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)
    • Note:Moved to discussion page to declutter here.--Cohaf (talk) 00:32, 21 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)
    Comment Comment: I agree with Jo-Jo. Just because it's "thankless" doesn't mean new page patrolling should be easy. Some of these "improvements" are just to make it easier and more automated, with the end result people don't have to think about what they're doing. Jacknstock (talk) 12:57, 20 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)
  • Support Support Titore (talk) 02:13, 19 November 2018 (UTC)
  • Support Support Shizhao (talk) 02:34, 19 November 2018 (UTC)
  • Support Support Handling new pages efficiently is essential. Johnuniq (talk) 04:42, 19 November 2018 (UTC)
  • Support Support I find it absurd that this process is the only way that these tools may even be fixed. The Foundation claims to want to help new editors, and spends much on outreach and the like, but when it comes to actual action to help new editors get their content into search engines via NPP, it's "just another feature on the wishlist". Without a working NPP process, all work on outreach is essentially wasted. Psiĥedelisto (talk) 05:08, 19 November 2018 (UTC)
  • Support Support Give NPP the tools they need (in proper condition) to succeed. — AfroThundr (u · t · c) 05:52, 19 November 2018 (UTC)
  • Support SupportTeratix 06:28, 19 November 2018 (UTC)
  • Support Support This is something that is long overdue....it helps the English Wikipedia and can be deployed in other wikis when they will gain a bit more of girth....so....Why the hell not ? FR30799386 (talk) 07:06, 19 November 2018 (UTC)
  • Support Support Waddie96 (talk) 07:33, 19 November 2018 (UTC)
  • Support Support We have to work towards making NPR as effective as AfC , and automation is the only way to go ! Devopam (talk) 07:45, 19 November 2018 (UTC)
  • Support Support Chandan Guha (talk) 08:56, 19 November 2018 (UTC)
  • Support Support - This will certainly enhance the work output at NPP. HitroMilanese (talk) 09:01, 19 November 2018 (UTC)
  • Support Support Remagoxer (talk) 10:30, 19 November 2018 (UTC)
  • Support SupportTheLongTone (talk) 11:33, 19 November 2018 (UTC)
  • Support Support Courcelles 14:54, 19 November 2018 (UTC)
  • Support Support Strikerforce (talk) 15:03, 19 November 2018 (UTC)
  • Support Support Randomeditor1000 (talk) 15:04, 19 November 2018 (UTC)
  • Support Support ONUnicorn (talk) 16:02, 19 November 2018 (UTC)
  • Support Support Much needed JackTracker (talk) 18:41, 19 November 2018 (UTC)
  • Support Support Chris Troutman (talk) 18:54, 19 November 2018 (UTC)
  • Support Support - unclear how much weight the argument "it won't help most users" can be given. If anything, this only means that more people will find NPP accessible and decide to undertake a role in it. El cid, el campeador (talk) 20:04, 19 November 2018 (UTC)
  • Support Support Weegaweek (talk) 20:55, 19 November 2018 (UTC)
  • Support Support JHCaufield (talk) 00:04, 20 November 2018 (UTC)
  • Support Support 331dot (talk) 01:08, 20 November 2018 (UTC)
  • Support Support Agree curation tools are important... Doc James (talk · contribs · email) 03:40, 20 November 2018 (UTC)
  • Support Support Cwmhiraeth (talk) 10:06, 20 November 2018 (UTC)
  • Support Support Famousdog (talk) 11:01, 20 November 2018 (UTC)
  • Oppose Oppose as this seems to be a single-wiki-purpose thing. → «« Man77 »» [de] 12:55, 20 November 2018 (UTC)
    Comment Comment Man77, the Page Curation tools were made to be used on any wiki when first developed (at least they were supposed to). There is a Phab task that requests making the tools non-en.wiki-specific (phab:T50552), which doesn't look like too much trouble. In fact, the New Page feed stuff that was recently woorked on was done with a future spread to other wikis in mind, so this is already partly done. I haven't added that task above because so far no other wikis have come forward asking for these tools as of yet and I'm not aware of how the processes on other wikis would work with the toolset as it currently stands and how this would exist with current processes on other wikis. If new page patrol analogues on other wikis are interested in activating the New Page feed and/or Page Curation tools on their wiki, it's something we could push for as it is in line with Community Tech's goal of doing work to help all Wikis. — Insertcleverphrasehere (or here) 13:47, 20 November 2018 (UTC)
    Man77 Note, see talk page comments and comments on the Phab task indicating that both zh.wiki (chinese) and the persian wiki have both espressed serious interest in these tools. Making these tools non-en.wiki-specific is something I'll be pushing for when the tech team starts work on this task. If anyone from other wikis wants to come forward and join the discussion about this, it would be helpful as I must profess my ignorance of New Page Review processes and teams on other wikis. — Insertcleverphrasehere (or here) 00:58, 21 November 2018 (UTC)
  • Support Support Willsome429 (talk) 15:48, 20 November 2018 (UTC)
  • Support Support And.martire (talk) 16:35, 20 November 2018 (UTC)
  • Support Support Mcampany (talk) 22:10, 20 November 2018 (UTC)
  • Support Support CAPTAIN RAJU(T) 22:24, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 23:03, 20 November 2018 (UTC)
  • Support Support Arian Talk 18:28, 21 November 2018 (UTC)
  • Support Support I've found NPP too frustrating with the current setup, and these changes look like they might fix that. EEng (talk) 19:12, 21 November 2018 (UTC)
  • Support Support Vulphere 01:17, 22 November 2018 (UTC)
  • Support Support ~Cybularny Speak? 15:46, 23 November 2018 (UTC)
  • Support Support JøhP (talk) 16:24, 23 November 2018 (UTC)
  • Support Support FlyingAce (talk) 01:07, 24 November 2018 (UTC)
  • Support Support Pf1127 (talk) 06:24, 24 November 2018 (UTC)
  • Support Support Hydronium Hydroxide (talk) 09:10, 24 November 2018 (UTC)
  • Support Support sounnds nooice JonathanLa (talk) 02:15, 25 November 2018 (UTC)
  • Support Support DannyS712 (talk) 08:11, 25 November 2018 (UTC)
  • Support Support these fixes are really badly needed. New Page Patrol is currently a failing process with the backlog of unpatrolled pages growing faster than we can handle. The tool fixes and enhancements will help us actually patrol rather than fighting with the tools and process. Please prioritize this. Legacypac (talk) 19:10, 25 November 2018 (UTC)
  • Support Support Ranjithsiji (talk) 22:36, 25 November 2018 (UTC)
  • Support Support Slashme (talk) 08:08, 26 November 2018 (UTC)
  • Support Support Dreamy Jazz (talk) 08:48, 26 November 2018 (UTC)
  • Support Support Whispering (talk) 14:27, 26 November 2018 (UTC)
  • Support Support -- Amanda (aka DQ) 22:42, 26 November 2018 (UTC)
  • Support Support Graeme Bartlett (talk) 23:23, 27 November 2018 (UTC)
  • Support Support These improvements are well overdue Noyster (talk) 13:04, 28 November 2018 (UTC)
  • Support Support By looking at the tickets, one gets the impression that they will benefit and a lot. In future it'd be best to have these votes for less tools so that we can decide one at a time, as opposed to such big block of changes. --1l2l3k (talk) 16:04, 29 November 2018 (UTC)

Collapse multiple consecutive revisions by same author

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

  • Support Support There is an option at Special:Preferences#mw-prefsection-rc to "Group changes by page in recent changes and watchlist". There is also a gadget at Persian Wikipedia to hide all bot edits from history page. Both of them are very useful. 4nn1l2 (talk) 02:44, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 03:33, 17 November 2018 (UTC)
  • Support Support FF-11 (talk) 09:51, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 10:14, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:07, 17 November 2018 (UTC)
  • Support Support JogiAsad (talk) 18:37, 17 November 2018 (UTC)
  • Support Support Mmitchell10 (talk) 20:39, 17 November 2018 (UTC)
  • Support Support Such a visual-collapse option is useful for ALL users who do article upkeep. (Also for Recent/Related changes) Wikicat (talk) 03:32, 18 November 2018 (UTC)
  • Support Support Abductive (talk) 09:52, 18 November 2018 (UTC)
  • Support Support Hydriz (talk) 14:26, 18 November 2018 (UTC)
  • Support Support Wikidata could benefit from this as more often than not one edit / editing session is actually split into multiple revisions ·addshore· talk to me! 09:57, 19 November 2018 (UTC)
  • Support Support Continue to store separate revisions in database, but make an option for collapse them when a user view history page. β16 - (talk) 09:58, 19 November 2018 (UTC)
  • Support Support BugWarp (talk) 23:59, 19 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 23:00, 20 November 2018 (UTC)
  • Support Support Vulphere 17:25, 22 November 2018 (UTC)
  • Support Support Sebari – aka Srittau (talk) 19:43, 22 November 2018 (UTC)
  • Support Support DannyS712 (talk) 19:49, 22 November 2018 (UTC)
  • Support Support FiliP ██ 20:06, 22 November 2018 (UTC)
  • Support Support Poslovitch (talk) 20:18, 22 November 2018 (UTC)
  • Support Support B20180 (talk) 17:43, 24 November 2018 (UTC)
  • Support Support Alexei Kopylov (talk) 17:57, 24 November 2018 (UTC)
  • Support Support Juntas (talk) 22:09, 24 November 2018 (UTC)
  • Support Support By erdo can • TLK 09:01, 25 November 2018 (UTC)
  • Support Support Per B16 Daniel Case (talk) 04:01, 26 November 2018 (UTC)
  • Support Support Dreamy Jazz (talk) 08:44, 26 November 2018 (UTC)
  • Support Support Optional gadget, possibly an expandable/collapsable sublist in the history display. But strongly oppose making it part of the back-end or making the separate edits invisible. There are good reasons editors may want bite-sized several edits and likewise good reasons that another editor may want to see what (the author feels are) separate chunks of work. DMacks (talk) 18:53, 26 November 2018 (UTC)
  • Support Support Per DMacks as a gadget - FlightTime (open channel) 22:13, 26 November 2018 (UTC)
  • Support Support YFdyh000 (talk) 15:10, 27 November 2018 (UTC)
  • Support Support Quedel (talk) 23:12, 27 November 2018 (UTC)
  • Support Support Iich1960 (talk) 10:36, 28 November 2018 (UTC)
  • Support Support Dumbassman (talk) 17:48, 29 November 2018 (UTC)
  • Support Support Ldorfman (talk) 20:41, 29 November 2018 (UTC)
  • Support Support Platonides (talk) 23:37, 29 November 2018 (UTC)
  • Support Support Stussll (talk) 06:48, 30 November 2018 (UTC)

Prevent DDoS-style attacks

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)

  • I thought MediaWiki had a ratelimit on editing, and maybe that should be even more tightened. — regards, Revi 16:34, 20 November 2018 (UTC)

Voting

  • Support Support Galobtter (talk) 18:47, 16 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 03:35, 17 November 2018 (UTC)
  • Support Support Hiàn (talk) 04:46, 17 November 2018 (UTC)
  • Support Support Kpgjhpjm (talk) 07:32, 17 November 2018 (UTC)
  • Support Support Dcheney (talk) 16:24, 17 November 2018 (UTC)
  • Support Support So like the Vandalbin on RationalWiki? https://rationalwiki.org/wiki/RationalWiki:Blocking_policy#Vandalbinning pythoncoder (talk | contribs) 17:00, 17 November 2018 (UTC)
  • Support Support I've noticed that too, but it was not a troll but a spammer. JackPotte (talk) 23:34, 17 November 2018 (UTC)
  • Support Support Ciao • Bestoernesto 06:48, 18 November 2018 (UTC)
  • Support Support ~ Amory (utc) 11:36, 18 November 2018 (UTC)
  • Support Support FR30799386 (talk) 07:06, 19 November 2018 (UTC)
  • Support Support Waddie96 (talk) 07:28, 19 November 2018 (UTC)
  • Support Support Veikk0.ma (talk) 12:09, 19 November 2018 (UTC)
  • Support Support Courcelles 14:51, 19 November 2018 (UTC)
  • Support Support Kb03 (talk) 15:38, 19 November 2018 (UTC)
  • Support Support ONUnicorn (talk) 15:58, 19 November 2018 (UTC)
  • Support Support Ahecht (TALK
    PAGE
    ) 16:21, 19 November 2018 (UTC)
  • Support Support Ronhjones (talk) 00:17, 20 November 2018 (UTC)
  • Support Support Needed for site security among other things IMO. Good functionality to have. Doc James (talk · contribs · email) 03:45, 20 November 2018 (UTC)
  • Support Support Johnuniq (talk) 06:09, 20 November 2018 (UTC)
  • Support Support Jamesmcmahon0 (talk) 10:18, 20 November 2018 (UTC)
  • Support Support Semiprotecting the entire encyclopedia would be wonderful, but until that happens I guess we're stuck with this. It would at least start to even up the appalling power imbalance between IPs and those of us who are stupid enough to be registered users. Gareth (talk) 10:35, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 23:01, 20 November 2018 (UTC)
  • Support Support Vulphere 05:59, 21 November 2018 (UTC)
  • Support Support; this looks like an important problem, and I can't imagine anyone would be against fixing it. HLHJ (talk) 03:44, 22 November 2018 (UTC)
  • Support Support ~Cybularny Speak? 15:45, 23 November 2018 (UTC)
  • Support Support FlyingAce (talk) 01:42, 24 November 2018 (UTC)
  • Support SupportTeratix 05:06, 25 November 2018 (UTC)
  • Support Support Daniel Case (talk) 03:11, 26 November 2018 (UTC)
  • Support Support Dreamy Jazz (talk) 08:45, 26 November 2018 (UTC)
  • Support Support This is a serious public-facing problem and the proposed solution sounds fairly easy to implement. DMacks (talk) 19:01, 26 November 2018 (UTC)
  • Support Support Alvarosinde (talk) 16:34, 29 November 2018 (UTC)
  • Support Support Schniggendiller (talk) 10:31, 30 November 2018 (UTC)

Create an integrated anti-spam/vandalism tool

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)

I agree anti-abuse tools could use more love. This proposal, on the other hand, could use more details. Are you specifically worried about logging? The difficulties local communities have in interacting with global tools? Are there specific features of Phalanx that you miss? What's wrong with global abuse filters? --Tgr (talk) 04:15, 25 November 2018 (UTC)

Fair point. I'll give a walk-through of the current state and point out the big problems that could be fixed. I'll also preface this by saying that integrating the elements into one tool is more for convenience; the problems are with each specific tool, and could be improved separately instead.
Spam blacklist: I notice a link being spammed by a couple of bots, so I want to add it to the spam blacklist. My workflow involves opening the page, waiting a few seconds for it to load, painfully scrolling down the list and trying to find a good place to add the regex. The page is so large that it lags going through it. Once I find the right place, I need to figure out what the correct regex is - I can speak regex-1, so simple additions are no problem, but I need to ask someone else to add anything more complex. After adding the text and waiting another 10-20 seconds for the page to save, I then need to manually add an entry on the spam blacklist log, since there is no automatic logging of additions. This takes another 10-20 seconds to get the diff number and justify the addition. Once I've made the addition, I have no ability to follow-up and see what it is blocking because the logging is done on a per-wiki basis and I don't have the time to check all 700 wikis. Total time: 1-2 minutes, when the rest of my anti-abuse workflow takes 10-20 seconds total. Big areas to improve: 1. change it from a big page to an extension that allows each entry to be handled individually. Imagine account blocking if you had to add the name of the account to a big page with thousands of other names. 2. automatic logging. 3. some system where you can see the impact of the action you just took - subsequent attempted uses of the blocked link.
Title blacklist: I notice an account name has been abused across multiple wikis, so I want to block the name. My workflow is a bit easier because the title blacklist is smaller than the spam blacklist, so it only lags a little bit. I add the appropriate regex to the appropriate section and create a log entry. Total time: 1 minute, still much slower than the rest of my workflow. There is no per-wiki or cross-wiki logging to see what impact my entry has had. Areas to improve: same as spam blacklist, individual entry handling, automatic logging, a way of auditing the actions blocked by the addition.
Global AbuseFilter: some cross-wiki vandal is doing a specific type of vandalism across multiple wikis. I create a filter to prevent such actions (this is already pretty complex, and could use some serious simplification for the less technically-minded among us), but it only applies to the small wikis that the global abusefilter is enabled on. The vandal continues to hit large wikis, forcing me to either contact local admins to get them to duplicate the global filter locally or (and this is what I usually end up doing) ignore the problem because I don't have half an hour to follow up on this. I also don't necessarily need a whole abusefilter: a simple condition that could be done through Phalanx or SpamRegex (old extension) would have sufficed. Areas to improve: make the global abusefilter global, add a lower tier of abuse prevention through the integrated tool.
And of course this is just a start of the laundry list of unaddressed problems with global anti-abuse tools. Global accounts cannot be blocked, requiring me to checkuser almost every account I lock so I can block the underlying IP as well. Abuse from developing countries tends to be on mobile ranges or from other public IP ranges, so there are often situations where I cannot place any IP blocks due to the potential collateral damage - the problem here being no other options to block people other than using IPs and account names. Many stewards also just block anyway, leading to the literal hundreds of unaddressed requests for unblock in our email queue from people caught in massive global rangeblocks. But this area seems like one where existing extensions (spamregex, phalanx) could be used as a starting point to make some easy fixes. – Ajraddatz (talk) 23:24, 25 November 2018 (UTC)
  • Comment. This proposal is probably to ambitions for the Community Whitelist. I doubt that this small team of developers can create such a tool within a year. Ruslik (talk) 18:04, 30 November 2018 (UTC)

Voting

Make undeletion page ID sensitive

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

Overhaul spam-blacklist

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 viewed 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)
          • What you ask for is a multilevel trustmodel tracking several concurrent sources (userstatus, material linked to, etc), it will be a major project. — Jeblad 02:14, 19 November 2018 (UTC)
            • @Jeblad: Isn’t that what we do with page protection, AbuseFilter etc. Yes, it will be a major project, but one that is due for years and equally utter neglected by WMF for years. Things are broken, outdated, people complain. —Dirk Beetstra T C (en: U, T) 02:59, 19 November 2018 (UTC)
  • @Man77: I am not sure if I understand what you mean. ‘Complex regexes’ are for filtering the added external links. That wikicode is too complex is a different story, independent of the mechanisms that make Wikipedia work. Is that what you mean? —Dirk Beetstra T C (en: U, T) 03:45, 21 November 2018 (UTC)
  • @Ryan Kaldari (WMF) and Beetstra: a simple hack would be to add an AbuseFilter function that takes a page name, loads the page, parses it into a regexp, and returns it (or matches it against the second argument). It would require some caching but even so it's fairly simple, does not require any structural changes to AF code, and would allow spam blacklists to be converted into filters, with all the UI and logic improvements that entails. --Tgr (talk) 05:01, 25 November 2018 (UTC)
    • @Tgr: True, that works, and that is what we sometimes do. But with thousands of blacklist rules that entails an enormous number of filters (including global ones). The AbuseFilter is in itself a slow system, where the interpretation (especially with complex regexes) will be the problem, which will only slow down if we use logic to select the rules (which, IMHO, could even be moved out of the AbuseFilter itself, into 'options' to significantly improve the speed - though then the options become so many that it defies the system). --Dirk Beetstra T C (en: U, T) 05:22, 25 November 2018 (UTC)
      • @Beetstra: Wouldy you really need many filters though? You could have one for non-admin, one for non-autoconfirmed, a few for specific namespaces maybe... there are only so many useful combinations of conditions. And since the regexes would be on a separate page and not in the AF rule, and parsed the same way they are now, AF parsing speed would not be an issue (as long as this does not significantly inflate the number of filters). --Tgr (talk) 05:45, 25 November 2018 (UTC)
        • @Tgr: It would be a significant number of filters (user-level (new editor/IP; non-admin only ..), namespace, page specific (stop adding youtube and twitter feeds to <subject>), full block/warning only; with probably some cross-combinations), with huge blocks of regexes (and the regexes need to be split, as there is a maximum size to one regex, you'd need the same blackist regex-parser for it).
    One of the other strengths of this adapted system (as suggested above, not grouped as you suggest), IMHO, is that we could tell for some why it is blocked and what to do (shorteners -> use the expanded rule; majorly copyright violating sites: link to the original; petition sites -> find either secondary sources and use those), and that we could more easy do per-page exceptions (you cannot link to this site anywhere, except on the subject-page). Moreover, logging hits is easier (if you group, you still have to dig through all hits to see how often spammers attempted to add <badcomain>.com). --Dirk Beetstra T C (en: U, T) 10:03, 25 November 2018 (UTC)
    @Beetstra: To be clear, I'm talking about a syntax like this: !(user_groups contains autoconfirmed) && blacklist_match( 'MediaWiki:Blacklist-autoconfirmed', added_links ). There is no huge blocks of regexes here, the regex is parsed from a separate page with a blacklist-like format.
    As you say this has some shortcomings (each type of blacklist needs to be on a separate page, which is maybe not always the most convenient choice; it's hard to tell exactly which blacklist item was triggered), on the other hand, it is actually possible to do with limited resources, so the question really is, is it preferable over nothing? (Or more optimistically, over waiting two years for an AbuseFilter rewrite.) --Tgr (talk) 20:56, 25 November 2018 (UTC)
    I guess this would be better than nothing, but I still think that this is going to be resulting in a massive number of rules (and lacks the possibility to pagespecific whitelist rules (‘everywhere, except <subject> for <subject.com>’).
Waiting 2 years for a rewrite .. we’re waiting for 10 years already. The protecting part of Wikipedia is utterly neglected, and will be neglected for years to come ... —Dirk Beetstra T C (en: U, T) 22:52, 25 November 2018 (UTC)

Voting

  • Support Support Essential upgrades required to keep this system relevant. – Ajraddatz (talk) 18:19, 16 November 2018 (UTC)
  • Support Support Galobtter (talk) 18:46, 16 November 2018 (UTC)
  • Support Support MER-C (talk) 18:58, 16 November 2018 (UTC)
  • Support Support HHill (talk) 21:10, 16 November 2018 (UTC)
  • Support Support Albert Cardozo (talk) 01:24, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 03:33, 17 November 2018 (UTC)
  • Proposer Support Support. This is long, long overdue. —Dirk Beetstra T C (en: U, T) 05:31, 17 November 2018 (UTC)
  • Support Support Xiplus (talk) 07:29, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:07, 17 November 2018 (UTC)
  • Support SupportMarcoAurelio (talk) 11:39, 17 November 2018 (UTC)
  • Support Support Martin Urbanec (talk) 13:47, 17 November 2018 (UTC)
  • Support Support Blue Rasberry (talk) 15:29, 17 November 2018 (UTC)
  • Support Support JogiAsad (talk) 18:38, 17 November 2018 (UTC)
  • Support Support pythoncoder (talk | contribs) 19:14, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 19:48, 17 November 2018 (UTC)
  • Support Support JOAN ~ (Questions?) 20:49, 17 November 2018 (UTC)
  • Support Support Ciao • Bestoernesto 07:02, 18 November 2018 (UTC)
  • Support Support Szalax (talk) 09:07, 18 November 2018 (UTC)
  • Support Support Jules78120 (talk) 09:31, 18 November 2018 (UTC)
  • Support Support — Draceane talkcontrib. 17:29, 18 November 2018 (UTC)
  • Support Support Courcelles 14:56, 19 November 2018 (UTC)
  • Support Support Yes. Spam is a growing issue. Doc James (talk · contribs · email) 03:48, 20 November 2018 (UTC)
  • Support Support I'd, however, like to say that I do not understand why complex regexes should be the solution here, whereas wiki-code has been identified as part of the problem for new editors. → «« Man77 »» [de] 12:51, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 23:03, 20 November 2018 (UTC)
  • Support Support Nihlus 22:13, 21 November 2018 (UTC)
  • Support Support A modernised approach to managing a blacklist for (parts of) domain names is indeed needed. As for technical implementation, though, I would recommend against another extension. Instead, I think it would be preferable for Meta-Wiki admins as well as affected end-users, for this to become part of the AbuseFilter extension itself via a dedicated sub-feature. Possibly improving the UI and performance of AbuseFilter in the process, as needed. Krinkle (talk) 01:00, 22 November 2018 (UTC)
    @Krinkle: This idea was somewhat expressed last year: make the AbuseFilter modular. I guess that some of the parts that are now usually coded could be done way more efficient and faster through checkbox-lists (namespace rlike “(1|2|10|11)” vs the checkbox system in search?, e.g.) (knowing that some abusefilters use within the code sometimes different checks for different namespaces), which would make the regex coding already lighter which could possibly allow for more expensive code like heavy regex checking. —Dirk Beetstra T C (en: U, T) 04:03, 22 November 2018 (UTC)
  • Support Support DannyS712 (talk) 19:59, 22 November 2018 (UTC)
  • Support Support MisterSynergy (talk) 10:20, 23 November 2018 (UTC)
  • Support Support ~Cybularny Speak? 15:41, 23 November 2018 (UTC)
  • Support Support Sannita - not just another it.wiki sysop 00:24, 24 November 2018 (UTC)
  • Support Support Matěj Suchánek (talk) 08:37, 24 November 2018 (UTC)
  • Support Support Winged Blades of Godric (talk) 09:13, 24 November 2018 (UTC)
  • Support Support B20180 (talk) 17:46, 24 November 2018 (UTC)
  • Support Support By erdo can • TLK 09:01, 25 November 2018 (UTC)
  • Support Support Johnuniq (talk) 10:33, 26 November 2018 (UTC)
  • Support Support Whispering (talk) 21:15, 26 November 2018 (UTC)
  • Support Support As a regular at the blacklists (and former Meta admin doing the same), this is long overdue. JzG (talk) 00:02, 27 November 2018 (UTC)
  • Support Support SQLQuery me! 00:14, 27 November 2018 (UTC)
  • Support Support Izno (talk) 01:15, 27 November 2018 (UTC)
  • Support Support WhatamIdoing (talk) 00:25, 28 November 2018 (UTC)
  • Support Support Ahm masum (talk) 21:15, 28 November 2018 (UTC)
  • Support Support Achim (talk) 21:46, 28 November 2018 (UTC)
  • Support Support Daniel Case (talk) 06:38, 29 November 2018 (UTC)
  • Support Support I guess it wouldn't hurt. PF4Eva (talk) 08:57, 29 November 2018 (UTC)
  • Support Support Alvarosinde (talk) 16:32, 29 November 2018 (UTC)
  • Support Support Schniggendiller (talk) 10:59, 30 November 2018 (UTC)
  • Support Support Wumbolo (talk) 15:46, 30 November 2018 (UTC)

Allow De-Privileged logons to webui

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)
  • Nice idea, but I wonder if the admins will use it. I sort of doubt it. — Jeblad 08:54, 18 November 2018 (UTC)
  • Some things to keep in mind: if/once this is implemented, would there be a window for users with multiple accounts to merge their contributions? And if/once those mergers are complete, should we amend the relevant policy as to disallow users having separate accounts (as opposed to using this feature)? Rehman 02:18, 20 November 2018 (UTC)
  • Actually like this idea a lot. The best way to implement it is to have the user always login without privileges. When he/she need admin permission, he would click on a button, may be get prompted for password and then his/her privileges are elevated. 15 minutes later, they fall back to normal privileges. See how Atlassian have implemented it for example in Jira —The preceding unsigned comment was added by Wk muriithi (talk) 13:48, 24 November 2018 (UTC)
  • Security measures that you allow will always have a tiny fraction of the impact of security measures that you require. It will be used by the most security-conscious users, who have strong unique passwords and good account security and thus aren't an easy target anyway. Unless you are ready to make this required, and to acutally enforce it by software (and I don't see how that would work), it's just not a good use of time. Something along the lines of what Wk muriithi said (make all logins de-privileged, and require a temporary elevation) makes more sense, and actually we are sort of doing it already for some very limited things (like password change), but figuring out how to do it without crippling the productivity of privileged users is not easy. --Tgr (talk) 04:00, 25 November 2018 (UTC)

Voting

  • Support Support as proposer. — xaosflux Talk 20:19, 16 November 2018 (UTC)
  • Support Support Dolotta (talk) 01:05, 17 November 2018 (UTC)
  • Support Support Hell yeah — regards, Revi 02:05, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 03:33, 17 November 2018 (UTC)
  • Support Support Kpgjhpjm (talk) 04:08, 17 November 2018 (UTC)
  • Support Support Hiàn (talk) 04:46, 17 November 2018 (UTC)
  • Support Support FF-11 (talk) 09:46, 17 November 2018 (UTC)
  • Support Support Jo-Jo Eumerus (talk, contributions) 10:00, 17 November 2018 (UTC)
  • Support Support Patriccck (talk) 10:35, 17 November 2018 (UTC)
  • Support Support --Alaa :)..! 10:36, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 19:53, 17 November 2018 (UTC)
  • Support Support Sebastian Wallroth (talk) 10:33, 18 November 2018 (UTC)
  • Support Support Would go nicely with the marginally-related phab:T199118. ~ Amory (utc) 11:27, 18 November 2018 (UTC)
  • Support Support stwalkerster (talk) 17:01, 18 November 2018 (UTC)
  • Support Support — Draceane talkcontrib. 17:29, 18 November 2018 (UTC)
  • Support Support And we should be able to test the Visual Editor even when we had chosen the wikicode (on some wikis the second modification tab is absent so we have to choose one the first time). JackPotte (talk) 19:42, 18 November 2018 (UTC)
  • Support Support --Wargo (talk) 20:57, 18 November 2018 (UTC)
  • Support Support Don't know if I'd use it personally, but it seems like a good idea. Kudpung (talk) 08:59, 19 November 2018 (UTC)
  • Support Support I have often had problems in other platforms that were difficult to resolve because the person trying to help me was too privileged to see the problem, or I was the one who was too privileged to see the problem. This is a sound concept for all computing environments. Jc3s5h (talk) 11:00, 19 November 2018 (UTC)
  • Support Support Martin Urbanec (talk) 14:01, 19 November 2018 (UTC)
  • Support Support Katietalk 16:36, 19 November 2018 (UTC)
  • Support Support. It would take away the headache of having to maintain multiple accounts for different uses (editing from home, editing from office, editing from unsafe network), and would also reduce the opacity of certain users (i.e. admins) reviewing editors owning multiple accounts. Rehman 02:18, 20 November 2018 (UTC)
  • Support Support Edgars2007 (talk) 18:40, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 22:59, 20 November 2018 (UTC)
  • Support Support Vulphere 06:15, 21 November 2018 (UTC)
  • Support Support Arian Talk 18:27, 21 November 2018 (UTC)
  • Support Support Framawiki (talk) 19:34, 21 November 2018 (UTC)
  • Support Support Nihlus 22:09, 21 November 2018 (UTC)
  • Support Support Good idea! YaganZ (talk) 23:46, 22 November 2018 (UTC)
  • Support Support MisterSynergy (talk) 10:19, 23 November 2018 (UTC)
  • Support Support ~Cybularny Speak? 15:43, 23 November 2018 (UTC)
  • Support Support Nice idea, adopt the sudo strategy so that it get wide usage. William —The preceding unsigned comment was added by Wk muriithi (talk) 13:59, 24 November 2018 (UTC)
  • Support Support Arne (Amjaabc) (talk) 08:40, 25 November 2018 (UTC)
  • Support Support IKhitron (talk) 19:21, 25 November 2018 (UTC)
  • Support Support Ranjithsiji (talk) 22:35, 25 November 2018 (UTC)
  • Support Support This would be great for the more security conscious among us. — AfroThundr (u · t · c) 01:02, 26 November 2018 (UTC)
  • Support Support Daniel Case (talk) 03:58, 26 November 2018 (UTC)
  • Support Support Dreamy Jazz (talk) 12:05, 27 November 2018 (UTC)
  • Support Support Nemo 22:23, 27 November 2018 (UTC)
  • Support Support Ahm masum (talk) 21:17, 28 November 2018 (UTC)
  • Support Support Courcelles 15:44, 29 November 2018 (UTC)
  • Support Support Tacsipacsi (talk) 20:03, 29 November 2018 (UTC)
  • Support Support I do use 2FA, and would absolutely prefer the proposed setup. Xymmax (talk) 04:18, 30 November 2018 (UTC)

Smarter undo function

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)

Agree with MER-C. The async wiki grant proposal I linked to from the machine-readable diffs discussion uses Git, which by almost all accounts does about as good a job as can reasonably be done of merging changes. If MediaWiki could do this natively, we'd all manually merge fewer edits, and all editing would be a bit faster and less frustrating. HLHJ (talk) 04:10, 22 November 2018 (UTC)
Git is actually not any better than MediaWiki, it basically merges two changes if they did not touch the same line, or neighbouring lines. That works pretty well for programming where lines tend to be the fundamental units of meaning, and it works poorly for wikitext. So one approach is making the diff algorithm non-line based - probably do some kind of sentence segmentation and then use sentences as the units of diffing. I think this is what HaeB was implying as well. --Tgr (talk) 04:52, 25 November 2018 (UTC)

Voting

Filter user contributions as patrolled or unpatrolled

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)

Have the filters from Recent Changes or Watchlist on Special:Contributions would help: here is an example, where manually patrolled edits are in blue and autopatrolled edits are in green, non-patrolled edits are white. It is also possible to display Unpatrolled edits only. Trizek (WMF) (talk) 10:11, 19 November 2018 (UTC)


Voting

Feature parity for tools dealing with deleted revisions

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

  • Support SupportAjraddatz (talk) 18:20, 16 November 2018 (UTC)
  • Support Support Galobtter (talk) 18:57, 16 November 2018 (UTC)
  • Support Support MER-C (talk) 18:58, 16 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 03:34, 17 November 2018 (UTC)
  • Support Support Jo-Jo Eumerus (talk, contributions) 10:02, 17 November 2018 (UTC)
  • Support Support Though, I think that a radical reform of the deletion system is in order. Winged Blades of Godric (talk) 13:00, 17 November 2018 (UTC)
  • Support Support JAn Dudík (talk) 19:54, 17 November 2018 (UTC)
  • Support Support Ciao • Bestoernesto 07:05, 18 November 2018 (UTC)
  • Support Support Would be hugely beneficial to sysops ~ Amory (utc) 11:28, 18 November 2018 (UTC)
  • Support Support stwalkerster (talk) 17:05, 18 November 2018 (UTC)
  • Support Support Courcelles 14:52, 19 November 2018 (UTC)
  • Support Support As per last year, this is the single most useful thing that could come from this, but it isn't sexy. TonyBallioni (talk) 05:57, 20 November 2018 (UTC)

Partial "Pending Changes" Reviewing

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)
  • Support Support FR30799386 (talk) 07:07, 19 November 2018 (UTC)
  • Support Support The current process inhibits the use of Pending Changes, this solution would reduce the need for Semi-Protection Waddie96 (talk) 07:35, 19 November 2018 (UTC)
  • Support Support ONUnicorn (talk) 16:03, 19 November 2018 (UTC)
  • Support Support One of the biggest pain points in a process with more than its share of pain points. FeRDNYC (talk) 10:08, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 22:57, 20 November 2018 (UTC)
  • Support Support Laboramus (talk) 07:20, 21 November 2018 (UTC)
  • Support Support ~Cybularny Speak? 15:42, 23 November 2018 (UTC)
  • Support Support Redalert2fan (talk) 12:40, 24 November 2018 (UTC)
  • Support Support DannyS712 (talk) 08:11, 25 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 01:35, 26 November 2018 (UTC)
  • Support Support Daniel Case (talk) 03:14, 26 November 2018 (UTC)
  • Support Support DMacks (talk) 18:47, 26 November 2018 (UTC)
  • Support Support Whispering (talk) 21:18, 26 November 2018 (UTC)
  • Support Support Denver20 (talk) 15:27, 29 November 2018 (UTC)
  • Support Support Ldorfman (talk) 20:40, 29 November 2018 (UTC)

Monitoring of new external links

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)
Actually don't see it related to censorship at all. Would just be like what we have today, but minimizing time wasted on URL that are highly likely to be clean Wk muriithi (talk) 15:00, 24 November 2018 (UTC)

An extension for this is to have a boot that go checking every link once a week. If a link isn't reachable 3 times (3 weeks), just have it listed here so that admins can remove it Wk muriithi (talk) 15:03, 24 November 2018 (UTC)

Voting

  • Support Support Liuxinyu970226 (talk) 03:35, 17 November 2018 (UTC)
  • Support Support Dirk Beetstra T C (en: U, T) 05:35, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 10:16, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:08, 17 November 2018 (UTC)
  • Support SupportMarcoAurelio (talk) 11:39, 17 November 2018 (UTC)
  • Support Support Martin Urbanec (talk) 13:48, 17 November 2018 (UTC)
  • Support Support JogiAsad (talk) 18:35, 17 November 2018 (UTC)
  • Support Support As the proposer Amir (talk) 18:47, 17 November 2018 (UTC)
  • Support Support Barcelona (talk) 18:53, 17 November 2018 (UTC)
  • Support Support Hanooz (talk) 19:40, 17 November 2018 (UTC)
  • Support Support Mardetanha talk 20:08, 17 November 2018 (UTC)
  • Support Support Yamaha5 (talk) 20:34, 17 November 2018 (UTC)
  • Support Support Fatemi 20:43, 17 November 2018 (UTC)
  • Support Support JOAN ~ (Questions?) 20:52, 17 November 2018 (UTC)
  • Support Support Tom (LT) (talk) 23:07, 17 November 2018 (UTC)
  • Support Support Temp3600 (talk) 05:42, 18 November 2018 (UTC)
  • Support Support Poya-P (talk) 06:11, 18 November 2018 (UTC)
  • Support Support Jules78120 (talk) 09:36, 18 November 2018 (UTC)
  • Support Support فرهنگ2016 (talk) 10:39, 18 November 2018 (UTC)
  • Support Support Cool idea Dvorapa (talk) 16:53, 18 November 2018 (UTC)
  • Support Support — Draceane talkcontrib. 17:31, 18 November 2018 (UTC)
  • Support Support Shizhao (talk) 02:33, 19 November 2018 (UTC)
  • Support Support Waddie96 (talk) 07:36, 19 November 2018 (UTC)
  • Support Support ~ Nahid Talk 09:25, 19 November 2018 (UTC)
  • Support Support Sounds sensible ·addshore· talk to me! 09:58, 19 November 2018 (UTC)
  • Support Support BugWarp (talk) 23:56, 19 November 2018 (UTC)
  • Support Support If we can censor those trying to spam us I am all for it. Doc James (talk · contribs · email) 03:37, 20 November 2018 (UTC)
  • Support Support Jamesmcmahon0 (talk) 10:15, 20 November 2018 (UTC)
  • Support Support Lofhi (talk) 17:49, 20 November 2018 (UTC)
  • Support Support Magalia (talk) 21:25, 20 November 2018 (UTC)
  • Support Support CAPTAIN RAJU(T) 22:22, 20 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 23:02, 20 November 2018 (UTC)
  • Support Support Tisfoon (talk) 06:12, 21 November 2018 (UTC)
  • Support Support Framawiki (talk) 19:33, 21 November 2018 (UTC)
  • Support Support Nihlus 22:12, 21 November 2018 (UTC)
  • Support Support I think it is a good idea to build a way to monitor additions and removals of external links, but without preventing user actions. This is for patrolling purposes only (analysing the wiki, not controlling it). For implementation, I think it might be easiest to implement this as a Toolforge tool with a background process that subscribes to EventStreams (or maybe Schema:ExternalLinksChange). It could be tracked in real-time with e.g. graphs summarising events per hour and per day. Helping to find domains for which the number of existing links is rapidly growing or shrinking. It would also help to track it by TLD, TLD+1 (base domain) and complete domain, e.g. "sub.of.example.org", "example.org" and "org". Krinkle (talk) 01:08, 22 November 2018 (UTC)
  • Support Support Winged Blades of Godric (talk) 13:27, 22 November 2018 (UTC)
  • Support Support Encycloon (talk) 18:30, 22 November 2018 (UTC)
  • Support Support Arian Talk 19:33, 22 November 2018 (UTC)
  • Support Support DannyS712 (talk) 19:56, 22 November 2018 (UTC)
  • Support Support SalmanZ (talk) 21:06, 22 November 2018 (UTC)
  • Support Support It is very logic Emgaz (talk) 14:15, 23 November 2018 (UTC)
  • Support Support ~Cybularny Speak? 15:44, 23 November 2018 (UTC)
  • Support Support Ghilt (talk) 13:20, 24 November 2018 (UTC)
  • Support Support A great idea. Ya, its better to list only links for new domains. For trusted domain, its too labour intensive to verify every article, better to audit against a domain and even better, just new domains Wk muriithi (talk) 14:13, 24 November 2018 (UTC)
  • Support Support B20180 (talk) 17:44, 24 November 2018 (UTC)
  • Support Support By erdo can • TLK 09:00, 25 November 2018 (UTC)
  • Support Support — AfroThundr (u · t · c) 01:34, 26 November 2018 (UTC)
  • Support Support Daniel Case (talk) 03:12, 26 November 2018 (UTC)
  • Support Support Dreamy Jazz (talk) 08:47, 26 November 2018 (UTC)
  • Support Support Equoreo (talk) 09:10, 26 November 2018 (UTC)
  • Support Support - FlightTime (open channel) 22:14, 26 November 2018 (UTC)
  • Support Support Izno (talk) 01:01, 27 November 2018 (UTC)
  • Support Support ifny (talk) 03:15, 27 November 2018 (UTC)
  • Support Support YFdyh000 (talk) 15:10, 27 November 2018 (UTC)
  • Oppose Oppose This could easily go wrong and flag a legitimate site by mistake. I once had a Palmer Report news link end up being removed for no particular reason. I would hate for that kind of false positive to become the norm. PF4Eva (talk) 08:52, 29 November 2018 (UTC)
  • Support Support Denver20 (talk) 15:30, 29 November 2018 (UTC)
  • Support Support Ldorfman (talk) 20:43, 29 November 2018 (UTC)
  • Support Support Schniggendiller (talk) 10:58, 30 November 2018 (UTC)

Mark multiple revisions in a diff as patrolled

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

Open diffs in new tab

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)
  • Handling multiple tabs is a pain on mobile, no matter what. (Plus I doubt browsers take kindly to scripts opening dozens of tabs.) If mobile is the focus of the feature, ideally you'd have some kind custom interface that lets you walk through a list of diffs, e.g. by offering them up one after the other with a set of action buttons (like rollback/accept) or with swipe-based navigation. That's a bit too involved for a gadget, though. --Tgr (talk) 02:09, 25 November 2018 (UTC)
@Tgr: Maybe opening the content of all diffs in just one tab? Like a list of diff. Not sure if possible... just an idea. Similar with what we have on the Atom feed.—Teles «Talk to me ˱C L @ S˲» 04:53, 25 November 2018 (UTC)
@Teles: It certainly is possible but again you need to design and implement a dedicated interface which is a nontrivial amount of work. My point is that "open a bunch of links in new tabs" sounds super simple but wouldn't really be helpful (definitely not on mobile) and a more proper solution wouldn't be simple so this isn't really the "quick win" task it sounds to be. --Tgr (talk) 21:56, 25 November 2018 (UTC)

Voting

  • Support Support Liuxinyu970226 (talk) 03:32, 17 November 2018 (UTC)
  • Support Support Please allow users to turn this on/off in the settings FF-11 (talk) 10:02, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:08, 17 November 2018 (UTC)
  • Support SupportThanks for the fish! talkcontribs 19:51, 17 November 2018 (UTC)
  • Support Support Another helpful idea might be to allow combining diffs per user... but that would take another proposal. :) Wikicat (talk) 03:19, 18 November 2018 (UTC)
  • Support Support Abductive (talk) 09:52, 18 November 2018 (UTC)
  • Support Support But it should be opt-in, if not will be so irritant open diffs in desktop and, perhaps, on mobiles too. Mr. Fulano! Talk 21:27, 19 November 2018 (UTC)
  • Support Support Mend My Way 23:43, 19 November 2018 (UTC)
  • Support Support Novak Watchmen (talk) 23:02, 20 November 2018 (UTC)
  • Support Support It is possible to do Nhatminh01 (talk) 11:18, 21 November 2018 (UTC)
  • Support Support Support NankineseYang (talk) 00:41, 26 November 2018 (UTC)
  • Support Support - Quality of life improvement that could be very helpful, especially for recent changes patrollers. Kirbanzo (talk) 18:53, 26 November 2018 (UTC)
  • Support Support Filipović Zoran (talk) 19:24, 26 November 2018 (UTC)
  • Support Support Ooo86 (talk) 20:44, 26 November 2018 (UTC)
  • Support Support Kirk 0Discussion0 17:25, 27 November 2018 (UTC)
  • Support Support This is a vital solution which we need. Denver20 (talk) 15:25, 29 November 2018 (UTC)