Community Wishlist Survey 2016/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[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[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[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[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[reply]

Voting – Hiding create protection from Special:ProtectedTitles

  1. (was support)-Shizhao (talk) 02:23, 28 November 2016 (UTC)Reply[reply]
      Neutral--Shizhao (talk) 17:56, 30 November 2016 (UTC)Reply[reply]
  2.   Neutral --Base (talk) 16:42, 28 November 2016 (UTC)Reply[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! TalkWork 17:44, 28 November 2016 (UTC)Reply[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! TalkWork 17:42, 30 November 2016 (UTC)Reply[reply]
  4.   Oppose Dubious value; WMF projects are not censored -FASTILY 09:14, 29 November 2016 (UTC)Reply[reply]
  5.   Oppose – In my opinion, hiding such information should be done very rarely. Guycn2 · 17:38, 29 November 2016 (UTC)Reply[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[reply]
  7.   Oppose--Leon saudanha (talk) 21:49, 30 November 2016 (UTC)Reply[reply]
  8.   Oppose The risk is largely bigger that the improvement. --Nouill (talk) 12:52, 1 December 2016 (UTC)Reply[reply]
  9.   Oppose Wikipedia is not censored -- Kndimov (talk) 18:00, 1 December 2016 (UTC)Reply[reply]
  10.   Oppose. Wikipedia is not censored. I don't think it would be useful. LlamaAl (talk) 05:45, 2 December 2016 (UTC)Reply[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[reply]
  12.   Oppose --Vogone (talk) 23:15, 2 December 2016 (UTC)Reply[reply]
  13.   Oppose per above. Jianhui67 talkcontribs 09:57, 3 December 2016 (UTC)Reply[reply]
  14.   Oppose if a title is too offensive, prevent its creation using AbuseFilters. Huji (talk) 19:33, 5 December 2016 (UTC)Reply[reply]
  15.   Oppose ArgonSim (talk) 22:02, 6 December 2016 (UTC)Reply[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[reply]
  17.   Support! — RandomDSdevel (talk) 22:49, 7 December 2016 (UTC)Reply[reply]
  18.   Support Miniapolis 18:24, 8 December 2016 (UTC)Reply[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[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[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[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[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[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[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[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[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[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[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[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[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[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[reply]

Voting – Quickly revert page creation vandalism

  1.   Support--Shizhao (talk) 02:24, 28 November 2016 (UTC)Reply[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[reply]
  2.   Support. May be useful. Jules78120 (talk) 12:07, 28 November 2016 (UTC)Reply[reply]
  3.   Support--Steinsplitter (talk) 15:10, 28 November 2016 (UTC)Reply[reply]
  4.   Oppose for now till some good reasoning is given. --Base (talk) 17:12, 28 November 2016 (UTC)Reply[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! TalkWork 17:58, 28 November 2016 (UTC)Reply[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! TalkWork 17:40, 30 November 2016 (UTC)Reply[reply]
  6.   Support --Ziko (talk) 21:05, 28 November 2016 (UTC)Reply[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[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[reply]
  9.   Neutral Is not essential, other priorities--Leon saudanha (talk) 21:53, 30 November 2016 (UTC)Reply[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[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[reply]
  12.   Oppose Not a priority. I don't think personally that is usefull. --Nouill (talk) 12:50, 1 December 2016 (UTC)Reply[reply]
  13.   Support can be easy Murbaut (talk) 13:13, 1 December 2016 (UTC)Reply[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[reply]
  15.   Support Good idea--Baskervilltalk 07:05, 2 December 2016 (UTC)Reply[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[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[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[reply]
  19.   Neutral Not sure whether this is a sensible idea. Jianhui67 talkcontribs 09:59, 3 December 2016 (UTC)Reply[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. 13:17, 3 December 2016 (UTC)Reply[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[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[reply]
  22.   Oppose -- Freddy2001 talk 09:41, 5 December 2016 (UTC)Reply[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[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[reply]
  24.   Weak support Could be useful, but still high-risk. Muhraz (talk) 15:17, 6 December 2016 (UTC)Reply[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[reply]
  26.   Oppose ArgonSim (talk) 22:05, 6 December 2016 (UTC)Reply[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[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[reply]
  29.   Support! — RandomDSdevel (talk) 22:50, 7 December 2016 (UTC)Reply[reply]
  30.   Support Miniapolis 18:26, 8 December 2016 (UTC)Reply[reply]
  31.   Oppose Deleting without viewing the pages' content may lead to incorrect results. --Uğurkenttalk 12:19, 10 December 2016 (UTC)Reply[reply]
  32.   Support FoCuSandLeArN (talk) 22:55, 11 December 2016 (UTC)Reply[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 (talkcontribs) 10:24, 11 November 2016 (UTC)Reply[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[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[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! TalkWork 16:46, 28 November 2016 (UTC)Reply[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[reply]

Voting – Special:GlobalRenameRequest blacklist

  1.   SupportAjraddatz (talk) 09:11, 28 November 2016 (UTC)Reply[reply]
  2.   Support --Stryn (talk) 11:09, 28 November 2016 (UTC)Reply[reply]
  3.   Support --MF-W 14:13, 28 November 2016 (UTC)Reply[reply]
  4.   SupportMarcoAurelio 15:08, 28 November 2016 (UTC)Reply[reply]
  5.   Support--Steinsplitter (talk) 15:10, 28 November 2016 (UTC)Reply[reply]
  6.   Neutral until I can get a feel for the severity of the problem. Stevie is the man! TalkWork 17:59, 28 November 2016 (UTC)Reply[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! TalkWork 17:47, 30 November 2016 (UTC)Reply[reply]
  7.   Support JAn Dudík (talk) 21:30, 28 November 2016 (UTC)Reply[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[reply]
  9.   Support Guycn2 · 17:40, 29 November 2016 (UTC)Reply[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[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[reply]
  12.   Support per cases that this in my home wikipedia--Leon saudanha (talk) 22:23, 30 November 2016 (UTC)Reply[reply]
  13.   Support reduce rename again with against policy :) Murbaut (talk) 13:07, 1 December 2016 (UTC)Reply[reply]
  14.   Support Jmvkrecords (Intra talk) 07:24, 2 December 2016 (UTC).Reply[reply]
  15.   Support--Kiril Simeonovski (talk) 11:16, 2 December 2016 (UTC)Reply[reply]
  16.   Support, unfortunately such a feature seems to be necessary. --Vogone (talk) 23:17, 2 December 2016 (UTC)Reply[reply]
  17.   Support DPdH (talk) 01:56, 3 December 2016 (UTC)Reply[reply]
  18.   Support Jianhui67 talkcontribs 10:00, 3 December 2016 (UTC)Reply[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. 13:31, 3 December 2016 (UTC)Reply[reply]
  20.   Support Great opinion--By erdo can (talk) 20:37, 3 December 2016 (UTC)Reply[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[reply]
  21.   Support --TerraCodes (talk) 03:13, 4 December 2016 (UTC)Reply[reply]
  22.   Support --Yeza (talk) 12:35, 4 December 2016 (UTC)Reply[reply]
  23.   Support I JethroBT (talk) 20:47, 5 December 2016 (UTC)Reply[reply]
  24.   Support Great idea! --Hedwig in Washington (talk) 01:32, 6 December 2016 (UTC)Reply[reply]
  25.   Support But what kind of blacklist?--Smorteza (talk) 06:12, 6 December 2016 (UTC)Reply[reply]
  26.   Support Muhraz (talk) 15:17, 6 December 2016 (UTC)Reply[reply]
  27.   Support Tiggerjay (talk) 20:30, 6 December 2016 (UTC)Reply[reply]
  28.   Support -- Amanda (aka DQ) 20:43, 6 December 2016 (UTC)Reply[reply]
  29.   Support Sure. Ks0stm (TCG) 21:01, 6 December 2016 (UTC)Reply[reply]
  30.   Support. - Mailer Diablo (talk) 06:53, 7 December 2016 (UTC)Reply[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[reply]
  32.   Support! — RandomDSdevel (talk) 20:17, 7 December 2016 (UTC)Reply[reply]
  33.   Support Amir (talk) 18:13, 8 December 2016 (UTC)Reply[reply]
  34.   Support Miniapolis 18:28, 8 December 2016 (UTC)Reply[reply]
  35.   Support --DangSunM (talk) 01:55, 10 December 2016 (UTC)Reply[reply]
  36.   Support --OrsolyaVirág (talk) 11:25, 10 December 2016 (UTC)Reply[reply]
  37.   Support --Uğurkenttalk 12:22, 10 December 2016 (UTC)Reply[reply]
  38.   Support — regards, Revi 12:29, 10 December 2016 (UTC)Reply[reply]
  39.   Support --TanvirH (talk) 20:31, 10 December 2016 (UTC)Reply[reply]
  40.   Support Cenya95 (talk) 00:24, 11 December 2016 (UTC)Reply[reply]
  41.   Support. For sure. RadiX 02:41, 12 December 2016 (UTC)Reply[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[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[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[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[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[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[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[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[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[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[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[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[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! TalkWork 16:57, 28 November 2016 (UTC)Reply[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[reply]
  3.   Support  @xqt 13:47, 29 November 2016 (UTC)Reply[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[reply]
  5.   Support StevenJ81 (talk) 17:09, 29 November 2016 (UTC)Reply[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[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[reply]
  8.   Support blocks can also be mistaken--Leon saudanha (talk) 22:29, 30 November 2016 (UTC)Reply[reply]
  9.   Support --Gerwoman (talk) 17:44, 1 December 2016 (UTC)Reply[reply]
  10.   Support. Beagel (talk) 17:56, 1 December 2016 (UTC)Reply[reply]
  11.   Support --Jojhnjoy (talk) 18:24, 1 December 2016 (UTC)Reply[reply]
  12.   Neutral per Rob. I think comments would be better. --AmaryllisGardener talk 18:51, 1 December 2016 (UTC)Reply[reply]
    Please note that the proposal (as it is now) is for comments only. --Tryptofish (talk) 19:43, 1 December 2016 (UTC)Reply[reply]
  13.   Support --Gestumblindi (talk) 20:42, 1 December 2016 (UTC) Not terribly urgent, but could be helpful.Reply[reply]
  14.   Support Can be useful in understanding why blocks have occured Emir of Wikipedia (talk) 22:28, 1 December 2016 (UTC).Reply[reply]
  15.   Support Perfectly reasonable solution to a totally unnecessary, albeit minor, problem. Everymorning (talk) 23:27, 1 December 2016 (UTC)Reply[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[reply]
    It's not clear to me what such a "local log" would be. --Tryptofish (talk) 23:40, 2 December 2016 (UTC)Reply[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. 13:43, 3 December 2016 (UTC)Reply[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[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[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[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[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[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[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[reply]
  20.   Support --Banfield - Reclamos aquí 15:00, 2 December 2016 (UTC)Reply[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[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[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[reply]
  23.   Oppose, per Multichill. --Vogone (talk) 23:17, 2 December 2016 (UTC)Reply[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[reply]
  25.   Support If caveats mentioned above are addressed. DPdH (talk) 02:02, 3 December 2016 (UTC)Reply[reply]
  26.   Oppose per Multichill. --Steinsplitter (talk) 10:00, 3 December 2016 (UTC)Reply[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. 13:43, 3 December 2016 (UTC)Reply[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[reply]
  28.   Oppose Logs are logs, no beauty contest. + potential abuse. --Sargoth (talk) 10:15, 4 December 2016 (UTC)Reply[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[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[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[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[reply]
  30.   Oppose User:Sargoth said it well Huji (talk) 19:37, 5 December 2016 (UTC)Reply[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[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[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[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! TalkWork 13:14, 6 December 2016 (UTC)Reply[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[reply]
  34.   Oppose, per Multichill and Sargoth. Muhraz (talk) 15:18, 6 December 2016 (UTC)Reply[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[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[reply]
  37.   Neutral - Very good idea in theory, but I can see some potential for abuse. Ks0stm (TCG) 21:03, 6 December 2016 (UTC)Reply[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[reply]
  39.   Support! — RandomDSdevel (talk) 20:33, 7 December 2016 (UTC)Reply[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[reply]
  41.   Support Miniapolis 18:30, 8 December 2016 (UTC)Reply[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[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[reply]
  44.   Support --TanvirH (talk) 20:32, 10 December 2016 (UTC)Reply[reply]
  45.   Support Very good idea Cenya95 (talk) 00:26, 11 December 2016 (UTC)Reply[reply]
  46.   Support Absolutely. I had a bogus block that was overturned at the administrators' noticeboard on, 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[reply]
  47.   Support --Mikheil Talk 20:52, 12 December 2016 (UTC)Reply[reply]
  48.   Support - They're logs, not the collected works of Shakespeare. MrX (talk) 22:49, 12 December 2016 (UTC)Reply[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[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[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[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[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[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[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[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[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! TalkWork 17:10, 28 November 2016 (UTC)Reply[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[reply]
  3.   Oppose Wikim/pedia is *not* my bank account. → «« Man77 »» [de] 11:00, 29 November 2016 (UTC)Reply[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[reply]
  5.   Oppose Nothing forced works--Leon saudanha (talk) 23:02, 30 November 2016 (UTC)Reply[reply]
  6.   Oppose very hard to new user for understanding and "ribet"Murbaut (talk) 13:09, 1 December 2016 (UTC)Reply[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[reply]
  8.   Oppose --Jojhnjoy (talk) 18:26, 1 December 2016 (UTC)Reply[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[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[reply]
  11.   Support White Master (es) 04:09, 2 December 2016 (UTC)Reply[reply]
  12.   Oppose. I think 2FA is beneficial. However, it should not be mandatory. LlamaAl (talk) 05:39, 2 December 2016 (UTC)Reply[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[reply]
  14.   Oppose--Baskervill talk 07:02, 2 December 2016 (UTC)Reply[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[reply]
  16.   Oppose --Banfield - Reclamos aquí 15:01, 2 December 2016 (UTC)Reply[reply]
  17.   Oppose --Vogone (talk) 23:18, 2 December 2016 (UTC)Reply[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[reply]
  19.   Oppose--Yeza (talk) 12:43, 4 December 2016 (UTC)Reply[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[reply]
  21.   Oppose Muhraz 15:20, 6 December 2016 (UTC)Reply[reply]
  22.   Oppose for many of the reasons stated above. Tiggerjay (talk) 20:38, 6 December 2016 (UTC)Reply[reply]
  23.   Support! — RandomDSdevel (talk) 20:34, 7 December 2016 (UTC)Reply[reply]
  24.   Oppose 2FA in any guise is a PITA for active editors. Miniapolis 18:34, 8 December 2016 (UTC)Reply[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[reply]
  26.   Support Easier 2FA, but still voluntary. --Yann (talk) 23:01, 12 December 2016 (UTC)Reply[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! TalkWork 17:17, 28 November 2016 (UTC)Reply[reply]
    Changed my mind to   Support after reading many of the informative support comments below. You have convinced me! :) Stevie is the man! TalkWork 20:48, 7 December 2016 (UTC)Reply[reply]
  2.   Support sounds like a useful task. Gryllida 23:18, 1 December 2016 (UTC)Reply[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[reply]
  4.   Support--Kiril Simeonovski (talk) 08:12, 2 December 2016 (UTC)Reply[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[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[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[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[reply]
  9.   Support -- the wub "?!" 16:39, 4 December 2016 (UTC)Reply[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[reply]
  11.   Support Mark Schierbecker (talk) 08:18, 5 December 2016 (UTC)Reply[reply]
  12.   Support Huji (talk) 19:29, 5 December 2016 (UTC)Reply[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[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[reply]
  15.   Support Muhraz (talk) 15:28, 6 December 2016 (UTC)Reply[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[reply]
  17.   Support Please. Ks0stm (TCG) 21:05, 6 December 2016 (UTC)Reply[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[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[reply]
  20.   Support! — RandomDSdevel (talk) 22:44, 7 December 2016 (UTC)Reply[reply]
  21.   Support Miniapolis 18:16, 8 December 2016 (UTC)Reply[reply]
  22.   Support MER-C (talk) 04:35, 10 December 2016 (UTC)Reply[reply]
  23.   Support OrsolyaVirág (talk) 11:29, 10 December 2016 (UTC)Reply[reply]
  24.   Support It should help streamline operations. --Caballero1967 (talk) 23:17, 11 December 2016 (UTC)Reply[reply]
  25.   Support. RadiX 02:45, 12 December 2016 (UTC)Reply[reply]
  26.   Support Quiddity (talk) 04:15, 12 December 2016 (UTC)Reply[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[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[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[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[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[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[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[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[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[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[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[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[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[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[reply]
  3.   Support--Kudpung (talk) 12:33, 28 November 2016 (UTC)Reply[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[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). 14:00, 3 December 2016 (UTC)Reply[reply]
  6.   Oppose agree with MF-W.--Steinsplitter (talk) 15:10, 28 November 2016 (UTC)Reply[reply]
  7.   Support in my comment's implementation proposal. --Base (talk) 16:35, 28 November 2016 (UTC)Reply[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! TalkWork 17:31, 28 November 2016 (UTC)Reply[reply]
  9.   Support Useful for small and middle wikis JAn Dudík (talk) 21:26, 28 November 2016 (UTC)Reply[reply]
  10.   Support --Izno (talk) 00:25, 29 November 2016 (UTC)Reply[reply]
  11.   Oppose per MF-W. These are a total eyesore imo. -FASTILY 09:14, 29 November 2016 (UTC)Reply[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[reply]
  13.   Oppose You may use CSS instead to display protection level  @xqt 13:44, 29 November 2016 (UTC)Reply[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[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[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[reply]
  16.   Support. Surprised this isn't automatic already.--Telaneo (User talk page) 21:20, 29 November 2016 (UTC)Reply[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[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[reply]
  19.   Support Beagel (talk) 17:58, 1 December 2016 (UTC)Reply[reply]
  20.   Support Great idea. --AmaryllisGardener talk 18:53, 1 December 2016 (UTC)Reply[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[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[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[reply]
  24.   Support--Kiril Simeonovski (talk) 08:28, 2 December 2016 (UTC)Reply[reply]
  25.   Support Draceane (talk) 09:43, 2 December 2016 (UTC)Reply[reply]
  26.   SupportJc86035 (talk) 11:05, 2 December 2016 (UTC)Reply[reply]
  27.   Oppose already done with css. Multichill (talk) 13:56, 2 December 2016 (UTC)Reply[reply]
  28.   Support --Morten Haan (talk) 23:11, 2 December 2016 (UTC)Reply[reply]
  29.   Oppose, unnecessary feature. --Vogone (talk) 23:13, 2 December 2016 (UTC)Reply[reply]
  30.   Support Jianhui67 talkcontribs 10:01, 3 December 2016 (UTC)Reply[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[reply]
  32.   Support Sounds good. Great idea !! IMHO :) — TBhagat (talk) 07:10, 4 December 2016 (UTC)Reply[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[reply]
  34.   Oppose No need to be shown the details of protection in read view Huji (talk) 19:30, 5 December 2016 (UTC)Reply[reply]
  35.   Support --Sphilbrick (talk) 21:58, 5 December 2016 (UTC)Reply[reply]
  36.   Support as nominator. Samsara (talk) 13:04, 6 December 2016 (UTC)Reply[reply]
  37.   Support Useful feature. Muhraz (talk) 15:29, 6 December 2016 (UTC)Reply[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[reply]
  39.   Oppose per MW-F. -- Amanda (aka DQ) 20:48, 6 December 2016 (UTC)Reply[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 (TCG) 21:06, 6 December 2016 (UTC)Reply[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[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 (TCG) 21:02, 7 December 2016 (UTC)Reply[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[reply]
  42.   Support! — RandomDSdevel (talk) 22:45, 7 December 2016 (UTC)Reply[reply]
  43.   Support --Dirk Beetstra T C (en: U, T) 08:39, 8 December 2016 (UTC)Reply[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[reply]
  45.   Support Miniapolis 18:18, 8 December 2016 (UTC)Reply[reply]
  46.   Support SarahSV talk 15:30, 11 December 2016 (UTC)Reply[reply]
  47.   Support--David1010 (talk) 20:17, 11 December 2016 (UTC)Reply[reply]
  48.   Support MrX (talk) 22:52, 12 December 2016 (UTC)</