2017 Community Wishlist Survey/Admins and stewards

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

2017 Community Wishlist Survey

Admins and stewards
14 proposals, 35 contributors

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

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:
  • Proposer: Vituzzu (talk) 20:43, 8 November 2017 (UTC)

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)
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)

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.
  • Proposer: Jenks24 (talk) 11:13, 7 November 2017 (UTC)

Discussion[edit]

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[edit]

Specialised blocks

Edit proposal/discussion

  • Problem: Currently the one way administrators can block users is by taking away all editing privileges, this is regardless of what caused the block in the first place, someone can be a good content editor but less than civil in the talk pages, or someone can be good at discussing things in talk pages but revert war in the articles themselves.
  • Who would benefit: Everyone, as content editors wouldn’t be prevented from continuing to improve content and metapedians who are lousy at content editing can continue to give good comments about the content itself.
  • Proposed solution: Blocks that exclusively apply to certain features, for example “Talk:XXX” blocks for users who have abused their ability to edit talk pages, or blocks that only apply to mainspace articles, or “Wikipedia:XXX”/”Commons:XXX” but not restrict uploading privileges or the the other way around where good content editors add copyrighted images be restricted from uploading exclusively, for sockpuppetry this could be account creation, or restricting only a single account to edit on an IP, for e-mail abuses this could only be disallowing that particular user to e-mail other users, Etc.
  • More comments: Currently the editor retention is low, after having experienced non-stop (and still ongoing) threats and insults (especially in the IRC) purely based on the fact that I'm a blocked editor I don't find this exodus surprising, one of the reason why people leave is because all editing privileges are revoked with a block and topic bans are a lot rarer than blocks even if many blocks are based on similar reasons.

Well, the reason I want this to be a thing is because there was a global lock 🔒 requested for a photographer who’s content I really like, on September 1st I drafted this message for Wikimedia Commons:

“Verzonden: vrijdag 1 september 2017 04:42:07 Aan: Donald Trung Onderwerp: Unblock Classiccardinal.

Classiccardinal is a great photographer, just because he can only speak in insults and harasses Hedwig in Washington and Yann doesn't mean that he should be barred from uploading his great pictures that benefit other Wikimedia projects, another measure should be taken to prevent his disruptive behaviour such as an interaction ban with the people he keeps harassing or another form of ban where his ability to edit talk pages and userpages is prevented while he could still upload pictures. He has been on Commonswiki for years and his contributions here benefit the project, Commons should be about the images and not its community. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 15:56, 11 November 2017 (UTC)”

But seeing the seriousness of this user’s harassment I don't have any immediate plans for requesting an unblock for them as they still don't seem to have learned to behave, but I don't think 🤔 that the community should miss high quality great pictures 📷 because the photographer can’t behave, maybe there are other ways to address this like making an “upload-only” user-class, but having specialised blocks might prevent any such harassment while great photographs such as [ these] can continued to be uploaded. Well, that’s why I think 🤔 why having such a feature would be greatly beneficial. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 15:56, 11 November 2017 (UTC)

  • Phabricator tickets:

Discussion[edit]

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.
  • Phabricator tickets:

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:T17294. MER-C (talk) 04:00, 13 November 2017 (UTC)

2FA and Huggle

Edit proposal/discussion

  • Problem: Admins with 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[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)

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

Edit proposal/discussion

  • Problem: Currently admins can only block accounts or IP addresses (short: users) from editing any page at all, or with the one exception of that user's own talk page. If a blocked account is granted the right to edit exclusively on a specific page or on a defined number of pages, the block has to be lifted totally. Users might misunderstand the intention of their block being lifted and edit pages they should not edit as they are still blocked de jure. Other possible options for an improved blocking tool are definable lists of pages a user can edit, a block that only targets non-talk pages, or blocks that are only targetted to uploads, to the wikimail function, or to the registration of accounts.
  • Who would benefit: Administrators and blocked users
  • Proposed solution:
    • Implement an option "user can edit {local site for appealing a block}" in the general block options
    • Implement an option "user can edit pages defined by {some regular expression}" in the general block options
    • Implement an option "user can edit talk pages" in the general block options
    • Implement an option for disallowing a user from sending wikimails that works without blocking that user from editing in the project itself.
    • Implement an option for disallowing a user only to upload files.
    • Implement an option for disallowing a user only to register an account.
  • More comments:
  • Proposer: → «« Man77 »» [de] 19:36, 14 November 2017 (UTC)

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)

