2017 Community Wishlist Survey/Admins and stewards

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

2017 Community Wishlist Survey

Admins and stewards
13 proposals, 241 contributors, 462 support votes

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

Here are the 2017 Community Wishlist Survey results!
The voting phase has ended. Thanks for your participation :)


Extend global blocks to named accounts

Edit proposal/discussion

  • Problem: Currently global locks are enforced as if they were de facto Global bans, this is despite the official policy stating “This list does not include accounts that have been globally locked on charges of cross wiki disruption, spamming, or vandalism. Such users are not globally banned, per se. If they create new accounts and are not disruptive with those accounts, they will not be locked again merely because it is discovered that they were previously globally locked.” Yet in reality they are enforced as global bans with Stewards locking them upon discovery and local admins of projects where there are no active blocks reverting the addition of educational content merely on the accusation of “lock evasion” (which doesn't exist) even if the content is wanted by the community, this inherently doesn't benefit any project. Although officially global locks 🛅 aren't global bans they unofficially are, and stewards also treat them as such. This can most recently been seen with Virajmishra who is globally banned all but in name, the same goes for Diegusjaimes who has requested an unlocking since July 27th, 2017 and still hasn't had their main account unlocked (as of November 8th, 2017), in fact they may believe that they’re globally banned.

Also note 📝 that global locks have always been meant to be a temporary measure until global blocking to named accounts would be implemented, however after (I think) around seven years this still hasn't been enabled.

  • Who would benefit: The communities, as wiki’s would be given local autonomy, the globally “banned” users (“owners” of locked accounts), and probably the Stewards too because then they won't have to deal with unlock requests.
  • Proposed solution: Extend the global blocking tool to named accounts, this would generally be used how global locks are done now, global locking would still be the preferred method for malicious bots (such as spam bots) and accounts with malicious usernames, but all other named accounts would then be automatically blocked on every new Wikimedia project they attempt to edit in, generally talk page access should be allowed unless abuse has proven too severe, then the user should be advised to kindly request talk page access (on wiki's where this hasn't been locally revoked) for wiki’s where the block reason is “Steward Global block-account”. Of course as one can see with my example a certain local admin doesn't want me to edit Dutch Wikipedia regardless of what positive contributions I could do there, so community discussion should be advised for local unblocking or an assumption of good faith where a chance should be given before bad faith is assumed, or that global block appeals should show the intent of what they would do locally rather than appeal based on the behaviour of other wiki’s. After the user has sufficiently proven that they’re not an immediate menace to the projects where they haven’t been blocked as a “Stewardblock-account”, then they could request a global unblock that doesn't override local blocks.

In this scenario User:Example is blocked on German Wikipedia locally and blocked on the German Wiktionary as a global block, if a steward removes their global block the block on German Wikipedia would stand but for the German Wiktionary would be lifted.

  • More comments: The global locking of Graaf Statler prior to their Foundation ban was unnecessary, and the Stewards shouldn't have locked him again after he edited as a good faith user on projects where he wasn't locally blocked, for this reason a global lock 🔒 has proven to be a de facto global ban.

Discussion

  • The reason why global blocking for named accounts does not exist is because it has no advantages over global locking. That's because almost all global locks are for troublemakers that aren't usually worth a second chance, such as spammers, LTA sockpuppets, globally banned users and the like. I also don't think that block evasion is usually tolerated. Everything else you are pointing out here seems like a policy question especially since you were in fact unlocked. Jo-Jo Eumerus (talk, contributions) 17:27, 9 November 2017 (UTC)
    The one benefit would be a global autoblock of the IP(s), saving us a couple of seconds running CheckUser on loginwiki (and being more effective than that). – Ajraddatz (talk) 17:30, 9 November 2017 (UTC)
    phab:T19929 seems like a task for making autoblocks be triggered by locking, although it's apparently not so simple? Jo-Jo Eumerus (talk, contributions) 19:29, 9 November 2017 (UTC)
    It's an absolute nightmare. An autoblock feature would need to be purpose built for global account blocking anyway, so it could be easier to just include it with locking instead. I think that's what past me was thinking anyway :P – Ajraddatz (talk) 20:45, 9 November 2017 (UTC)
  • phab:T17294. MER-C (talk) 04:00, 13 November 2017 (UTC)

Voting

  • Support Support a little --Liuxinyu970226 (talk) 12:48, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:34, 28 November 2017 (UTC)
  • Support Support Winston Spencer (talk) 13:10, 30 November 2017 (UTC)
  • Support Support Terra  (talk) 06:33, 2 December 2017 (UTC)
  • Oppose Oppose As unnecessary. Also, I am not convinced that any of the features of global block for named accounts are useful (some might actually be harmful) in the context of the actions that global locks are deployed against. Jo-Jo Eumerus (talk, contributions) 11:12, 2 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 02:23, 4 December 2017 (UTC)
  • Oppose Oppose Unnecessary. And that fact that he names Graaf Statler as a good faith user victimized by this, makes me scary. Especially since Graaf Statler is still sending me disturbing e-mails. The Banner (talk) 16:25, 4 December 2017 (UTC)

2FA and Huggle

Edit proposal/discussion

  • Problem: Admins with two-factor authentication (2FA) cannot use Huggle. In wikis with a small number of admins this is a big issue - it means choosing between being very effective doing maintainance or securing admin accounts. A two-velocity system of admins develops, where those who use Huggle end up doing most of the work and others can't keep up.
  • Who would benefit: All admins in projects where Huggle is enabled.
  • Proposed solution: Make 2FA compatible with Huggle.
  • More comments:

Discussion

I'd rather characterize this as "make Huggle support BotPasswords or OAuth". Max Semenik (talk) 19:34, 14 November 2017 (UTC)

Bot passwords do not require any dedicated support; they are just passwords. You should be able to use Huggle with a bot password even if you have 2FA. --Tgr (WMF) (talk) 00:37, 17 November 2017 (UTC)

Bot passwords? Raystorm (talk) 18:50, 27 November 2017 (UTC)
mw:Manual:Bot passwords. In short, an alternate password to log into your account via the API with limited user rights. Anomie (talk) 14:49, 28 November 2017 (UTC)

Voting

Allow further user block options ("can edit XY" etc.)

Edit proposal/discussion

  • Problem: Admins can only block users from editing any page at all (the one exception being that user's talk page). If a blocked user is given the right to edit on a specific page or specific pages, the block still has to be lifted completely. This could be confusing, as the community has still decided to block them from other pages.
  • Who would benefit: Administrators and blocked users.
  • Proposed solution: Create options for users to edit pages to appeal the block, edit or not edit certain pages or namespaces, or do certain actions such as registering an account, use email or upload files.
  • More comments:
  • Proposer: → «« Man77 »» [de] 19:36, 14 November 2017 (UTC)

Discussion

  • good idea. maybe add a possibility to block only specific namespace. For example block the main namespace but not draft namespace. - yona B. (D) 13:26, 15 November 2017 (UTC)
    • added → «« Man77 »» [de] 18:28, 15 November 2017 (UTC)
  • For some of my research into blocking tools, I've found several other requests for similar functionality to add extra levels of granularity into blocking tools. Here's a list of what I've found so far. I think this would be a very beneficial feature to explore/build. We'll need to decide how all of this is logged and stored appropriately. — Trevor Bolliger, WMF Product Manager 🗨 18:56, 15 November 2017 (UTC)
  • We Steward often have problems with abusive uploads by accounts in specific ranges, for example filesharing on Wikimedia Commons through Wikipedia Zero. If we could disallow uploads for IPs or IP ranges, that would help a lot.
  • Further, we have trolls which only create abusive user names but rarely edit. At the moment, we can only full-block ranges when it would be more useful to only disallow account creations while users could still edit. Can you add that to this proposal, should I ask at #Specialised blocks, or should I create another proposal, Man77? —DerHexer (Talk) 13:12, 18 November 2017 (UTC)
    • DerHexer: Please feel free to add further options to the list above, if you think it fits in here. For my part, I think that IP range block options could also be dealt with separately. However, the better strategy could also be not to atomize the proposals in order to get all the votes her ;) → «« Man77 »» [de] 14:00, 18 November 2017 (UTC)
      • I tried to make the change as little as possible. Are you okay with that? Best, —DerHexer (Talk) 11:34, 19 November 2017 (UTC)
  • The Community Tech team would like to merge this and 2017 Community Wishlist Survey/Admins and stewards/Specialised blocks. Are you fine with us doing that? /Johan (WMF) (talk) 17:47, 20 November 2017 (UTC)
  • Endorse I really don't want Wikimedia Commons to miss good quality images because a user misbehaves outside of uploading such as here. And for Wikipedia's this would be largely beneficial for the encyclopedia as most of the time content creators get banned not for bad edits in the mainspace but for insults and hot-headed debates in talk pages. --Donald Trung (Talk 🤳🏻) 09:20, 24 November 2017 (UTC)
  • Also with this idea 💡 topic bans and interaction bans can finally be enforced. --Donald Trung (Talk 🤳🏻) 09:21, 24 November 2017 (UTC)
  • I think that you can do this all using the abuse filter (called as edit filter somewhere), though it's not so easy for non technical users. Stryn (talk) 19:02, 27 November 2017 (UTC)
  • Can the reverse of this happen? For example, X is blocked due to BLP issues, but their edits on dinosaurs are sound. So in other words, can X be blocked from editing all articles in Category:Living people, but edit other articles? Lugnuts (talk) 18:44, 4 December 2017 (UTC)
  • Hello all — This item did not make the Top 10 for the 2017 Wishlist, but the Wikimedia Foundation's Anti-Harassment Tools team is already looking into building better blocking tools in early 2018. Support for this proposal and the comments are already being taken into account. Read more and participate in the discussion at Community health initiative/Blocking tools and improvements. Thank you, and I hope to see you there! — Trevor Bolliger, WMF Product Manager 🗨 23:07, 14 December 2017 (UTC)

Voting

  • Support Support Reception123 (talk) 20:01, 27 November 2017 (UTC)
  • Support Support Goldzahn (talk) 23:02, 27 November 2017 (UTC)
  • Support Support Matiia (talk) 00:37, 28 November 2017 (UTC)
  • Support Support - yona B. (D) 05:47, 28 November 2017 (UTC)
  • Support Supportviciarg414 08:11, 28 November 2017 (UTC)
  • Support Support --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 08:13, 28 November 2017 (UTC)
  • Support Support β16 - (talk) 10:09, 28 November 2017 (UTC)
  • Support Support Jo-Jo Eumerus (talk, contributions) 10:28, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 12:37, 28 November 2017 (UTC)
  • Support Support Jianhui67 talkcontribs 14:09, 28 November 2017 (UTC)
  • Support Support Jc86035 (talk) 14:43, 28 November 2017 (UTC)
  • Support Support Sakretsu (talk) 17:03, 28 November 2017 (UTC)
  • Support Support Yiyi (talk) 18:50, 28 November 2017 (UTC)
  • Support Support Gripweed (talk) 21:26, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:34, 28 November 2017 (UTC)
  • Support Support MichaelSchoenitzer (talk) 00:15, 29 November 2017 (UTC)
  • Support Support Drm310 (talk) 19:08, 29 November 2017 (UTC)
  • Support Support Niklem (talk) 19:11, 29 November 2017 (UTC)
  • Support Support --Christian Ferrer (talk) 19:18, 29 November 2017 (UTC)
  • Support Support Or even namespace blocks. --Ruthven (talk) 19:34, 29 November 2017 (UTC)
  • Support Support EVinente (talk) 19:43, 29 November 2017 (UTC)
  • Support Support Aunva6 (talk) 20:10, 29 November 2017 (UTC)
  • Support Support Pallanz (talk) 20:13, 29 November 2017 (UTC)
  • Support Support Patar knightchat/contributions 20:42, 29 November 2017 (UTC)
  • Nominal support, but Community Tech should not be working on this. Their resources are better spent elsewhere while the Anti-Harassment team tackles this. MER-C (talk) 20:52, 29 November 2017 (UTC)
  • Support SupportMeiræ 21:55, 29 November 2017 (UTC)
  • Support Support MGChecker (talk) 22:02, 29 November 2017 (UTC)
  • Support Support (a first step towards a namespace block, useful for when you'd need to force a user to temporarily work only in ns0) --g (talk) 23:48, 29 November 2017 (UTC)
  • Support Support This would also help in handling users who showed selective problematicity on some arguments/articles while being good contributors elsewhere.--L736Etell me 07:34, 30 November 2017 (UTC)
  • Support Support Winston (talk) 08:38, 30 November 2017 (UTC)
  • Support Support Winston Spencer (talk) 13:11, 30 November 2017 (UTC)
  • Support Support Strongly needed. —DerHexer (Talk) 16:08, 30 November 2017 (UTC)
  • Support Support Laurel Lodged (talk) 19:38, 30 November 2017 (UTC)
  • Support Support Tropicalkitty (talk) 20:07, 30 November 2017 (UTC)
  • Support Support Dromedar61 (talk) 20:25, 30 November 2017 (UTC)
  • Support Support Daniel Case (talk) 00:32, 1 December 2017 (UTC)
  • Support Support DonBarredora (talk) 01:24, 1 December 2017 (UTC)
  • Support Support Good idea. AndyAndyAndyAlbert (talk) 07:59, 1 December 2017 (UTC)
  • Support Support HaythamAbulela 18:16, 1 December 2017 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 20:54, 1 December 2017 (UTC)
  • Support Support but perhaps not with Community Tech per MER-C. J947 03:33, 2 December 2017 (UTC)
  • Support Support Operator873 (talk) 05:35, 2 December 2017 (UTC)
  • Support Support Wostr (talk) 10:10, 2 December 2017 (UTC)
  • Support Support --Bubo 11:43, 2 December 2017 (UTC)
  • Support Support ~Cybularny Speak? 11:57, 2 December 2017 (UTC)
  • Support Support Szoltys (talk) 12:02, 2 December 2017 (UTC)
  • Support Support Ented (talk) 12:24, 2 December 2017 (UTC)
  • Support Support«« Man77 »» [de] 13:52, 2 December 2017 (UTC)
  • Support Support Emir of Wikipedia (talk) 15:40, 2 December 2017 (UTC)
  • Support Support Tacsipacsi (talk) 16:57, 2 December 2017 (UTC)
  • Support Support TheCatalyst31 (talk) 16:58, 2 December 2017 (UTC)
  • Support Support Otapka (talk) 18:43, 2 December 2017 (UTC)
  • Support Support Kostas20142 (talk) 21:17, 2 December 2017 (UTC)
  • Support Support Wiklol (talk) 21:24, 2 December 2017 (UTC)
  • Support Support yes please, more granularity! Chris Keating (The Land) (talk) 21:33, 2 December 2017 (UTC)
  • Support Support Sometimes a full block would be too heavy-handed. NinjaRobotPirate (talk) 07:24, 3 December 2017 (UTC)
  • Support Support Mz7 (talk) 10:22, 3 December 2017 (UTC)
  • Support Support -- seth (talk) 10:37, 3 December 2017 (UTC)
  • Support Support -- Dolotta (talk) 13:59, 3 December 2017 (UTC)
  • Support Support Winged Blades of Godric (talk) 16:22, 3 December 2017 (UTC)
  • Support Support rxy (talk) 22:17, 3 December 2017 (UTC)
  • BA candidate.svg Weak oppose unnecessary complication, I think that edit-protected pages and template editors at english wikipedia are already a complication, and adding fine-grained blocks is another even greater complication, instead we need better review system so that new edits and newcomers receive attention at the time they make their first edit. Add more volunteers who help with this process. English Wikipedia has not enough helpers and assisting persons and resolving this by fine graining the blocks sounds like an overkill in my personal opinion. --Gryllida 00:31, 4 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 02:27, 4 December 2017 (UTC)
  • Support Support: This would vastly improve our ability to deal with disruption but often-good editors we want to retain. It should be possible to a) block editors with a PoV problem from articles by name or by category; and b) unblock blocked editors for particular pages by name or category (including, e.g., ArbCom, ANI, and other dispute resolution pages, as well as selective content pages).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:03, 4 December 2017 (UTC)
  • Support Support Jpcomic (talk) 10:22, 4 December 2017 (UTC)
  • Support Support - Great idea!, I've seen it more than once on EN where an editor is blocked but they've been given the opportunity to comment for instance at Arbcom or ANI and have been told under no certain terms if they edit any other page they'll be blocked (rightly so) so having this would give those blocked the oppertunity to defend themselves or have their say - Ofcourse if they abuse it it'll be revoked. –Davey2010Talk 15:15, 4 December 2017 (UTC)
  • Support Support Ronhjones (talk) 18:10, 4 December 2017 (UTC)
  • Support Support Yeza (talk) 23:03, 4 December 2017 (UTC)
  • Support Support as much as I believe editors should be mature enough to not require the community to babysit them, the reality is that some editors get indeffed because they cannot control a small aspect of their onwiki behaviour, while the rest of their activity is an asset. enL3X1 ¡‹delayed reaction›¡ 03:39, 6 December 2017 (UTC)
  • Support Support I do agree that certain users might be able to contribute on certain points, if not all Yohannvt (talk) 11:53, 6 December 2017 (UTC)
  • Support Support Ixocactus (talk) 01:37, 7 December 2017 (UTC)
  • Support Support Chealer (talk) 03:51, 7 December 2017 (UTC)
  • Support Support Ealdgyth (talk) 13:35, 7 December 2017 (UTC)
  • Support Support X:: black ::X (talk) 14:38, 7 December 2017 (UTC)
  • Support Support Ahm masum (talk) 21:17, 7 December 2017 (UTC)
  • Support Support --jdx Re: 18:45, 8 December 2017 (UTC)
  • Support Support. Basically we need anything between a full lock and a full editing. There are many possible options, including block from editing a namespace (e.g. user cannot edit templates), from editing a group of pages (e.g. user cannot edit articles about living politicians), from editing a specific page (e.g. user cannot edit a page where they were engaged in an edit war) or vice versa (e.g. user can edit only a specific page, which already happened in a real life case where a user violated rules but had to prepare a page of an offline event at the same time). Having at least some of these options would be a huge plus — NickK (talk) 20:21, 8 December 2017 (UTC)
  • Support Support -- Amanda (aka DQ) 18:19, 10 December 2017 (UTC)
  • Support Support Perrak (talk) 20:43, 10 December 2017 (UTC)
  • Support Support Jnanaranjan sahu (talk) 06:38, 11 December 2017 (UTC)
  • Support Support HakanIST (talk) 12:24, 11 December 2017 (UTC)
  • Support Support Facenapalm (talk) 12:36, 11 December 2017 (UTC)
  • Support Support — Luchesar • T/C 13:08, 11 December 2017 (UTC)
  • Support Support Pxos (talk) 14:20, 11 December 2017 (UTC)
  • Support Support --Meno25 (talk) 15:38, 11 December 2017 (UTC)
  • Support Support Braveheart (talk) 16:48, 11 December 2017 (UTC)
  • Support Support Support; could replace "bans" or similar verdicts, that have to be monitored by all admins to be effective (unlikely), including those that were not involved in the actual discussion (most unlikely) He3nry (talk) 17:07, 11 December 2017 (UTC)
  • Support Support KPFC💬 17:15, 11 December 2017 (UTC)

