Community Wishlist Survey 2017/Admins and stewards
Extend global blocks to named accounts
- 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.
- Phabricator tickets: phab:T17294
- Proposer: Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 09:22, 9 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]- 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: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)
- 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:T17294. MER-C (talk) 04:00, 13 November 2017 (UTC)
Voting
[edit]- Support a little --Liuxinyu970226 (talk) 12:48, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:34, 28 November 2017 (UTC)
- Support Winston Spencer (talk) 13:10, 30 November 2017 (UTC)
- Support Terra ❤ (talk) 06:33, 2 December 2017 (UTC)
- 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 Ciao • Bestoernesto • ✉ 02:23, 4 December 2017 (UTC)
- 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
- 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:
- Phabricator tickets: T180279 - Enable 2FA normal login. Also semi-related: T137076 - Add OAuth support for Huggle and T178818 - --login option - support bot passwords
- Proposer: Raystorm (talk) 17:16, 14 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]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)
- BotPasswords already work with Huggle, AWB, etc. See w:en:Wikipedia:Using AWB with 2FA for some examples. — xaosflux Talk 20:42, 27 November 2017 (UTC)
Voting
[edit]- Oppose as unnecessary, just grab a password from Special:Botpasswords. MER-C (talk) 01:58, 28 November 2017 (UTC)
- Oppose Per MER-C, Botpassword is much easier than 2FA. --Liuxinyu970226 (talk) 12:49, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:34, 28 November 2017 (UTC)
- Oppose Unneeded, per above. Nihlus 04:49, 30 November 2017 (UTC)
- Support DAVID MAS V. (talk) 11:32, 30 November 2017 (UTC)
- Oppose per above --Terra ❤ (talk) 06:34, 2 December 2017 (UTC)
- Oppose Botpassword is easier by orders:)Winged Blades of Godric (talk) 16:22, 3 December 2017 (UTC)
- Support Tiputini (talk) 07:12, 4 December 2017 (UTC)
- Support GoboFR (talk) 10:55, 11 December 2017 (UTC)
Allow further user block options ("can edit XY" etc.)
- 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:
- Phabricator tickets: phab:T119795, phab:T27400, phab:T6995, phab:T16636, phab:T18644
- Proposer: → «« Man77 »» [de] 19:36, 14 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]- 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)
- 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)
- The Community Tech team would like to merge this and Community Wishlist Survey 2017/Admins and stewards/Specialised blocks. Are you fine with us doing that? /Johan (WMF) (talk) 17:47, 20 November 2017 (UTC)
- Here again: Yes, → «« Man77 »» [de] 17:24, 22 November 2017 (UTC)
- I've attempted to destill the two proposals and rephrase this one to contain the gist of both this proposal and Community Wishlist Survey 2017/Admins and stewards/Specialised blocks. Feel free to edit as necessary if you think I've damaged it, it's a suggestion. /Johan (WMF) (talk) 02:33, 25 November 2017 (UTC)
- Here again: Yes, → «« Man77 »» [de] 17:24, 22 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
[edit]- Support Reception123 (talk) 20:01, 27 November 2017 (UTC)
- Support Goldzahn (talk) 23:02, 27 November 2017 (UTC)
- Support Matiia (talk) 00:37, 28 November 2017 (UTC)
- Support - yona B. (D) 05:47, 28 November 2017 (UTC)
- Support —viciarg414 08:11, 28 November 2017 (UTC)
- Support --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 08:13, 28 November 2017 (UTC)
- Support β16 - (talk) 10:09, 28 November 2017 (UTC)
- Support Jo-Jo Eumerus (talk, contributions) 10:28, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:37, 28 November 2017 (UTC)
- Support Jianhui67 talk★contribs 14:09, 28 November 2017 (UTC)
- Support Jc86035 (talk) 14:43, 28 November 2017 (UTC)
- Support Sakretsu (talk) 17:03, 28 November 2017 (UTC)
- Support Yiyi (talk) 18:50, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:26, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:34, 28 November 2017 (UTC)
- Support MichaelSchoenitzer (talk) 00:15, 29 November 2017 (UTC)
- Support Drm310 (talk) 19:08, 29 November 2017 (UTC)
- Support Niklem (talk) 19:11, 29 November 2017 (UTC)
- Support --Christian Ferrer (talk) 19:18, 29 November 2017 (UTC)
- Support Or even namespace blocks. --Ruthven (talk) 19:34, 29 November 2017 (UTC)
- Support EVinente (talk) 19:43, 29 November 2017 (UTC)
- Support Aunva6 (talk) 20:10, 29 November 2017 (UTC)
- Support Pallanz (talk) 20:13, 29 November 2017 (UTC)
- 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 – Meiræ 21:55, 29 November 2017 (UTC)
- Support MGChecker (talk) 22:02, 29 November 2017 (UTC)
- 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 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 Winston (talk) 08:38, 30 November 2017 (UTC)
- Support Winston Spencer (talk) 13:11, 30 November 2017 (UTC)
- Support Strongly needed. —DerHexer (Talk) 16:08, 30 November 2017 (UTC)
- Support Laurel Lodged (talk) 19:38, 30 November 2017 (UTC)
- Support Tropicalkitty (talk) 20:07, 30 November 2017 (UTC)
- Support Dromedar61 (talk) 20:25, 30 November 2017 (UTC)
- Support Daniel Case (talk) 00:32, 1 December 2017 (UTC)
- Support DonBarredora (talk) 01:24, 1 December 2017 (UTC)
- Support Good idea. AndyAndyAndyAlbert (talk) 07:59, 1 December 2017 (UTC)
- Support HaythamAbulela 18:16, 1 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:54, 1 December 2017 (UTC)
- Support but perhaps not with Community Tech per MER-C. J947 03:33, 2 December 2017 (UTC)
- Support Operator873 (talk) 05:35, 2 December 2017 (UTC)
- Support Wostr (talk) 10:10, 2 December 2017 (UTC)
- Support --Bubo 容 11:43, 2 December 2017 (UTC)
- Support ~Cybularny Speak? 11:57, 2 December 2017 (UTC)
- Support Szoltys (talk) 12:02, 2 December 2017 (UTC)
- Support Ented (talk) 12:24, 2 December 2017 (UTC)
- Support → «« Man77 »» [de] 13:52, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:40, 2 December 2017 (UTC)
- Support Tacsipacsi (talk) 16:57, 2 December 2017 (UTC)
- Support TheCatalyst31 (talk) 16:58, 2 December 2017 (UTC)
- Support Otapka (talk) 18:43, 2 December 2017 (UTC)
- Support Kostas20142 (talk) 21:17, 2 December 2017 (UTC)
- Support Wiklol (talk) 21:24, 2 December 2017 (UTC)
- Support yes please, more granularity! Chris Keating (The Land) (talk) 21:33, 2 December 2017 (UTC)
- Support Sometimes a full block would be too heavy-handed. NinjaRobotPirate (talk) 07:24, 3 December 2017 (UTC)
- Support Mz7 (talk) 10:22, 3 December 2017 (UTC)
- Support -- seth (talk) 10:37, 3 December 2017 (UTC)
- Support -- Dolotta (talk) 13:59, 3 December 2017 (UTC)
- Support Winged Blades of Godric (talk) 16:22, 3 December 2017 (UTC)
- Support rxy (talk) 22:17, 3 December 2017 (UTC)
- 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 Ciao • Bestoernesto • ✉ 02:27, 4 December 2017 (UTC)
- 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 Jpcomic (talk) 10:22, 4 December 2017 (UTC)
- 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 Ronhjones (talk) 18:10, 4 December 2017 (UTC)
- Support Yeza (talk) 23:03, 4 December 2017 (UTC)
- 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 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 Ixocactus (talk) 01:37, 7 December 2017 (UTC)
- Support Chealer (talk) 03:51, 7 December 2017 (UTC)
- Support Ealdgyth (talk) 13:35, 7 December 2017 (UTC)
- Support X:: black ::X (talk) 14:38, 7 December 2017 (UTC)
- Support Ahm masum (talk) 21:17, 7 December 2017 (UTC)
- Support --jdx Re: 18:45, 8 December 2017 (UTC)
- 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 -- Amanda (aka DQ) 18:19, 10 December 2017 (UTC)
- Support Perrak (talk) 20:43, 10 December 2017 (UTC)
- Support Jnanaranjan sahu (talk) 06:38, 11 December 2017 (UTC)
- Support HakanIST (talk) 12:24, 11 December 2017 (UTC)
- Support Facenapalm (talk) 12:36, 11 December 2017 (UTC)
- Support — Luchesar • T/C 13:08, 11 December 2017 (UTC)
- Support Pxos (talk) 14:20, 11 December 2017 (UTC)
- Support --Meno25 (talk) 15:38, 11 December 2017 (UTC)
- Support Braveheart (talk) 16:48, 11 December 2017 (UTC)
- 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 KPFC 💬 17:15, 11 December 2017 (UTC)
U2F support for 2FA
- 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:
- Phabricator tickets: phab:T100373
- Proposer: Amir (talk) 12:01, 18 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]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
[edit]- Support Tgr (talk) 05:48, 28 November 2017 (UTC)
- 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 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 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 Thomas Obermair 4 (talk) 21:35, 28 November 2017 (UTC)
- Support 𝔊 (Gradzeichen Diſk✉Talk) 06:45, 29 November 2017 (UTC)
- Support I'd love to have this as an option for those who'd want to use it. —TheDJ (talk • contribs) 10:01, 29 November 2017 (UTC)
- 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 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 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 Winston Spencer (talk) 13:11, 30 November 2017 (UTC)
- Support WQL (talk) 09:51, 1 December 2017 (UTC)
- Support Eug (talk) 11:58, 1 December 2017 (UTC)
- Support Jacob Robertson (talk) 13:58, 1 December 2017 (UTC)
- Support Terra ❤ (talk) 06:39, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:41, 2 December 2017 (UTC)
- 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 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 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 Tiputini (talk) 07:13, 4 December 2017 (UTC)
- 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 —Alvaro Molina (✉ - ✔) 01:35, 5 December 2017 (UTC)
- Support as an alternative method. the wub "?!" 00:30, 6 December 2017 (UTC)
- Support with low priority.. Yohannvt (talk) 11:56, 6 December 2017 (UTC)
- Support Zppix (talk) 14:19, 7 December 2017 (UTC)
- Support Ahm masum (talk) 21:13, 7 December 2017 (UTC)
- 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 -- as optional of course NaBUru38 (talk) 22:34, 9 December 2017 (UTC)
Allow protection of multiple pages (from the same Category)
- 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:
- Proposer: Reception123 (talk) 06:34, 7 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]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
[edit]- Support David1010 (talk) 07:34, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:42, 28 November 2017 (UTC)
- Oppose No nuke buttons in a collaborative environment, please. --TMg 12:53, 28 November 2017 (UTC)
- Oppose There is no reason to replace ban with bulk protection.--YFdyh000 (talk) 13:21, 28 November 2017 (UTC)
- Support although this would probably only be suited for Commons and Wikidata. Jc86035 (talk) 14:44, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:27, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:36, 28 November 2017 (UTC)
- Support Shizhao (talk) 02:48, 29 November 2017 (UTC)
- 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 "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 Laurel Lodged (talk) 19:39, 30 November 2017 (UTC)
- Support Daniel Case (talk) 00:33, 1 December 2017 (UTC)
- Oppose per g and L736E. --Superchilum(talk to me!) 16:11, 1 December 2017 (UTC)
- Oppose There is no reason for protecting a whole section of Wikipedia. -Theklan (talk) 18:31, 1 December 2017 (UTC)
- Oppose per g. Wostr (talk) 10:12, 2 December 2017 (UTC)
- Oppose ~Cybularny Speak? 12:09, 2 December 2017 (UTC)
- Oppose Ented (talk) 12:27, 2 December 2017 (UTC)
- Oppose Could be very dangerous if works also for subcategories. --Termininja (talk) 15:28, 2 December 2017 (UTC)
- Oppose per g. —Tacsipacsi (talk) 17:00, 2 December 2017 (UTC)
- 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 Ciao • Bestoernesto • ✉ 02:29, 4 December 2017 (UTC)
- Oppose overkill --OlEnglish (Talk) 06:18, 4 December 2017 (UTC)
- 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 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 Zppix (talk) 14:19, 7 December 2017 (UTC)
Bring Special:Undelete to feature parity with live page histories
- Problem: Special:Undelete/PAGENAME and the corresponding API are clunky and cumbersome to use because of their limited functionality. To make it easier for admins on any project to deal with deleted content and achieve equivalent functionality to live page histories, the following should be implemented:
- Paging for Special:Undelete, so that long lists of deleted revisions don't take ages to load. And again, except for deleted title search.
- Add deleted title search to the API.
- Add date cutoffs, size diffs. Add the sizediffs to the API as well.
- I want to be able to compare non-adjacent deleted edits on the same page.
- I want to compare deleted content to live revisions under the same title, or live/deleted revisions for a different title. This is especially useful to check whether a page has been substantially reposted. I could do this via Special:Diff or the API... but deleted revision links should use "rev_id" not "page/timestamp". Not being able to easily discover the revid is a damn nuisance.
- Likewise, the undelete API should take a revid parameter that is a list of the revision IDs to be undeleted.
- Deletion log entries should be interspersed with the deleted revisions so I can easily see when a page was recreated. Edit summaries are an unreliable indicator of this.
- API alldeletedrevisions should be vectorized over adruser like API usercontribs is vectorized over ucuser.
- Proposer: MER-C (talk) 01:09, 8 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]- 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
[edit]- Support as proposer. MER-C (talk) 01:41, 28 November 2017 (UTC)
- Support Jenks24 (talk) 06:51, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:46, 28 November 2017 (UTC)
- Support Sadads (talk) 13:33, 28 November 2017 (UTC)
- Support — Arkanosis ✉ 13:50, 28 November 2017 (UTC)
- Support Jianhui67 talk★contribs 14:07, 28 November 2017 (UTC)
- Support yes please. Easily the thing that would have the most practical impact of any of these suggestions, even if it isn't the sexiest. TonyBallioni (talk) 17:19, 28 November 2017 (UTC)
- Support — Draceane talkcontrib. 17:50, 28 November 2017 (UTC)
- Support – Ajraddatz (talk) 20:31, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:27, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:36, 28 November 2017 (UTC)
- Support Carnildo (talk) 01:25, 29 November 2017 (UTC)
- Support Shizhao (talk) 02:48, 29 November 2017 (UTC)
- Support Shanmugamp7 (talk) 06:52, 29 November 2017 (UTC)
- Support Patar knightchat/contributions 20:42, 29 November 2017 (UTC)
- Support Seb26 (talk) 21:45, 29 November 2017 (UTC)
- Support MGChecker (talk) 22:03, 29 November 2017 (UTC)
- Support — putnik 01:26, 30 November 2017 (UTC)
- Support – DMacks (talk) 04:19, 30 November 2017 (UTC)
- Support Nihlus 04:51, 30 November 2017 (UTC)
- Support Premeditated Chaos (talk) 13:16, 1 December 2017 (UTC)
- Support Jo-Jo Eumerus (talk, contributions) 11:13, 2 December 2017 (UTC)
- Support ~Cybularny Speak? 12:08, 2 December 2017 (UTC)
- Support —MarcoAurelio (talk) 15:25, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:45, 2 December 2017 (UTC)
- Support I would also like to view a version (i.e. parsed content, not wikicode) without two page loads, with a separate link or by using live preview if the user has selected it in their settings. Tacsipacsi (talk) 17:17, 2 December 2017 (UTC)
- Support Matěj Suchánek (talk) 21:07, 2 December 2017 (UTC)
- Support Very definitely, yes, this would be a great help. Boing! said Zebedee (talk) 21:42, 2 December 2017 (UTC)
- Support --Philippe (talk) 21:47, 2 December 2017 (UTC)
- Support Yes, please Vanamonde93 (talk) 06:21, 3 December 2017 (UTC)
- Support Disruption that involves viewing deleted articles is a huge pain to investigate. NinjaRobotPirate (talk) 07:37, 3 December 2017 (UTC)
- Support Long overdue! Waldir (talk) 10:14, 3 December 2017 (UTC)
- Support Mz7 (talk) 10:20, 3 December 2017 (UTC)
- Support Will be quite helpful to sysops:) Winged Blades of Godric (talk) 16:24, 3 December 2017 (UTC)
- Support B20180 (talk) 19:55, 3 December 2017 (UTC)
- Support Ciao • Bestoernesto • ✉ 02:30, 4 December 2017 (UTC)
- Support OlEnglish (Talk) 06:21, 4 December 2017 (UTC)
- Support Ronhjones (talk) 18:17, 4 December 2017 (UTC)
- Support Yeza (talk) 23:08, 4 December 2017 (UTC)
- Support -Bryanrutherford0 (talk) 17:31, 5 December 2017 (UTC)
- Support Lofhi (talk) 17:56, 5 December 2017 (UTC)
- Support JAn Dudík (talk) 08:09, 7 December 2017 (UTC)
- Support OJJ (talk) 17:46, 7 December 2017 (UTC)
- Support Ahm masum (talk) 21:11, 7 December 2017 (UTC)
- Support My first priority is being able to compare two different versions of a deleted page — NickK (talk) 20:34, 8 December 2017 (UTC)
- Support Ruslik (talk) 13:00, 10 December 2017 (UTC)
- Support Perrak (talk) 20:45, 10 December 2017 (UTC)
- Support — Luchesar • T/C 13:09, 11 December 2017 (UTC)
Merging files will include merging in file history too
- 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)
- Translations: none yet
Discussion
[edit]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
[edit]- Support IKhitron (talk) 18:13, 27 November 2017 (UTC)
- Support - yona B. (D) 05:48, 28 November 2017 (UTC)
- Support Jenks24 (talk) 06:52, 28 November 2017 (UTC)
- Support David1010 (talk) 07:35, 28 November 2017 (UTC)
- Support Mahir256 (talk) 08:30, 28 November 2017 (UTC)
- Support β16 - (talk) 10:14, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:46, 28 November 2017 (UTC)
- Support TMg 12:54, 28 November 2017 (UTC)
- Support Consulnico (talk) 15:29, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:36, 28 November 2017 (UTC)
- Support Shizhao (talk) 02:49, 29 November 2017 (UTC)
- Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:24, 29 November 2017 (UTC)
- Support --g (talk) 00:23, 30 November 2017 (UTC)
- Support--L736Etell me 07:54, 30 November 2017 (UTC)
- Support Veneziano (talk) 14:07, 30 November 2017 (UTC)
- Support Dromedar61 (talk) 20:29, 30 November 2017 (UTC)
- Support --Superchilum(talk to me!) 16:12, 1 December 2017 (UTC)
- Support HaythamAbulela 18:13, 1 December 2017 (UTC)
- Support Theklan (talk) 18:31, 1 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:52, 1 December 2017 (UTC)
- Support --Honischboy (talk) 21:22, 1 December 2017 (UTC)
- Support ~Cybularny Speak? 12:05, 2 December 2017 (UTC)
- Support Петър Петров (talk) 14:59, 2 December 2017 (UTC)
- Support Termininja (talk) 15:21, 2 December 2017 (UTC)
- Support —MarcoAurelio (talk) 15:26, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:31, 2 December 2017 (UTC)
- Support Waldir (talk) 10:18, 3 December 2017 (UTC)
- Support Talmoryair (talk) 17:06, 3 December 2017 (UTC)
- Support Ronhjones (talk) 18:17, 4 December 2017 (UTC)
- Support Yeza (talk) 23:10, 4 December 2017 (UTC)
- Support --jdx Re: 18:50, 8 December 2017 (UTC)
- Support — NickK (talk) 20:34, 8 December 2017 (UTC)
- Support NaBUru38 (talk) 22:35, 9 December 2017 (UTC)
- Support Ruslik (talk) 12:27, 10 December 2017 (UTC)
- Support -- Amanda (aka DQ) 18:20, 10 December 2017 (UTC)
- Oppose Strange! What if files histories are rich and interleaving? There will be a mess after merge! --Infovarius (talk) 13:13, 11 December 2017 (UTC)
- Support--KRLS (talk) 14:11, 11 December 2017 (UTC)
Allow Special:Nuke to delete imported pages
- 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.
- Phabricator tickets: T11120
- Proposer: Reception123 (talk) 12:18, 11 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]Voting
[edit]- Support --Liuxinyu970226 (talk) 12:41, 28 November 2017 (UTC)
- Support Matěj Suchánek (talk) 14:46, 28 November 2017 (UTC)
- Support Jc86035 (talk) 14:52, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:36, 28 November 2017 (UTC)
- Support Shizhao (talk) 02:50, 29 November 2017 (UTC)
- Support AndyAndyAndyAlbert (talk) 08:05, 1 December 2017 (UTC)
- Support HaythamAbulela 18:14, 1 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:52, 1 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:31, 2 December 2017 (UTC)
- Support Kostas20142 (talk) 21:12, 2 December 2017 (UTC)
- Support ukexpat (talk) 01:25, 3 December 2017 (UTC)
- Support Ciao • Bestoernesto • ✉ 02:32, 4 December 2017 (UTC)
- Support Guycn2 · ☎ 19:13, 4 December 2017 (UTC)
- Strong oppose and abolish Special:Nuke. Far too much power in the hands of administrators. Mr. Guye (talk) 23:09, 7 December 2017 (UTC)
- Support — NickK (talk) 20:35, 8 December 2017 (UTC)
- Support Zppix (talk) 20:56, 10 December 2017 (UTC)
Make 2FA easier to use
- 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:
- Phabricator tickets:
- Proposer: Deryck C. 22:05, 9 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]- 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 (talk • contribs) 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 alsoSpecialPage::getLoginSecurityLevel()
/SpecialPage::checkLoginSecurityLevel()
). Anomie (talk) 15:27, 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
- 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
[edit]- Support Reception123 (talk) 20:06, 27 November 2017 (UTC)
- Support — xaosflux Talk 20:41, 27 November 2017 (UTC)
- Support Strainu (talk) 22:52, 27 November 2017 (UTC)
- Support —viciarg414 08:09, 28 November 2017 (UTC)
- Support ·addshore· talk to me! 10:35, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:46, 28 November 2017 (UTC)
- Support — Arkanosis ✉ 13:28, 28 November 2017 (UTC)
- Support Sadads (talk) 13:31, 28 November 2017 (UTC)
- Support - Mailer Diablo (talk) 15:17, 28 November 2017 (UTC)
- Support Owula kpakpo (talk) 15:42, 28 November 2017 (UTC)
- Support AFAIK it conflict with AWB and the mobile app. It should be a priority. --Sannita - not just another it.wiki sysop 15:48, 28 November 2017 (UTC)
- Support Husky (talk) 16:13, 28 November 2017 (UTC)
- Support --Sakretsu (talk) 16:59, 28 November 2017 (UTC)
- Support - Darwin Ahoy! 17:01, 28 November 2017 (UTC)
- Support — Luchesar • T/C 20:01, 28 November 2017 (UTC)
- Support Laboramus (talk) 20:28, 28 November 2017 (UTC)
- Support – Ajraddatz (talk) 20:29, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:31, 28 November 2017 (UTC)
- Support 𝔊 (Gradzeichen Diſk✉Talk) 06:43, 29 November 2017 (UTC)
- Support Shanmugamp7 (talk) 06:52, 29 November 2017 (UTC)
- Support Without polish a feature is broken. time to polish. —TheDJ (talk • contribs) 10:02, 29 November 2017 (UTC)
- Support Joshualouie711 (talk) 19:32, 29 November 2017 (UTC)
- Support EVinente (talk) 19:44, 29 November 2017 (UTC)
- Support Patar knightchat/contributions 20:44, 29 November 2017 (UTC)
- Support Javad|Talk (8 Azar 1396) 21:17, 29 November 2017 (UTC)
- Support Mhollo (talk) 23:19, 29 November 2017 (UTC)
- Support George Ho (talk) 01:13, 30 November 2017 (UTC)
- Support — putnik 01:29, 30 November 2017 (UTC)
- Support Nihlus 04:52, 30 November 2017 (UTC)
- Support Another Yes Please. — regards, Revi 06:16, 30 November 2017 (UTC)
- Support --OrsolyaVirág (talk) 19:34, 30 November 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:53, 1 December 2017 (UTC)
- Support Ckoerner (talk) 21:23, 1 December 2017 (UTC)
- Support Amir (talk) 00:45, 2 December 2017 (UTC)
- Support J947 03:39, 2 December 2017 (UTC)
- Support Terra ❤ (talk) 06:28, 2 December 2017 (UTC)
- Support Wostr (talk) 10:02, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:32, 2 December 2017 (UTC)
- Support Петър Петров (talk) 16:04, 2 December 2017 (UTC)
- Support TheCatalyst31 (talk) 16:51, 2 December 2017 (UTC)
- Support Kostas20142 (talk) 21:13, 2 December 2017 (UTC)
- Support --Philippe (talk) 21:15, 2 December 2017 (UTC)
- Support I have 2FA on my account and it's definitely not the most intuitive of things - anything that makes it easier to be taken up more widely has to be a good thing. Boing! said Zebedee (talk) 21:23, 2 December 2017 (UTC)
- Support I don't have 2FA enabled largely because or ease-of-use considerations. Chris Keating (The Land) (talk) 21:29, 2 December 2017 (UTC)
- Support [stwalkerster|talk] 22:35, 2 December 2017 (UTC)
- Support OlEnglish (Talk) 23:56, 2 December 2017 (UTC)
- Support I see no reason why this could hurt, and plenty for why it could help. Vanamonde93 (talk) 05:42, 3 December 2017 (UTC)
- Support Pretty please. Especially the recovery / disabling procedure needs to provide alternatives for when there are problems with the default flow (e.g. lost mobile device). Waldir (talk) 10:17, 3 December 2017 (UTC)
- Support Winged Blades of Godric (talk) 16:25, 3 December 2017 (UTC)
- Support rxy (talk) 22:19, 3 December 2017 (UTC)
- Support Jon Kolbert (talk) 16:37, 4 December 2017 (UTC)
- Support Yeza (talk) 23:12, 4 December 2017 (UTC)
- Support (Non-admin / steward) With the 2FA-for-all requests (which I have supported), this proposal is also important. Cocohead781 (talk) 03:27, 6 December 2017 (UTC)
- Support JAn Dudík (talk) 13:10, 6 December 2017 (UTC)
- Support J36miles (talk) 21:41, 7 December 2017 (UTC)
- Support per The Land — NickK (talk) 20:36, 8 December 2017 (UTC)
- Support Ruslik (talk) 12:29, 10 December 2017 (UTC)
- Support Steinsplitter (talk) 14:13, 10 December 2017 (UTC)
- Support Ragesoss (talk) 20:05, 10 December 2017 (UTC)
- Support Akau (talk) 05:55, 11 December 2017 (UTC)
- Support Ed [talk] [en] 13:51, 11 December 2017 (UTC)
Create a global whitelist for global autoblocks
- 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:
- Proposer: Vituzzu (talk) 20:43, 8 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]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)
- I can't see why this is needed given that we have both global and local IP block exemption systems. Additionally we have "whitelists" already locally en:Special:ListUsers/ipblock-exempt, and (maybe?) globally Special:GlobalBlockWhitelist. A Den Jentyl Ettien Avel Dysklyver (talk) 16:25, 9 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)
- 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)
- Did you ever dealt with spambots floods or our loyal LTAs? --Vituzzu (talk) 10:07, 17 November 2017 (UTC)
- By not blocking entire subnets because they include "several open proxies"? --Tgr (WMF) (talk) 00:55, 17 November 2017 (UTC)
Voting
[edit]- Support Stryn (talk) 18:58, 27 November 2017 (UTC)
- Support Matiia (talk) 00:37, 28 November 2017 (UTC)
- Support Defender (talk) 01:39, 28 November 2017 (UTC)
- Support - yona B. (D) 05:46, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:47, 28 November 2017 (UTC)
- Support Owula kpakpo (talk) 15:43, 28 November 2017 (UTC)
- Support Sakretsu (talk) 17:06, 28 November 2017 (UTC)
- Support --Sannita - not just another it.wiki sysop 19:31, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:24, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:32, 28 November 2017 (UTC)
- Support Gbear605 (talk) 21:37, 28 November 2017 (UTC)
- Support Shizhao (talk) 02:45, 29 November 2017 (UTC)
- Support Shanmugamp7 (talk) 06:50, 29 November 2017 (UTC)
- Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 10:24, 29 November 2017 (UTC)
- Support --Ruthven (talk) 19:33, 29 November 2017 (UTC)
- Support --g (talk) 00:24, 30 November 2017 (UTC)
- Support --隼鷹 (talk) 05:35, 30 November 2017 (UTC)
- Support--L736Etell me 07:55, 30 November 2017 (UTC)
- Support Dromedar61 (talk) 20:30, 30 November 2017 (UTC)
- Support Daniel Case (talk) 00:36, 1 December 2017 (UTC)
- Support ~Cybularny Speak? 12:06, 2 December 2017 (UTC)
- Support —MarcoAurelio (talk) 15:24, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:32, 2 December 2017 (UTC)
- Support WikiMasterGhibif (talk) 23:42, 2 December 2017 (UTC)
- Support Ciao • Bestoernesto • ✉ 02:33, 4 December 2017 (UTC)
- Support Yeza (talk) 23:14, 4 December 2017 (UTC)
- Support X:: black ::X (talk) 14:10, 7 December 2017 (UTC)
- Support Ahm masum (talk) 21:15, 7 December 2017 (UTC)
- Support Wikimedia projects ally with other open content, information access advocacy projects. There are high profile activists who decline to send their communities to Wikimedia projects because of the lack of personal security we offer. We need to have predictable technical and social infrastructure aligned with each other to provide editing access to registered accounts which need to use VPNs. VPN use is a necessity for some people, not a bothersome luxury, and we need to set a good example for the world and with our partners by making it easy to grant these rights. Blue Rasberry (talk) 15:20, 9 December 2017 (UTC)
- Support Ruslik (talk) 12:32, 10 December 2017 (UTC)
- Support --HakanIST (talk) 12:27, 11 December 2017 (UTC)
Make AbuseFilter easy to use for nontechnical admins by making filter editing more visual
- 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)
- Translations: none yet
Discussion
[edit]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)
- 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)
- 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
[edit]- Support I've seen some people struggle with AbuseFilter if they don't have technical knowledge of regex, so this is a definite + Reception123 (talk) 18:29, 27 November 2017 (UTC)
- Support Tgr is right! It is set up for tech people and those actually want to use it. OrsolyaVirág (talk) 18:55, 27 November 2017 (UTC)
- Support Stryn (talk) 18:59, 27 November 2017 (UTC)
- Support Rschen7754 19:22, 27 November 2017 (UTC)
- Support Tacsipacsi (talk) 20:11, 27 November 2017 (UTC)
- Support It would be very helpful Kuailong (talk) 22:29, 27 November 2017 (UTC)
- Support Jc86035 (talk) 01:17, 28 November 2017 (UTC)
- Support as proposer. Tgr (talk) 05:29, 28 November 2017 (UTC)
- Support - yona B. (D) 05:47, 28 November 2017 (UTC)
- Support β16 - (talk) 10:06, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:47, 28 November 2017 (UTC)
- Support YFdyh000 (talk) 13:16, 28 November 2017 (UTC)
- Support Sadads (talk) 13:32, 28 November 2017 (UTC)
- Support Jianhui67 talk★contribs 14:10, 28 November 2017 (UTC)
- Support Consulnico (talk) 15:30, 28 November 2017 (UTC)
- Support Owula kpakpo (talk) 15:44, 28 November 2017 (UTC)
- Support Sakretsu (talk) 17:02, 28 November 2017 (UTC)
- Support – Ajraddatz (talk) 20:30, 28 November 2017 (UTC)
- Support —Alvaro Molina (✉ - ✔) 20:31, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:24, 28 November 2017 (UTC)
- Support Chico Venancio (talk) 21:29, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:32, 28 November 2017 (UTC)
- Support Sjoerd de Bruin (talk) 22:03, 28 November 2017 (UTC)
- Support IKhitron (talk) 22:53, 28 November 2017 (UTC)
- Support Good idea. Jules78120 (talk) 00:09, 29 November 2017 (UTC)
- Support Shizhao (talk) 02:46, 29 November 2017 (UTC)
- Support Paucabot (talk) 06:45, 29 November 2017 (UTC)
- Support--Shanmugamp7 (talk) 06:49, 29 November 2017 (UTC)
- Support JAn Dudík (talk) 10:46, 29 November 2017 (UTC)
- Support --Eurodyne (talk) 19:35, 29 November 2017 (UTC)
- Support EVinente (talk) 19:43, 29 November 2017 (UTC)
- Support Defender (talk) 20:02, 29 November 2017 (UTC)
- Support Patar knightchat/contributions 20:43, 29 November 2017 (UTC)
- Support Keith D (talk) 20:57, 29 November 2017 (UTC)
- Support – Meiræ 21:59, 29 November 2017 (UTC)
- Support MGChecker (talk) 22:03, 29 November 2017 (UTC)
- Support --g (talk) 00:25, 30 November 2017 (UTC)
- Support --L736Etell me 07:57, 30 November 2017 (UTC)
- Support, also to reduce chances of error even among the clueful. JzG (talk) 15:23, 30 November 2017 (UTC)
- Support Good idea. Vachovec1 (talk) 17:28, 30 November 2017 (UTC)
- Support Trizek from FR 20:00, 30 November 2017 (UTC)
- Support Dromedar61 (talk) 20:31, 30 November 2017 (UTC)
- Support --Superchilum(talk to me!) 16:13, 1 December 2017 (UTC)
- Support Bencemac (talk) 17:42, 1 December 2017 (UTC)
- Support Pamputt (talk) 18:58, 1 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:53, 1 December 2017 (UTC)
- Support Ckoerner (talk) 21:23, 1 December 2017 (UTC)
- Support Amir (talk) 00:46, 2 December 2017 (UTC)
- Support ~Cybularny Speak? 12:11, 2 December 2017 (UTC)
- Support I do not really understand why the VE has been developped with emphasis while the filtering tool or sparql is less self-explanatory than the source code for wiki pages has ever been → «« Man77 »» [de] 13:49, 2 December 2017 (UTC)
- Support Emir of Wikipedia (talk) 15:33, 2 December 2017 (UTC)
- Support --MARKELLOSLeave me a message 17:52, 2 December 2017 (UTC)
- Support --PallertiRabbit Hole 18:46, 2 December 2017 (UTC)
- Support Yes, please. I'm one of the "non-technical admins" who deals with a lot of vandals and spammers. I've never touched an abuse-filter for fear of breaking it. While acknowledging that an "improvement" may end up not helping me, I think any effort in this direction would be worthwhile. Oh, and it would help a lot if we had a guide to editing abuse filters, too. Vanamonde93 (talk) 05:53, 3 December 2017 (UTC)
- Support Slemi (talk) 05:58, 3 December 2017 (UTC)
- Support Waldir (talk) 10:13, 3 December 2017 (UTC)
- Support Winged Blades of Godric (talk) 16:21, 3 December 2017 (UTC)
- Support ★ Anoop / ಅನೂಪ್ ✉ © 17:56, 3 December 2017 (UTC)
- Support rxy (talk) 22:17, 3 December 2017 (UTC)
- Support Guycn2 · ☎ 19:15, 4 December 2017 (UTC)
- Support Yeza (talk) 23:15, 4 December 2017 (UTC)
- Support Lofhi (talk) 17:58, 5 December 2017 (UTC)
- Support →Spiritia 19:20, 5 December 2017 (UTC)
- Support Ixocactus (talk) 01:39, 7 December 2017 (UTC)
- Support Ahm masum (talk) 21:16, 7 December 2017 (UTC)
- Support Unfortunately there are too many people who have good ideas on improving AbuseFilters but are not technical enough to write rules for it, and too few people who both have good ideas and can write AbuseFilter rules — NickK (talk) 19:37, 8 December 2017 (UTC)
- Support --Szilas (talk) 19:41, 9 December 2017 (UTC)
- Support - Akela (talk) 22:53, 9 December 2017 (UTC)
- Support --EniPort (talk) 23:31, 9 December 2017 (UTC)
- Support --Hkoala (talk) 05:00, 10 December 2017 (UTC)
- Support -- User: Perhelion 13:31, 10 December 2017 (UTC)
- Support Steinsplitter (talk) 14:13, 10 December 2017 (UTC)
- Support -- Hungarikusz Firkász (talk) 11:21, 11 December 2017 (UTC)
- Support --Tobias1984 (talk) 11:40, 11 December 2017 (UTC)
- Support --HakanIST (talk) 12:25, 11 December 2017 (UTC)
- Support — Luchesar • T/C 13:12, 11 December 2017 (UTC)
- Support Winston (talk) 13:15, 11 December 2017 (UTC)
- Support Hirannor (talk) 14:10, 11 December 2017 (UTC)
- Support --Rlevente (talk) 14:42, 11 December 2017 (UTC)
- Support Szalax (talk) 16:02, 11 December 2017 (UTC)
- Support Hunyadym (talk) 17:13, 11 December 2017 (UTC)
- Support Samat (talk) 17:39, 11 December 2017 (UTC)
Implement delete and move warning for associated talk pages
- 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.
- Phabricator tickets: phab:T12814
- Proposer: Jenks24 (talk) 11:13, 7 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]- 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
[edit]- Support as nom Jenks24 (talk) 06:50, 28 November 2017 (UTC)
- Support --Liuxinyu970226 (talk) 12:47, 28 November 2017 (UTC)
- Support Matěj Suchánek (talk) 14:45, 28 November 2017 (UTC)
- Support, per above. TonyBallioni (talk) 17:17, 28 November 2017 (UTC)
- Support Gripweed (talk) 21:24, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:32, 28 November 2017 (UTC)
- Support Shizhao (talk) 02:46, 29 November 2017 (UTC)
- Support We don't like dozens of orphaned talkpages. JAn Dudík (talk) 10:47, 29 November 2017 (UTC)
- Support —TheDJ (talk • contribs) 17:24, 29 November 2017 (UTC)
- Support Drm310 (talk) 19:08, 29 November 2017 (UTC)
- Support Pallanz (talk) 20:12, 29 November 2017 (UTC)
- Support Bardia90 (talk) 20:14, 29 November 2017 (UTC)
- Support Andrew (talk) 20:14, 29 November 2017 (UTC)
- Support --g (talk) 23:39, 29 November 2017 (UTC)
- Support Nihlus 04:53, 30 November 2017 (UTC)
- Support --L736Etell me 07:59, 30 November 2017 (UTC)
- Support Dromedar61 (talk) 20:32, 30 November 2017 (UTC)
- Support DonBarredora (talk) 01:26, 1 December 2017 (UTC)
- Support --Superchilum(talk to me!) 16:14, 1 December 2017 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 20:53, 1 December 2017 (UTC)
- Support Wostr (talk) 10:06, 2 December 2017 (UTC)
- Support ~Cybularny Speak? 12:11, 2 December 2017 (UTC)
- Support Tacsipacsi (talk) 17:35, 2 December 2017 (UTC)
- Support I've been hit a few times with the "Where did the talk page go?" thing. Boing! said Zebedee (talk) 21:25, 2 December 2017 (UTC)
- Support OlEnglish (Talk) 00:03, 3 December 2017 (UTC)
- Support Mariusmm (talk) 01:40, 3 December 2017 (UTC)
- Support Vanamonde93 (talk) 05:55, 3 December 2017 (UTC)
- Support -- seth (talk) 10:28, 3 December 2017 (UTC)
- Support Winged Blades of Godric (talk) 16:21, 3 December 2017 (UTC)
- Support Would be great feature to have, I run into this problem when I create a draft talk page at enwiki (to mark belonging to wikiprojects) and then someone deletes the draft but not its talk page. Gryllida 00:28, 4 December 2017 (UTC)
- Support Jpcomic (talk) 10:14, 4 December 2017 (UTC)
- Support Ronhjones (talk) 18:20, 4 December 2017 (UTC)
- Support Lofhi (talk) 17:58, 5 December 2017 (UTC)
- Support Kudpung (talk) 19:55, 6 December 2017 (UTC)
- Support Zppix (talk) 14:21, 7 December 2017 (UTC)
- Support Ahm masum (talk) 21:18, 7 December 2017 (UTC)
- Support I hate seeing this. Mr. Guye (talk) 23:11, 7 December 2017 (UTC)
- Support Julia\talk 10:33, 8 December 2017 (UTC)
- Support --jdx Re: 18:41, 8 December 2017 (UTC)
- Support, those oprhaned talk pages are really difficult to manage — NickK (talk) 19:39, 8 December 2017 (UTC)
- Support Ruslik (talk) 12:33, 10 December 2017 (UTC)
- Support -- User: Perhelion 13:32, 10 December 2017 (UTC)
- Support — Luchesar • T/C 13:12, 11 December 2017 (UTC)
- Support --Meno25 (talk) 15:40, 11 December 2017 (UTC)
Automatic detection of admin candidates
- 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:
- Proposer: The Anome (talk) 00:46, 17 November 2017 (UTC)
- Translations: none yet
Discussion
[edit]- 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
[edit]- Oppose This proposal has limited impact as a project-specific problem. MER-C (talk) 01:59, 28 November 2017 (UTC)
- Oppose Per MER-C, too much unnecessary. --Liuxinyu970226 (talk) 12:41, 28 November 2017 (UTC)
- 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 --Gripweed (talk) 21:26, 28 November 2017 (UTC)
- Support Thomas Obermair 4 (talk) 21:33, 28 November 2017 (UTC)
- Oppose IKhitron (talk) 22:55, 28 November 2017 (UTC)
- 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 Andrew (talk) 20:14, 29 November 2017 (UTC)
- 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 I don't see how anything good can come of this. Nihlus 04:48, 30 November 2017 (UTC)
- 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 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 this cannot be done in automatic or even semi-automatic mode. --Superchilum(talk to me!) 16:14, 1 December 2017 (UTC)
- Oppose Wostr (talk) 10:07, 2 December 2017 (UTC)
- Oppose --Termininja (talk) 15:32, 2 December 2017 (UTC)
- Support Otapka (talk) 18:41, 2 December 2017 (UTC)
- Oppose Admins should be recruited/nominated by the community, not a bot. Matěj Suchánek (talk) 21:04, 2 December 2017 (UTC)
- Oppose per the opposes above. Boing! said Zebedee (talk) 21:22, 2 December 2017 (UTC)
- Support WikiMasterGhibif (talk) 23:42, 2 December 2017 (UTC)
- 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 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--Per above.Winged Blades of Godric (talk) 16:23, 3 December 2017 (UTC)
- 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 Most likely it only identifies dull candidates, not the good ones. The Banner (talk) 16:22, 4 December 2017 (UTC)
- Oppose Humans need to do this job.-Bryanrutherford0 (talk) 17:32, 5 December 2017 (UTC)
- 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)
- 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, 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 Zppix (talk) 20:55, 10 December 2017 (UTC)