Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Admins and stewards

< Community Wishlist Survey 2016
(Redirected from 2016 Community Wishlist Survey/Categories/Admins and stewards)
Admins and stewards
9 proposals, 164 contributors, 255 support votes



Allow create-protection to not show up in Special:ProtectedTitles

  • Problem: When a page is creation-protected, it shows up in Special:ProtectedTitles. While this is generally a good thing, once in a while the reason for protecting the title is because the title itself is too ofensive; making it show up in the Protected titles page gives it more visibility.
  • Who would benefit: Admins fighting against the creation of pages with offensive titles
  • Proposed solution: Add an option when protecting a non-existing page to "Not display in Special:ProtectedTitles" or something like that; by default, it will be set to show up there.
  • Phabricator tickets:

Community discussion

I'd be wary of it not showing up in the list at all, because that would make it impossible to get a list of all protected titles. Showing up as "<title hidden>" would IMO probably be fine though. Anomie (talk) 15:47, 11 November 2016 (UTC)[reply]

Something like a deleted title? Like an "Hide user" block, but by deletion rather than by blocking. Jo-Jo Eumerus (talk, contributions) 10:10, 12 November 2016 (UTC)[reply]
The problem with hiding it usiong the deletion option is that if somepone males a mistake, it's not easily correctably by the same user. On the other hand, with hiding usernames, I assume that if a user was blocked with the wrong setting on the "hide" flag, all it takes to fix it is a properly autherized user (an oversighter, as the feature currently works) to block the user with the correct setting. עוד מישהו Od Mishehu 18:10, 12 November 2016 (UTC)[reply]
Depending on the way it is designed, it may be possible to undelete article and title in one go. Not sure if hideuser allows unhiding and unblocking in one action, or how that works. Jo-Jo Eumerus (talk, contributions) 15:59, 21 November 2016 (UTC)[reply]

Is that really a problem? Anyways it definitely must be just an option with per wiki opt-in or opt-out default status. Even in wikis where I am not an admin I would like to have access to protected red titles not just via API. --Base (talk) 16:42, 28 November 2016 (UTC)[reply]

Voting – Hiding create protection from Special:ProtectedTitles

  1. (was support)-Shizhao (talk) 02:23, 28 November 2016 (UTC)[reply]
      Neutral--Shizhao (talk) 17:56, 30 November 2016 (UTC)[reply]
  2.   Neutral --Base (talk) 16:42, 28 November 2016 (UTC)[reply]
  3. {{neutral}} While it's possible there's some value to this proposal, I am having trouble feeling the severity of the problem. It seems to me that anyone who visits Special:ProtectedTitles (and I think this would be very few users), perhaps they should take with them a strong stomach. :) Stevie is the man! Talk • Work 17:44, 28 November 2016 (UTC)[reply]
      Oppose now. The more I ponder this, the less value it seems to have. I can't see this being any priority for WMF. Stevie is the man! Talk • Work 17:42, 30 November 2016 (UTC)[reply]
  4.   Oppose Dubious value; WMF projects are not censored -FASTILY 09:14, 29 November 2016 (UTC)[reply]
  5.   Oppose – In my opinion, hiding such information should be done very rarely. Guycn2 · ☎ 17:38, 29 November 2016 (UTC)[reply]
  6.   Oppose. We need a manner to track these and editors looking up creation-protected titles know they're going to find problematic pages. BU Rob13 (talk) 05:24, 30 November 2016 (UTC)[reply]
  7.   Oppose--Leon saudanha (talk) 21:49, 30 November 2016 (UTC)[reply]
  8.   Oppose The risk is largely bigger that the improvement. --Nouill (talk) 12:52, 1 December 2016 (UTC)[reply]
  9.   Oppose Wikipedia is not censored -- Kndimov (talk) 18:00, 1 December 2016 (UTC)[reply]
  10.   Oppose. Wikipedia is not censored. I don't think it would be useful. LlamaAl (talk) 05:45, 2 December 2016 (UTC)[reply]
  11.   Oppose I have to agree that this is trivial, as very few users visit that page. Frankly speaking, I had never looked at that page on any of our projects in my eight-year experience before a link was included in the proposal. Additionally, it is not clear to me how the administrators fighting against offensive titles are really going to benefit from it.--Kiril Simeonovski (talk) 10:29, 2 December 2016 (UTC)[reply]
  12.   Oppose --Vogone (talk) 23:15, 2 December 2016 (UTC)[reply]
  13.   Oppose per above. Jianhui67 talk★contribs 09:57, 3 December 2016 (UTC)[reply]
  14.   Oppose if a title is too offensive, prevent its creation using AbuseFilters. Huji (talk) 19:33, 5 December 2016 (UTC)[reply]
  15.   Oppose ArgonSim (talk) 22:02, 6 December 2016 (UTC)[reply]
  16.   Oppose, Special:ProtectedTitles is not a page an average newbie will find. There is no need to hide offensive titles there. It is perfectly reasonable to expect this page to contain inappropriate titles, and thus there is nothing to fix here — NickK (talk) 15:09, 7 December 2016 (UTC)[reply]
  17.   Support! — RandomDSdevel (talk) 22:49, 7 December 2016 (UTC)[reply]
  18.   Support Miniapolis 18:24, 8 December 2016 (UTC)[reply]
  19.   Oppose If admins are capable of this, I do oppose but if it's OS level, hmm... I'll reconsider. — regards, Revi 12:44, 10 December 2016 (UTC)[reply]

Button to quickly revert page creation vandalism

 
  • Problem: Page creation vandalism is currently laborious to revert.
  • Who would benefit: Admins and ultimately the community at large.
  • Proposed solution: In contribution lists, add a revert button against page creations. Assign that deletion button a special log entry to show that the button was used, and make it clear that just like the existing revert button, the new one also is to be used only for a narrow set of situations (principally page creation vandalism; particularly: floods).
  • Phabricator tickets:

Community discussion

  • Are you aware of Special:Nuke? MER-C (talk) 00:18, 15 November 2016 (UTC)[reply]
    • (ec revision) Yes, but thanks for mentioning it. The main idea here is that there are already dedicated revert buttons for edits and moves, and something analogous should exist for page creations. HTH, Samsara (talk) 02:55, 15 November 2016 (UTC)[reply]
      • But that functionality already exists in Nuke. What's the point of making another extension to do the same thing? Admins can add buttons to nuke from wherever using JS, but that's not something that needs WMF resources. – Ajraddatz (talk) 03:00, 15 November 2016 (UTC)[reply]
        • Finer grained control, and consistency of button availability. Since the functionality already exists, and assuming the MediaWiki codebase has a nice MVC structure, this is a five minute change for someone who knows what they're doing. Samsara (talk) 03:06, 15 November 2016 (UTC)[reply]
          • I'm really not sure how much more you could reduce the workflow of more --> delete --> reason --> enter (or contribs --> mass delete --> reason --> enter for mass page creation). How in fact is the current system laborious? What would your proposed workflow look like? This still seems like a case for user-created js. – Ajraddatz (talk) 03:15, 15 November 2016 (UTC)[reply]
            • I don't know what's so hard to understand. The proposal is entirely analogous with existing buttons for reverting moves and edits, as previously stated. Samsara (talk) 03:25, 15 November 2016 (UTC)[reply]
              • Because your proposal doesn't make sense, at least not how I'm reading it. You say the link would be added to page creations in user contributions, but that nuke isn't sufficient. So what are the situations in which you would want to individually delete pages without reading them, but not want to mass delete all pages created by a user? I can't think of a single use for your proposed idea in my experience. – Ajraddatz (talk) 03:38, 15 November 2016 (UTC)[reply]
                • We seem to be lacking in imagination here. If the title of a page is "Celebrity X is a ****" I think we can safely delete it without looking at it, no? Samsara (talk) 03:47, 15 November 2016 (UTC)[reply]
                  • Yeah, there's a case. So you want a delete button beside the title, so you can save a whole single click of going to the page or going to nuke and pressing enter. Just use JS. Actually, given how easy this is to make, I suppose it would be OK. – Ajraddatz (talk) 03:49, 15 November 2016 (UTC)[reply]
                    1. (ec) Further up this very page you find a complaint about how JavaScript creates maintenance problems.
                    2. Suggesting an alternative programming language doesn't solve the problem.
                    3. There is clearly a usability problem with Nuke if there is a question of whether I've heard about it. Samsara (talk) 04:01, 15 November 2016 (UTC)[reply]

┌─────────────────────────────────┘
 Maybe the way to go about this is to have rollback trigger a deletion rather than an error message when it's applied to a page with no editors other than the one whose edits are being rolled back. That will need some poking at the permissions, of course. Jo-Jo Eumerus (talk, contributions) 16:01, 21 November 2016 (UTC)[reply]

I am still not convinced. It is either 1) a bad contributor creates all obscenity/gibberish titled pages — I suggest you still spend 20s to load one of them to be 100% and not 99% sure for the sake of AGF and then you go Nuking their edits and banning them. 2) A somewhat good-standing editor out of blue creates a seemingly gibberish/obscenity titled page — in this case I even more strongly suggest you assume good face even more and now definitely load the page to see whether it is not some legit page like en:Putin khuilo! is while exactly matching the "Celebrity X is a ****" pattern proposed (especially the redirect en:Putin is a dickhead which is more understandable for non-Slavic languages speakers). If it isn't then you normally delete it and anyway you would also probably need to write a warning to the user or reach him off wiki to confirm their account is not compromised if there's a way so saving those 30 seconds and 2 clicks is not a big win. That being said I still don't see a legit case to rush into deleting some individual page without looking. Even if it is easy to implement, there are already tens if not hundreds of tasks on Phab which require less than 10 code lines to be resolved but hang there for years… --Base (talk) 17:12, 28 November 2016 (UTC)[reply]

@BU Rob13: Your concern (development resources needed) was raised before, and afaiaa, this change is as trivial as re-using the URL from NUKE as a get request on new page links on contribs pages. In terms of MVC, this is just V code and should take an experienced and familiar coder about five minutes. Samsara (talk) 07:15, 30 November 2016 (UTC)[reply]