U2F support for 2FA

Edit proposal/discussion

  • Problem: Admins and people with higher rights constantly are under attack by hackers trying to guess or steal their passwords. Having two-factor authentication (2FA) protects against this, but it is vulnerable to phishing and hacking of mobile phones, and confusing for some non-technical users.
  • Who would benefit: Admins/Checkusers/People who have access to sensitive data and all other people whose data they have access to
  • Proposed solution: Enable Universal 2nd Factor (U2F) support for Wikimedia projects. U2F is a more modern 2FA mechanism with several advantages:
    • it's self-contained, no need to install any software - just plug it into an USB slot / touch it to your phone and it works;
    • it is hardware-based, thus unhackable (the secret key never leaves the device and there is no way to tamper with the software);
    • keys are bound to the website domain so it is immune to phishing.
  • More comments:
  • Proposer: Amir (talk) 12:01, 18 November 2017 (UTC)

Discussion

I expanded the description; feel free to change or revert. --Tgr (talk) 08:07, 20 November 2017 (UTC)

One of the biggest downsides to U2F compared to 2FA is the need for dedicated hardware. Most people have mobile phones to install authenticators on, whereas people may not have the hardware required for this. Some staff use YubiKeys. Is specialised hardware required, or could one theoretically use a generic USB stick? I'm wondering if this wish could be coupled with an initiative to distribute the relevant hardware to people. If preconfigured devices were brought by staff to public Wikimedia events (hackathons, Wikimania, etc.) then the only added costs would be staff time to set up the devices and the cost of small-capacity USB sticks. (This is just an idle thought I had, I have no control over any budget to do this.) --Dan Garry, Wikimedia Foundation (talk) 15:09, 20 November 2017 (UTC)

