Community Wishlist Survey 2019/Admins and patrollers
Allow partial reverts for edits
- 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)
- 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)
- 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)
- 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
- Support Szoltys (talk) 18:33, 16 November 2018 (UTC)
- Support James Martindale (talk) 18:35, 16 November 2018 (UTC)
- Support Tom Ja (talk) 19:41, 16 November 2018 (UTC)
- Support Useful. Super Wang on zhwiki (Share your opinions) 23:42, 16 November 2018 (UTC)
- Support Gehenna1510 (talk) 00:16, 17 November 2018 (UTC)
- Support That would be great ! Braveheidi (talk) 01:12, 17 November 2018 (UTC)
- Support I agree, there are times that revert all the content that was posted by a user only for minor details that can even be pointed out or changed by the same who reversed them. Albert Cardozo (talk) 01:27, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 03:35, 17 November 2018 (UTC)
- Support Hiàn (talk) 04:47, 17 November 2018 (UTC)
- Support --John Cline (talk) 04:48, 17 November 2018 (UTC)
- Support Mahir256 (talk) 06:12, 17 November 2018 (UTC)
- Support Xiplus (talk) 07:30, 17 November 2018 (UTC)
- Support Libcub (talk) 10:13, 17 November 2018 (UTC)
- Support --Alaa :)..! 10:37, 17 November 2018 (UTC)
- Support Will be really helpful in removing old spam/vandalism. ‐‐1997kB (talk) 11:05, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:07, 17 November 2018 (UTC)
- Support 94rain (talk) 13:57, 17 November 2018 (UTC)
- Support Sakretsu (talk) 14:19, 17 November 2018 (UTC)
- Support Townie (talk) 16:44, 17 November 2018 (UTC)
- Support Barcelona (talk) 18:54, 17 November 2018 (UTC)
- Support PamD (talk) 18:57, 17 November 2018 (UTC)
- Support —Thanks for the fish! talk•contribs 19:54, 17 November 2018 (UTC)
- Support JAn Dudík (talk) 19:56, 17 November 2018 (UTC)
- Support JOAN ~ (Questions?) 21:00, 17 November 2018 (UTC)
- Support Vercelas (quæstiones?) 21:22, 17 November 2018 (UTC)
- Support —AlvaroMolina (✉ - ✔) 00:36, 18 November 2018 (UTC)
- Support Tim Landscheidt (talk) 01:43, 18 November 2018 (UTC)
- Support Temp3600 (talk) 05:45, 18 November 2018 (UTC)
- Oppose This is more or less an ordinary edit. — Jeblad 08:47, 18 November 2018 (UTC)
- Support Vriullop (talk) 09:35, 18 November 2018 (UTC)
- Support Sebastian Wallroth (talk) 10:35, 18 November 2018 (UTC)
- Support Seems dope, seems hard ~ Amory (u • t • c) 11:23, 18 November 2018 (UTC)
- Support stwalkerster (talk) 17:07, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:29, 18 November 2018 (UTC)
- Strong support Waddie96 (talk) 07:38, 19 November 2018 (UTC)
- Support Joalbertine (talk) 08:40, 19 November 2018 (UTC)
- Support ~ Nahid Talk 09:28, 19 November 2018 (UTC)
- Support Courcelles 14:57, 19 November 2018 (UTC)
- Support Geraki TL 17:12, 19 November 2018 (UTC)
- Support BugWarp (talk) 23:57, 19 November 2018 (UTC)
- Support Iridescent (talk) 10:21, 20 November 2018 (UTC)
- Support CAPTAIN RAJU(T) 22:23, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:04, 20 November 2018 (UTC)
- Support Rschen7754 01:55, 21 November 2018 (UTC)
- Support Muhammad Abul-Futooh (talk) 11:52, 21 November 2018 (UTC)
- Support Framawiki (talk) 19:37, 21 November 2018 (UTC)
- Support Skyman gozilla (talk) 20:07, 21 November 2018 (UTC)
- Support Nihlus 22:13, 21 November 2018 (UTC)
- Support Nandhinikandhasamy (talk) 02:44, 23 November 2018 (UTC)
- Support ~Cybularny Speak? 15:48, 23 November 2018 (UTC)
- Support James F. (talk) 22:43, 23 November 2018 (UTC)
- Support Pf1127 (talk) 06:22, 24 November 2018 (UTC)
- Support Adithyak1997 (talk) 10:16, 24 November 2018 (UTC)
- Support Uanfala (talk) 20:05, 24 November 2018 (UTC)
- Support Tgr (talk) 04:04, 25 November 2018 (UTC)
- Support Helder 12:03, 25 November 2018 (UTC)
- Support Quebec99 (talk) 19:03, 25 November 2018 (UTC)
- Support There are always some copyedits, or attempts at copyediting, where there's one edit you really should keep amid a bunch you dumped Daniel Case (talk) 04:04, 26 November 2018 (UTC)
- Support Dreamy Jazz (talk) 08:44, 26 November 2018 (UTC)
- Support Ninja✮Strikers «☎» 11:35, 26 November 2018 (UTC)
- Support - while normal editing can achieve this, it can be tedious. Kirbanzo (talk) 18:55, 26 November 2018 (UTC)
- Support Silvio Haehner (talk) 22:56, 26 November 2018 (UTC)
- Support Izno (talk) 00:58, 27 November 2018 (UTC)
- Support Kirk Discussion 17:28, 27 November 2018 (UTC)
- Support Iich1960 (talk) 10:54, 28 November 2018 (UTC)
- Support Denver20 (talk) 15:28, 29 November 2018 (UTC)
- Support Ldorfman (talk) 20:44, 29 November 2018 (UTC)
- Support Tarheel95 (talk) 03:24, 30 November 2018 (UTC)
Page Curation and New Pages Feed improvements
- 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.
- Phabricator tickets:
- Bug Fixes: T169441, T157046, T92621, T157048;
- Flagging page issues and sorting: T207847, T207757, T189929, T169120, T167475, T207238, T207761;
- Other high priority improvements: T207485, T207442, T207452, T207443, T207237, T207439, T208685.
- Making the tools non-en.wiki-specific (being able to disable en.wiki specific stuff so that the tools can be rolled out on other language wikis if they want) T50552 (identified as a priority during voting)
- Proposer: — Insertcleverphrasehere (or here) 07:34, 30 October 2018 (UTC)
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)
- „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, 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)
- 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)
- 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)
- 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)
- 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)
- 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 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 @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 — Insertcleverphrasehere (or here) 18:10, 16 November 2018 (UTC)
- Support - Atsme📞📧 18:17, 16 November 2018 (UTC)
- Support - Wholeheartedly. Onel5969 TT me 18:34, 16 November 2018 (UTC)
- Support James Martindale (talk) 18:34, 16 November 2018 (UTC)
- Support Rosguill (talk) 18:38, 16 November 2018 (UTC)
- Support Alucard 16 (talk) 18:39, 16 November 2018 (UTC)
- Support definitely.--SkyGazer 512 (talk) 18:40, 16 November 2018 (UTC)
- Support Regards, — Moe Epsilon 18:40, 16 November 2018 (UTC)
- 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.Flooded with them hundreds (talk) 18:41, 16 November 2018 (UTC)
- Support Kb03 (talk) 18:41, 16 November 2018 (UTC)
- Support --Kges1901 (talk) 18:42, 16 November 2018 (UTC)
- Support Drm310 (talk) 18:44, 16 November 2018 (UTC)
- Support Galobtter (talk) 18:45, 16 November 2018 (UTC)
- 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 Theroadislong (talk) 18:47, 16 November 2018 (UTC)
- Support Pkbwcgs (talk) 18:48, 16 November 2018 (UTC)
- Support Saederup92 (talk) 18:49, 16 November 2018 (UTC)
- Support Shellwood (talk) 18:52, 16 November 2018 (UTC)
- Support Wumbolo (talk) 18:54, 16 November 2018 (UTC)
- Support Mark the train (talk) 18:55, 16 November 2018 (UTC)
- Support MER-C (talk) 18:57, 16 November 2018 (UTC)
- Support Anaxial (talk) 18:58, 16 November 2018 (UTC)
- Support Pichpich (talk) 19:00, 16 November 2018 (UTC)
- Support Redalert2fan (talk) 19:01, 16 November 2018 (UTC)
- Support — Newslinger talk 19:02, 16 November 2018 (UTC)
- Support MrX (talk) 19:08, 16 November 2018 (UTC)
- Support Staszek Lem (talk) 19:10, 16 November 2018 (UTC)
- Support SEMMENDINGER (talk) 19:12, 16 November 2018 (UTC)
- Support StudiesWorld (talk) 19:21, 16 November 2018 (UTC)
- Support --Seacactus 13 (talk) 19:22, 16 November 2018 (UTC)
- Support Agtx (talk) 19:23, 16 November 2018 (UTC)
- Support Zchrykng (talk) 19:24, 16 November 2018 (UTC)
- Support Argento Surfer (talk) 19:26, 16 November 2018 (UTC)
- Support Kosack (talk) 19:28, 16 November 2018 (UTC)
- 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 strongly, this is a vital tool Atlantic306 (talk) 19:41, 16 November 2018 (UTC)
- 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 - very strongly, particularly with the increasing merging of NPP and AfC Nosebagbear (talk) 19:45, 16 November 2018 (UTC)
- 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 = paul2520 (talk) 19:50, 16 November 2018 (UTC)
- Support FitIndia Talk 19:55, 16 November 2018 (UTC)
- Support L293D (☎ • ✎) 19:57, 16 November 2018 (UTC)
- Support CoolSkittle (talk) 20:07, 16 November 2018 (UTC)
- Support Bradv (talk) 20:10, 16 November 2018 (UTC)
- Support My name is not dave (talk) 20:19, 16 November 2018 (UTC)
- 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 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 Geoff Who, me? 20:30, 16 November 2018 (UTC)
- Support Dodger67 (talk) 20:35, 16 November 2018 (UTC)
- Support Vermont (talk) 21:31, 16 November 2018 (UTC)
- Strong support (disclosure: I get the NPP newsletter) — pythoncoder (talk | contribs) 22:08, 16 November 2018 (UTC)
- 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--Ozzie10aaaa (talk) 22:29, 16 November 2018 (UTC)
- Support Araratic (talk) 22:32, 16 November 2018 (UTC)
- Support John Broughton (talk) 23:27, 16 November 2018 (UTC)
- 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 ToThAc (talk) 23:51, 16 November 2018 (UTC)
- Support — JJMC89 (T·C) 00:15, 17 November 2018 (UTC)
- Support Gehenna1510 (talk) 00:20, 17 November 2018 (UTC)
- Support – numbermaniac 00:37, 17 November 2018 (UTC)
- Support Anarchyte (work | talk) 00:41, 17 November 2018 (UTC)
- Support- Dcheagle (talk) 01:17, 17 November 2018 (UTC)
- Support-CASSIOPEIA (talk) 01:26, 17 November 2018 (UTC)
- Support AmericanAir88 (talk) 01:29, 17 November 2018 (UTC)
- Support — Akhiljaxxn (talk) 01:35, 17 November 2018 (UTC)
- Support Natureium (talk) 02:16, 17 November 2018 (UTC)
- Support MRD2014 (talk) 03:09, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 03:35, 17 November 2018 (UTC)
- Support Winged Blades of Godric (talk) 04:37, 17 November 2018 (UTC)
- Support JTP (talk • contribs) 04:46, 17 November 2018 (UTC)
- Support Abzeronow (talk) 04:52, 17 November 2018 (UTC)
- Support Ehime«…» 05:46, 17 November 2018 (UTC)
- Support about time Kudpung (talk) 07:17, 17 November 2018 (UTC)
- Support Kpgjhpjm (talk) 07:33, 17 November 2018 (UTC)
- Support Domdeparis (talk) 07:37, 17 November 2018 (UTC)
- Support this is essential for maintaining the integrity of wikipedia. Polyamorph (talk) 08:56, 17 November 2018 (UTC)
- Support good. 333-blue 09:49, 17 November 2018 (UTC)
- 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 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: 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, 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: 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 PratyushSinha101 (talk) 10:13, 17 November 2018 (UTC)
- Support Patriccck (talk) 10:35, 17 November 2018 (UTC)
- Support Jc86035 (talk) 10:56, 17 November 2018 (UTC)
- Support ‐‐1997kB (talk) 11:03, 17 November 2018 (UTC)
- Support AlexLeeCN (talk) 11:44, 17 November 2018 (UTC)
- Support Much needed for the project Cahk (talk) 11:46, 17 November 2018 (UTC)
- Support Jcc (talk) 12:12, 17 November 2018 (UTC)
- Support Like tears in rain (talk) 12:23, 17 November 2018 (UTC)
- Support This seems reasonable. I have seen canvassing.GreyGreenWhy (talk) 15:07, 17 November 2018 (UTC)
- 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 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 Mmitchell10 (talk) 20:51, 17 November 2018 (UTC)
- 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 completely! :) Megalibrarygirl (talk) 02:26, 18 November 2018 (UTC)
- Support Catrìona (talk) 06:04, 18 November 2018 (UTC)
- Support Curb Safe Charmer (talk) 09:49, 18 November 2018 (UTC)
- Support Sdkb (talk) 11:01, 18 November 2018 (UTC)
- Support Abelmoschus Esculentus (talk) 11:59, 18 November 2018 (UTC)
- Support Eddie891 (talk) 12:26, 18 November 2018 (UTC)
- Support Sebastian Wallroth (talk) 13:13, 18 November 2018 (UTC)
- Support enL3X1 ¡‹delayed reaction›¡ 14:41, 18 November 2018 (UTC) #94
- Support SilverTiger12 (talk) 15:20, 18 November 2018 (UTC)
- Support --AntanO 15:58, 18 November 2018 (UTC)
- Support Schwede66 (talk) 17:40, 18 November 2018 (UTC)
- Support · · · Peter (Southwood) (talk): 18:09, 18 November 2018 (UTC)
- Support ProgrammingGeek talktome 19:57, 18 November 2018 (UTC)
- Support Ajpolino (talk) 20:42, 18 November 2018 (UTC)
- Support Crystallizedcarbon (talk) 20:44, 18 November 2018 (UTC)
- Support Esquivalience (talk) 23:58, 18 November 2018 (UTC)
- Support Barbara (WVS) (talk) 00:46, 19 November 2018 (UTC)
- Support Titore (talk) 02:13, 19 November 2018 (UTC)
- Support Shizhao (talk) 02:34, 19 November 2018 (UTC)
- Support Handling new pages efficiently is essential. Johnuniq (talk) 04:42, 19 November 2018 (UTC)
- 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 Give NPP the tools they need (in proper condition) to succeed. — AfroThundr (u · t · c) 05:52, 19 November 2018 (UTC)
- Support – Teratix ₵ 06:28, 19 November 2018 (UTC)
- 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 Waddie96 (talk) 07:33, 19 November 2018 (UTC)
- 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 Chandan Guha (talk) 08:56, 19 November 2018 (UTC)
- Support - This will certainly enhance the work output at NPP. HitroMilanese (talk) 09:01, 19 November 2018 (UTC)
- Support Remagoxer (talk) 10:30, 19 November 2018 (UTC)
- SupportTheLongTone (talk) 11:33, 19 November 2018 (UTC)
- Support Courcelles 14:54, 19 November 2018 (UTC)
- Support Strikerforce (talk) 15:03, 19 November 2018 (UTC)
- Support Randomeditor1000 (talk) 15:04, 19 November 2018 (UTC)
- Support ONUnicorn (talk) 16:02, 19 November 2018 (UTC)
- Support Much needed JackTracker (talk) 18:41, 19 November 2018 (UTC)
- Support Chris Troutman (talk) 18:54, 19 November 2018 (UTC)
- 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 Weegaweek (talk) 20:55, 19 November 2018 (UTC)
- Support JHCaufield (talk) 00:04, 20 November 2018 (UTC)
- Support 331dot (talk) 01:08, 20 November 2018 (UTC)
- Support Agree curation tools are important... Doc James (talk · contribs · email) 03:40, 20 November 2018 (UTC)
- Support Cwmhiraeth (talk) 10:06, 20 November 2018 (UTC)
- Support Famousdog (talk) 11:01, 20 November 2018 (UTC)
- Oppose as this seems to be a single-wiki-purpose thing. → «« Man77 »» [de] 12:55, 20 November 2018 (UTC)
- 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)
- 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)
- Support Willsome429 (talk) 15:48, 20 November 2018 (UTC)
- Support And.martire (talk) 16:35, 20 November 2018 (UTC)
- Support Mcampany (talk) 22:10, 20 November 2018 (UTC)
- Support CAPTAIN RAJU(T) 22:24, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:03, 20 November 2018 (UTC)
- Support Arian Talk 18:28, 21 November 2018 (UTC)
- 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 Vulphere 01:17, 22 November 2018 (UTC)
- Support ~Cybularny Speak? 15:46, 23 November 2018 (UTC)
- Support JøhP (talk) 16:24, 23 November 2018 (UTC)
- Support FlyingAce (talk) 01:07, 24 November 2018 (UTC)
- Support Pf1127 (talk) 06:24, 24 November 2018 (UTC)
- Support Hydronium Hydroxide (talk) 09:10, 24 November 2018 (UTC)
- Support sounnds nooice JonathanLa (talk) 02:15, 25 November 2018 (UTC)
- Support DannyS712 (talk) 08:11, 25 November 2018 (UTC)
- 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 Ranjithsiji (talk) 22:36, 25 November 2018 (UTC)
- Support Slashme (talk) 08:08, 26 November 2018 (UTC)
- Support Dreamy Jazz (talk) 08:48, 26 November 2018 (UTC)
- Support Whispering (talk) 14:27, 26 November 2018 (UTC)
- Support -- Amanda (aka DQ) 22:42, 26 November 2018 (UTC)
- Support Graeme Bartlett (talk) 23:23, 27 November 2018 (UTC)
- Support These improvements are well overdue Noyster (talk) 13:04, 28 November 2018 (UTC)
- 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
- 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 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 Liuxinyu970226 (talk) 03:33, 17 November 2018 (UTC)
- Support FF-11 (talk) 09:51, 17 November 2018 (UTC)
- Support Libcub (talk) 10:14, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:07, 17 November 2018 (UTC)
- Support JogiAsad (talk) 18:37, 17 November 2018 (UTC)
- Support Mmitchell10 (talk) 20:39, 17 November 2018 (UTC)
- 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 Abductive (talk) 09:52, 18 November 2018 (UTC)
- Support Hydriz (talk) 14:26, 18 November 2018 (UTC)
- 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 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 BugWarp (talk) 23:59, 19 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:00, 20 November 2018 (UTC)
- Support Vulphere 17:25, 22 November 2018 (UTC)
- Support Sebari – aka Srittau (talk) 19:43, 22 November 2018 (UTC)
- Support DannyS712 (talk) 19:49, 22 November 2018 (UTC)
- Support FiliP ██ 20:06, 22 November 2018 (UTC)
- Support Poslovitch (talk) 20:18, 22 November 2018 (UTC)
- Support B20180 (talk) 17:43, 24 November 2018 (UTC)
- Support Alexei Kopylov (talk) 17:57, 24 November 2018 (UTC)
- Support Juntas (talk) 22:09, 24 November 2018 (UTC)
- Support By erdo can • TLK 09:01, 25 November 2018 (UTC)
- Support Per B16 Daniel Case (talk) 04:01, 26 November 2018 (UTC)
- Support Dreamy Jazz (talk) 08:44, 26 November 2018 (UTC)
- 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 Per DMacks as a gadget - FlightTime (open channel) 22:13, 26 November 2018 (UTC)
- Support YFdyh000 (talk) 15:10, 27 November 2018 (UTC)
- Support Quedel (talk) 23:12, 27 November 2018 (UTC)
- Support Iich1960 (talk) 10:36, 28 November 2018 (UTC)
- Support Dumbassman (talk) 17:48, 29 November 2018 (UTC)
- Support Ldorfman (talk) 20:41, 29 November 2018 (UTC)
- Support Platonides (talk) 23:37, 29 November 2018 (UTC)
- Support Stussll (talk) 06:48, 30 November 2018 (UTC)
Prevent DDoS-style attacks
- 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:
- Proposer: Jayron32 (talk) 19:08, 30 October 2018 (UTC)
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)
- @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)
- 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)
- 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)
- 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)
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)
- 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)
- @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)
- 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 Galobtter (talk) 18:47, 16 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 03:35, 17 November 2018 (UTC)
- Support Hiàn (talk) 04:46, 17 November 2018 (UTC)
- Support Kpgjhpjm (talk) 07:32, 17 November 2018 (UTC)
- Support Dcheney (talk) 16:24, 17 November 2018 (UTC)
- 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 I've noticed that too, but it was not a troll but a spammer. JackPotte (talk) 23:34, 17 November 2018 (UTC)
- Support Ciao • Bestoernesto • ✉ 06:48, 18 November 2018 (UTC)
- Support ~ Amory (u • t • c) 11:36, 18 November 2018 (UTC)
- Support FR30799386 (talk) 07:06, 19 November 2018 (UTC)
- Support Waddie96 (talk) 07:28, 19 November 2018 (UTC)
- Support Veikk0.ma (talk) 12:09, 19 November 2018 (UTC)
- Support Courcelles 14:51, 19 November 2018 (UTC)
- Support Kb03 (talk) 15:38, 19 November 2018 (UTC)
- Support ONUnicorn (talk) 15:58, 19 November 2018 (UTC)
- Support Ahecht (TALK
PAGE) 16:21, 19 November 2018 (UTC) - Support Ronhjones (talk) 00:17, 20 November 2018 (UTC)
- 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 Johnuniq (talk) 06:09, 20 November 2018 (UTC)
- Support Jamesmcmahon0 (talk) 10:18, 20 November 2018 (UTC)
- 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 Novak Watchmen (talk) 23:01, 20 November 2018 (UTC)
- Support Vulphere 05:59, 21 November 2018 (UTC)
- 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 ~Cybularny Speak? 15:45, 23 November 2018 (UTC)
- Support FlyingAce (talk) 01:42, 24 November 2018 (UTC)
- Support – Teratix ₵ 05:06, 25 November 2018 (UTC)
- Support Daniel Case (talk) 03:11, 26 November 2018 (UTC)
- Support Dreamy Jazz (talk) 08:45, 26 November 2018 (UTC)
- 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 Alvarosinde (talk) 16:34, 29 November 2018 (UTC)
- Support Schniggendiller (talk) 10:31, 30 November 2018 (UTC)
Create an integrated anti-spam/vandalism tool
- 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:
- Proposer: – Ajraddatz (talk) 19:05, 29 October 2018 (UTC)
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
- Support James Martindale (talk) 18:35, 16 November 2018 (UTC)
- Support Galobtter (talk) 18:48, 16 November 2018 (UTC)
- Support Vermont (talk) 21:29, 16 November 2018 (UTC)
- Support Super Wang on zhwiki (Share your opinions) 23:42, 16 November 2018 (UTC)
- Support — regards, Revi 02:06, 17 November 2018 (UTC)
- Support Rschen7754 02:44, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 03:32, 17 November 2018 (UTC)
- Support Kpgjhpjm (talk) 04:03, 17 November 2018 (UTC)
- Support Hiàn (talk) 04:47, 17 November 2018 (UTC)
- Support BRP ever 05:36, 17 November 2018 (UTC)
- Support Dirk Beetstra T C (en: U, T) 09:59, 17 November 2018 (UTC)
- Support Additionally tools like this are avail but doesn't work always. ‐‐1997kB (talk) 10:24, 17 November 2018 (UTC)
- Support --Alaa :)..! 10:38, 17 November 2018 (UTC)
- Support MER-C (talk) 10:39, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:07, 17 November 2018 (UTC)
- Support —MarcoAurelio (talk) 11:37, 17 November 2018 (UTC)
- Support Martin Urbanec (talk) 13:47, 17 November 2018 (UTC)
- Support Vwanweb (talk) 15:27, 17 November 2018 (UTC)
- Support Cross wiki vandalism is only increasing and the time to respond is NOW. If automated vandalism ever gets ahead of human editor capability then we have a crisis. Blue Rasberry (talk) 15:29, 17 November 2018 (UTC)
- Support Townie (talk) 16:44, 17 November 2018 (UTC)
- Support JogiAsad (talk) 18:40, 17 November 2018 (UTC)
- Support —Thanks for the fish! talk•contribs 19:55, 17 November 2018 (UTC)
- Support –Ammarpad (talk) 20:55, 17 November 2018 (UTC)
- Support Temp3600 (talk) 05:44, 18 November 2018 (UTC)
- Support Szalax (talk) 09:13, 18 November 2018 (UTC)
- Support ~ Amory (u • t • c) 11:27, 18 November 2018 (UTC)
- Support Abelmoschus Esculentus (talk) 12:07, 18 November 2018 (UTC)
- Support Hydriz (talk) 14:27, 18 November 2018 (UTC)
- Support Stryn (talk) 15:58, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:30, 18 November 2018 (UTC)
- Support JackPotte (talk) 19:21, 18 November 2018 (UTC)
- Support – Meiræ 22:12, 18 November 2018 (UTC)
- Support --Defender (talk) 22:14, 18 November 2018 (UTC)
- Support Shizhao (talk) 02:33, 19 November 2018 (UTC)
- Support ~ Nahid Talk 09:19, 19 November 2018 (UTC)
- Support ·addshore· talk to me! 09:58, 19 November 2018 (UTC)
- Support Elmidae (talk) 14:01, 19 November 2018 (UTC)
- Support Courcelles 14:56, 19 November 2018 (UTC)
- Support StringRay (talk) 22:28, 19 November 2018 (UTC)
- Support Another great idea. Doc James (talk · contribs · email) 03:41, 20 November 2018 (UTC)
- Support TonyBallioni (talk) 05:58, 20 November 2018 (UTC)
- Support Johnuniq (talk) 06:13, 20 November 2018 (UTC)
- Support Tomybrz Bip Bip 17:34, 20 November 2018 (UTC)
- Support Lofhi (talk) 17:49, 20 November 2018 (UTC)
- Support CAPTAIN RAJU(T) 22:19, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:00, 20 November 2018 (UTC)
- Support Framawiki (talk) 19:35, 21 November 2018 (UTC)
- Support Regards, ZI Jony (Talk) 19:38, 21 November 2018 (UTC)
- Support Skyman gozilla (talk) 20:05, 21 November 2018 (UTC)
- Support Nihlus 22:13, 21 November 2018 (UTC)
- Support Krinkle (talk) 01:10, 22 November 2018 (UTC)
- Support fine Matiia (talk) 01:31, 22 November 2018 (UTC)
- Support yes. Cohaf (talk) 01:34, 22 November 2018 (UTC)
- Support anything that makes the wikis as a whole more resistant to vandalism; we seem to be able to get scale on our side here HLHJ (talk) 03:49, 22 November 2018 (UTC)
- Support — JJMC89 (T·C) 08:30, 22 November 2018 (UTC)
- Support Bencemac (talk) 10:08, 22 November 2018 (UTC)
- Support--►Neriman2003 talk 18:33, 22 November 2018 (UTC)
- Support Sebari – aka Srittau (talk) 19:46, 22 November 2018 (UTC)
- Support ~Cybularny Speak? 15:46, 23 November 2018 (UTC)
- Support Matěj Suchánek (talk) 08:36, 24 November 2018 (UTC)
- Support Quiddity (talk) 18:37, 24 November 2018 (UTC)
- Support Arne (Amjaabc) (talk) 08:35, 25 November 2018 (UTC)
- Support By erdo can • TLK 08:57, 25 November 2018 (UTC)
- Support Chrisjj (talk) 17:57, 25 November 2018 (UTC)
- Support Boothsift (talk) 18:46, 25 November 2018 (UTC)
- Support Ranjithsiji (talk) 22:34, 25 November 2018 (UTC)
- Support WhatamIdoing (talk) 00:33, 26 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 01:29, 26 November 2018 (UTC)
- Support Dreamy Jazz (talk) 08:47, 26 November 2018 (UTC)
- Support Whispering (talk) 21:15, 26 November 2018 (UTC)
- Support Izno (talk) 00:56, 27 November 2018 (UTC)
- Support Jaccard (talk) 11:16, 27 November 2018 (UTC)
- Support Franck.schneider (talk) 20:39, 27 November 2018 (UTC)
- Support Pmlineditor (t · c · l) 17:12, 28 November 2018 (UTC)
- Support PF4Eva (talk) 08:39, 29 November 2018 (UTC)
- Support Dumbassman (talk) 17:45, 29 November 2018 (UTC)
- Support Schniggendiller (talk) 10:56, 30 November 2018 (UTC)
- Support NicoScribe (talk) 11:26, 30 November 2018 (UTC)
Make undeletion page ID sensitive
- 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.
- More comments: This and Community Wishlist Survey 2019/Admins and stewards/Feature parity for tools dealing with deleted revisions are mutually exclusive. Either one can be implemented, but not both.
- Phabricator tickets: T193690, T206587, T161671#4199220
- Proposer: GeoffreyT2000 (talk) 00:41, 1 November 2018 (UTC)
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
- Support Liuxinyu970226 (talk) 03:32, 17 November 2018 (UTC)
- Oppose As written, this is overcomplicated and includes undesirable features. Better would be phab:T20493 or Community Wishlist Survey 2019/Admins and stewards/Feature parity for tools dealing with deleted revisions. Anomie (talk) 14:11, 17 November 2018 (UTC)
- Agreed ~ Amory (u • t • c) 11:30, 18 November 2018 (UTC)
- Support Novak Watchmen (talk) 22:59, 20 November 2018 (UTC)
Overhaul spam-blacklist
- 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
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.
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)
- Proposer: --Dirk Beetstra T C (en: U, T) 11:33, 30 October 2018 (UTC)
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)
- It is also easy to fool the existing URL blacklist system.C933103 (talk) 15:20, 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)
- @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)
- @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)
- 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)
- 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: 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)
- 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: 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)
- @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).
- @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)
- 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>’).
- @Beetstra: To be clear, I'm talking about a syntax like this:
- 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)
- @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)
- 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 Essential upgrades required to keep this system relevant. – Ajraddatz (talk) 18:19, 16 November 2018 (UTC)
- Support Galobtter (talk) 18:46, 16 November 2018 (UTC)
- Support MER-C (talk) 18:58, 16 November 2018 (UTC)
- Support HHill (talk) 21:10, 16 November 2018 (UTC)
- Support Albert Cardozo (talk) 01:24, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 03:33, 17 November 2018 (UTC)
- Proposer Support. This is long, long overdue. —Dirk Beetstra T C (en: U, T) 05:31, 17 November 2018 (UTC)
- Support Xiplus (talk) 07:29, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:07, 17 November 2018 (UTC)
- Support —MarcoAurelio (talk) 11:39, 17 November 2018 (UTC)
- Support Martin Urbanec (talk) 13:47, 17 November 2018 (UTC)
- Support Blue Rasberry (talk) 15:29, 17 November 2018 (UTC)
- Support JogiAsad (talk) 18:38, 17 November 2018 (UTC)
- Support — pythoncoder (talk | contribs) 19:14, 17 November 2018 (UTC)
- Support —Thanks for the fish! talk•contribs 19:48, 17 November 2018 (UTC)
- Support JOAN ~ (Questions?) 20:49, 17 November 2018 (UTC)
- Support Ciao • Bestoernesto • ✉ 07:02, 18 November 2018 (UTC)
- Support Szalax (talk) 09:07, 18 November 2018 (UTC)
- Support Jules78120 (talk) 09:31, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:29, 18 November 2018 (UTC)
- Support Courcelles 14:56, 19 November 2018 (UTC)
- Support Yes. Spam is a growing issue. Doc James (talk · contribs · email) 03:48, 20 November 2018 (UTC)
- 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 Novak Watchmen (talk) 23:03, 20 November 2018 (UTC)
- Support Nihlus 22:13, 21 November 2018 (UTC)
- 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 DannyS712 (talk) 19:59, 22 November 2018 (UTC)
- Support MisterSynergy (talk) 10:20, 23 November 2018 (UTC)
- Support ~Cybularny Speak? 15:41, 23 November 2018 (UTC)
- Support Sannita - not just another it.wiki sysop 00:24, 24 November 2018 (UTC)
- Support Matěj Suchánek (talk) 08:37, 24 November 2018 (UTC)
- Support Winged Blades of Godric (talk) 09:13, 24 November 2018 (UTC)
- Support B20180 (talk) 17:46, 24 November 2018 (UTC)
- Support By erdo can • TLK 09:01, 25 November 2018 (UTC)
- Support Johnuniq (talk) 10:33, 26 November 2018 (UTC)
- Support Whispering (talk) 21:15, 26 November 2018 (UTC)
- 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 SQLQuery me! 00:14, 27 November 2018 (UTC)
- Support Izno (talk) 01:15, 27 November 2018 (UTC)
- Support WhatamIdoing (talk) 00:25, 28 November 2018 (UTC)
- Support Ahm masum (talk) 21:15, 28 November 2018 (UTC)
- Support Achim (talk) 21:46, 28 November 2018 (UTC)
- Support Daniel Case (talk) 06:38, 29 November 2018 (UTC)
- Support I guess it wouldn't hurt. PF4Eva (talk) 08:57, 29 November 2018 (UTC)