Voting – Quickly revert page creation vandalism

  1.   Support--Shizhao (talk) 02:24, 28 November 2016 (UTC)[reply]
    Change to   Oppose - upon reflection, I stand with my initial assessment. The "Button to quickly revert page creation vandalism" is at Special:Nuke and is already linked to in the contribs page. I'm still not seeing much added value here, though I will point out that it's not necessarily a bad idea; i.e. it won't actively make anything worse. – Ajraddatz (talk) 09:12, 28 November 2016 (UTC)[reply]
  2.   Support. May be useful. Jules78120 (talk) 12:07, 28 November 2016 (UTC)[reply]
  3.   Support--Steinsplitter (talk) 15:10, 28 November 2016 (UTC)[reply]
  4.   Oppose for now till some good reasoning is given. --Base (talk) 17:12, 28 November 2016 (UTC)[reply]
  5. {{neutral}} maybe useful for convenience in occasional cases, but the value to the wiki projects overall seems low and therefore the use of special WMF resources is questionable. Stevie is the man! Talk • Work 17:58, 28 November 2016 (UTC)[reply]
      Oppose now per Fastily and the more I ponder this, the less I want this to be a more convenient action. Stevie is the man! Talk • Work 17:40, 30 November 2016 (UTC)[reply]
  6.   Support --Ziko (talk) 21:05, 28 November 2016 (UTC)[reply]
  7.   Oppose Not seeing the necessity, easy to accidentally mis-click, doesn't add any significant value beyond that which is already provided via Special:Nuke -FASTILY 09:14, 29 November 2016 (UTC)[reply]
  8.   Neutral With infinite time and resources, I would support this wholeheartedly, but we're far from having infinite time and resources. There are other more valuable proposals. BU Rob13 (talk) 05:25, 30 November 2016 (UTC)[reply]
  9.   Neutral Is not essential, other priorities--Leon saudanha (talk) 21:53, 30 November 2016 (UTC)[reply]
  10.   Neutral I can see the sense in having such a tool for quickly reverting page creation vandalism, but as I have never even personally found the need for Nuke, I can't see see it being a development priority for the time being. From time to time the possibility of partly unbundling deletion for the use of vandalism patrolers in special situations has been suggested (not by me), and it might be better to wait and see what happens there. Kudpung (talk) 04:17, 1 December 2016 (UTC)[reply]
  11.   Oppose Per above. User JS or a volunteer-developed gadget would be the most appropriate solution for this problem. MER-C (talk) 05:15, 1 December 2016 (UTC)[reply]
  12.   Oppose Not a priority. I don't think personally that is usefull. --Nouill (talk) 12:50, 1 December 2016 (UTC)[reply]
  13.   Support can be easy Murbaut (talk) 13:13, 1 December 2016 (UTC)[reply]
  14.   Oppose, not a high-priority task. Somebody can create a gadget if this is really needed. Usually it's better to first open a page before deleting. --Stryn (talk) 15:55, 1 December 2016 (UTC)[reply]
  15.   Support Good idea--Baskervilltalk 07:05, 2 December 2016 (UTC)[reply]
  16.   Oppose This may be helpful for blind-delete, which is a terrible way of acting. Normally, the page should be viewed for one to identify if it is vandalism or not before taking any action. Therefore, this does not seem to save any time or efforts.--Kiril Simeonovski (talk) 10:40, 2 December 2016 (UTC)[reply]
  17.   Oppose I think there are more downsides than benefits, as outlined by Kiril Simeonovski. --Vogone (talk) 23:16, 2 December 2016 (UTC)[reply]
  18. Conditional   Support - having rollback on a page where only one editor has been active performing a deletion instead of an error message may be useful at removing vandal pages faster, hiding vandalism quickly is after all the point of rollback. But I suspect it can be done with JS as well. Jo-Jo Eumerus (talk, contributions) 09:46, 3 December 2016 (UTC)[reply]
  19.   Neutral Not sure whether this is a sensible idea. Jianhui67 talk★contribs 09:59, 3 December 2016 (UTC)[reply]
  20. Comment. Consider the legit page en:James_while_John_had_had_had_had_had_had_had_had_had_had_had_a_better_effect_on_the_teacher. I'm against blind-delete generally speaking. I think I would support a modified proposal, which likely addresses the heart of the matter: it would be nice if there was a button, available to all users, called FlagThisArticleForDeletion. After spotting a bad entry, and marking it as needing deletion (using the proposed button), including supplying an edit-comment with the policy-based reason for the action, the non-admin could then *inform* an admin about the problem, either manually via usertalk or automatically by admins watchlisting a special page; if they admin already trusts that *particular* non-admin's judgement, based on previous interactions, then the admin can quasi-blindly hit the ConfirmDeletion button (also newly-programmed but only appears after and in response to the previous FlagThisArticleForDeletion button-press). Thataway, it is not really a 'blind' deletion, but rather, a delegation of the prose-check to a trusted helper. Nuking all contribs by a person, should be an admin-discretion action; I would *not* want to see any kind of FlagAllThisUsersContribsForNukeFromOrbit button. 47.222.203.135 13:17, 3 December 2016 (UTC)[reply]
    You are completely misrepresenting the proposal as several different ideas all of whom are NOT what this proposal suggests. The button is NOT for flagging articles for deletion. The button is NOT for non-admin use, and the button would NOT nuke everything. It's specifically designed to be used on a per-article basis, as opposed to NUKE, which defaults to killing everything. Samsara (talk) 09:12, 7 December 2016 (UTC)[reply]
  21.   Oppose Might be useful in some cases, but too easy to blind-delete, so too easy to mistake and too dangerous. Best regards, Kertraon (talk) 11:05, 4 December 2016 (UTC)[reply]
  22.   Oppose -- Freddy2001 talk 09:41, 5 December 2016 (UTC)[reply]
    Can be done with a script. No need to waste a lot of manpower on this. --Hedwig in Washington (talk) 01:31, 6 December 2016 (UTC)[reply]
  23.   Oppose I think this option can causes some careless actions and it may decrease the chance of improvement in many articles. --Smorteza (talk) 06:10, 6 December 2016 (UTC)[reply]
  24.   Weak support Could be useful, but still high-risk. Muhraz (talk) 15:17, 6 December 2016 (UTC)[reply]
  25.   Oppose Blind deletions are of concern, along with using it for other purposes not approved through community policy. Admins are trusted with delete for a reason. -- Amanda (aka DQ) 20:42, 6 December 2016 (UTC)[reply]
  26.   Oppose ArgonSim (talk) 22:05, 6 December 2016 (UTC)[reply]
  27.   Support Opposes seem to follow either one of two fallacies - that it would take lots of WMF resources to implement this (ridiculously untrue - if it can be done with JavaScript as some have argued, it's obviously trivial in server-side code), or that content will go down the drain by hapless clicking. This is also unlikely, as the feature by design should only work on freshly created and otherwise untouched pages. Nobody would have access to this button who can't undelete, so undoing the damage from "accidental clicks" is trivial. Samsara (talk) 09:03, 7 December 2016 (UTC)[reply]
  28.   Oppose There should be no way to speedily delete pages without explaining reason. As an administrator I find very important to have the reason of deletion clearly understandable to everyone 'including the author of the article). There is already an option to delete multiple articles explaining the reason at Special:Nuke, which works well for fighting vandalism — NickK (talk) 12:22, 7 December 2016 (UTC)[reply]
  29.   Support! — RandomDSdevel (talk) 22:50, 7 December 2016 (UTC)[reply]
  30.   Support Miniapolis 18:26, 8 December 2016 (UTC)[reply]
  31.   Oppose Deleting without viewing the pages' content may lead to incorrect results. --Uğurkenttalk 12:19, 10 December 2016 (UTC)[reply]
  32.   Support FoCuSandLeArN (talk) 22:55, 11 December 2016 (UTC)[reply]

Create a blacklist of users who can not use Special:GlobalRenameRequest

  • Problem: Some users abuse the Special:GlobalRenameRequest page. Stewards and global renamers should be able to restrict certain users from registering new requests for rename.
  • Proposed solution: A special page such as Special:GlobalRenameBlacklist manageable for those with centralauth-rename rights. Should support also regex filtering. The list should be manageable from Meta and should prevent the user from using the request page on any wiki. The blacklist should also support temporary blocking to avoid cluttering.
  • More comments: See Phabricator task.
  • Phabricator tickets: phab:T101615, where discussion is happening.

Community discussion

Ehm. Continuous harassment of our systems would seem to me to translate into eventual global ban and block wouldn't it ? Aren't we solving the wrong problem ? —TheDJ (talk • contribs) 10:24, 11 November 2016 (UTC)[reply]

Block is not the solution since the special page can be accessed from any wiki. Moreover, blocked accounts do need to access that special page in case they were blocked for username violations. Some users might be well disruptive to deserve a global lock of their account, but that's not the case in the vast majority of cases. —MarcoAurelio 10:34, 11 November 2016 (UTC)[reply]
Per MA, there are people who just request too many renames. That doesn't necessarily mean that they should be forceably logged out of their accounts and not permitted to log in again ever. This would be an incredibly useful feature. – Ajraddatz (talk) 00:45, 15 November 2016 (UTC)[reply]

Does anyone have any stats or ballpark guesses to illustrate the abuse? (e.g., How many "some users" or repetitive attempts per day?). Stevie is the man! Talk • Work 16:46, 28 November 2016 (UTC)[reply]

It doesn't happen much, thankfully. But when it does there is no way to keep track of it and relay that info to the 94 users with the ability to rename accounts. The only other option would be to make a list of such banned users, that renamers would need to check before each rename. That would be incredibly inconvenient, to say the least. – Ajraddatz (talk) 09:19, 29 November 2016 (UTC)[reply]

Voting – Special:GlobalRenameRequest blacklist

  1.   Support – Ajraddatz (talk) 09:11, 28 November 2016 (UTC)[reply]
  2.   Support --Stryn (talk) 11:09, 28 November 2016 (UTC)[reply]
  3.   Support --MF-W 14:13, 28 November 2016 (UTC)[reply]
  4.   Support —MarcoAurelio 15:08, 28 November 2016 (UTC)[reply]
  5.   Support--Steinsplitter (talk) 15:10, 28 November 2016 (UTC)[reply]
  6.   Neutral until I can get a feel for the severity of the problem. Stevie is the man! Talk • Work 17:59, 28 November 2016 (UTC)[reply]
    Staying a neutral, because the problem is small and affects a very narrow aspect of the wikis. Even though this should be fixed eventually, I can't see this as a priority for WMF. Stevie is the man! Talk • Work 17:47, 30 November 2016 (UTC)[reply]
  7.   Support JAn Dudík (talk) 21:30, 28 November 2016 (UTC)[reply]
  8.   Support If Stewards think it can help them, there is no reason to oppose. Even en:WP:UTRS has a "ban user from tool" button. ☺ · Salvidrim! · ✉ 00:23, 29 November 2016 (UTC)[reply]
  9.   Support Guycn2 · ☎ 17:40, 29 November 2016 (UTC)[reply]
  10.   Neutral I'm not fully convinced we can't handle this conventionally through warnings. If a username comes up repeatedly, couldn't stewards raise the issue at a relevant noticeboard and then warn the editor not to submit additional rename requests? I see other issues as more pressing. BU Rob13 (talk) 05:29, 30 November 2016 (UTC)[reply]
  11.   Support some users simply won't stop asking renames against policies, the only way to stop them is a global lock, which is an overkill. --Vituzzu (talk) 14:24, 30 November 2016 (UTC)[reply]
  12.   Support per cases that this in my home wikipedia--Leon saudanha (talk) 22:23, 30 November 2016 (UTC)[reply]
  13.   Support reduce rename again with against policy :) Murbaut (talk) 13:07, 1 December 2016 (UTC)[reply]
  14.   Support Jmvkrecords ⚜ (Intra talk) 07:24, 2 December 2016 (UTC).[reply]
  15.   Support--Kiril Simeonovski (talk) 11:16, 2 December 2016 (UTC)[reply]
  16.   Support, unfortunately such a feature seems to be necessary. --Vogone (talk) 23:17, 2 December 2016 (UTC)[reply]
  17.   Support DPdH (talk) 01:56, 3 December 2016 (UTC)[reply]
  18.   Support Jianhui67 talk★contribs 10:00, 3 December 2016 (UTC)[reply]
  19. Comment This seems to be getting some support, but it is phrased as a very binary thing -- rather than implement a blacklist-feature where users can either request an infinite number of renames, or are prevented from *ever* requesting renames via the normal mechanism, I would suggest instead implementing a time-delay-abusefilter mechanism. If a particular user is requesting 'too many' renames and overloading the system, then an admin or steward can add their (global) username to the NoRenameRequestsForOneMonth set of parameters, and if the same person is problematic in the same way at a future date they can be 'throttled down' again, this time using the NoRenameRequestsForSixMonths parameters, and so on. Such a time-limited-global-pageblock feature would potentially useful in other situations; the narrow blacklist-only idea is not going to be as applicable to other situations methinks. 47.222.203.135 13:31, 3 December 2016 (UTC)[reply]
  20.   Support Great opinion--By erdo can (talk) 20:37, 3 December 2016 (UTC)[reply]
    That's a great idea, actually. A rate limit on rename requests. It would be game-able, since you could go to a different project or request via email, but it would be worth doing. Unfortunately, this doesn't necessarily help in all cases where a user shouldn't be allowed to change their name but that information can't be widely distributed. – Ajraddatz (talk) 06:10, 4 December 2016 (UTC)[reply]
  21.   Support --TerraCodes (talk) 03:13, 4 December 2016 (UTC)[reply]
  22.   Support --Yeza (talk) 12:35, 4 December 2016 (UTC)[reply]
  23.   Support I JethroBT (talk) 20:47, 5 December 2016 (UTC)[reply]
  24.   Support Great idea! --Hedwig in Washington (talk) 01:32, 6 December 2016 (UTC)[reply]
  25.   Support But what kind of blacklist?--Smorteza (talk) 06:12, 6 December 2016 (UTC)[reply]
  26.   Support Muhraz (talk) 15:17, 6 December 2016 (UTC)[reply]
  27.   Support Tiggerjay (talk) 20:30, 6 December 2016 (UTC)[reply]
  28.   Support -- Amanda (aka DQ) 20:43, 6 December 2016 (UTC)[reply]
  29.   Support Sure. Ks0stm (T•C•G) 21:01, 6 December 2016 (UTC)[reply]
  30.   Support. - Mailer Diablo (talk) 06:53, 7 December 2016 (UTC)[reply]
  31.   Support, potentially an easy option and a useful one, although not of the highest priority — NickK (talk) 12:25, 7 December 2016 (UTC)[reply]
  32.   Support! — RandomDSdevel (talk) 20:17, 7 December 2016 (UTC)[reply]
  33.   Support Amir (talk) 18:13, 8 December 2016 (UTC)[reply]
  34.   Support Miniapolis 18:28, 8 December 2016 (UTC)[reply]
  35.   Support --DangSunM (talk) 01:55, 10 December 2016 (UTC)[reply]
  36.   Support --OrsolyaVirág (talk) 11:25, 10 December 2016 (UTC)[reply]
  37.   Support --Uğurkenttalk 12:22, 10 December 2016 (UTC)[reply]
  38.   Support — regards, Revi 12:29, 10 December 2016 (UTC)[reply]
  39.   Support --TanvirH (talk) 20:31, 10 December 2016 (UTC)[reply]
  40.   Support Cenya95 (talk) 00:24, 11 December 2016 (UTC)[reply]
  41.   Support. For sure. RadiX∞ 02:41, 12 December 2016 (UTC)[reply]

Enable administrators to update block logs

  • Problem: From time to time, editors are blocked, but subsequently it is decided that there is some sort of reason that the block should not be regarded as a "black mark" on that editor's contributions. Such editors often feel alienated by the experience, and this problem is harmful to editor morale and retention. Presently, unless the unblock entry states explicitly what the caveat associated with unblocking was, there is no good way to "correct" a block log subsequently. (Clearly, re-blocking briefly just to make a new block log entry is a bad solution.)
  • Who would benefit: In an immediate sense, this would benefit a subset of editors who have been blocked, but ultimately it will make work easier for administrators and assist in community processes (such as requests for additional permissions) by clarifying things that are otherwise unclear.
  • Proposed solution: Enable administrators to edit and modify existing entries in block logs. Enable administrators to make comment-only entries in block logs, without blocking or unblocking.
  • More comments: Obviously, projects that elect to make use of this feature will also need to establish policies governing when an administrator may or may not modify an entry a decision made previously by another administrator.
  • Phabricator tickets:

