Jump to content

Talk:Submissions/Roundtable: Admin tools development

From Wikimania 2014 • London, United Kingdom
Latest comment: 10 years ago by Geraldshields11 in topic Review

WereSpielChequers wishlist

If we have some resource available to improve admin tools there are a few things on my wishlist. I've created each as a separate subheading so people can comment on them individually: WereSpielChequers (talk) 15:00, 29 March 2014 (UTC)Reply

Smart Blocking

One of the blunter tools in the admin's toolbox is the rangeblock. Allegedly the bycatch of the millions of IPs we have blocked with range blocks is one of the more plausible reasons for the fall in goodfaith IP editing. With Smart Range blocks the admin would have to specify a particular edit or edits as necessitating the block, and the block would then apply to anyone editing in that IP range using the same hardware, browser and O/S as the vandal. For Privacy reasons the admin would not know what those settings were unless they were also a Checkuser, but they wouldn't need to know for this to work. Of course that would still lead to some people being caught by range blocks, and some people with access to multiple devices would need a smart block for each device, in some cases a traditional rangeblock would still be required. But for millions of potential editors this would mean they no longer experienced a block when they tried to edit. We would also need to amend our privacy policy so that the IP and other details of a vandalism edit could be kept for years so that the smart range block could work, but I don't see that as a problem, and if people didn't like it they could always appeal and ask for another admin to check that their edit really was vandalism. WereSpielChequers (talk) 15:00, 29 March 2014 (UTC)Reply

Training session IP addresses

One of the things I get involved in via the UK chapter is training sessions for newbies. These hit a couple of problems due to automated throttles restricting the number of new Userids that can be created by an IP address and the number of edits that new and or unregistered editors can do at one IP address in a short period of time. There is a lot of logic in having such throttles, normally they prevent mass vandalism, but they do make training sessions more complex. Currently we cater for this through a combination of:

  1. Encouraging new editors to create an account before they attend a session.
  2. Having mobile WiFi hotspots in order to spread the load across multiple IP addresses.
  3. Having an admin or account creator on hand to create people's accounts for them.
  4. Having an admin set participating accounts as "confirmed users"
  5. Structuring the training so you never tell more than five newbies to "all hit save now" at the same time.
  6. Not being too ambitious in the number of editors we recruit in one event.

None of the above are ideal, some infringe somewhat on people's privacy. They certainly add to the idea that editing Wikipedia is a complicated process with strange pitfalls.

It also confuses things when experienced editors are training newbies as unconfirmed editors ave to go through the capcha process when adding external links - even in references.

Ideally we would have an option so that an admin could set an IP address as unthrottled for 24 hours. The admin wouldn't even need to know the IP address, just be able to do two things: Either set their current IP address as unthrottled; Or set the IP address of a given edit as unthrottled. So a trainer setting up an event would just leave a note on the admin's noticeboard or an admin they knew and had arranged this with, and an admin could look at the diff of their note "Hi, am at event xxxxxx, please unthrottle this IP ~~~~" and click a button to mark whatever IP that editor was using as unthrottled for the next 24 hours. WereSpielChequers (talk) 15:00, 29 March 2014 (UTC)Reply

Protect articles against certain named editors

Our tools for handling edit warring are not ideal. Often we go straight to a block on the theory that the participating editors should know the rules. So in some ways we are treating our good faith editors more roughly than the vandals who usually get four levels of warning before they are blocked, despite the fact that vandals are rarely reformed but most edit warrers will continue to do good edits after their blocks. A much better tool to deal with edit warring would be one that restricted paricular accounts from not editing particular articles for a set period of time. "I've restricted that article so that neither of you can edit it for 7 days. Please edit somewhere else" is less bitey than "I have blocked you both for editwarring" it also gives the edit warrers the option to edit other articles. Yes I'm sure there would still be occasions when the feud just moved to another article and it still had to be escalated to a block. But it would be an escalation, not the current block first solution that contributes to the biteyness of the pedia. WereSpielChequers (talk) 15:13, 29 March 2014 (UTC)Reply

Review

Strong Keep because we need to improve tools. Well written abstract and well written supplement on talk page. Geraldshields11 (talk) 13:04, 19 April 2014 (UTC)Reply