@Deskana (WMF): Custom hardware is required. Part of the security guarantee of U2F is that your secret keys never leave the device so all the encryption, certificate verification etc. has to be done by the firmware. Cheap options are around $15 (U2F Zero is $9 but very barebones). High-end ones are $50-ish. I don't think they require any setup typically (Yubikey definitely doesn't; it supports a bunch of other authentication methods, like the OTP-based one used for WMF VPN access, and that requires some configuration, but the U2F functionality works out of the box). --Tgr (talk) 05:47, 28 November 2017 (UTC)
  • I believe this proposal should clarify that U2F support is going to supplement, not replace the currently existing 2FA mechanism (which may as well be made more user-friendly, but that's the topic of Make 2FA easier to use). It is my impression that people like L736E vote against the proposal based on the (I believe) wrong assumption that U2F will be the only supported 2FA method. Amir, Tgr?
    — Luchesar • T/C 17:19, 1 December 2017 (UTC)
    That's correct. What this proposal wants is to make it add the support, people can choose between these two options. Amir (talk) 23:50, 1 December 2017 (UTC)

Voting

  • Support Support Tgr (talk) 05:48, 28 November 2017 (UTC)
  • Oppose Oppose Many good password managers are available for free, like PasswordSafe or LastPass, and they can create unlimited number of passwords of any length. For instance, I connect to Wikimedia projects with a 24-character password, composed of lowercase letters, uppercase letters, numbers, and non-alphanumeric characters. Don't ask me what it is, only my browsers and my password manager do. If you try to log in to my account, you will need to solve CAPTCHAs after some failed attempts. LoginNotify runs on all projects. You can only read Wikimedia projects using w:HSTS and w:HTTPS. All exchanges are done using "PKCS #1 SHA-256 With RSA Encryption". If you ever have a chance to read on w:Kevin Mitnick and social engineering, you will learn that the weak point in security is the human, very seldom the machine. For these reasons, we don't need further connection protection, but users must use a good password manager. U2F cannot correct erratic or weak human behavior. Cantons-de-l'Est (talk) 12:37, 28 November 2017 (UTC)
    • (One of) the points of U2F is that your credentials are tied to a specific origin (domain). Thus it intends to reduce social engineering attacks like you describe above, as the human is no longer responsible for determining if the site in question is actually Wikipedia or not. Thus I don't think this oppose makes sense. BWolff (WMF) (talk) 22:07, 28 November 2017 (UTC)
  • Oppose Oppose per above, SHA-256 is too long for external users who hates English to understand. --Liuxinyu970226 (talk) 12:43, 28 November 2017 (UTC)
    • This definitely doesn't make sense, as users of U2F don't have to know anything about SHA-256 to use it. In the same way visiting this page doesn't require you to understand SHA-256 despite the fact your web browser has to in order to connect to Wikipedia (depending on cipher selection for TLS). BWolff (WMF) (talk) 22:07, 28 November 2017 (UTC)
  • Support Support Combining something you know with something you have is a very well established security practice that stops a large number of attacks. It is true that users must still choose strong passwords and keep them safe, and that they should be encouraged to use password managers. But saying that 2FA is redundant once the users are doing the above is at best a gross underestimation of the security problems involved if not a sign of incompetence. I'm sorry if I sound rude, but this is exactly an example of how the human link is indeed the weakest one: when humans rely too much on certain technology, be it HTTPS, password strength or something else. This is also connected with one more reason why 2FA is very much desirable— the multi-layer approach to security, which is another basic security principle. HTTPS, HSTS and everything else (including U2F, for that matter) can and will fail one day. But when you have multiple layers of protection, the probability that all of them will fail at the same time is much lower. Therefore, I strongly endorse the U2F support, although I'm not sure why there's a separate suggestion, as U2F is already mentioned in Make 2FA easier to use. — Luchesar • T/C 20:48, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:35, 28 November 2017 (UTC)
  • Support Support 𝔊 (Gradzeichen DiſkTalk) 06:45, 29 November 2017 (UTC)
  • Support Support I'd love to have this as an option for those who'd want to use it. —TheDJ (talkcontribs) 10:01, 29 November 2017 (UTC)
  • Oppose Oppose if it's meant as a forced choice; neutral if an option. --g (talk) 00:16, 30 November 2017 (UTC)
    • 2FA is an option as of now and I don't think it will be forced anyway for now. — regards, Revi 06:15, 30 November 2017 (UTC)
  • Support Support Yes. Please. That oppose reasons doesn't make sense. That password manager oppose doesn't make sense as per BWolff. — regards, Revi 06:15, 30 November 2017 (UTC)
  • Oppose Oppose Who will provide/handle/maintain the list of compatible hardware devices? Who will grant that all admins in all countries may have easy access to buy those devices (think about commercial restrictions, restrictive local laws on security devices and so on)? Did you consider that a "cheap 15US$" may sound not so "cheap" in many countries of the world (in Bangladesh, the average wage is 17US$ per month, so your "cheap 15US$" would mean "one month of salary" for them)? "Forcing" this device may discourage users in such conditions to candidate for adminships or other "sensitive" roles. And yes, I see that this goes "against" the mantra "we need more admin, we need to encourage admin candidatures": it introduces a physical and economical barreer: unnecessary, not in the spirit of a "Free Encyclopedia". Especially considering that 2FA is already there, for free, for all. --L736Etell me 07:48, 30 November 2017 (UTC)
  • Support Support Winston Spencer (talk) 13:11, 30 November 2017 (UTC)
  • Support Support WQL (talk) 09:51, 1 December 2017 (UTC)
  • Support Support Eug (talk) 11:58, 1 December 2017 (UTC)
  • Support Support Jacob Robertson (talk) 13:58, 1 December 2017 (UTC)
  • Support Support Terra  (talk) 06:39, 2 December 2017 (UTC)
  • Support Support Emir of Wikipedia (talk) 15:41, 2 December 2017 (UTC)
  • Support Support, and those opposes based on a misunderstanding that U2F would be a forced replacement for the existing 2FA need to be disregarded. Boing! said Zebedee (talk) 21:32, 2 December 2017 (UTC)
  • Support Support This definitely should be as an alternative to OATH for those who don't have a hardware device, but U2F should definitely be an option for those of us who do. [stwalkerster|talk] 22:42, 2 December 2017 (UTC)
  • Support Support I don't see why the option should not exist: it's only if we were coercing people to implement this instead of 2FA that we'd have a problem, and that seems to be no part of the proposal Vanamonde93 (talk) 06:15, 3 December 2017 (UTC)
  • Support Support Tiputini (talk) 07:13, 4 December 2017 (UTC)
  • Support Support with low priority. I have no problem adding this as an option, but I have doubts about the number of users who would adopt this as a solution. Aervanath (talk) 00:26, 5 December 2017 (UTC)
  • Support SupportAlvaro Molina ( - ) 01:35, 5 December 2017 (UTC)
  • Support Support as an alternative method. the wub "?!" 00:30, 6 December 2017 (UTC)
  • Support Support with low priority.. Yohannvt (talk) 11:56, 6 December 2017 (UTC)
  • Support Support Zppix (talk) 14:19, 7 December 2017 (UTC)
  • Support Support Ahm masum (talk) 21:13, 7 December 2017 (UTC)
  • Oppose Oppose, probably too costly for very limited impact. I think quite few users would prefer U2F over 2FA, and on the other side having a U2F that would fit all users would be rather costly to develop. U2F imposes very significant limits (e.g. it relies on only two browsers, it might not be available in certain countries etc.) which probably make investment in it not that cost-efficient — NickK (talk) 20:32, 8 December 2017 (UTC)
  • Support Support -- as optional of course NaBUru38 (talk) 22:34, 9 December 2017 (UTC)

Allow protection of multiple pages (from the same Category)

Edit proposal/discussion

  • Problem: Currently pages have to be protected one-by one. If there is a specific topic that is being vandalized or anything else to warrant protection, it would be nice if all the articles in that topic (or Category) could all be protected by one click.
  • Who would benefit: Administrators who need to protect various pages from the same topic by doing one at a time
  • Proposed solution: Add an option to allow administrators to be able to protect all pages from the same Category (or another criteria)
  • More comments:
  • Phabricator tickets:

Discussion

English Wikipedia has a tool called Twinkle; a quick test shows that the "p-batch" option does the job for a category. עוד מישהו Od Mishehu 16:22, 7 November 2017 (UTC)

Voting

  • Support Support David1010 (talk) 07:34, 28 November 2017 (UTC)
  • Support Support --Liuxinyu970226 (talk) 12:42, 28 November 2017 (UTC)
  • Oppose Oppose No nuke buttons in a collaborative environment, please. --TMg 12:53, 28 November 2017 (UTC)
  • Oppose Oppose There is no reason to replace ban with bulk protection.--YFdyh000 (talk) 13:21, 28 November 2017 (UTC)
  • Support Support although this would probably only be suited for Commons and Wikidata. Jc86035 (talk) 14:44, 28 November 2017 (UTC)
  • Support Support Gripweed (talk) 21:27, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:36, 28 November 2017 (UTC)
  • Support Support Shizhao (talk) 02:48, 29 November 2017 (UTC)
  • Oppose Oppose protection, just like block, is always an exceptional solution, better to suggest a cautious case-specific approach to these tools. --g (talk) 00:21, 30 November 2017 (UTC)
  • Oppose Oppose "Bulk protection" may only make sense in case of "massive" trolling or vandalic operations made by several unregistered users all together at a time. Never faced this kind of issue so far. Categories may encompass hundreds of articles: this tool would potentially block any cooperative actions on large parts of the project in one shot. Too strong and too much against the "Free Encyclopedia" principle.--L736Etell me 07:40, 30 November 2017 (UTC)
  • Support Support Laurel Lodged (talk) 19:39, 30 November 2017 (UTC)
  • Support Support Daniel Case (talk) 00:33, 1 December 2017 (UTC)
  • Oppose Oppose per g and L736E. --Superchilum(talk to me!) 16:11, 1 December 2017 (UTC)
  • Oppose Oppose There is no reason for protecting a whole section of Wikipedia. -Theklan (talk) 18:31, 1 December 2017 (UTC)
  • Oppose Oppose per g. Wostr (talk) 10:12, 2 December 2017 (UTC)
  • Oppose Oppose ~Cybularny Speak? 12:09, 2 December 2017 (UTC)
  • Oppose Oppose Ented (talk) 12:27, 2 December 2017 (UTC)
  • Oppose Oppose Could be very dangerous if works also for subcategories. --Termininja (talk) 15:28, 2 December 2017 (UTC)
  • Oppose Oppose per g. —Tacsipacsi (talk) 17:00, 2 December 2017 (UTC)
  • Oppose Oppose Protecting an entire category would usually be massive overkill. And as categorization frequently changes, it might be impossible to undo once it's no longer needed. Boing! said Zebedee (talk) 21:37, 2 December 2017 (UTC)
  • Support Support Ciao • Bestoernesto 02:29, 4 December 2017 (UTC)
  • Oppose Oppose overkill --OlEnglish (Talk) 06:18, 4 December 2017 (UTC)
  • Oppose Oppose as is overkill - Instead of protecting every article in that category we can just block the idiot vandalising .... this way has worked for 10 years .... no need to change it now. –Davey2010Talk 15:19, 4 December 2017 (UTC)
  • Support Support but with caution and after another admin has "signed it off" for want of a better term. Lugnuts (talk) 18:46, 4 December 2017 (UTC)
  • Support Support Zppix (talk) 14:19, 7 December 2017 (UTC)

Bring Special:Undelete to feature parity with live page histories

Edit proposal/discussion

Discussion

  • A tool [1]: Query deleted page history on zhwiki--Shizhao (talk) 02:37, 8 November 2017 (UTC)
  • This would be so useful. TonyBallioni (talk) 23:29, 14 November 2017 (UTC)
  • Agreed, the current Undelete page is so frustrating to use. Premeditated Chaos (talk) 23:31, 14 November 2017 (UTC)
  • Yes, we definitely need this. I work a lot in this area, and the current limitations make it very time-consuming. This is one of the features that should have been available many years ago. DGG (talk) 01:15, 20 November 2017 (UTC)
  • From the Community Tech team: This is a good proposal, as long as folks are aware that we'd probably take an iterative approach to this -- taking one piece at a time, and not necessarily doing all of the requested steps on this proposal. -- DannyH (WMF) (talk) 17:25, 20 November 2017 (UTC)
    I think the deletion mechanism should be more similar to revdelete than current deletion, though it would need a non-trivial amount of software rewriting. --Vituzzu (talk) 14:41, 23 November 2017 (UTC)

Voting

Merging files will include merging in file history too

Edit proposal/discussion

  • Problem:

Today if we use the merging function on two files (two page in file-namespace) the merge include only the history of the description but not the history of the file itself (file history change only when we use "Upload a new version of this file")

  • Who would benefit:

All users group who have the permission to merge (admins, bureaucrats)

  • Proposed solution:

two possibility:

    • using the merge existing today to include the file merging
    • creat a new tool to merge pages.
  • More comments:
  • Phabricator tickets:
  • Proposer: - yona B. (D) 09:26, 15 November 2017 (UTC)

Discussion

Old image revisions are indexed by filename + timestamp so a merge would change links to old versions (and be generally a pain to implement as timestamps can conflict). Not a huge deal but this would be a lot easier to implement after phab:T28741 is fixed. --Tgr (WMF) (talk) 00:45, 17 November 2017 (UTC)

Voting

Allow Special:Nuke to delete imported pages

Edit proposal/discussion

  • Problem: Currently, Special:Nuke does not list imported pages, and therefore these cannot be nuked.
  • Who would benefit: Administrators and Bureaucrats
  • Proposed solution: Special:Nuke should be able to allow mass deletion of imported pages as well.
  • More comments: If an administrator and/or bureaucrat makes a mistake, and accidentally imports pages that they did not want to, it would be good if Special:Nuke could mass delete those pages, so that the administrator/bureaucrat does not have to delete them all manually.

Discussion

Voting

Make 2FA easier to use

Edit proposal/discussion

  • Problem:

We've had Two-factor authentication enabled for admins (and other functionaries) for some time. But MediaWiki's implementation of 2FA is rather clumsy at the moment: the secret and the scratch codes are only shown once, which means a user cannot use multiple token-generating devices (unless the user sets them up all at the same time) and cannot change devices without disabling all existing devices and scratch codes. The common option to remember a device, so that future log-ins only require password but not an authenticator token, is also noticeably absent.

  • Who would benefit:

Everybody who wants to use two-factor authentication

  • Proposed solution:
    • Change the OATH interface to allow further devices to be added without revoking existing devices and scratch codes.
    • Add a "remember this device" option so that future logins from the same device requires only password.
  • More comments:
  • Proposer: Deryck C. 22:05, 9 November 2017 (UTC)

Discussion

  • The latter point, that there is no 'remember' option, is the primary reason I don't use 2FA. I'd love to, but I switch between accounts too often for it to be useful. Samwalton9 (talk) 23:06, 9 November 2017 (UTC)
  • This would certainly be a useful change for 2FA. We should also require that users have an email attached to their account to use 2FA, and allow for 2FA to be removed from an account after confirming in an email rather than using the scratch codes. With that done, the extension could be more widely rolled out. – Ajraddatz (talk) 23:08, 9 November 2017 (UTC)
  • Provided that the account could be recovered by confirming ones password and receiving an email, I think this is fine. Strongly worded setup instructions to encourage the use of a committed identity would be a good idea from the outset. I would like to use 2FA, however I know many people don't, and it will of course be optional. A Den Jentyl Ettien Avel Dysklyver (talk) 14:57, 11 November 2017 (UTC)
  • Only showing 2FA keys once is a standard security feature. It means your 2FA identity cannot be compromised if the attacker gains temporary access to your account (steals your cookies or opens your preferences while you turn your back on your laptop). Changing that seems like a bad idea. Maybe we could allow multiple different keys (with notification emails and everything). For more modern 2FA methods like U2F that will be a requirement anyway.
    Remembering the device is less problematic but with 1-year login durations how much difference does it make? --Tgr (WMF) (talk) 00:53, 17 November 2017 (UTC)
    How about showing them again, as an elevated action, where you have to enter your existing 2FA again. —TheDJ (talkcontribs) 13:45, 18 November 2017 (UTC)
    That could work. --Tgr (WMF) (talk) 22:46, 18 November 2017 (UTC)
    We could also add it to password resets (if it isn't already). Some sites are already doing this. Github calls it sudo mode, Phabricator calls it high security mode. 😂 (talk) 07:52, 6 December 2017 (UTC)
    We do (for Special:ChangePassword, not Special:PasswordReset of course). Although there's no UI to indicate the "elevated" mode and no way to deactivate it besides waiting for it to expire in (by default) 5 minutes. On the code level, see AuthManager::securitySensitiveOperationStatus() (and also SpecialPage::getLoginSecurityLevel()/SpecialPage::checkLoginSecurityLevel()). Anomie (talk) 15:27, 6 December 2017 (UTC)
  • It's important to improve this, but I don't want to specify specific technical functionality -- one definite need is for easier account recovery. I've also been informed there is no way of setting up 2FA from a Mac interface. DGG (talk) 01:59, 20 November 2017 (UTC)
  • U2F support would indeed be very welcome, as I think it's going to be easier for many less technically inclined people (apart from the need for a physical key, of course). Overall, if several 2FA methods could be supported (including more than one of a type, e.g. registering two U2F keys), that would be ideal and—especially if plain backup codes are supported as well—would also automatically solve the problem with account recovery (besides committed identity, but that may again be too much for some people). The option to remember the device should also help to convince more people that 2FA isn't going to be an unbearable burden (and it's still going to be more secure than using no 2FA whatsoever).
    — Luchesar • T/C 20:24, 28 November 2017 (UTC)

Voting

Create a global whitelist for global autoblocks

Edit proposal/discussion

  • Problem:

Many subnets belonging to colo/hosting service are globally blocked in order to stop spam or per NOP. Several legit users/organisation may be affected if they use private VPN, private proxies which are caught by these blocks. Currently the only way to unblock a single IP is chunking the relevant rangeblock in 32-blocked prefix lenght blocks (for IPv4).

  • Who would benefit:

Legit users caught by proxyblock, stewards saving complains to give answers and administrative overhead in managing the block of many smaller subnets.

  • Proposed solution:

Allow a global whitelisting of IPs (or even ranges) included in a globally blocked subnet.

  • More comments:
  • Phabricator tickets:

Discussion

Is Global IP block exemptions insufficient? Anomie (talk) 14:58, 9 November 2017 (UTC)

Nope, GIPBE is a big deal since it allows an user to edit from *any* blocked connection, also it obviously only works for registered users. --Vituzzu (talk) 10:49, 14 November 2017 (UTC)
Not at all, there are 900 wikis where it would be potentially needed. An example, I just got an email from a local US government which offers a free wifi service. The service uses a captive portal hosted in a colocation facility. Colocation subnet is blocked because it also hosts several open proxies. How would you solve this? --Vituzzu (talk) 10:49, 14 November 2017 (UTC)
By not blocking entire subnets because they include "several open proxies"? --Tgr (WMF) (talk) 00:55, 17 November 2017 (UTC)
Did you ever dealt with spambots floods or our loyal LTAs? --Vituzzu (talk) 10:07, 17 November 2017 (UTC)
Yes, although no doubt on a smaller scale than large wiki / crosswiki antiabuse people. My point (made in a flippant tone that was uncalled for; sorry about that) was that if a block is sweeping enough to include important institutions that we notice we don't want to block, then it's probably also going to include lots of "unimportant" well-intentioned users whom we won't notice. It would be better to think about improving block targeting instead of issuing wide blocks and whitelisting a lucky few. --Tgr (WMF) (talk) 06:34, 19 November 2017 (UTC)
Well, I made just an example, but most of complains are from single users, usually those using their own VPNs. Rangeblocks are not indiscriminate, I usually don't block transit while I usually block webhosting. Also, a significant percentage of users caught are actually affected by some fancy malware.
What I am proposing here is not meant to be a general purpose solution, but another tool to ease the handling of the big burden of crosswiki issues. A tool which would be, in my experience, the "cheapest" way to solve a variety of problems. --Vituzzu (talk) 20:51, 19 November 2017 (UTC)

Voting

Make AbuseFilter easy to use for nontechnical admins by making filter editing more visual

Edit proposal/discussion

  • Problem: AbuseFilter is very powerful and flexible. There are plenty of situations where it could be a more appropriate tool than blocking or page protection (see e.g. all the proposals about limited blocks of problem users), and can handle spammers and sockpuppeteers who can defeat all other tools. Unfortunately it was written by tech people for tech people. Most admins are effectively excluded from using it because it's presented like a programming language, even though its concept is not that difficult (simple statements using "and" and "or").
  • Who would benefit: Admins and the communities they work for.
  • Proposed solution: Make AbuseFilter intuitive and easy to use for everyone by
    • replacing (or, preferably, complementing) the programming-language-like interface with some kind of visual condition editor (Blockly would be one good candidate);
    • integrating a decent regex editor (good example: regex101);
    • merging the filter editing / creation interface and the filter testing interface: show what the filter would match as it's being edited.
  • More comments:
  • Phabricator tickets:
  • Proposer: Tgr (talk) 11:17, 20 November 2017 (UTC)

Discussion

Tgr: Good proposal, but at the moment it's very broad – making the tool easier to use, and then a number of different things we could potentially do. I'm worried that if people vote for this, hope for something and the team then does some of the potential proposals but not what people were hoping for, they'll be disappointed. Could we narrow it down a bit, make it more specific? /Johan (WMF) (talk) 17:22, 20 November 2017 (UTC)

@Johan (WMF): do you mean changing the title to better match the three specific things proposed, or removing (splitting up? if that's OK to do past the proposal deadline) the proposed solutions so there is one technical task per proposal? Tgr (talk) 20:55, 20 November 2017 (UTC)

I think there could be a number of ways to go about that – either splitting it up, rephrasing it, or focusing more on specific solutions (e.g. "here are the things I think should be done" instead of "some potential solutions") or problems. Just so we don't end up in the situation where everyone who wants something done about the AbuseFilter think this is the task and then the Community Tech team ends up focusing on something else than they were hoping for. /Johan (WMF) (talk) 21:22, 20 November 2017 (UTC)
The "proposed solutions" section seems pretty specific to me: it lists the three things which IMO should be done - make a visual condition editor, integrate a regex visualisation/testing tool, live-update the list of matches as the filter is being edited (or at least make it easy to update them, without having to context-switch and copy-paste between the filter edit page and the filter test page). I only mentioned the specific technologies/tools I had in mind as examples because I haven't done the investigation needed to be sure they are viable. --Tgr (talk) 21:36, 20 November 2017 (UTC)
And the three features are interdependent (at least in my mind) - they visualize different aspects of the filter (logical structure, regular expressions, actual effect on edits) that a non-technical person would have a hard time understanding from the current interface. --Tgr (talk) 21:38, 20 November 2017 (UTC)
Tgr: Reading through this again, I'm wondering if I didn't read "situations" as "solutions" first. Mea culpa. But I think a more specific title would be a good idea. (: /Johan (WMF) (talk) 14:41, 22 November 2017 (UTC)
Renamed. --Tgr (talk) 19:31, 22 November 2017 (UTC)
I see the third feature as the critical one. If it's easy for non-technical people to edit abuse filters, it must be easy for them to see what their filters will do. For an example of what happens without this feedback, see the history of the Enwiki titleblacklist from around 2008, where a user without a good understanding of regex managed to do things like block all pagemoves to titles containing the letter "p", or block a randomly-selected quarter of all pagemoves. --Carnildo (talk) 23:58, 28 November 2017 (UTC)

Voting

Implement delete and move warning for associated talk pages

Edit proposal/discussion

  • Problem: When moving a page over another page (available only for sysops) the talk page is not moved if the talk page of the second page exists and an error message appears saying that the talk page was not moved. This results in talk pages often being 'left behind' at the old title.
  • Who would benefit: Administrators who move pages. Other editors and readers who wouldn't find missing/disjointed talk pages.
  • Proposed solution: The delete and move warning should be displayed another time (first time for the page itself, second time for the talk page) for the talk page making it possible to move the page and its talk page together.
  • More comments: This has been a bug since at least 2007.

Discussion

  • I'd support this. It is quite frustrating and was something I was unaware of when I first got the tools. TonyBallioni (talk) 21:58, 20 November 2017 (UTC)
  • It would be nice also "merging" discussions together as a consequence of the move and delete (but this is another history) --L736Etell me 07:59, 30 November 2017 (UTC)

Voting

Automatic detection of admin candidates

Edit proposal/discussion

  • Problem: There is a persistent shortage of admins. We need a better process for recruiting new admins.
  • Who would benefit: Everyone.
  • Proposed solution: More of less the reverse of an anti-vandal bot. Run a bot which examines editors' history: contributions, talk page activity, warnings, block logs, etc. etc., and use appropriate algorithms (to be determined) to detect accounts that might be potential good admins. (This might, for example, be a neural network trained on the contributions of current admins before they were made admins.) Make this list public, and send those accounts messages suggesting they put themselves forward for adminship.

    It's also possible that this automatic pre-review might also offer communities the possibility of shortening the current lengthy review/interview process for admin candidates selected this way.

  • More comments:
  • Phabricator tickets:

Discussion

  • Some current (not-the-best alternatives) include w:WP:List of administrator hopefuls and tools like Enterprisey's admin score/Enterprisey's candidate search (why are these not the same tool--as in, why does the admin score not show up in the candidate search, or at least a cross reference link? @Enterprisey: :D ) as well as the xtools version of admin score. --Izno (talk) 18:34, 17 November 2017 (UTC)
  • Spamming potential candidates is not a viable (or correct) solution IMO. Eligible candidates typically decline nominations because RfA is synonymous with a trip to the village stocks. -FASTILY 01:44, 18 November 2017 (UTC)
  • This proposal is very enwiki-centric and doesn't necessarily apply elsewhere. --Rschen7754 18:31, 19 November 2017 (UTC)
  • A bot is anything but a good solution for this kind of issue. I don't think anything automatic is a good approach in finding potential candidates but, anyway, a SQL query is far more efficient than realtime edit scanning. --Vituzzu (talk) 14:37, 23 November 2017 (UTC)
  • Ninety percent of any serious RfA voter's criteria are based on trust and an evaluation of the cadidates competence and knowledge, things that no AI or bot can do. This would just produce a lot of failed Requests for Adminship with accompanying disappointment and loss of face for the candidates. Kudpung (talk) 20:01, 6 December 2017 (UTC)

Voting

  • Oppose Oppose This proposal has limited impact as a project-specific problem. MER-C (talk) 01:59, 28 November 2017 (UTC)
  • Oppose Oppose Per MER-C, too much unnecessary. --Liuxinyu970226 (talk) 12:41, 28 November 2017 (UTC)
  • Oppose Oppose Further to the above, the English Wikipedia already has more admins than the next 15 Wikipedias combined. Jc86035 (talk) 15:02, 28 November 2017 (UTC)
  • Oppose Oppose --Gripweed (talk) 21:26, 28 November 2017 (UTC)
  • Support Support Thomas Obermair 4 (talk) 21:33, 28 November 2017 (UTC)
  • Oppose Oppose IKhitron (talk) 22:55, 28 November 2017 (UTC)
  • Support Support Get the engine working - and then use with extra care. A mandatory opt-in should be enforced. I know, it is somewhat not the idea, as it would only find future admins willing to be found, but the alternative would be listing user's activity without their consent (legal or not, that is not proper, in my book) Nabla (talk) 19:25, 29 November 2017 (UTC)
  • Support Support Andrew (talk) 20:14, 29 November 2017 (UTC)
  • Oppose Oppose good to have such keen tools to evaluate contribs, but very bad for suggesting candidates (an undeclared bot would score the best records...) --g (talk) 23:43, 29 November 2017 (UTC)
  • Oppose Oppose I don't see how anything good can come of this. Nihlus 04:48, 30 November 2017 (UTC)
  • Oppose Oppose In the choice of potentially eligible admins, a key role is the way they approach other users from the human relationship perspective. This cannot be detected by a bot, however "neural" it may be. Furhtermore, there's a consent issue: not all "good contributors" may have the will to become admin. Supporting this tool would mean also, for fairness reasons, developing a kind of "no, thanks" tool to exclude from the algorithm all the users who explicitly decline the idea for becoming admin. But this paves the way to further technical and ethical issues: a way to "step back" from the "no thanks" list (people may change their mind with the time), exposing user names without their permissions, adequate advisment to all registered users (new and existing) that their name could be chosen by an automatic system, an adequate handling of "accept/don't accept" that option, and so on. The balance costs+drawbacks+implications vs. benefits is heavily negative, IMHO. --L736Etell me 07:27, 30 November 2017 (UTC)
  • Oppose Oppose As the saying goes, "to err is human. To really screw things up takes a computer". The only good I could possibly imagine coming of this would be that for once everybody would agree on what the problem is with our admin-selection process.

    If you like computer dating works out for you, you'll love computer admin-recruitment. Daniel Case (talk) 00:45, 1 December 2017 (UTC)

  • Oppose Oppose this cannot be done in automatic or even semi-automatic mode. --Superchilum(talk to me!) 16:14, 1 December 2017 (UTC)
  • Oppose Oppose Wostr (talk) 10:07, 2 December 2017 (UTC)
  • Oppose Oppose --Termininja (talk) 15:32, 2 December 2017 (UTC)
  • Support Support Otapka (talk) 18:41, 2 December 2017 (UTC)
  • Oppose Oppose Admins should be recruited/nominated by the community, not a bot. Matěj Suchánek (talk) 21:04, 2 December 2017 (UTC)
  • Oppose Oppose per the opposes above. Boing! said Zebedee (talk) 21:22, 2 December 2017 (UTC)
  • Support Support WikiMasterGhibif (talk) 23:42, 2 December 2017 (UTC)
  • Oppose Oppose When it comes to selecting admins ultimately I would trust the judgement of human editors over any algorithm. -- OlEnglish (Talk) 00:07, 3 December 2017 (UTC)
  • Oppose Oppose It is easy to detect many kind of bad edits. But it's technically impossible in a sufficient way to detect good people. This will hold for the next few years. So don't let us waste time in such topics. -- seth (talk) 10:35, 3 December 2017 (UTC)
  • Oppose Oppose--Per above.Winged Blades of Godric (talk) 16:23, 3 December 2017 (UTC)
  • Oppose Oppose - IMHO humans should pick and select the suitable candidates - Not bots and all that, (If they run for RFA and it's instantly SNOWCLOSED then that really wont look good on you or the project). –Davey2010Talk 15:09, 4 December 2017 (UTC)
  • Oppose Oppose Most likely it only identifies dull candidates, not the good ones. The Banner (talk) 16:22, 4 December 2017 (UTC)
  • Oppose Oppose Humans need to do this job.-Bryanrutherford0 (talk) 17:32, 5 December 2017 (UTC)
  • Oppose Oppose There will indeed come a time when the number of candidates no longer compensates the attrition, but not for anytime soon. Kudpung (talk) 20:08, 6 December 2017 (UTC)
  • GA candidate.svg Weak support Support as long as we use machine learning technology and it only gets a list of a few BLATANTLY satisfactory Admin candidates. Mr. Guye (talk) 23:17, 7 December 2017 (UTC)
  • Oppose Oppose, unfortunately. Anything simple would not work as simple definition of what is a good admin does not exist. I can imagine a very complex solution where interactions (messages, edits/reverts etc.) of each user are studied and compared to patterns of previously successful admins, but this would be probably too complex to develop for a rather limited impact. In the end most editors have a few names of good potential admin candidates, and this would be way more impactful than a complex tool — NickK (talk) 20:13, 8 December 2017 (UTC)
  • Support Support Zppix (talk) 20:55, 10 December 2017 (UTC)