Community discussion

A difficulty with edits to log comments is that you then need a history for the log comments and an ability to watch those types of edits (e.g. more entries in RecentChanges). And then possibly the ability to edit the comments in that history, which needs a history for those edits, etc. The ability to merely hide log comments already exists. Anomie (talk) 15:44, 11 November 2016 (UTC)[reply]

Why is that a difficulty? It's not like we have a limitation on server space. --Tryptofish (talk) 17:13, 11 November 2016 (UTC)[reply]
We do have limitations on how many layers of history and edit function we can built around the edit function of the log entry on the edit function of the log entry and so on. Constructing an onion bulb of edit functions and associated histories seems like a low quality work. I think the issue with the revision deletion of log entries is that you need to suppress the log entry to get it out of the public log (and thus into the suppression log which isn't public), mere revdel just strikes the entry out. And the suppression policy does not cover this usecase. Jo-Jo Eumerus (talk, contributions) 10:09, 12 November 2016 (UTC)[reply]
Mere revdel does hide the entry from anyone who doesn't have the ability to see revision-deleted content. Or is the complaint here specifically about hiding it from sysops? Anomie (talk) 14:17, 12 November 2016 (UTC)[reply]
Nay, it is about removing it from the (public) block log entirely. Jo-Jo Eumerus (talk, contributions) 09:32, 13 November 2016 (UTC)[reply]

This proposal is honestly more of a community issue, a stigma about having block log entries to your name. It would take quite a bit of time to develop it seems, and not add any actual technical benefit; blocks can already be explained, without modifying the reason for making them. If enwiki in particular wants to explain bad blocks, then amending policy to allow the block log entry to be deleted in such cases would make more sense. – Ajraddatz (talk) 03:42, 15 November 2016 (UTC)[reply]

  • Thanks for the feedback, everyone. Thinking about these comments, I think an alternative approach would be to enable adding entries to the log, without blocking or unblocking. I'm not so much concerned with being able to hide blocks, as with being able to subsequently set the "record" straight when appropriate. At present, that entails adding another, very brief, block, which is silly. Simply being able to add an administrative note to the log should be easier to code, and would also serve the purpose. --Tryptofish (talk) 16:42, 19 November 2016 (UTC)[reply]
    @Tryptofish: On that note, before we can move to the voting some clarification will be needed. It sounds like either annotations or ability to add another log entry is what you are looking for. Could we decide on one, so that people know exactly what they're supporting/opposing? Thanks for your participation! MusikAnimal (WMF) (talk) 19:09, 21 November 2016 (UTC)[reply]
    Thanks for asking me that. I've revised the "Proposed solution" to clarify that, based upon the feedback so far, I am no longer proposing annotations of existing entries (thus, no need for an edit history), but instead proposing the ability to add comment-only entries, without the need to block or unblock as part of the entry process. I also tweaked the wording in the "More comments" part, for consistency. I don't think anything else in what I submitted needs to be revised along with that. --Tryptofish (talk) 19:50, 21 November 2016 (UTC)[reply]
  • Why not put meaningful block reasons initially in the first place? Can we illustrate this request with an example? --Gryllida 23:05, 1 December 2016 (UTC)[reply]
  • If this absolutely has to be implemented, I propose that the 'block update' actions are also logged (like page renames are). --Gryllida 23:05, 1 December 2016 (UTC)[reply]
If the log is added to, that in itself is a permanent record that can be easily found. Of course, everyone would want meaningful reasons to be given in the first place, as much for unblocks as for blocks. But there are plenty of instances where a user was unblocked with a cursory notation when in fact there are good reasons to explain that there were issues with the block. (Editors might be sensitive about being presented as an example.) --Tryptofish (talk) 23:40, 2 December 2016 (UTC)[reply]

Voting – Updating block logs

  1.   Support only new comment-only entries, not changes to existing entries as that could be abused (and would be difficult to implement per the discussion above). I can see the value of admins adding further explanations. Stevie is the man! Talk • Work 16:57, 28 November 2016 (UTC)[reply]
  2.   Support Comment-only block log entries, which can both help in the above discussed scenarios (commenting a previous block), but also to add a rationale if a block was accidentally made without a rationale or with the wrong summary. ☺ · Salvidrim! · ✉ 00:16, 29 November 2016 (UTC)[reply]
  3.   Support  @xqt 13:47, 29 November 2016 (UTC)[reply]
  4.   Support Having been personally victimized by a bad block, and having seen many other editors suffer through it as well, this is at least a step in the right direction. Admins, being people, make mistakes. Having a block log that can not be amended, short of blocking/unblocking, prevents our ability to correct errors. --Hammersoft (talk) 15:59, 29 November 2016 (UTC)[reply]
  5.   Support StevenJ81 (talk) 17:09, 29 November 2016 (UTC)[reply]
  6.   Neutral I heartily support comment-only entries. I also would support providing either bureaucrats or possibly oversighters the ability to update or remove past entries. I oppose administrators being able to potentially edit their own log entries due to the potential for abuse, even if I generally trust our administrators. BU Rob13 (talk) 05:30, 30 November 2016 (UTC)[reply]
  7.   Support as nom. I've been reading the votes so far, and I agree that this should be comment-only, and not revise. I also agree that we don't want misuse such as what BU Rob13 just pointed out, but that is really a matter of project policy, rather than software features. --Tryptofish (talk) 22:01, 30 November 2016 (UTC)[reply]
  8.   Support blocks can also be mistaken--Leon saudanha (talk) 22:29, 30 November 2016 (UTC)[reply]
  9.   Support --Gerwoman (talk) 17:44, 1 December 2016 (UTC)[reply]
  10.   Support. Beagel (talk) 17:56, 1 December 2016 (UTC)[reply]
  11.   Support --Jojhnjoy (talk) 18:24, 1 December 2016 (UTC)[reply]
  12.   Neutral per Rob. I think comments would be better. --AmaryllisGardener talk 18:51, 1 December 2016 (UTC)[reply]
    Please note that the proposal (as it is now) is for comments only. --Tryptofish (talk) 19:43, 1 December 2016 (UTC)[reply]
  13.   Support --Gestumblindi (talk) 20:42, 1 December 2016 (UTC) Not terribly urgent, but could be helpful.[reply]
  14.   Support Can be useful in understanding why blocks have occured Emir of Wikipedia (talk) 22:28, 1 December 2016 (UTC).[reply]
  15.   Support Perfectly reasonable solution to a totally unnecessary, albeit minor, problem. Everymorning (talk) 23:27, 1 December 2016 (UTC)[reply]
  16.   Oppose I don't want an admin editing logs. Potential abuse. Local log messages can be writted otherwise to reduce that "black mark", Jmvkrecords ⚜ (Intra talk) 07:41, 2 December 2016 (UTC).[reply]
    It's not clear to me what such a "local log" would be. --Tryptofish (talk) 23:40, 2 December 2016 (UTC)[reply]
    User_talk archive. AN/I thread archive. Anywhere, really. See my comment below: block log is NOT a criminal record, permanent transcript, or somesuch. This proposal is inherently flawed, because it will MAKE the block log into such a thing, with many unintended consequences. 47.222.203.135 13:43, 3 December 2016 (UTC)[reply]
    I had not thought of user talk as a "log". But if adding a comment to the block log would lead to the problems that you claim will happen, then I would think that making that comment on the user talk page would too. And if making the comment on the user talk page would be helpful, then I cannot see how making that comment in the block log would be worse. --Tryptofish (talk) 22:43, 3 December 2016 (UTC)[reply]
    Sorry if I was not clear. I was talking about local predeterminated messages we can use in logs, like MediaWiki:Ipbreason-dropdown. Exemple, "inserting nonsense/gibberish into pages" can be changed for something better, maybe something about "how to help". Jmvkrecords ⚜ (Intra talk) 05:04, 8 December 2016 (UTC).[reply]
    Thanks for the clarification. If I understand correctly, this actually would be adding to the block log, but it would employ predetermined phrases from a list, rather than an individual administrator's own choice of words. --Tryptofish (talk) 01:30, 9 December 2016 (UTC)[reply]
  17.   Oppose I really do not see that this will immediately lead to major improvements to justify the time and efforts that the community members should spend on establishing the policies that will govern it.--Kiril Simeonovski (talk) 11:33, 2 December 2016 (UTC)[reply]
  18.   Oppose I don't want to be able to rewrite history or have users ask me to rewrite history. Multichill (talk) 13:59, 2 December 2016 (UTC)[reply]
    I would hope that all administrators would be willing to take responsibility for their administrative actions, but nobody has to comment into a log if they do not want to. --Tryptofish (talk) 23:40, 2 December 2016 (UTC)[reply]
  19.   Support Only adding new comments, not the deletion or edit of previous comments which could be easily abused without any check or balance. Emir of Wikipedia (talk) 14:50, 2 December 2016 (UTC)[reply]
  20.   Support --Banfield - Reclamos aquí 15:00, 2 December 2016 (UTC)[reply]
  21.   Neutral Advantages and disadvantages. Adding a comment preferred, this seems sufficient to correct or specify entries more precisely. --Holmium (talk) 15:30, 2 December 2016 (UTC)[reply]
  22.   Oppose any reason to revert or change a block would be included in the action reason already, and talk page of the user has the full history which can be traced to later document or dispute the block should it be queried Gnangarra (talk) 15:56, 2 December 2016 (UTC)[reply]
    I sure would like to believe that every block log entry, both at blocking and at unblocking, would be perfectly crafted, but it simply is not true that administrators never make errors. --Tryptofish (talk) 23:40, 2 December 2016 (UTC)[reply]
  23.   Oppose, per Multichill. --Vogone (talk) 23:17, 2 December 2016 (UTC)[reply]
  24.   Support, as an editor who was unduly blocked by a trigger-happy admin for 30 days (I was promptly unblocked by the blocking admin less than 24 hours later once two other admins pointed out the blocking admin's error to him) - thereby ruining what was long an unblemished block log - I absolutely support this. I previously moved to have RevDel amended [1] to allow total obfuscation of block logs in the case of accidental blocks. It's well and good to say "we don't want to rewrite history" but the reality is, a block log does permanently and irreversibly devalue one's contributions to WP. Even an IRL criminal has the opportunity to have his arrest record expunged after a few years. Why do I, an innocent person, have to have my "wiki-arrest" record with me for the next 80 years, or however long WP lasts? The only way I would Oppose this excellent suggestion is if there were a policy in place for mandatory de-sysoping of any admin found to have made an erroneous block for any reason (a fairly mild suggestion - an desysoped admin can always get his administratorship back ... I can never recover my clean block log). LavaBaron (talk) 00:42, 3 December 2016 (UTC)[reply]
  25.   Support If caveats mentioned above are addressed. DPdH (talk) 02:02, 3 December 2016 (UTC)[reply]
  26.   Oppose per Multichill. --Steinsplitter (talk) 10:00, 3 December 2016 (UTC)[reply]
  27.   Comment Oppose strongly. Admins should *not* block until they are very sure. Blocked people should *not* be encouraged to beg for grading-on-a-curve. The block button is very crude, that is by design, and adding the "apology-button" would be severe mistake, which would cause many unintended consequences. With great powers come great responsibilities. Accidental and/or mistaken and/or wouldaCouldaShoulda blocks sometimes happen, the unblock is the ONLY thing that can be allowed to matter. Building an encyclopedia here; pretending that blocks are like a 'permanent record' in elementary school, or even worse like a 'criminal record' in the judicial system, WILL SCREW UP PURSUIT OF THAT MAIN GOAL. If you were blocked by mistake, ask to be unblocked politely, and you will be. If you block by mistake, slow the fuck down, and remember to ask questions first rather than going all trigger-happy with your big ol' banhammer. 47.222.203.135 13:43, 3 December 2016 (UTC)[reply]
    Sorry to be expressing my annoyance, but what a naive and mean-spirited view of how things work in the real world. --Tryptofish (talk) 22:37, 3 December 2016 (UTC)[reply]
  28.   Oppose Logs are logs, no beauty contest. + potential abuse. --Sargoth (talk) 10:15, 4 December 2016 (UTC)[reply]
  29.   Oppose Too easily abused. Maybe not on enwiki, but on a lot of smaller wikis with 5 admins, 3 of them inactive, and 2 of them corrupt... --Rschen7754 22:07, 4 December 2016 (UTC)[reply]
    I think your hypothetical smaller project, with only two admins, both corrupt, would have bigger problems than comments in a block log – such as actual blocks and unblocks! And I would hope that the Stewards would be helping in such a case. But I also think that you brought up a very good and helpful point, that this might work at enwiki but fail at smaller projects. I think that's true, and I also continue to believe that it would be very helpful at enwiki. Interestingly, nearly all of the oppose votes here are in fact coming from smaller projects, and the votes segregate that way to a significant (not 100%) extent. (At enwiki, administrators are pretty much forbidden to say that they don't want to have to bother explaining their decisions or correct their errors.) I know that, this year, the plan is to make sure that some proposals that help smaller groups will not be overlooked, but I also think that this cuts both ways. If something would help a lot at a big project, it may be bad if smaller projects were to essentially veto it because it wouldn't also be helpful to them. Maybe this proposal is something that should be rolled out only at enwiki, and then made available to other projects on request. --Tryptofish (talk) 20:26, 5 December 2016 (UTC)[reply]
    "I think your hypothetical smaller project, with only two admins, both corrupt, would have bigger problems than comments in a block log – such as actual blocks and unblocks! And I would hope that the Stewards would be helping in such a case" - I can name several projects (even a few that are large enough to have CheckUsers) off the top of my head where such a functionality would likely be abused. Stewards are very reluctant to intervene in situations like this - I've seen plenty of threads on stewards-l (when I was on the list) peter out, when (at least in my opinion) something should have been done. It is at the edge of their remit (they are not a global ArbCom and can only act on community consensus, per Steward policy), and many stewards are barely active or too worried about their next reconfirmation. Just take a look at RFC. --Rschen7754 01:24, 6 December 2016 (UTC)[reply]
    Understood, thanks. And I was not questioning that there are projects where such problems happen, and I certainly did not mean to go off on a tangent about Stewards. With respect to the proposal here, I don't want to lose track of the point that at larger projects such as enwiki, the situation is different than that. --Tryptofish (talk) 01:38, 6 December 2016 (UTC)[reply]
  30.   Oppose User:Sargoth said it well Huji (talk) 19:37, 5 December 2016 (UTC)[reply]
  31.   Support, specific to the comment-only additions to the block log for clarification. This is something I would have used in the past when I have made blocks with (what I felt like to be) insufficient detail. I JethroBT (talk) 20:53, 5 December 2016 (UTC)[reply]
  32.   Support the general concept, not fully sure this is the best way to do it. --Sphilbrick (talk) 22:01, 5 December 2016 (UTC)[reply]
  33.   Strong oppose Logs log, that's why they are logs. Enable editing them is contrary to what logs are supposed to do. We'll have pages over pages of request to change the log. Better to scrap logs than to enable editing. I can see the whining on admin noticeboards right now, accused me of XYZ, nonsense requests, typo corrections, etc. Discussions that are several pages long, each. I can see them now. No thanks. --Hedwig in Washington (talk) 01:38, 6 December 2016 (UTC)[reply]
      Comment I wonder what the Oppose voters think of the alternative of just allowing comment-only entries (instead of editing existing entries). Might any of you support that? I think we can assume good faith that admins will be careful in the use of that. Stevie is the man! Talk • Work 13:14, 6 December 2016 (UTC)[reply]
    Thank you very much for that comment. I regret that, as the proposal got revised prior to the voting period, I failed to make it clear enough that the current version of the proposal is, indeed, only for comment-only entries, and not for being able to revise existing entries. --Tryptofish (talk) 20:23, 6 December 2016 (UTC)[reply]
  34.   Oppose, per Multichill and Sargoth. Muhraz (talk) 15:18, 6 December 2016 (UTC)[reply]
  35.   Oppose stronly. Logs exist for good reason, and should be read as historical. However I would support the ability to enter NEW logs as comments only, but there still needs to be a policy of this. As well as careful review to ensure this new use of the block logs doesn't break tools which currently count blocks, etc. Tiggerjay (talk) 20:33, 6 December 2016 (UTC)[reply]
  36.   Oppose While I see some use cases, it's not significant enough for me to support a tool where we are supressing (normal sense of the word) information in logs. -- Amanda (aka DQ) 20:40, 6 December 2016 (UTC)[reply]
  37.   Neutral - Very good idea in theory, but I can see some potential for abuse. Ks0stm (T•C•G) 21:03, 6 December 2016 (UTC)[reply]
  38.   Oppose, easy to abuse in the current form and especially huge potential for admin-shopping and harassment of administrators (will anyone add a comment to my block log that my block was unfair?). If a block was completely wrong it can be hidden from the block log using revdelete feature, comments can be useful in a very limited number of cases but the abuse potential is much higher — NickK (talk) 12:56, 7 December 2016 (UTC)[reply]
  39.   Support! — RandomDSdevel (talk) 20:33, 7 December 2016 (UTC)[reply]
  40.   Support Each wiki could decide how (or whether) to use the feature, but it should be available. Rivertorch (talk) 05:50, 8 December 2016 (UTC)[reply]
  41.   Support Miniapolis 18:30, 8 December 2016 (UTC)[reply]
  42.   Oppose with two, and only two exceptions: 1) Where a block was made purely accidentally through a technicality. I nearly blocked the wrong user myself once by having several blocking interface windows open at the same time, while rapidly blocking some socks on a spree.and some of our most highly respected admins have made a genuine misclick. 2) Where a block was clearly identified as a blatant deliberate misuse of the tools identified by Arbcom or a strong community consensus. Kudpung (talk) 02:26, 10 December 2016 (UTC)[reply]
  43.   Support There should be some limits to when this is allowed but I fully support the concept because blocks are made all the time that shouldn't have and are later revoked. Maybe this could be limited to Bureaucrats or something to limit the chance of abuse. Reguyla (talk) 18:05, 10 December 2016 (UTC)[reply]
  44.   Support --TanvirH (talk) 20:32, 10 December 2016 (UTC)[reply]
  45.   Support Very good idea Cenya95 (talk) 00:26, 11 December 2016 (UTC)[reply]
  46.   Support Absolutely. I had a bogus block that was overturned at the administrators' noticeboard on en.wiki, retroactively, as unjustified, but no one can tell. All they see is that I was blocked, and this is frequently used as a weapon against me.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:18, 11 December 2016 (UTC)[reply]
  47.   Support --Mikheil Talk 20:52, 12 December 2016 (UTC)[reply]
  48.   Support - They're logs, not the collected works of Shakespeare. MrX (talk) 22:49, 12 December 2016 (UTC)[reply]