U2F support for 2FA

Edit proposal/discussion

  • Problem: Admins and people with higher rights constantly are under attack, lots of non-technical users have trouble using "Google Authenticator".
  • Who would benefit: Admins/CUs/People who have access to sensitive data and all other people who we store their data
  • Proposed solution: Enable U2F support for Wikimedia projects, it can increase security of the users greatly by enabling them to have a hardware key and use it instead of the software.
  • More comments:
  • Proposer: Amir (talk) 12:01, 18 November 2017 (UTC)

Discussion[edit]

Create a tool for merging global accounts

Edit proposal/discussion

  • Problem: There is no way to merge global accounts now. During the SUL finalisation it happened often, that one contributor ended up with more global accounts. There can be other reasons as well, why one person has more than one accounts, and would like to merge them. As a bureaucrat and recently a global renamer I received several requests from many users in the last 10 years to merge their accounts, and I promised them that it will be possible soon (it is relative, but in some years), and I was waited for this feature as it was planned in the frame of the SUL finalization. Until end of last year when the developers announced that this feature doesn't work trustfully and won't be deployed.
  • Who would benefit: Contributors, who has more (global) accounts and would like to merge them.
  • More comments: Before the voting phase I would like to see if this request is technically possible or not. Please investigate if this is simply impossible for Wikimedia wikis or we need "only" to improve our software/hardware infrastructure to solve the problems.
  • Proposer: Samat (talk) 12:39, 18 November 2017 (UTC)

Discussion[edit]

@Legoktm (WMF), Hoo man, Keegan (WMF), MarcoAurelio, and Nemo bis: I would appreciate your expert opinion on this topic. Samat (talk) 12:39, 18 November 2017 (UTC)

We worked a lot on this but irreversibly broke accounts trying to merge them, see phab:T104686. For the tool, see further phab:T156584 and the tag usermerge on Phabricator. Best, —DerHexer (Talk) 13:23, 18 November 2017 (UTC)
I think I know the earlier cases and the current situation, but this means only that it is currently not working and disabled. It is not clear for me, that the request is absolute not possible or just relative ( = hard to solve). Samat (talk) 14:04, 18 November 2017 (UTC)
@Samat: You will not get an answer. It is a question of cost and benefit. What is the benefit? For some time now all new account are global. Only very old account would profit, and of those only that account that are still active, and of those only the ones that still want it. Let's say for the sake of the argument, that these are 200 people who benefit. What is the cost? It has been tried before, accounts have been irreversibly broken. Before it is tried again you need to test a new solution. You cannot test on production, so you will not break any more accounts. You need to create a replica for testing: 800+ wikipedias, with dozens of millions of users, with billions of edits. This test environment would need a hardware as big as that of production. That would cost millions, So instead you will run it on a smaller hardware. It will still run, but slow. The test of a single unification might take 2 days to complete. To test all 200 accounts may take 400 days. But if after 399 days of testing the system breaks, you have to correct the unification software and than start over. The correction might work, but in the end you may find another error, and you start again... Yes it is possible, No it will never be done. --𝔊 (Gradzeichen DiſkTalk) 23:57, 18 November 2017 (UTC)
Thank you for your explanation. It is sad, but rational. Samat (talk) 00:30, 19 November 2017 (UTC)
The tool exists, but there's a lot of legacy in the databases that prevent the tool from working on old accounts sadly, which are the ones that would really benefit from this. See phab:T49918#1933044 for details. That said, I'd love that now that we know the issues, try to work on fixing them if at all possible. —MarcoAurelio (talk) 20:30, 19 November 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 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[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)

Bring Special:Undelete to feature parity with live page histories

Edit proposal/discussion

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)

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[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)

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[edit]

Implement standard 2FA features

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[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 (talkcontribs) 13:45, 18 November 2017 (UTC)
    That could work. --Tgr (WMF) (talk) 22:46, 18 November 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)