Make two-factor authentication easier to use

retitled; original title was "Require Admins (and other users with additional rights) to use 2FA once 2FA becomes public"

  • Problem: Wikipedia gets compromised by compromised admin accounts. Admin accounts have in the past been hacked because of the use of non unique passwords. Admins have in public spoken about using insecure passwords. Admins have in public protested against being required to use a password of at least 8 bytes. Admins have protested against 2FA.
  • Who would benefit: people reading wikipedia without being logged in. People reading wikipedia logged in. People editing wikipedia. Admins whose accounts don't get compromised.
  • Who would not benefit: Admins who already use a save password.
  • Proposed solution:
    • Add alternative ways to get the 6-digit code without a smartphone (SMS, email, ...)
    • Add a way to change between connected accounts, without the need to enter another 6-digit code.
    • Add a way to get new scratch codes without turning off 2FA.
    • Start now a RFC on meta to require admins to use 2FA (to be moved to a different place)
    • Wait for 2FA to become public
    • mass mail admins on all projects to volantarily use 2FA
    • Wait 3 month
    • Make 2FA mandatory (to be moved to a different place)
  • More comments: This is controversial. Admins have said, that every damage a compromised admin account could do, could be undone by another admin. But I have discussed a threat that cannot be undone with a member of the WMF security team in a mail from 03.01.2016, 13:43, TOP #3.
BTW: If you manage your banking account with an online banking solution (TAN, iTAN, PhotoTAN, Password-Generator, ...), use your credit card in the internet (Verified by Visa, Mastercard SecureCode, AMEX SafeKey, JCB J/Secure), you already use 2FA yourself. There is a reason for it.
  • Phabricator tickets:

Community discussion

Or, better phrased: If this is a community decision, then the technical wishlist is probably not the best place to have that discussion. (: However, most technical elements of the proposal are simply about making 2FA easier. Maybe focus on those? /Johan (WMF) (talk) 10:39, 15 November 2016 (UTC)[reply]
  • As sysop in dewiki I refuse to rely on my mobile phone and on a piece of software I do not want to install in order to access my account just for checking my watchlist or for editing a typo. Optional 2FA is fine, so is a 2FA which gives you more options to choose. If for some reason sysopping will only be allowed with 2FA at some point in the future, please build a way that ensures a sysop account can be used without 2FA, but 2FA needs to be completed in order to turn on the additional powers. → «« Man77 »» [de] 17:25, 17 November 2016 (UTC)[reply]
  • @°: Please re-scope this request to just the technical parts (the first 3 items in your bullet list). The community parts can be handled by the community. I would suggest also renaming the proposal to something like "Make 2FA easier to use". Ryan Kaldari (WMF) (talk) 22:27, 17 November 2016 (UTC)[reply]
  • Not sure what Add a way to change between connected accounts, without the need to enter another 6-digit code means. For accounts connected via SUL (ie. same account on different wiki) you only need to log in once, so you only need to enter the 2FA code once as well. There is no other means of connecting accounts currently, AFAIK. --Tgr (WMF) (talk) 22:52, 21 November 2016 (UTC)[reply]
  • I think a more important first step to improve account security would be to require reasonably strong passwords for all users. I really don't understand why Wikimedia projects still accept laughably weak passwords for non-admins when virtually any trivial web forum etc. has decent standard requirements for password strength. According to the RfC "Password policy for users with certain advanced permissions", the general requirements as of December 2015 were only "Password must be at least 1 character long" (one character! really?) and "Password cannot be the same as the username", and I think this hasn't changed for non-admins. And the requirements for admins (and other "users with certain advanced permissions") introduced by that 2015 RfC are still not really impressive. Of course, even a very good password will not protect you if you don't follow basic, well-known precautions such as never to use the same or similar passwords for multiple sites. Careless people might benefit from 2FA, as it forces some security on them. Still, as I am using a strong, secure password and use this for Wikimedia exclusively (and change it from time to time), I think that 2FA would only be unnecessary hassle for me. So, those who feel confident in their approach to "classical" password security certainly shouldn't have 2FA imposed upon then. Gestumblindi (talk) 21:01, 1 December 2016 (UTC)[reply]
    • I oppose stronger password requirements for all users. For them, we can add strength indicators and 'your password is unchanged for 3 months, please consider changing it' naggers, but not any requirements. These requirements are incredibly frustrating and annoying. When websites have such requirement, I often just close the tab and do not sign up at all. --Gryllida 23:16, 1 December 2016 (UTC)[reply]
  • Definitely FA needs clear documentation on its own page; there is none at present. I don't know how to use the code I am shown! Nobody else does either. --Gryllida 23:16, 1 December 2016 (UTC)[reply]
  • For admins, we maybe need to survey them and ask what their problems with 2FA are. --Gryllida 23:16, 1 December 2016 (UTC)[reply]

Voting – Easier 2FA

  1.   Oppose Overkill/overreaction, IMHO. This should be a matter of policy. Have strong password policies and enforce them. Stevie is the man! Talk • Work 17:10, 28 November 2016 (UTC)[reply]
  2.   Oppose Yes, 2FA is important, but I'm not convinced that forcing users to make the switch will lead to a productive outcome -FASTILY 09:14, 29 November 2016 (UTC)[reply]
  3.   Oppose Wikim/pedia is *not* my bank account. → «« Man77 »» [de] 11:00, 29 November 2016 (UTC)[reply]
  4.   Oppose any WMF involvement in local password protection policies. This is not the place for the WMF to step in. I would support technical measures to require accounts with advanced user rights to use a secure password and update it every X months, but only if the actual requirements were determined locally. BU Rob13 (talk) 05:33, 30 November 2016 (UTC)[reply]
  5.   Oppose Nothing forced works--Leon saudanha (talk) 23:02, 30 November 2016 (UTC)[reply]
  6.   Oppose very hard to new user for understanding and "ribet"Murbaut (talk) 13:09, 1 December 2016 (UTC)[reply]
  7.   Support I am not an admin. I feel like those who are and who therefore have more responsibilities should take measures to protect their accounts. Having a secure password is not overkill, it is as simple as having a functional lock on your door. -- Kndimov (talk) 17:55, 1 December 2016 (UTC)[reply]
  8.   Oppose --Jojhnjoy (talk) 18:26, 1 December 2016 (UTC)[reply]
  9.   Neutral for the current wording "Make 2FA easier to use". Nothing against making it easier to use. But even more important would be to finally require reasonably strong passwords from all users, see also my more detailed comments in the discussion section above. --Gestumblindi (talk) 21:05, 1 December 2016 (UTC)[reply]
  10.   Support any steps about enhancing authentication security including 2FA. We also need to log login history, I opened a quick task about it (maybe a duplicate). --Gryllida 23:16, 1 December 2016 (UTC)[reply]
  11.   Support White Master (es) 04:09, 2 December 2016 (UTC)[reply]
  12.   Oppose. I think 2FA is beneficial. However, it should not be mandatory. LlamaAl (talk) 05:39, 2 December 2016 (UTC)[reply]
  13.   Oppose 2FA is good concept but I'm oppose to the current 2FA because it give my details to a 3rd party site to generate the code, that means someone not associated with the WMF can track my activity. It also needs to be something that isnt smartphone dependent as I dont travel with my phone. Problems greater than easy of use need to addressed first Gnangarra (talk) 06:32, 2 December 2016 (UTC)[reply]
  14.   Oppose--Baskervill talk 07:02, 2 December 2016 (UTC)[reply]
  15.   Oppose This is a way overkill. Users should look for enhancing their passwords instead of requiring stricter authentication.--Kiril Simeonovski (talk) 08:31, 2 December 2016 (UTC)[reply]
  16.   Oppose --Banfield - Reclamos aquí 15:01, 2 December 2016 (UTC)[reply]
  17.   Oppose --Vogone (talk) 23:18, 2 December 2016 (UTC)[reply]
  18.   Support Privileged accounts always need stronger authentication, however should be transparent for the admin user. DPdH (talk) 02:08, 3 December 2016 (UTC)[reply]
  19.   Oppose--Yeza (talk) 12:43, 4 December 2016 (UTC)[reply]
  20.   Oppose Other things matter more. Not a bad idea in general, just very low priority. --Hedwig in Washington (talk) 01:41, 6 December 2016 (UTC)[reply]
  21.   Oppose Muhraz 15:20, 6 December 2016 (UTC)[reply]
  22.   Oppose for many of the reasons stated above. Tiggerjay (talk) 20:38, 6 December 2016 (UTC)[reply]
  23.   Support! — RandomDSdevel (talk) 20:34, 7 December 2016 (UTC)[reply]
  24.   Oppose 2FA in any guise is a PITA for active editors. Miniapolis 18:34, 8 December 2016 (UTC)[reply]
  25.   Oppose You can do whatever you want for yourself, but you can't force others to do whatever you want. — regards, Revi 12:31, 10 December 2016 (UTC)[reply]
  26.   Support Easier 2FA, but still voluntary. --Yann (talk) 23:01, 12 December 2016 (UTC)[reply]

Make renames trivial on backend

  • Problem: rename of users is a heavy and complicated operation, involving DBA and devs (and even more so for users with many edits)
  • Who would benefit: Stewards, global renamers, users being renamed, DBA, developers (namely legoktm), Disk space on WMF servers.
  • Proposed solution: see ticket for details

Community discussion

Voting – Trivial renames

  1. {{Neutral}} Seems a general good idea for its narrow use, but I don't think this will be taken as a great value for the wiki projects overall. Stevie is the man! Talk • Work 17:17, 28 November 2016 (UTC)[reply]
    Changed my mind to   Support after reading many of the informative support comments below. You have convinced me! :) Stevie is the man! Talk • Work 20:48, 7 December 2016 (UTC)[reply]
  2.   Support sounds like a useful task. Gryllida 23:18, 1 December 2016 (UTC)[reply]
  3.   Support would definitely make renames much easier, potentially opening up to self-service renames. Legoktm (talk) 03:13, 2 December 2016 (UTC)[reply]
  4.   Support--Kiril Simeonovski (talk) 08:12, 2 December 2016 (UTC)[reply]
  5.   Support I agree that this should be as simple as possible to save time for other tasks. Zapyon (talk) 14:10, 2 December 2016 (UTC)[reply]
  6.   Neutral Not clear what the proposal is, but I am not an admin nor a steward. Emir of Wikipedia (talk) 15:09, 2 December 2016 (UTC)[reply]
  7.   Support, a good thing which needs to be done and won't be done unless enough people keep stressing its importance. --Vogone (talk) 23:19, 2 December 2016 (UTC)[reply]
  8.   Support Needs to be done, even if it won't score highly during this process. – Ajraddatz (talk) 06:11, 4 December 2016 (UTC)[reply]
  9.   Support -- the wub "?!" 16:39, 4 December 2016 (UTC)[reply]
  10.   Support Some users with a lot of edits cannot be renamed presently, due to the database workload. --Rschen7754 04:42, 5 December 2016 (UTC)[reply]
  11.   Support Mark Schierbecker (talk) 08:18, 5 December 2016 (UTC)[reply]
  12.   Support Huji (talk) 19:29, 5 December 2016 (UTC)[reply]
  13.   Support I see requests for username changes often enough as an admin, especially from newer editors who are just getting familiar with project policies. Because of all the backend work needed, the rename can take some time. By the time the rename is done, some editors simply go inactive. I JethroBT (talk) 20:42, 5 December 2016 (UTC)[reply]
  14.   Support Yes good idea to make it easier, but please not a self-rename feature. Our poor logs... Low priority, tho. --Hedwig in Washington (talk) 01:45, 6 December 2016 (UTC)[reply]
  15.   Support Muhraz (talk) 15:28, 6 December 2016 (UTC)[reply]
  16.   Support I was surprises to see just how dirty usernames are currently handled in the DB. This is a step in the right direction. Tiggerjay (talk) 20:41, 6 December 2016 (UTC)[reply]
  17.   Support Please. Ks0stm (T•C•G) 21:05, 6 December 2016 (UTC)[reply]
  18.   Support Would be very helpful and should avoid many problems, such as contributions lost in process. One difficult case I have observed is uk:Special:Contributions/Renamed user 000001 where user's contributions were attached to a wrong account in user contributions but are attached to the correct one in edit history — NickK (talk) 13:36, 7 December 2016 (UTC)[reply]
  19.   Support Very much support this as it currently is very difficult to rename high edit number users. -Djsasso (talk) 18:11, 7 December 2016 (UTC)[reply]
  20.   Support! — RandomDSdevel (talk) 22:44, 7 December 2016 (UTC)[reply]
  21.   Support Miniapolis 18:16, 8 December 2016 (UTC)[reply]
  22.   Support MER-C (talk) 04:35, 10 December 2016 (UTC)[reply]
  23.   Support OrsolyaVirág (talk) 11:29, 10 December 2016 (UTC)[reply]
  24.   Support It should help streamline operations. --Caballero1967 (talk) 23:17, 11 December 2016 (UTC)[reply]
  25.   Support. RadiX∞ 02:45, 12 December 2016 (UTC)[reply]
  26.   Support Quiddity (talk) 04:15, 12 December 2016 (UTC)[reply]

Make the display of protection templates automatic

  • Problem: (This description applies to the English Wikipedia. The situation on other wikis may or may not differ.) Page protection involves two separate steps, one to protect the page and one to add a template to indicate that this is so. The second step is superfluous on a technical level. Worse, when protection expires, the protection template currently has to be removed "manually", either by bot or in some cases by hand (bots don't seem to catch all occurrences).
  • Who would benefit: Admins.
  • Proposed solution: Automatically display a mark to indicate protection status, exactly as is done with templates currently, or configure which template or parameters correspond to which protection status. Leave configurable on a per-wiki basis whether to use this mechanism or not.

Community discussion

  • A really needed feature. It was asked twice (in 2014 and 2015) in my Finnish Wikipedia talk page that why I didn't add the protection template after I protected a page. My answer in 2014 was that I don't want to get a notification then that "your edit was reverted" (because there is a user who reverts your template addition after the protect ends) and in 2015 I found out that there is a d:MediaWiki:Gadget-ProtectionIndicators.js on Wikidata that does the work (automatically adds the template) but I haven't tested would it work on Wikipedia. --Stryn (talk) 18:45, 16 November 2016 (UTC)[reply]
If this eature is implemented, it needs to be smarter than simply looking at the page's own protection log - specificly, title blacklist and cascading-protection need to be handled. עוד מישהו Od Mishehu 19:26, 16 November 2016 (UTC)[reply]
I'm pretty sure that cascade-protected pages "know" whether or not they are protected. Maybe there's something I'm missing? Thanks. Samsara (talk) 21:14, 16 November 2016 (UTC)[reply]
If memory serves, the issue with having the protection status auto-display is a performance issue: Looking up protection status every time an edit page is called is cheap, every time the regular page is called not so much. Jo-Jo Eumerus (talk, contributions) 19:27, 17 November 2016 (UTC)[reply]
Simple question of setting the right triggers for caching. Absolutely not rocket science by any stretch of the imagination. Samsara (talk) 21:02, 17 November 2016 (UTC)[reply]
In terms of existing pages, only those pages with the NOEDIT flag are relevant. On English Wikipedia (the biggest wiki, I beleive), we did have an addition of the noedit flag in early October, an other addition of one in mid June, and nothing otherwise since the beginning of April, so caching would probably tend to work well. An other possible solution would be for the software to keep an internal list of the noedit entries, updating the list every time the blacklist is updated, and checking all pages aginast it (there are currently only 7 such lines in English Wikipedia); this would take much less time than checking the entire blacklist. עוד מישהו Od Mishehu 14:20, 24 November 2016 (UTC)[reply]

I think the best is to not show some template(s) but just add CSS classes indicating all protection statuses of the page. Like mw-protection-move-sysop, mw-protection-edit-none, mw-protection-edit-sysop-cascade and so forth (I do not claim my naming is the best possible). Then the communities can do or not do whatever they want with those classes. Some may show a fancy message for everybody, some would do it just for some types of protection in some namespaces, some will build opt-inable gadgets and some will just leave it up to the users' CSS knowledge. Even if it is too difficult to implement for cascade variant it would be nice to have it at least for simple one. --Base (talk) 16:35, 28 November 2016 (UTC)[reply]

@StevenJ81: It is the current "manual" mechanism that draws attention to unprotection, which is one problem the proposed change will address. Samsara (talk) 22:34, 29 November 2016 (UTC)[reply]

@Samsara: Perhaps. But in some cases seeing the lock on the page at all creates attention in and of itself. StevenJ81 (talk) 22:46, 29 November 2016 (UTC)[reply]
@StevenJ81: Sometimes I see editors put the lock on articles that aren't protected at all, and that deception works to some extent, too. So I think having a lock displayed cuts both ways. Samsara (talk) 00:37, 30 November 2016 (UTC)[reply]
@Samsara: I've responded below. In short, I'm still not so fond of automatic placing of the lock. But I'm ok with automatic removal when protection ends. StevenJ81 (talk) 03:56, 30 November 2016 (UTC)[reply]

Voting – Automatic protection templates

  1.   Supportadd a new message at page header? see phabricator:T20418--Shizhao (talk) 02:26, 28 November 2016 (UTC)[reply]
  2.   Neutral Not all protected pages need or should have a protection template (for example, user pages). Moreover if a page has many types of protection, such as semi-edit, full-move, current enwiki practice is to have only a silver lock, not also a green one. While I wouldn't oppose this feature in article space it would have to be highly configurable and per-page overridable to fit community norms about use of protection templates. BethNaught (talk) 08:00, 28 November 2016 (UTC)[reply]
    {{#Support}}, for the reasons I gave in the comments section. --Stryn (talk) 11:23, 28 November 2016 (UTC) I didn't know it's as easy as just creating fi:MediaWiki:Gadget-ProtectionIndicator.js. So just a gadget is fine. --Stryn (talk) 14:21, 9 December 2016 (UTC)[reply]
  3.   Support--Kudpung (talk) 12:33, 28 November 2016 (UTC)[reply]
  4.   Oppose The obvious solution would be abolish nonsensical protection templates. The protection reason is already shown when one tries to edit. --MF-W 14:16, 28 November 2016 (UTC)[reply]
  5. Comment. I hate the template-boilerplate as much as the next person, but the reason here *is* solid: to inform the readership that the page is currently controversial, or currently subject to intense vandalism, or potentially outdated, or whatever. It isn't a note to editors (they get that note when they click edit), it is a note intended for readers, to alert them that things might not be kosher with the article-content (because normal editing is under some restriction). 47.222.203.135 14:00, 3 December 2016 (UTC)[reply]
  6.   Oppose agree with MF-W.--Steinsplitter (talk) 15:10, 28 November 2016 (UTC)[reply]
  7.   Support in my comment's implementation proposal. --Base (talk) 16:35, 28 November 2016 (UTC)[reply]
  8.   Neutral This has a feel of automating something that maybe shouldn't exist the way it does now. There should be wide discussion about whether these templates are needed at all (per MF-W) or whether a simpler approach is pursued per Base's idea. Stevie is the man! Talk • Work 17:31, 28 November 2016 (UTC)[reply]
  9.   Support Useful for small and middle wikis JAn Dudík (talk) 21:26, 28 November 2016 (UTC)[reply]
  10.   Support --Izno (talk) 00:25, 29 November 2016 (UTC)[reply]
  11.   Oppose per MF-W. These are a total eyesore imo. -FASTILY 09:14, 29 November 2016 (UTC)[reply]
  12.   Support Useful, though of course as with previous changes of this nature it will exacerbate the "we're losing editors" meme. I take the point that logged in people will learn this info when they try to edit. But if you aren't logged in you just don't see an edit button so this or some sort of template is needed. WereSpielChequers (talk) 12:20, 29 November 2016 (UTC)[reply]
  13.   Oppose You may use CSS instead to display protection level  @xqt 13:44, 29 November 2016 (UTC)[reply]
  14. {{oppose}}, mostly per MF-W. Additionally: it seems to me that sometimes we want there to be a clear indication of protection, and sometimes we don't want to draw unusual attention to it. Better to leave manual. StevenJ81 (talk) 17:06, 29 November 2016 (UTC)[reply]
      Neutral I'm still not all that fond of automatic placing of protection templates. I'm opposed to that, and if this proposal goes through in full, I really want it to be configurable. But on the assumption that protection templates will continue to exist, I'm ok with their automatically disappearing when protection ends. StevenJ81 (talk) 03:54, 30 November 2016 (UTC)[reply]
  15.   Support – This is a great idea! It can be so useful! Wikis that don't want these automatic protection messages will be able to disable them via CSS or by blanking the appropriate system messages (I guess). Guycn2 · ☎ 17:30, 29 November 2016 (UTC)[reply]
  16.   Support. Surprised this isn't automatic already.--Telaneo (User talk page) 21:20, 29 November 2016 (UTC)[reply]
  17.   Support, preferably with a toggle for local enabling/disabling. This should be an option for local wikis who decide all protected pages should have such a template. BU Rob13 (talk) 05:34, 30 November 2016 (UTC)[reply]
  18.   Support Although it considers valid the ponderation of MF-W, ban the use of these templates in 27 wikis is practically impossible. It's up to the developers to make this process automatic and standard in all wikipedias and another wiki projects.--Leon saudanha (talk) 23:52, 30 November 2016 (UTC)[reply]
  19.   Support Beagel (talk) 17:58, 1 December 2016 (UTC)[reply]
  20.   Support Great idea. --AmaryllisGardener talk 18:53, 1 December 2016 (UTC)[reply]
  21.   Neutral Not relevant for German-language Wikipedia (my home Wikipedia); protection templates aren't used there. Apparently, the message indicating that a page is protected when trying to edit it is seen as sufficient. --Gestumblindi (talk) 21:15, 1 December 2016 (UTC)[reply]
  22.   Oppose per MW-F. Readers don't need to know whether a page is protected or not, there is no need to show the template in read tab view. --Gryllida 23:21, 1 December 2016 (UTC)[reply]
  23.   Support being able to to automate the templates inclusion immediately is a good idea, knowing a content dispute is taking place is beneficial to readers. Also knowing it get removes immediately when the protection expires is equally beneficial. Gnangarra (talk) 06:39, 2 December 2016 (UTC)[reply]
  24.   Support--Kiril Simeonovski (talk) 08:28, 2 December 2016 (UTC)[reply]
  25.   Support Draceane (talk) 09:43, 2 December 2016 (UTC)[reply]
  26.   Support —Jc86035 (talk) 11:05, 2 December 2016 (UTC)[reply]
  27.   Oppose already done with css. Multichill (talk) 13:56, 2 December 2016 (UTC)[reply]
  28.   Support --Morten Haan (talk) 23:11, 2 December 2016 (UTC)[reply]
  29.   Oppose, unnecessary feature. --Vogone (talk) 23:13, 2 December 2016 (UTC)[reply]
  30.   Support Jianhui67 talk★contribs 10:01, 3 December 2016 (UTC)[reply]
  31.   Support along the same lines as the temp admin access proposal; it can be enabled as an option, and would save volunteer time by automatically updating things. – Ajraddatz (talk) 06:12, 4 December 2016 (UTC)[reply]
  32.   Support Sounds good. Great idea !! IMHO :) — TBhagat (talk) 07:10, 4 December 2016 (UTC)[reply]
  33.   Neutral The problem about automatically adding the protecting information may lead to some problems, especially on main pages. If you go to Wikipedia and each time you see a Protected, what would you think? You may think if it is free to edit and everyone edit. Thus, I am casting my neutral vote. If the proposal gets improved such that some highly visible pages won't get notified to everyone, then I will cast a support ticket. I don't cast an opposition is because of the goodwill of this proposal.--1233 | Questions?| This message is left by him at 15:05, 5 December 2016 (UTC)[reply]
  34.   Oppose No need to be shown the details of protection in read view Huji (talk) 19:30, 5 December 2016 (UTC)[reply]
  35.   Support --Sphilbrick (talk) 21:58, 5 December 2016 (UTC)[reply]
  36.   Support as nominator. Samsara (talk) 13:04, 6 December 2016 (UTC)[reply]
  37.   Support Useful feature. Muhraz (talk) 15:29, 6 December 2016 (UTC)[reply]
  38.   Support but would suggest a very minimalistic approach to the automatic template applied only to article space and also automatically detects if another manual protection template is used. There are cases where a custom template may be more appropriate than the automatic template. While we're at, standardize the way 'manual templates' for page protection are created so (1) they turn off the automatic one; with a side benefit of (2) being much easier for the bots to detect and remove. Tiggerjay (talk) 20:45, 6 December 2016 (UTC)[reply]
  39.   Oppose per MW-F. -- Amanda (aka DQ) 20:48, 6 December 2016 (UTC)[reply]
  40.   Oppose Sometimes it is better to choose the protection template to display and in what form, rather than have it done automatically. Ks0stm (T•C•G) 21:06, 6 December 2016 (UTC)[reply]
    @Ks0stm: It seems to me this should be done during the protection step. We already implicitly do this when we select BLP vs. V vs. disruptive vs. dispute etc. Samsara (talk) 15:17, 7 December 2016 (UTC)[reply]
    Maybe I'm weird, but I just like doing it myself. Takes me all of two seconds with Twinkle. Not to mention that you can do both at the same time with Twinkle if you so choose. Ks0stm (T•C•G) 21:02, 7 December 2016 (UTC)[reply]
  41.   Oppose, this should not be a Community Tech project. These features are already available in several project, for example, such gadget is already available in Ukrainian Wikipedia at uk:MediaWiki:Gadget-ProtectionIndicator.js. There is no need to make it a Community Tech project: this needs just a few lines of JavaScript and a community consensus to implement it. This can be perfectly done without WMF staff — NickK (talk) 14:02, 7 December 2016 (UTC)[reply]
  42.   Support! — RandomDSdevel (talk) 22:45, 7 December 2016 (UTC)[reply]
  43.   Support --Dirk Beetstra T C (en: U, T) 08:39, 8 December 2016 (UTC)[reply]
  44.   Oppose Unnecessary complexity and loss of flexibility. What if you want a protected page to not display a protection template for some reason? What about cascading protection? Pppery (talk) 17:49, 8 December 2016 (UTC)[reply]
  45.   Support Miniapolis 18:18, 8 December 2016 (UTC)[reply]
  46.   Support SarahSV talk 15:30, 11 December 2016 (UTC)[reply]
  47.   Support--David1010 (talk) 20:17, 11 December 2016 (UTC)[reply]
  48.   Support MrX (talk) 22:52, 12 December 2016 (UTC)[reply]

Allow user rights to expire automatically

Note: References to the "proposal above" and "previous proposal" are to a proposal which was removed.

  • Who would benefit: Would save work from stewards if the removal is done automatically, and logs would look better with automatic summaries. Also can get rid of the page mentioned above. This could also help wikis that want user rights granted for a specific period of time, e.g. wikis that have decided admins are elected for a specific period of time.
  • Proposed solution: When granting user rights, add a new option to set a time how long the rights will last (maybe a drop-down menu?).
  • Phabricator tickets:

Community discussion

Qwertz84: Would it be OK if we considered these proposals as duplicates and moved ahead with only one to the voting phase? As for how it'd be used, that discussion is bigger than a proposal in this technical wishlist. /Johan (WMF) (talk) 16:45, 15 November 2016 (UTC)[reply]
OK for me. Thanks. Qwertz84 (talk) 17:26, 15 November 2016 (UTC)[reply]
It looks goodMurbaut (talk) 00:55, 16 November 2016 (UTC)[reply]
Certainly - see my comment above. The technical ability belongs in the wishlist, the actual use belongs in a community discussion. עוד מישהו Od Mishehu 03:57, 16 November 2016 (UTC)[reply]
Stryn, Qwertz84: I've added a sentence to this proposal to highlight that it could be useful not only for stewards, merging it with the technical parts of Qwertz84's suggestion. Please edit/undo if there's a problem with this. /Johan (WMF) (talk) 12:04, 16 November 2016 (UTC)[reply]
Fine to me. --Stryn (talk) 12:07, 16 November 2016 (UTC)[reply]

This sounds like phabricator:T18509 / phabricator:T12493. --MZMcBride (talk) 05:22, 17 November 2016 (UTC)[reply]

I'd assume the "make" is to be read in connection with "automatically" – that is, if the user right is expiring (which some communities already have by default, or because it was a temporary user right), it's already expiring – just manually, which is a hassle. (: Stryn, would you like to clarify this maybe, to be on the safe side? /Johan (WMF) (talk) 12:17, 25 November 2016 (UTC)[reply]
Ah, a good catch. Of course it should be allow, because make sounds like it will be then a default setting. --Stryn (talk) 14:21, 25 November 2016 (UTC)[reply]

Yes! And it should have normal prolonging feature. Current practice of prolonging temporal flagship by removing the flag and giving it right away back with a new comment is just stupid. --Base (talk) 16:39, 28 November 2016 (UTC)[reply]

Voting – Automatic expiring of user rights

  1.   Support optional userright expiry. This would be useful on English Wikipedia for assigning "account creator" for specific events. BethNaught (talk) 08:02, 28 November 2016 (UTC)[reply]
  2.   Support Would definitely be nice to have. Samwalton9 (talk) 08:59, 28 November 2016 (UTC)[reply]
  3.   Support very much useful for steward work. – Ajraddatz (talk) 09:11, 28 November 2016 (UTC)[reply]
    Agree also with Base that there should be an extending option as well. – Ajraddatz (talk) 21:33, 29 November 2016 (UTC)[reply]
  4.   Support Léna (talk) 11:05, 28 November 2016 (UTC)[reply]
  5.   Support --Stryn (talk) 11:24, 28 November 2016 (UTC)[reply]
  6.   Support Jules78120 (talk) 12:18, 28 November 2016 (UTC)[reply]
  7.   Support as an optional feature, so we can manage everything from SRAT in an automatic fashion. —MarcoAurelio 15:09, 28 November 2016 (UTC)[reply]
  8.   Support --Base (talk) 16:39, 28 November 2016 (UTC)[reply]
  9.   Support. Stevie is the man! Talk • Work 17:36, 28 November 2016 (UTC)[reply]
  10.   Support useful for granting ip-block-exempt at Commons during WLM contests and and for eliminators at fawiki who are elected for a one-year tenure. 4nn1l2 (talk) 18:27, 28 November 2016 (UTC)[reply]
  11.   Support MichaelMaggs (talk) 19:45, 28 November 2016 (UTC)[reply]
  12.   Support as possibilty, oppose as default. JAn Dudík (talk) 21:27, 28 November 2016 (UTC)[reply]
  13.   Support This should be possible. Matěj Suchánek (talk) 21:40, 28 November 2016 (UTC)[reply]
  14.   Strong support -- it would be exceptionally useful for IPBE to expire along with the block affecting the user, this would allow temporary user-rights for specific events, and making this technically possible opens up a whole new set of proposals possible on local projects w/r/t to time-defined adminship/cratship (one, two, three years) and user-right debundling. ☺ · Salvidrim! · ✉ 00:21, 29 November 2016 (UTC)[reply]
  15.   Support also good for the "flood" right use case. --Izno (talk) 00:25, 29 November 2016 (UTC)[reply]
  16.   Support — Jeblad 02:02, 29 November 2016 (UTC)[reply]
  17.   Support -FASTILY 09:14, 29 November 2016 (UTC)[reply]
  18.   Oppose this would further normalise the damaging process of removing userrights from currently inactive accounts. We should be more concerned at reactivating and welcoming back currently inactive editors, not doing things to make them feel unwelcome when they return. WereSpielChequers (talk) 12:23, 29 November 2016 (UTC)[reply]
    None of the potential use cases of this relate to removal for inactivity. How could you even use this for that purpose? Is there a standard time that people stay active for after being granted advanced permissions? – Ajraddatz (talk) 21:32, 29 November 2016 (UTC)[reply]
    May I point out the usercases in Salvidrim's support rationale? There are those who would support using this feature to put all userights holders on a treadmill with userrights only renewable if you maintain an obsessive level of activity. WereSpielChequers (talk) 13:47, 1 December 2016 (UTC)[reply]
    I assume he's talking about temporary access on small wikis, or temporary access based on membership on arbcom as dewiki does. There are any number of uses for it, without the stretch of forcing all permissions holders to spend their lives on here. I too would not support such an outcome, but this is just the technical framework for the numerous cases in which this would be beneficial and useful. – Ajraddatz (talk) 05:35, 2 December 2016 (UTC)[reply]
  19.   Support Mahdy Saffar (talk) 13:23, 29 November 2016 (UTC)[reply]
  20.   Support  @xqt 13:42, 29 November 2016 (UTC)[reply]
  21.   Support --Zerabat (discusión) 16:44, 29 November 2016 (UTC)[reply]
  22.   Oppose I am a little concerned about the social effects such a change may have - that it would encourage the use of such expiry in situations where it is not appropriate (arguments about how long a given permission should last). Jo-Jo Eumerus (talk, contributions) 17:27, 29 November 2016 (UTC)[reply]
  23.   Support. --Telaneo (User talk page) 21:20, 29 November 2016 (UTC)[reply]
  24.   Support BU Rob13 (talk) 05:17, 30 November 2016 (UTC)[reply]
  25.   Support optional, ofc. --Vituzzu (talk) 14:25, 30 November 2016 (UTC)[reply]
  26.   Support --Mess (talk) 18:46, 30 November 2016 (UTC)[reply]
  27.   Support would be great for cases of ipblock-exempt, which have to be manually removed after a certain period of use--Leon saudanha (talk) 00:02, 1 December 2016 (UTC)[reply]
  28.   Support This would be great on the English Wikipedia where we temporarily grant account creator rights for editathons. I've encountered a few accounts here or there who did not have the rights removed until a few months later. I also see this as being beneficial for the stewards when they grant yearly adminships to users on smaller wikis. Mike V • Talk 02:38, 1 December 2016 (UTC)[reply]
  29.   Support MER-C (talk) 05:57, 1 December 2016 (UTC)[reply]
  30.   Support I don't understand Jo-Jo Eumerus and WereSpielChequers. You are opposed to use that in your wiki, but let the possibility for others wiki which can be interested... --Nouill (talk) 12:54, 1 December 2016 (UTC)[reply]
    I am not thinking just of enwiki. Jo-Jo Eumerus (talk, contributions) 16:22, 1 December 2016 (UTC)[reply]
  31.   Support Good idea Murbaut (talk) 13:05, 1 December 2016 (UTC)[reply]
  32.   Support This would, appropriately, make user rights like driving--you have to get re-certified every few years to ensure you're still competent enough to have the rights/driver's license. Everymorning (talk) 23:30, 1 December 2016 (UTC)[reply]
  33.   Support White Master (es) 04:10, 2 December 2016 (UTC)[reply]
  34.   Support. Could be useful. LlamaAl (talk) 05:49, 2 December 2016 (UTC)[reply]
  35.   Support I think useful.--Baskervill talk 07:02, 2 December 2016 (UTC)[reply]
  36.   Support Jmvkrecords ⚜ (Intra talk) 07:21, 2 December 2016 (UTC).[reply]
  37.   Oppose Automatic expiry of user rights may be useful only in case of having inactive users that should be stripped off their special user rights because of inactivity. In all other cases, it is very confusing to me how one determines the time length one should be granted special user rights for. It might lead to policy changes towards re-granting the user rights for a longer time after the expiry of the shortest time length, which is not at all the set-up that we should be aiming for.--Kiril Simeonovski (talk) 08:49, 2 December 2016 (UTC)[reply]
    How could it be used for inactivity-based removals? Different users go inactive at different rates; it makes no sense that this could be used to predict how long a user will stay active when it is first being assigned. We already have temporary permissions - see SRAT for an example of how they need to be manually tracked. This way, the system would do it automatically, and we wouldn't need to worry about people slipping through the cracks or spending extra volunteer time managing the antiquated system. – Ajraddatz (talk) 06:07, 4 December 2016 (UTC)[reply]
  38.   Support —Jc86035 (talk) 11:06, 2 December 2016 (UTC)[reply]
  39.   Support--Sannita - not just another it.wiki sysop 13:54, 2 December 2016 (UTC)[reply]
  40.   Support Emir of Wikipedia (talk) 15:10, 2 December 2016 (UTC)[reply]
  41.   Oppose not convinced that process wont be corrupted as way to avenge the actions of a sysop/crat/cu/steward when hard decisions were necessary, previously even trusted arbcom committee members have openly acted or campaigned on such reasons. Gnangarra (talk) 16:01, 2 December 2016 (UTC)[reply]
  42.   Support it'll be useful MohammadtheEditor (talk) 17:24, 2 December 2016 (UTC)[reply]
  43.   Support. Yes, this is definitely useful. --Vogone (talk) 23:14, 2 December 2016 (UTC)[reply]
  44.   Support less burden, less errors. DPdH (talk) 01:54, 3 December 2016 (UTC)[reply]
  45.   Support Good idea. Sensible suggestion by Stryn. Jianhui67 talk★contribs 09:56, 3 December 2016 (UTC)[reply]
  46.   Support --Teukros (talk) 10:19, 3 December 2016 (UTC)[reply]
  47.   Support--Àlex (talk) 10:46, 3 December 2016 (UTC)[reply]
    (support), this is the equivalent of en:Term limits for politicians. The argument that the auto-expiration could improperly ALWAYS be treated as the equivalent of rights-stripping through intent of a completed discussion about a desysop action (or whatever the specific case might be in a given instance), is troublesome... we don't want to have admins stripped of adminship by some term-limit-bot, and then pretend that is MORALLY equivalent to being desysop'd. It ain't. But methinks implementing this feature *will* be very useful, in cases where the INTENT is to grant rights with auto-expiration: for a one year trial-by-fire period prior to granting the usual indef adminship, for deputizing some editors temporarily as a means of "creating a posse" to deal with an unexpected spike in vandalism or blatant COI or similar emergencies, for the duration of a wikiconference, and similar scenarios. There are many ways this feature could improve wiki-gridlock. To make it clear that this is Just A Bot™ acting without malice nor intent, mayhap it will help if the feature is implemented so that, instead of *stripping* the person of their admin-bit (or whatever the case might be), instead the person has their bit marked as suspended-by-bot-action? Thataway, there is not just a semantic difference (desysop versus bit-expired-and-bot-stripped-it), but there is a actually a technological distinction (bit-stripped versus bit-suspended-due-to-timeout-expiration). This distinction would also help in cases such as the admin-passwd-compromise scenario, where the admin-bit of the cracked username can be suspended (by setting the timeout to "right now"), and then later when the crack is corrected the admin-bit can be restored (by resetting the timeout to the previous value of "indefinite length"). It will take some care to implement this properly, but when finished it will be very useful. 47.222.203.135 14:58, 3 December 2016 (UTC) Please log in and sign your comment -- we can't accept votes from anonymous users. Thanks! -- DannyH (WMF) (talk) 16:04, 3 December 2016 (UTC)[reply]
  48.   Support --TerraCodes (talk) 03:27, 4 December 2016 (UTC)[reply]
  49.   Oppose It's a security truism that unused access should be terminated, so on the surface this makes good sense. However, as a matter of practice this is very rarely a problem. At least on enwiki, the number of problems I'm aware of that have been caused by unused account creator flags is zero. The number of known problems from IPBE is countable on one hand. Most recent account compromises have involved accounts in active use. I wouldn't like to see scarce development resources invested in solutions to largely hypothetical problems, especially when those solutions could have unpredictable and destabilizing social consequences. Opabinia regalis (talk) 04:14, 4 December 2016 (UTC)[reply]
    @Opabinia regalis: so it might not be a good thing to use on enwiki, but that doesn't mean that it wouldn't be good elsewhere. Stewards, for example, use temporary access on smaller projects without local communities as a 'check' on indefinitely-tenured sysops controlling the projects without oversight. It's already possible for access to be temporary - you just remove it when it expires. The only change this would have is remove the need to manually track it like at SRAT. Also, the phrase "unused accounts" has come up a bunch here, but I don't see how this proposal is related to it. Can we magically predict when admin accounts go inactive, to assign that expiry time when the rights are first given? Do we calculate the average and then use that as the expiry time? That doesn't make sense to me. – Ajraddatz (talk) 06:04, 4 December 2016 (UTC)[reply]
    If it were exclusive to the stewards' interface for the purpose of managing small wikis, that would be reasonable. But you can see from the comments that people are imagining lots of local use cases where the purported problem to be solved isn't actually a problem as experienced on the largest project, where such problems would be most likely to turn up. (To be honest, the prospect of people wanting to use this to further limit IPBE is by itself enough to make me want to dig my heels in.)
    On the unused accounts thing, I expect what people are imagining is to routinely grant user rights for some limited but long amount of time and allow renewal on request, thus quietly removing from the group anyone who doesn't show up to request renewal. This of course is extremely vulnerable to pressure for a change from "renew on request" to "renew only after review". Opabinia regalis (talk) 04:09, 5 December 2016 (UTC)[reply]
    Well, I certainly wouldn't want any of those scenarios to come true... I suppose I'm thinking just of my own work here, without taking the community's ability to co-opt new inventions into mind. I'm getting flashbacks of ECP... – Ajraddatz (talk) 09:12, 5 December 2016 (UTC)[reply]
  50.   Support Great idea — TBhagat (talk) 07:15, 4 December 2016 (UTC)[reply]
  51.   Support Sounds like this could facilitate some good changes. AndrewRT (talk) 12:04, 4 December 2016 (UTC)[reply]
  52.   Support--Yeza (talk) 12:45, 4 December 2016 (UTC)[reply]
  53.   Support Currently we have SRAT, but it depends on stewards using the right template, which (sadly) quite a few forget to do, resulting in the user having the rights indefinitely. I could see other uses too: to facilitate rights on wikis that have yearly elections, or for stewards to temporarily self-grant themselves rights (because some forget to remove the rights after they're done). --Rschen7754 04:38, 5 December 2016 (UTC)[reply]
  54.   Support This is the classical example of what computers can do better than humans. Let the computers do it! Huji (talk) 19:31, 5 December 2016 (UTC)[reply]
  55.   Neutral I can see some ways where this would be helpful, but the proposal is too vague. I think that this should not only be optional, but also that it should explicitly apply only to future situations in which rights are granted. It would be far too vulnerable to abuse if it could be applied retroactively to rights that were granted in the past. --Tryptofish (talk) 21:34, 5 December 2016 (UTC)[reply]
    I endorse Tryptofish's restriction, although I continue to support this proposal. Stevie is the man! Talk • Work 12:59, 6 December 2016 (UTC)[reply]
  56.   Support Very useful and essential. Thank you. --Smorteza (talk) 05:56, 6 December 2016 (UTC)[reply]
  57.   Support --Nikosguard (talk) 09:26, 6 December 2016 (UTC)[reply]
  58.   Support Muhraz (talk) 15:31, 6 December 2016 (UTC)[reply]
  59.   Support. There are many non-controversial uses for that and not only for small wikis. For instance, Portuguese Wikipedia elects their checkusers for a one year term. Even if the user is elected again, the right has to be removed and added again. Sometimes, people just forget the expirying date and the checkuser keeps the right longer than should.—Teles «Talk to me ˱C L @ S˲» 16:46, 6 December 2016 (UTC)[reply]
  60.   Support even if someone who takes extended wikibreaks, like myself, having those rights restored should be trivial. While the upside is that an abandoned account is less suseptiable to abuse if hacked becauase the rights are removed. Tiggerjay (talk) 20:46, 6 December 2016 (UTC)[reply]
  61.   Support -- Amanda (aka DQ) 20:49, 6 December 2016 (UTC)[reply]
  62.   Support Ks0stm (T•C•G) 21:07, 6 December 2016 (UTC)[reply]
  63.   Support, under condition that it will be available by default only to stewards for temporary permissions and to opt-in projects like Swedish Wikipedia — NickK (talk) 14:56, 7 December 2016 (UTC)[reply]
  64.   Support! — RandomDSdevel (talk) 22:47, 7 December 2016 (UTC)[reply]
  65.   Oppose Per Opabinia regalis & WereSpielChequers. Espresso Addict (talk) 05:44, 8 December 2016 (UTC)[reply]
  66.   Support Amir (talk) 18:13, 8 December 2016 (UTC)[reply]
  67.   Support Miniapolis 18:20, 8 December 2016 (UTC)[reply]
  68.   Oppose Per Opabinia regalis. There must be a concern of community (or at least some members) to remove rights. Cf. a case in cs.wikipedia, where removed rights were +/- immediately re-voted to keep/restore. --Kusurija (talk) 19:26, 9 December 2016 (UTC)[reply]
  69.   Oppose Per Opabinia regalis & WereSpielChequers. There seems to be amisunderstanding that the operative word automatic in this proposal means a back-door introduction of term limits. Term limits for any user group should be proposed and debated by local Wikipedias. Kudpung (talk) 02:38, 10 December 2016 (UTC)[reply]
    I would also say that there is a misunderstanding about what this proposal means. Adding this technical function would only allow existing temporary permissions to be removed automatically instead of manually. And other changes would require consensus on said local Wikipedias, as always is the case when new technology is introduced. – Ajraddatz (talk) 02:48, 10 December 2016 (UTC)[reply]
    I wish it were true that new technology always required local consensus, that would require a major change of mindset at the WMF, but it would be a huge change for the better across the movement. A few years of that and much of the distrust of the WMF would go. However I do accept that this feature is likely to be driven by local consensus - the WMF is somewhat concerned about editor retention and is likely to be less keen on this "term limits by the back door" proposal. WereSpielChequers (talk) 08:17, 10 December 2016 (UTC)[reply]
  70.   Oppose This goes against the very fundamental wiki principle of permissiveness and AGF by default: user rights should be provided not as an award for past work, or recent commitment, but as the removal of barriers for future work. The cases of temporary rights *should* remain exceptions, and therefore the manual processing of such cases rightly enforces the social norms that we've developed over time, and which we should never underestimate, considering that our principles of minimization of personal merit in favor of collaborative resource-building are pretty much an exception in modern societies. --Waldir (talk) 09:35, 10 December 2016 (UTC)[reply]
  71.   Support --OrsolyaVirág (talk) 11:31, 10 December 2016 (UTC)[reply]
  72.   Support I believe this will make stewards' life easier by allowing them to set expiration days for my kowikinews and kowikiversity temp sysop. (I don't much care about local use and I don't find any reason local should be using it?) — regards, Revi 12:38, 10 December 2016 (UTC)[reply]
  73.   Support --Burumbátor (talk) 16:14, 10 December 2016 (UTC)[reply]
  74.   Support Very good idea. Reguyla (talk) 18:06, 10 December 2016 (UTC)[reply]
  75.   Support --Misibacsi (talk) 19:10, 10 December 2016 (UTC)[reply]
  76.   Support We have waaay too many inactive ancient admins, most of whom probably have weak passwords.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:15, 11 December 2016 (UTC)[reply]
  77.   Support IJBall (talk) 19:10, 11 December 2016 (UTC)[reply]
  78.   Support--Shanmugamp7 (talk) 02:30, 12 December 2016 (UTC)[reply]
  79.   Support. Matiia (talk) 02:34, 12 December 2016 (UTC)[reply]
  80.   Support It's "along the lines of greatest usefulness". RadiX∞ 02:37, 12 December 2016 (UTC)[reply]

Allow admins to hide names of users while blocking them

  • Problem: Currently, Oversighters have the ability, when blocking a user, to hide the existence of the user from anyone without oversight-level permission - including their block log, creation log, the entry on Special:ListUsers and Special:BlockList. Admins should have the right to do the same for admin-level hiding.
  • Who would benefit: Admins who find usernames which are bad enough to need redacting.
  • Proposed solution: Allow an option in the block user page to allow admins to hide the user, similar to what oversighters have.

Community discussion

phab:T23097 is the existing task. In my opinion, splitting the hideuser right into an oversight-level function and an admin-level function would be the right way to go about this. Jo-Jo Eumerus (talk, contributions) 16:21, 10 November 2016 (UTC)[reply]
I agree, but think that in that case we need to include bureaucrats to the equation as well. –Tommy Kronkvist (talk), 23:46, 12 November 2016 (UTC).[reply]
For what reason? How does hiding usernames relate to assigning community user rights? – Ajraddatz (talk) 03:42, 15 November 2016 (UTC)[reply]
I think if appoval, admin must assigned the confindentially agreement. Murbaut (talk) 05:04, 15 November 2016 (UTC)[reply]
I'm talking about admin-level hiding, which is already being done using RevDel for edits and logs (including the block log), which i a level below oversight-level hiding, where this featur already exists. I see no reason why this requires any higher level of confidentiality. עוד מישהו Od Mishehu 07:01, 15 November 2016 (UTC)[reply]
Oh :), I don't think it in the below os, :)Murbaut (talk) 00:59, 16 November 2016 (UTC)[reply]

Voting – Hiding names of blocked users

  1.   Support Currently, regular admins are unable to properly hide inappropriate usernames. Using RevDel to hide the entries on Special:Log/block and Special:Log/newusers after blocking accounts is virtually useless, since the accounts remain publicly visible on Special:BlockList and Special:ListUsers, which are now full of garbage. See phab:T27763 for more details if you're not aware. Defender (talk) 15:03, 28 November 2016 (UTC)[reply]
  2.   Support and the 'hide' option from CentralAuth should be updated to block at admin-level redaction globally too. —MarcoAurelio 15:07, 28 November 2016 (UTC)[reply]
  3.   Support--Steinsplitter (talk) 15:11, 28 November 2016 (UTC)[reply]
  4.   Support now is problem to rename abusive username JAn Dudík (talk) 21:29, 28 November 2016 (UTC)[reply]
  5.   Support Matěj Suchánek (talk) 21:41, 28 November 2016 (UTC)[reply]
  6.   Oppose I'm not convinced of the need to hide most usernames, and I'm not sure what the added value would be to add admin-level hiding to that. Probably just more hidings than needed. – Ajraddatz (talk) 09:16, 29 November 2016 (UTC)[reply]
    To expand on this a little bit, there are a few points why this isn't a good idea:
    Usernames are now global, so local-level hideuser blocks don't even make sense in the current technical reality. The solution to that isn't creating another level of local-level username hiding.
    Most usernames, even offensive ones, don't actually need to be hidden. The only place they show up is in the user list. They aren't visible. They aren't making people feel uncomfortable or driving them away from reading our wikis. If they are truly grossly offensive, then suppress them. Otherwise, it's a make-work project with little to no benefit.
    The hideuser feature is already misused quite a bit. It doesn't take long looking through suppression logs (especially the meta one involving steward actions, I'm afraid to say) to find accounts which have had their usernames hidden with poor or absent justification. We don't even have a global policy on what the criteria for hiding is in those cases. If nothing else, more work should be done community-side before rolling this out. – Ajraddatz (talk) 22:19, 4 December 2016 (UTC)[reply]
  7.   Support  @xqt 13:43, 29 November 2016 (UTC)[reply]
  8.   Support Clearly a good idea. There are plenty of abusive usernames. ThePlatypusofDoom (talk) 17:25, 29 November 2016 (UTC)[reply]
  9.   Oppose – I don't think this is really necessary. Hiding information should not be done frequently, and when needed – admins can do it using the "change visibility" button on Special:Log/block. Guycn2 · ☎ 17:35, 29 November 2016 (UTC)[reply]
  10.   Support - This issue has been nothering me during my work at English Wikipedia to complete the hiding of log entry data (e.g requests to block users with highly disruptive names, patrol log entries for deleted pages where the deletion log wqas redacted.) The fact that these user names are still visible to ythe public is a problem. עוד מישהו Od Mishehu 20:23, 29 November 2016 (UTC)[reply]
  11.   Support I often come across such usernames but don't spend the time seeking out an oversighter when I have other things that need doing. This would help. BU Rob13 (talk) 05:22, 30 November 2016 (UTC)[reply]
  12.   Support +1. --Liuxinyu970226 (talk) 11:22, 30 November 2016 (UTC)[reply]
  13.   Support KylieTastic (talk) 20:35, 30 November 2016 (UTC)[reply]
  14.   Support excelent idea--Leon saudanha (talk) 00:06, 1 December 2016 (UTC)[reply]
  15.   Support Attack usernames don't come up that often, but admin time is scarce. MER-C (talk) 05:59, 1 December 2016 (UTC)[reply]
  16.   Support Stanko (talk) 18:18, 1 December 2016 (UTC)[reply]
  17.   Support We need it in Azerbaijani Wikipedia.--Baskervilltalk 07:03, 2 December 2016 (UTC)[reply]
  18.   Support--Kiril Simeonovski (talk) 10:14, 2 December 2016 (UTC)[reply]
  19.   Support --Banfield - Reclamos aquí 14:59, 2 December 2016 (UTC)[reply]
  20.   Support MohammadtheEditor (talk) 17:24, 2 December 2016 (UTC)[reply]
  21. Oppose, per Ajraddatz. Not a feature I would prioritise. --Vogone (talk) 23:14, 2 December 2016 (UTC)[reply]
  22.   Support. We have insulting usernames on eswiki multiple times a week. LlamaAl (talk) 04:50, 3 December 2016 (UTC)[reply]
  23.   Support Jo-Jo Eumerus (talk, contributions) 09:45, 3 December 2016 (UTC)[reply]
  24.   Support Jianhui67 talk★contribs 09:56, 3 December 2016 (UTC)[reply]
  25.   Support. Érico (talk) 20:05, 3 December 2016 (UTC)[reply]
  26.   Support --TerraCodes (talk) 03:31, 4 December 2016 (UTC)[reply]
  27.   Support Gratus (talk) 12:30, 4 December 2016 (UTC)[reply]
  28.   Support --Yeza (talk) 12:48, 4 December 2016 (UTC)[reply]
  29.   Support because I see a lot of usernames that are only offensive enough to be admin-level redacted, yet they must be oversighted because that is the only way to hide them. --Rschen7754 22:10, 4 December 2016 (UTC)[reply]
    I fully agree with Ajraddatz's last point about some stewards being way too sensitive in terms of hiding usernames, but I think that providing admin-level redaction would help to resolve the problem. --Rschen7754 04:35, 5 December 2016 (UTC)[reply]
  30.   Support Reducing the visibility of usernames intended to provoke or harass others, or are otherwise inappropriate is important for supporting community health. I JethroBT (talk) 20:45, 5 December 2016 (UTC)[reply]
    Such usernames are already eligible for suppression under the OS policy. – Ajraddatz (talk) 20:49, 5 December 2016 (UTC)[reply]
  31.   Oppose per Ajraddatz, who makes what seem to me to be good arguments. In particular, I think the fact that usernames are global means that this would only make sense if admins at one project could hide the name at every other project, which of course does not make sense. --Tryptofish (talk) 21:40, 5 December 2016 (UTC)[reply]
  32.   Support --Hedwig in Washington (talk) 01:27, 6 December 2016 (UTC)[reply]
  33.   Oppose Blocked users can't do anything and this causes they will not be seen. There is no need to any technical changes to improve it. That's enough. Thank you. --Smorteza (talk) 06:04, 6 December 2016 (UTC)[reply]
  34.   Oppose This is really a bad idea, as explained by Ajraddatz. It will only lead to unnecessary hiding actions which will be super-uneffective, as they will only apply on one wiki each time, while all accounts are global nowadays and exist on multiple wikis from the start. Most people who request usernames to be hidden or suppressed are also hypersensitive and mostly request so for names which don't even need to be hidden. --MF-W 11:14, 6 December 2016 (UTC)[reply]
  35.   Oppose per Ajraddatz. Even if this was somehow necessary, I can't see any priority for the WMF. Stevie is the man! Talk • Work 13:06, 6 December 2016 (UTC)[reply]
  36.   Support Muhraz (talk) 15:15, 6 December 2016 (UTC)[reply]
  37.   Oppose If it's really that bad, there is oversight. This would be a mass-revdel tool that admins already don't know enough about current existing policy to use it. -- Amanda (aka DQ) 20:40, 6 December 2016 (UTC)[reply]
  38.   Oppose per MF-W. Ks0stm (T•C•G) 21:00, 6 December 2016 (UTC)[reply]
  39.   Oppose per Ajraddatz — NickK (talk) 15:04, 7 December 2016 (UTC)[reply]
  40.   Support It could help as a form of deterrence for serial vandals. Harlock81 (talk) 18:51, 7 December 2016 (UTC)[reply]
  41.   Support! — RandomDSdevel (talk) 22:48, 7 December 2016 (UTC)[reply]
  42.   Oppose Wikimedia projects are not censored -FASTILY 07:43, 8 December 2016 (UTC)[reply]
  43.   Support -- w:WP:DENY, but a bit stronger. --Dirk Beetstra T C (en: U, T) 08:41, 8 December 2016 (UTC)[reply]
  44.   Support Cleans up some inconsistencies. Pppery (talk) 17:51, 8 December 2016 (UTC)[reply]
  45.   Support Miniapolis 18:22, 8 December 2016 (UTC)[reply]
  46.   Support Bharel (talk) 09:13, 9 December 2016 (UTC)[reply]
  47.   Support--DangSunM (talk) 02:01, 10 December 2016 (UTC)[reply]
  48.   Oppose. Not a priority until such times as a compelling need for it can be solidly evidenced. Kudpung (talk) 02:41, 10 December 2016 (UTC)[reply]
  49.   Support --OrsolyaVirág (talk) 11:33, 10 December 2016 (UTC)[reply]
  50.   Oppose Basically per Ajr. — regards, Revi 12:42, 10 December 2016 (UTC)[reply]
  51.   Oppose I strongly oppose this change. It's way to likely to be abused. Reguyla (talk) 18:08, 10 December 2016 (UTC)[reply]
  52.   Oppose. It's worth mentioning that most of administrators are not aware of current policies, although there is a lot of use cases for this. RadiX∞ 02:55, 12 December 2016 (UTC)[reply]
  53.   Oppose I don't see a need for it. It can also hamper sockpuppet investigations. Ramaksoud2000 (talk) 09:18, 12 December 2016 (UTC)[reply]
  54.   Question: (for opposers) should regular admins stop using RevisionDelete (the "change visibility" button) on the block log (Special:Log/block) after blocking accounts with abusive usernames while waiting for the assistence of a steward or local oversighter? At the top of Special:Log/block it is written: "This is a log of user blocking and unblocking actions. Automatically blocked IP addresses are not listed. See the block list for the list of currently operational bans and blocks." It is quite easy for the public to click the link, go to the list of active blocks and immediately see the (log details removed), which may also contain non-public information waiting to be oversighted. Do you consider this appropriate? Defender (talk) 14:03, 12 December 2016 (UTC)[reply]
  55.   Support --Mikheil Talk 20:54, 12 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Admins_and_stewards&oldid=18854095"