Jump to content

Wikipedia:Requests for comment/Bureaucrat removal of adminship policy

Add links
From Wikipedia, the free encyclopedia
The result of this RfC is that bureaucrats, once granted the technical ability to do so in accordance with Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag, may remove administrator permissions A) at the request of the administrator in question, B) on instruction from the Arbitration Committee in accordance with that committee's procedures or as a result of a remedy in a closed case, or C) in accordance with Wikipedia:Administrators#Procedural removal for inactive administrators. Please refer to individual sections for specific rationales. HJ Mitchell | Penny for your thoughts? 17:01, 7 August 2011 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

If there is consensus that bureaucrats should be granted the technical ability to remove the administrator permission from user accounts at Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag, the use of that ability needs to be governed by a policy specifying in which cases bureaucrats should be allowed to do so.

Currently there are four different scenarios in which stewards are authorized to remove the administrator permission from user accounts:

  1. If the user is deemed inactive per Wikipedia:Administrators#Procedural removal for inactive administrators;
  2. Following an official request from the Arbitration Committee;
  3. Following a self-request for removal by the administrator;
  4. In an emergency when an administrator account appears to be compromised or otherwise uses the tools to disrupt Wikipedia.

This discussion was started to determine which of those cases should be handled by bureaucrats on this project directly instead of requesting the stewards to do it.

Note: The implementation of this proposal is dependent on bureaucrats having the technical ability to remove the administrator permission. If Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag fails to achieve consensus, the policy proposed in this RfC is moot.

RFC started: 20:04, 7 July 2011 (UTC)

Proposals

[edit]

If multiple proposals for separate situations gain consensus (e.g. for self-requests and inactive accounts) but the proposal for all situations does not, only the proposals with consensus in their favor will be added to the policy. In this case, !votes in favor of the "all situations" proposal will be counted as !votes in favor of all four separate proposals, unless the !voting user clearly specifies that they only support a policy that includes the complete "all situations" proposal or who specified that they disagree that their !vote is counted this way.

Proposals are being discussed individually; any that carry will be combined into a coherent section upon the closure of the RFC.

All situations

[edit]
SNOW-closed in lieu of discussing each situation individually below
The following discussion has been closed. Please do not modify it.
SNOW-closed in lieu of discussing each situation individually below

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Bureaucrats will be expanded by adding the following section
==Removal of adminship==
Bureaucrats may remove the "administrator" user right from an editor's account under the following circumstances:
  1. If the user is deemed inactive per Wikipedia:Administrators#Procedural removal for inactive administrators;
  2. Following an official request from the Arbitration Committee;
  3. Following a self-request for removal by the administrator;
  4. In an emergency when an administrator account appears to be compromised or an editor has been using the administrative tools to disrupt Wikipedia.
If a bureaucrat removes the "administrator" user right from any user, they are required to notify the user in question immediately, including an explanation why the user right was removed and how they may re-gain it. Notification is not required if the user was already notified of the removal or they requested the removal themselves.
Users who endorse this proposal
  1. No problems giving Bureaucrats, among the most trusted of our community, the complete bundle from 1-4. As for those expressing concerns about number 4, in the unlikely even that a 'crat abuses this power, ArbCom stands ready to remedy such actions.Jusdafax 08:33, 7 July 2011 (UTC)[reply]
  2. Assuming the poll to grant Bureaucrats the technical ability to desysop passes, I would be OK with it being used in all these situations, as they're all uncontroversial cases. The last one could be the most problematic, but I think we can trust our 'crats to only use such a power in circumstances where it is clearly required (and backed by consensus) and not to just start desysopping admins willy-nilly. Robofish (talk) 15:03, 7 July 2011 (UTC)[reply]
  3. AD 17:28, 7 July 2011 (UTC)[reply]
  4. -- Ed (Edgar181) 20:15, 7 July 2011 (UTC)[reply]
  5. Seems good. -- Eraserhead1 <talk> 20:18, 7 July 2011 (UTC)[reply]
  6. 1-3 are uncontroversial cases, where crats would be able to do on this project what stewards do at meta, so that the logs are kept at one wiki and there is no reason why those should be handled at meta by stewards. Crats were selected because we trust them to act correctly and they have had to pass higher bars than stewards have. I agree about the concerns regarding #4 (I didn't link to WP:DE when I wrote the RFC draft) but I would support it provided that the policy strictly specifies which kind of disruption is meant (e.g. an admin using their tools to severely damage the project in a manner that cannot easily be repaired (mass-deleting articles, removing critical MediaWiki pages etc.)). We can discuss this in the discussion section though. Regards SoWhy 20:54, 7 July 2011 (UTC)[reply]
  7. No problems with it. demize (t · c) 20:57, 7 July 2011 (UTC)[reply]
  8. 4 is no problem as a crat taking to wide of an approach will not be a crat for long. Agathoclea (talk) 21:49, 7 July 2011 (UTC)[reply]
  9. Support one, two, three; four is too vague, especially, "... editor has been using the administrative tools to disrupt Wikipedia". /ƒETCHCOMMS/ 03:16, 8 July 2011 (UTC)[reply]
  10. Support. I can live with alternate wording of four if there is a consensus for that. Eluchil404 (talk) 07:10, 8 July 2011 (UTC)[reply]
  11. It's a pity that #4 doesn't go far enough, but progress is progress.—S Marshall T/C 08:39, 8 July 2011 (UTC)[reply]
  12. Support -- Alex146 (talk) 01:52, 15 July 2011 (UTC)[reply]
Users who oppose this proposal
  1. Dubious about #4 (see below); no problem with the others. MastCell Talk 20:23, 7 July 2011 (UTC)[reply]
  2. Share concerns of MastCell r.e. #4, I support the general idea of making de-sysoping easier, but that is way too ambiguous for an initial policy. --Errant (chat!) 20:34, 7 July 2011 (UTC)[reply]
  3. I also agree with MastCell about number 4. I also wonder if it might be worth adding the option for a community-consensus desysop, similar to the way that community bans work. MacMedtalkstalk 20:53, 7 July 2011 (UTC)[reply]
  4. Agree with the editors above: the situation described in #4 should be handled by ArbCom, and come to the bureaucrat via #2. I specificially do support #1. Beyond My Ken (talk) 20:55, 7 July 2011 (UTC)[reply]
  5. Yep, #4 is too broadly defined for one person to make that determination alone, whoever it is and however trusted and reasonable he or she might be. If an administrator is using tools disruptively they should be blocked pending review by Arbcom. --causa sui (talk) 20:58, 7 July 2011 (UTC)[reply]
  6. Probably better to discuss the points individually. Number 4 is the controversial part here. Jafeluv (talk) 22:00, 7 July 2011 (UTC)[reply]
  7. On account of #4. Standard procedure is to block disruptive accounts, admin accounts would be included in that standard procedure. If the disruptive admin unblocks himself, he's only digging his own grave, and such an unblock wouldn't stick anyways. Sven Manguard Wha? 03:41, 8 July 2011 (UTC)[reply]
  8. "Disruption" as described by #4 is far too vague. —mc10 (t/c) 03:50, 8 July 2011 (UTC)[reply]
  9. No I can't support this.... although I may support other sections. 1) RFB did not given the current crats the mandate for such a role 2) Reinforces perception that 'crats are in someway higher up the greasy pole (IMHO) 3) "Disruption" far to broad. Pedro :  Chat  07:15, 8 July 2011 (UTC)[reply]
  10. The second part of #4 is too broad and vague. The first part is unnecessary: it can be handled by ArbCom or in a true emergency by stewards. Ruslik_Zero 08:51, 8 July 2011 (UTC)[reply]
Discussion
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Inactive admins

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There is consensus that removing administrative rights of inactive accounts is one of the routine operations as currently shaped in policy. The current practice is that bureaucrats coordinate the desysopping of inactive accounts with the stewards; this simply removes a layer of complexity. Bureaucrats are reminded to exercise due caution as laid out in policy regarding notification, and that the removal is purely procedural. Crazynas t 07:02, 7 August 2011 (UTC)[reply]
Wikipedia:Bureaucrats will be expanded by adding the following section
==Removal of adminship==
Bureaucrats may remove the "administrator" user right from an editor's account if the editor is deemed inactive per Wikipedia:Administrators#Procedural removal for inactive administrators
If a bureaucrat removes the "administrator" user right from any user, they are required to notify the user in question immediately, including an explanation on why the user right was removed and how they may re-gain it.

Users who endorse this proposal

[edit]
  1. I support.--Kiwhan (talk) 01:54, 31 July 2011 (UTC)[reply]
  2. Yes; if the technical right is granted then this isn't even really worth voting on - we already agreed by consensus that inactive admins should be de-sysoped, to my mind the two RFC's then make it a de-facto policy :) --Errant (chat!) 20:35, 7 July 2011 (UTC)[reply]
  3. Support --Kudpung กุดผึ้ง (talk) 21:05, 7 July 2011 (UTC)[reply]
  4. Why not? ErikHaugen (talk | contribs) 21:08, 7 July 2011 (UTC)[reply]
  5. Sensible and in line with existing policy. Ucucha 21:20, 7 July 2011 (UTC)[reply]
  6. I think this is a no-brainer, we already approved of this more-or-less, and if we say crats can technically do this, this should be a non-controversial use of the tool. -- Atama頭 21:27, 7 July 2011 (UTC)[reply]
  7. This should be uncontroversial now that the policy has been adopted. Jafeluv (talk) 21:58, 7 July 2011 (UTC)[reply]
  8. Saves the stewards some time and lets us keep the entries in a local log rather than a remote one on meta. --(ʞɿɐʇ) ɐuɐʞsǝp 22:00, 7 July 2011 (UTC)[reply]
  9. This is a case where using local resources will help us make sure local policy is followed. After the initial passage of the new policy for this, a steward who wasn't familiar with the details desysopped a number of inactive admins based on a premature request on Meta. If this had been requested on WP:BN, the mistake probably would have been avoided. I support all four points (with the alternative for #4 below), but supporting here as a fallback in case they don't all achieve consensus. --RL0919 (talk) 00:06, 8 July 2011 (UTC)[reply]
  10. This is consistent with the new policy. Dabomb87 (talk) 00:20, 8 July 2011 (UTC)[reply]
  11. As noted, this policy is alreay enacted. Jusdafax 00:44, 8 July 2011 (UTC)[reply]
  12. Obvious. /ƒETCHCOMMS/ 03:19, 8 July 2011 (UTC)[reply]
  13. Obvious. Sven Manguard Wha? 03:42, 8 July 2011 (UTC)[reply]
  14. Support. --Rschen7754 03:47, 8 July 2011 (UTC)[reply]
  15. Obviously. —mc10 (t/c) 03:49, 8 July 2011 (UTC)[reply]
  16. jorgenev 04:22, 8 July 2011 (UTC)[reply]
  17. Yes to this one as I supported the linked policy. Graeme Bartlett (talk) 08:38, 8 July 2011 (UTC)[reply]
  18. Mos. def. Ironholds (talk) 11:34, 8 July 2011 (UTC)[reply]
  19. Support, makes sense to allow bcrats to do this instead of just stewards. --SarekOfVulcan (talk) 18:02, 8 July 2011 (UTC)[reply]
  20. Obvious. Ben MacDui 18:56, 8 July 2011 (UTC)[reply]
  21. Support per above. Regards SoWhy 19:28, 8 July 2011 (UTC)[reply]
  22. Most certainly, especially considering that we recently passed a desysopping procedure for inactive administrators. Reaper Eternal (talk) 19:42, 8 July 2011 (UTC)[reply]
  23. Support. -- Ed (Edgar181) 22:40, 8 July 2011 (UTC)[reply]
  24. Support - though the wording needs improving; there is some ambiguity about giving bureaucrats decision power here, when following the "suspension of inactive admins" should be a boring technical job with little to no decision involved. Supporting because I don't think anyone misunderstands in the current context - but that might change down the line if it's implemented as written. Rd232 public talk 22:59, 8 July 2011 (UTC)[reply]
  25. Support Sir Armbrust Talk to me Contribs 00:44, 9 July 2011 (UTC)[reply]
  26. Support. 28bytes (talk) 01:43, 9 July 2011 (UTC)[reply]
  27. Support Nick-D (talk) 08:02, 9 July 2011 (UTC)[reply]
  28. Support Agathoclea (talk) 09:45, 9 July 2011 (UTC)[reply]
  29. Support Graham87 09:57, 9 July 2011 (UTC)[reply]
  30. Support. WJBscribe (talk) 10:31, 9 July 2011 (UTC)[reply]
  31. Support uncontroversial since the desysop policy for inactive admins is approved. jsfouche ☽☾Talk 15:18, 9 July 2011 (UTC)[reply]
  32. Support. --Tryptofish (talk) 16:30, 9 July 2011 (UTC)[reply]
  33. Support Hut 8.5 16:55, 9 July 2011 (UTC)[reply]
  34. Support  Ronhjones  (Talk) 17:11, 9 July 2011 (UTC)[reply]
  35. AD 17:14, 9 July 2011 (UTC)[reply]
  36. Long overdue. Skomorokh 17:46, 9 July 2011 (UTC)[reply]
  37. -- Eraserhead1 <talk> 18:41, 9 July 2011 (UTC)[reply]
  38. Support -FASTILY (TALK) 04:37, 10 July 2011 (UTC)[reply]
  39. Support - if they have the technical right, and the situation is clear and self-evident that the user should be de-sysopped, then there is no reason that they shouldn't do it. עוד מישהו Od Mishehu 07:34, 10 July 2011 (UTC)[reply]
  40. - Dank (push to talk) 11:34, 10 July 2011 (UTC)[reply]
  41. Support A 'crat can only act according to consensus, of which policy is a codified example. LessHeard vanU (talk) 12:58, 10 July 2011 (UTC)[reply]
  42. Support. — Mr. Stradivarius ♫ 14:39, 10 July 2011 (UTC)[reply]
  43.  Sandstein  19:11, 10 July 2011 (UTC)[reply]
  44. Support Guy Macon (talk) 19:30, 10 July 2011 (UTC)[reply]
  45. Support This would reduce admin bloat and allow veteran editors to have a chance to become admin. Johnny Au (talk/contributions) 23:17, 10 July 2011 (UTC)[reply]
  46. Support - My76Strat talk 23:43, 10 July 2011 (UTC)[reply]
  47. Support Of course Bob House 884 (talk) 23:47, 10 July 2011 (UTC)[reply]
  48. Support — Edokter (talk) — 00:51, 11 July 2011 (UTC)[reply]
  49. Support as a simple matter of enforcing existing procedure. hare j 01:13, 11 July 2011 (UTC)[reply]
  50. Support. Tiderolls 01:39, 11 July 2011 (UTC)[reply]
  51. Support Not really controversial. Gigs (talk) 02:00, 11 July 2011 (UTC)[reply]
  52. Support demize (t · c) 02:35, 11 July 2011 (UTC)[reply]
  53. --JaGatalk 04:03, 11 July 2011 (UTC)[reply]
  54. Support English Wikipedia should not be a place where stewards are needed for routine tasks. We've now made it, however wisely, routine to remove the tools for inactive accounts, and we should take care of that within the project. ‡ MAHEWA ‡ • talk 05:00, 11 July 2011 (UTC)[reply]
  55. Support — Bill william comptonTalk 06:54, 11 July 2011 (UTC)[reply]
  56. Support Themeparkgc  Talk  07:21, 11 July 2011 (UTC)[reply]
  57. Support, no issues with proposal, as worded. — Cirt (talk) 07:26, 11 July 2011 (UTC)[reply]
  58. Support - kinda obvious :o) Pesky (talk …stalk!) 07:34, 11 July 2011 (UTC)[reply]
  59. Straightforward. T. Canens (talk) 08:07, 11 July 2011 (UTC)[reply]
  60. Support Hekerui (talk) 08:45, 11 July 2011 (UTC)[reply]
  61. Support. This seems to be the reason we're having this discussion in the first place, no? SchuminWeb (Talk) 09:28, 11 July 2011 (UTC)[reply]
  62. Support, enables implementation of the already agreed inactivity policy. --Taelus (talk) 11:48, 11 July 2011 (UTC)[reply]
  63. Yes fine. Herostratus (talk) 12:32, 11 July 2011 (UTC)[reply]
  64. Support - This is why we are here. Lets make this happen. - Burpelson AFB ✈ 12:47, 11 July 2011 (UTC)[reply]
  65. Support Tyrol5 [Talk] 12:51, 11 July 2011 (UTC)[reply]
  66. Support Non controversial use. WormTT · (talk) 13:05, 11 July 2011 (UTC)[reply]
  67. Perfectly logical to keep the inactive removals in our rights logs locally. Courcelles 15:24, 11 July 2011 (UTC)[reply]
  68. Support - as long as inactive admins can immediately regain it through proper channels. Magog the Ogre (talk) 17:35, 11 July 2011 (UTC)[reply]
  69. Support - Common-sense implementation of the inactive admin policy. TotientDragooned (talk) 20:01, 11 July 2011 (UTC)[reply]
  70. Protonk (talk) 20:31, 11 July 2011 (UTC)[reply]
  71. Net plus. AGK [•] 23:15, 11 July 2011 (UTC)[reply]
  72. Support - Although really I am just piling on at this point... Barts1a | Talk to me | Yell at me 01:17, 12 July 2011 (UTC)[reply]
  73. sonia♫ 01:23, 12 July 2011 (UTC)[reply]
  74. Jujutacular talk 03:15, 12 July 2011 (UTC)[reply]
  75. —GFOLEY FOUR!— 03:52, 12 July 2011 (UTC)[reply]
  76. Strong Support It is already established policy to remove inactive admins after sufficient notification thus I seen no need to involve a steward in what is essentially an administrative action.  Jim Reed (Talk)  04:15, 12 July 2011 (UTC)[reply]
  77. Support Edgepedia (talk) 04:59, 12 July 2011 (UTC)[reply]
  78. Support. I didn't support the proposal to desysop inactive accounts, but consensus didn't go my way, and that's OK with me. So as long as we're doing this, why not let bureaucrats contribute to the workload? szyslak (t) 07:54, 12 July 2011 (UTC)[reply]
  79. Support Jebus989✰ 08:28, 12 July 2011 (UTC)[reply]
  80. Support - Per my reasoning in Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag, I am supporting all four. -Porch corpter (talk/contribs) 10:26, 12 July 2011 (UTC)[reply]
  81. Support makes sense given recent developments on desysoping of inactive admins. BencherliteTalk 14:53, 12 July 2011 (UTC)[reply]
  82. Support – In order to reduce enwiki's dependence on Stewards. --Michaeldsuarez (talk) 16:07, 13 July 2011 (UTC)[reply]
  83. Support Good idea. ~~EBE123~~ talkContribs 22:24, 13 July 2011 (UTC)[reply]
  84. Support. Cla68 (talk) 05:34, 14 July 2011 (UTC)[reply]
  85. Support: To carry out the new policy smoother than non-local stewards could, I see no reason not to allow this. --Sgt. R.K. Blue (talk) 10:05, 14 July 2011 (UTC)[reply]
  86. Support A no-brainer, as per Atama (#5) -- Alexf(talk) 15:21, 14 July 2011 (UTC)[reply]
  87. Support - this is the simplest arrangement possible. There's no need to involve stewards or anybody else. PhilKnight (talk) 16:31, 14 July 2011 (UTC)[reply]
  88. Strong Support Makes perfect sense. All the boxes seem to be checked. Lighthead þ 16:34, 14 July 2011 (UTC)[reply]
  89. Support - Bazj (talk) 17:14, 14 July 2011 (UTC)[reply]
  90. Sensible in its utility and limitations. — Scientizzle 20:46, 14 July 2011 (UTC)[reply]
  91. Support. Keeps the logs together and easier to access. Useight (talk) 22:42, 14 July 2011 (UTC)[reply]
  92. Support North8000 (talk) 00:36, 15 July 2011 (UTC)[reply]
  93. Support -- Alex146 (talk) 01:52, 15 July 2011 (UTC)[reply]
  94. I, Dr. 'Krant' M. L. Verma, am of the same opinion and as such I endorse this policy of English Wikipedia.Krantmlverma (talk) 05:16, 15 July 2011 (UTC)[reply]
  95. Support - Duh. Manning (talk) 09:06, 15 July 2011 (UTC)[reply]
  96. Support. But could the wording be fixed? "If a bureaucrat removes the "administrator" user right from any a user, they are the bureacrat is required to notify the user in question immediately, including an explanation on of why the user right was removed and how they may re-gain the user may regain it." Unsure why "administrator" is in quotes, but maybe it's a technical nicety. Tony (talk) 13:08, 15 July 2011 (UTC)[reply]
  97. Support - Any instance where the community has decided admin rights should be removed. GB fan please tell me what you think of my editing 14:18, 15 July 2011 (UTC)[reply]
  98. Strong support — Joyson Noel Holla at me! 14:24, 15 July 2011 (UTC)[reply]
  99. Support -Casliber (talk · contribs) 15:21, 15 July 2011 (UTC)[reply]
  100. Support as part of this group of proposals designed to work well together. Jd2718 (talk) 17:50, 15 July 2011 (UTC)[reply]
  101. Support this logical proposed addition to the policy text. SuperMarioMan 21:22, 15 July 2011 (UTC)[reply]
  102. Support It would make no sense to add the ability to remove admin without having this area of responsibility included with it, uncontroversial procedural de-sysops with no precedential value are entirely appropriate for this. Monty845 04:56, 16 July 2011 (UTC)[reply]
  103. Support Makes sense, for housekeeping purposes and to advocate new administratorship. NECRATSpeak to me 09:32, 16 July 2011 (UTC)[reply]
  104. Logan Talk Contributions 13:08, 16 July 2011 (UTC)[reply]
  105. Support. As there is no discretion involved in this sort of removal, merely the checking of dates, I think that bureaucrats should be able to implement this policy. RJC TalkContribs 14:01, 16 July 2011 (UTC)[reply]
  106. ---Balloonman Poppa Balloon 15:23, 16 July 2011 (UTC)[reply]
  107. Support. It makes perfect sense along with the other procedural changes. Lightmouse (talk) 16:40, 16 July 2011 (UTC)[reply]
  108. Support. As a noncontroversial, procedural action, it just makes sense. elektrikSHOOS (talk) 19:39, 16 July 2011 (UTC)[reply]
  109. Support. — Waterfox ~talk~ 22:10, 16 July 2011 (UTC)[reply]
  110. Mr.Z-man 00:15, 17 July 2011 (UTC)[reply]
  111. Support. SteveStrummer (talk) 05:31, 17 July 2011 (UTC)[reply]
  112. Support. Comte0 (talk) 09:26, 17 July 2011 (UTC)[reply]
  113. Oh Yeah!!.For the admin's who are not patient enough! If they want to re-gained the status they should examined :) RohG ??· 10:40, 17 July 2011 (UTC)[reply]
  114. Support. As it has been decided to suspend admin rights of inactive admins, it makes sense for crats to be able to do it -- Boing! said Zebedee (talk) 16:05, 17 July 2011 (UTC)[reply]
  115. Yes, says Ratibgreat (talk) 16:27, 17 July 2011 (UTC)[reply]
  116. Support. -- Ϫ 00:36, 18 July 2011 (UTC)[reply]
  117. Support. Cind.amuse 06:50, 18 July 2011 (UTC)[reply]
  118. Support nothing controversial here. Totnesmartin (talk) 17:10, 18 July 2011 (UTC)[reply]
  119. Support - As this would be uncontroversial and purely procedural, why not? --SoCalSuperEagle (talk) 17:28, 18 July 2011 (UTC)[reply]
  120. As long as "inactivity" is clearly and unambiguously defined, I don't see a problem. EVula // talk // ☯ // 21:17, 18 July 2011 (UTC)[reply]
  121. Strong Support I see this as a big help to new editors who attempt to contact an admin that is no longer active. Quinxorin (talk) 03:00, 19 July 2011 (UTC)[reply]
  122. Support Peter (Southwood) (talk): 12:42, 19 July 2011 (UTC)[reply]
  123. Support - Makes sense with existing policy and bureaucrats should be able to take on inactive admins on en wiki to allow stewards to focus on smaller projects. CT Cooper · talk 20:18, 19 July 2011 (UTC)[reply]
  124. Support - Uncontroversial, sensible proposal - Nick Thorne talk 03:02, 20 July 2011 (UTC)[reply]
  125. Support Clearly defined activity, not likely to produce confusion, abuse, or controversy. I, Jethrobot drop me a line (note: not a bot!) 05:23, 20 July 2011 (UTC)[reply]
  126. Support Being able to grant but not retract a capability is silly. One either deserves a specified level of power or does not deserve it. Ornithikos (talk) 06:52, 20 July 2011 (UTC)[reply]
  127. Support - it makes sense. Ability to re-earn is a must, however. —JeevanJones (talk) 11:40, 20 July 2011 (UTC)[reply]
  128. Support - sensible Ruhrfisch ><>°° 11:42, 20 July 2011 (UTC)[reply]
  129. Support Jehochman Talk 20:15, 20 July 2011 (UTC)[reply]
  130. Support - clear-cut decision, saves stewards time, easy to see abuse - ProtoFire→talk 00:01, 21 July 2011 (UTC)[reply]
  131. Support - 12 months of no activity, notice, ability to re-sysop. Bearian (talk) 17:56, 21 July 2011 (UTC)[reply]
  132. Support Blue Rasberry (talk) 14:21, 22 July 2011 (UTC)[reply]
  133. Support - If you want to be an administrator, you need to administrate. Kafziel Complaint Department: Please take a number 19:14, 22 July 2011 (UTC)[reply]
  134. Support - Of course! --Nathan2055talk 19:19, 22 July 2011 (UTC)[reply]
  135. Support No question, I still shudder when I remember one Admin I ran across who seemed to know virtually nothing about policy. Dougweller (talk) 09:53, 23 July 2011 (UTC)[reply]
  136. Support Definitely, if inactive for six months then their sysop powers should be revoked and bureaucrats should be able to do this. Jezhotwells (talk) 17:27, 23 July 2011 (UTC)[reply]
  137. Support Something like this exists at the Portuguese Wikipedia. - Al Lemos (talk) 23:37, 23 July 2011 (UTC)[reply]
  138. --Cybercobra (talk) 06:27, 24 July 2011 (UTC)[reply]
  139. Support per "counter"-comments in the oppose section: Stewards shouldn't have to deal with. mabdul 16:33, 24 July 2011 (UTC)[reply]
  140. Support - seems obvious. Ale_Jrbtalk 17:22, 24 July 2011 (UTC)[reply]
  141. Support - this is just carrying out a procedure that has already been crafted through consensus. maclean (talk) 20:35, 25 July 2011 (UTC)[reply]
  142. Support, sensible. Titoxd(?!? - cool stuff) 07:08, 28 July 2011 (UTC)[reply]
  143. Support Why have 'crats?--Gilderien Talk|Contribs 20:23, 28 July 2011 (UTC)[reply]
  144. Support. If they are not active, take it away. Kitty DeClaude (talk) 22:35, 29 July 2011 (UTC)[reply]
  145. Support As there is provision for an admin to ask for it back should they return, I see no problem with this. PhantomSteve/talk|contribs\ 22:24, 30 July 2011 (UTC)[reply]
  146. Support. —Jclavet (talk) 20:38, 31 July 2011 (UTC)[reply]
  147. Support. Blackvisionit (talk) 02:45, 1 August 2011 (UTC)[reply]
  148. Support - allows Bureaucrats to perform a job that we agree needs doing. Huon (talk) 11:47, 1 August 2011 (UTC)[reply]
  149. Support - frankie (talk) 16:52, 1 August 2011 (UTC)[reply]
  150. Support If the bureaucrats get the ability to do this, that will mean that we already agreed that someone should remove rights from inactive admins and that bureaucrats should be able to remove rights from admins; it would be silly to agree to those things but to say that bureaucrats couldn't do it. Nyttend (talk) 04:39, 2 August 2011 (UTC)[reply]
  151. Support (would even support "must remove" instead of "may remove") Choyoołʼįįhí:Seb az86556 > haneʼ 06:22, 2 August 2011 (UTC)[reply]
  152. Support Xymmax So let it be written So let it be done 12:50, 4 August 2011 (UTC)[reply]
  153. Support Practical Bejinhan talks 13:39, 4 August 2011 (UTC)[reply]
  154. Support --Commander (Ping Me) 15:48, 5 August 2011 (UTC)[reply]
  155. Support -- It's policy to do it, and it's a bureaucratic task, one that probably should be done by a 'bot. --John Nagle (talk) 19:27, 5 August 2011 (UTC)[reply]

Users who oppose this proposal

[edit]
  1. -Atmoz (talk) 21:29, 8 July 2011 (UTC)[reply]
  2. Prodego talk 20:08, 9 July 2011 (UTC)[reply]
  3. - As far as I can see, a strong case hasn't been made that there are any problems stemming from leaving it up to the stewards. Rivertorch (talk) 22:53, 12 July 2011 (UTC)[reply]
  4. - I'm with Rivertorch. --Whoop whoop pull up Bitching Betty | Averted crashes 13:18, 13 July 2011 (UTC)[reply]
  5. Stewards can and do work this job fine. Toa Nidhiki05 19:53, 14 July 2011 (UTC)[reply]
    Whilst stewards could do it by themselves; they could spend their time more productively on smaller wikis who need that extra help; while we can be self-sustaining and don't need the stewards help. --Addihockey10 e-mail 04:55, 15 July 2011 (UTC)[reply]
    Oppose The wording of this section is in conflict with the wording at Wikipedia:Administrators#Procedural_removal_for_inactive_administrators; it should state here that notifications should be made one month and several days before desysopping, as it does there. Otherwise it should just say "Refer to Wikipedia:Administrators#Procedural_removal_for_inactive_administrators. This may seem like a nitpick, but inconsistencies irk me. -RunningOnBrains(talk) 08:33, 15 July 2011 (UTC)[reply]
    Refer to Guy Macon's much-more-eloquent statement of this point in the "Discussion" section below. -RunningOnBrains(talk) 08:38, 15 July 2011 (UTC)[reply]
    The "per" means that they can only remove the rights in accordance with the policy. If the procedure set out in policy is not followed (i.e. the notification requirements prior to the removal of the rights have not been fulfilled), they may not remove the rights. –xenotalk 16:49, 15 July 2011 (UTC)[reply]
    Agreed, if you specify the wording here and then it changes there, then you open this discussion up again. If you make this contigent upon the wording in the specifically defined policy, then you say, "As long as they are following the rules as defined there, then they can have this."---Balloonman Poppa Balloon 15:53, 16 July 2011 (UTC)[reply]
    Fair enough. I have struck my oppose, since it appears to be technically in order, I just think the wording could be made clearer. -RunningOnBrains(talk) 14:34, 18 July 2011 (UTC)[reply]
  6. Oppose - I think this kind of decision should be made at higher level like Stewards. This situation is not an emergency afterall. Wikiglobaleditor (talk) 13:42, 21 July 2011 (UTC)[reply]
    Stewards shouldn't be making decisions here, period. That isn't their job. They execute, they don't judge. (I mean, they judge when they should execute, but...) If there was a system in place for removing inactive admins, we (the enwiki community) have to run thru the process, someone would have to close it (probably the 'crats), and then the closer would explicitly ask the stewards (over on meta) to remove the bit; the steward wouldn't have to judge, they'd only have to execute as a result of the process. The stewards won't/shouldn't be coming here and saying "oh, hey, you're inactive, you're no longer an admin". EVula // talk // ☯ // 16:40, 21 July 2011 (UTC)[reply]
  7. Oppose. The recent bungling of inactive-admin desysopping does not give me confidence. Chick Bowen 15:32, 27 July 2011 (UTC)[reply]
    Hmm - could you clarify? That was done by non-enwiki Stewards, not bureaucrats... –xenotalk 15:45, 27 July 2011 (UTC)[reply]
    I mean, I do not have confidence that the policy has been defined and will be carried out in a clear and consistent way, and thus I do not wish it to be expedited or further inscribed within more policy pages (I would have opposed the policy in the first place had I been around at the time; I only became aware of it when I noticed some old friends being abruptly desysoped). Chick Bowen 16:03, 27 July 2011 (UTC)[reply]
  8. Oppose If a specific period of inactivity is the criterion for desysopping then it would best be handled by a bot. Bots can handle this task in more consistent and equitable fashion than bureacrats are capable of.I think the time and energy of our bureacrats is an important resource that would be better spent doing things that require human intervention. BrandonHoward (talk) 13:09, 30 July 2011 (UTC)[reply]
  9. Abstain/Oppose on the same grounds as User:BrandonHoward - if something is automatic with bot-compatible criteria, and doesn't require consideration of the individual situation, then it makes sense for a bot to do it without needing human intervention. Mike Peel (talk) 18:57, 30 July 2011 (UTC)[reply]

Discussion

[edit]

The statement "If a bureaucrat removes the "administrator" user right from any user, they are required to notify the user in question immediately, including an explanation why the user right was removed and how they may re-gain it." appears to conflict with the statement "Bureaucrats may remove the "administrator" user right from an editor's account if the editor is deemed inactive per Wikipedia:Administrators#Procedural removal for inactive administrators" -- which references the following statement: "The admin must be contacted on their user talk page and via email (if possible) one month prior to the request for desysopping and again several days before the desysopping would go into effect." It should be made clear that endorsing this proposal is endorsing removal after attempting to contact the admin, and not endorsing removal followed by attempting to contact the admin. Guy Macon (talk) 19:28, 10 July 2011 (UTC)[reply]

Agree that it would be better to restate here that posting two notifications is a requirement. It is stated in the inactivity policy, but putting it in the crat policy as well would leave less room for misunderstandings. Jafeluv (talk) 19:38, 10 July 2011 (UTC)[reply]
Also agree...I listed this as an "Oppose" reason before even reading your point; good job beating me to the punch :) -RunningOnBrains(talk) 08:34, 15 July 2011 (UTC)[reply]
There is no conflict. The policy proposed here requires a post-removal notification in addition to the pre-removal notifications required in the inactivity policy. We directly reference and link to that policy, which clearly states its own requirements. Restating the content of that policy would be redundant and would make conflicts between the two more likely, not less likely. --RL0919 (talk) 11:42, 15 July 2011 (UTC)[reply]
Indeed. The word "per" means the bureaucrats may only remove rights in accordance with the relevant policy - so they must ensure the procedure (including notification) has been followed. And then they will still post a follow-up note once the rights have been actually removed. –xenotalk 16:54, 15 July 2011 (UTC)[reply]
I used the phrase "appears to conflict with" deliberately. You shouldn't have to follow a link to figure out the details of what you are voting for. If the proposal specifically mentions a requirement to notify after, it should also specifically mention the requirement to notify one month before and again several days before. Guy Macon (talk) 15:06, 22 July 2011 (UTC)[reply]

I'm not sure I understand the rationale for this - are there specific problems posed by having inactive admin accounts? Mike Peel (talk) 18:45, 30 July 2011 (UTC)[reply]

Ah, never mind, I found Wikipedia:Village pump (proposals)/suspend sysop rights of inactive admins - so the basic reasons are security, and tidiness. Mike Peel (talk) 18:49, 30 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Arbitration Committee requests

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Although there is reasonable opposition on the basis that such removals are not normally emergencies, there is overwhelming support for the proposal, largely on the basis that it brings official actions of the Arbitration Committee into the local logs and to reduce some of the complexity of such actions. Therefore, there is consensus that bureaucrats may remove administrator permissions as the result of an Arbitration Committee motion, in accordance with the committee's procedures outlined at Wikipedia:Arbitration Committee/Procedures#Removal of permissions, or in accordance with a remedy in a closed case which specifically mandates the removal of the permissions. HJ Mitchell | Penny for your thoughts? 14:15, 7 August 2011 (UTC)[reply]
Wikipedia:Bureaucrats will be expanded by adding the following section
==Removal of adminship==
Bureaucrats may remove the "administrator" user right by official request of the Arbitration Committee.
If a bureaucrat removes the "administrator" user right from any user, they are required to notify the user in question immediately, including an explanation why the user right was removed and how they may re-gain it. Notification is not required if the user was already notified of the removal.

Users who endorse this proposal

[edit]
  1. Yes- Stewards will do, simply, what Arbcom requests anyway. This cuts out some overhead without actually changing who decides on the de-sysop --Errant (chat!) 20:36, 7 July 2011 (UTC)[reply]
  2. More the merrier. ErikHaugen (talk | contribs) 21:09, 7 July 2011 (UTC)[reply]
  3. Yeah, once Arbcom has decided that a user should be desysopped, it doesn't much matter who does it. --causa sui (talk) 21:27, 7 July 2011 (UTC)[reply]
  4. I don't see the problem with this, it just means we don't have to go to a steward for the request. -- Atama頭 21:29, 7 July 2011 (UTC)[reply]
  5. Per ErrantX. Jafeluv (talk) 21:56, 7 July 2011 (UTC)[reply]
  6. Saves the stewards some time and lets us keep the entries in a local log rather than a remote one on meta. --(ʞɿɐʇ) ɐuɐʞsǝp 22:00, 7 July 2011 (UTC)[reply]
  7. Local support for our local Committee's decisions. I support all four points (with the alternative for #4 below), but supporting here as a fallback in case they don't all achieve consensus. --RL0919 (talk) 23:58, 7 July 2011 (UTC)[reply]
  8. Makes sense. Dabomb87 (talk) 00:20, 8 July 2011 (UTC)[reply]
  9. Rschen7754 00:50, 8 July 2011 (UTC)[reply]
  10. I have no issues with 'crats having this power... not explained, however, is if the power to de-admin is taken from stewards, as in my view these actions should all be on one log. One or the other. Jusdafax 00:55, 8 July 2011 (UTC)[reply]
    Stewards generally don't perform actions when local users are available to perform them, so apart from emergency situations all desysoppings covered by the crat policy would be performed by local crats if the policy is accepted. Jafeluv (talk) 07:37, 8 July 2011 (UTC)[reply]
  11. As there is usually a crat on ArbCom, I support this in principle but would like to know whether it matters if the desysopping crat is part of ArbCom. /ƒETCHCOMMS/ 03:22, 8 July 2011 (UTC)[reply]
  12. I'd personally rather not have the desysoping 'crat be on ArbCom, as there needs to be some sort of separation there. This makes sense. Sven Manguard Wha? 03:45, 8 July 2011 (UTC)[reply]
  13. Agree; we don't need meta stewards to enforce ArbCom decisions. —mc10 (t/c) 03:46, 8 July 2011 (UTC)[reply]
  14. jorgenev 04:22, 8 July 2011 (UTC)[reply]
  15. Since this is already the main path to the controversial desysop I support this policy proposal. Graeme Bartlett (talk) 08:37, 8 July 2011 (UTC)[reply]
  16. Certainly. Ironholds (talk) 11:34, 8 July 2011 (UTC)[reply]
  17. Completely uncontroversial. --SarekOfVulcan (talk) 18:03, 8 July 2011 (UTC)[reply]
  18. Ben MacDui 18:56, 8 July 2011 (UTC)[reply]
  19. Support per above. Regards SoWhy 19:29, 8 July 2011 (UTC)[reply]
  20. No reason not to, as otherwise the stewards will do it, achieving the same effect. (However, this has the important benefit of keeping all logs here.) Reaper Eternal (talk) 19:43, 8 July 2011 (UTC)[reply]
  21. Support. -- Ed (Edgar181) 22:41, 8 July 2011 (UTC)[reply]
  22. Support' Sir Armbrust Talk to me Contribs 00:46, 9 July 2011 (UTC)[reply]
  23. Support. 28bytes (talk) 01:46, 9 July 2011 (UTC)[reply]
  24. Support Seems logical, and might save ArbCom some work from time to time Nick-D (talk) 08:04, 9 July 2011 (UTC)[reply]
  25. Support Agathoclea (talk) 09:45, 9 July 2011 (UTC)[reply]
  26. Support Graham87 09:58, 9 July 2011 (UTC)[reply]
  27. Support. WJBscribe (talk) 10:31, 9 July 2011 (UTC)[reply]
  28. Support but agree with discussion points below that the notification should be handled by ArbCom. jsfouche ☽☾Talk 15:20, 9 July 2011 (UTC)[reply]
  29. Support. I also see ArbCom as the ones who should do the notification and explanation, with the Crat just carrying out the mechanical step. --Tryptofish (talk) 16:32, 9 July 2011 (UTC)[reply]
  30. Support Hut 8.5 16:56, 9 July 2011 (UTC)[reply]
  31. Support  Ronhjones  (Talk) 17:11, 9 July 2011 (UTC)[reply]
  32. AD 17:15, 9 July 2011 (UTC)[reply]
  33. First it giveth... Skomorokh 17:48, 9 July 2011 (UTC)[reply]
  34. -- Eraserhead1 <talk> 18:41, 9 July 2011 (UTC)[reply]
  35. Support -FASTILY (TALK) 04:40, 10 July 2011 (UTC)[reply]
  36. Support - if they have the technical right, and the situation is clear and self-evident that the user should be de-sysopped, then there is no reason that they shouldn't do it. עוד מישהו Od Mishehu 07:35, 10 July 2011 (UTC)[reply]
  37. - Dank (push to talk) 11:35, 10 July 2011 (UTC)[reply]
  38. Support A 'crat can only act according to consensus, of which ArbCom decisions is an example. LessHeard vanU (talk) 13:00, 10 July 2011 (UTC)[reply]
  39. Support. This doesn't seem controversial to me. ArbCom's decisions will be upheld either way, so we may as well let the 'crats do the actual de-sysopping. — Mr. Stradivarius ♫ 14:42, 10 July 2011 (UTC)[reply]
  40. Also noting that I have copy-edited the text of the proposal to read "by official request of" instead of "as a result an official request from" (sic); this text is shorter and does not change the meaning.  Sandstein  19:14, 10 July 2011 (UTC)[reply]
  41. Support Guy Macon (talk) 19:32, 10 July 2011 (UTC)[reply]
  42. Support - My76Strat talk 23:44, 10 July 2011 (UTC)[reply]
  43. Support Can't really find any argument against allowing them the ability to do so at request of arbs Bob House 884 (talk) 23:49, 10 July 2011 (UTC)[reply]
  44. Support — Edokter (talk) — 00:52, 11 July 2011 (UTC)[reply]
  45. Support Akin to having admins enforce ArbCom decisions. hare j 01:16, 11 July 2011 (UTC)[reply]
  46. Support. Tiderolls 01:40, 11 July 2011 (UTC)[reply]
  47. Support just simplifies things. Gigs (talk) 02:01, 11 July 2011 (UTC)[reply]
  48. Support demize (t · c) 02:35, 11 July 2011 (UTC)[reply]
  49. --JaGatalk 04:04, 11 July 2011 (UTC)[reply]
  50. Eluchil404 (talk) 04:06, 11 July 2011 (UTC)[reply]
  51. Support This is not something that will be controversial (whether the decision was made, not the underlying issue), if they're going to have the power they should be able to carry these out. ‡ MAHEWA ‡ • talk 05:00, 11 July 2011 (UTC)[reply]
  52. Support Bentogoa (talk) 06:31, 11 July 2011 (UTC)[reply]
  53. Support — Bill william comptonTalk 06:57, 11 July 2011 (UTC)[reply]
  54. Support Themeparkgc  Talk  07:21, 11 July 2011 (UTC)[reply]
  55. Support, this appears pretty straightforward. — Cirt (talk) 07:27, 11 July 2011 (UTC)[reply]
  56. Support - so long as the decision has been made, it's more sensible to allow 'crats to implement it than go chasing around for a steward. Pesky (talk …stalk!) 07:49, 11 July 2011 (UTC)[reply]
  57. Support - especially when admins apparent behavior is different in treatment of different sides in a discussion. ..असक्तः सततं कार्य कर्म समाचर | असक्तः हि आचरन् कर्म.. Humour Thisthat2011 07:58, 11 July 2011 (UTC)[reply]
  58. Sounds straightforward. T. Canens (talk) 08:10, 11 July 2011 (UTC)[reply]
  59. Support - I see nothing wrong with granting Bureaucrats the ability to fulfill requests from Arbcom. - Burpelson AFB ✈ 12:48, 11 July 2011 (UTC)[reply]
  60. Support Tyrol5 [Talk] 12:52, 11 July 2011 (UTC)[reply]
  61. Yes OK. Herostratus (talk) 13:02, 11 July 2011 (UTC)[reply]
  62. Support Though I think it should be Arbcom communicating it, not the 'crat. WormTT · (talk) 13:08, 11 July 2011 (UTC)[reply]
  63. Makes lots of sense to keep removals "for cause" easily visible in our log here. Courcelles 15:25, 11 July 2011 (UTC)[reply]
  64. Support Hekerui (talk) 18:09, 11 July 2011 (UTC)[reply]
  65. Support Sure, why not. There's no point bothering the Stewards for stuff that could be done on-en. TotientDragooned (talk) 20:02, 11 July 2011 (UTC)[reply]
  66. Sure, so long as b-crats can refuse should they feel arbcom has their heads in their asses. Protonk (talk) 20:32, 11 July 2011 (UTC)[reply]
  67. Yes, in order to transfer in full to the bureaucrats the role that the stewards presently fill. AGK [•] 23:12, 11 July 2011 (UTC)[reply]
  68. Support. Concur with comment by ErikHaugen. Build redundancy into system, particularly for fast action on ArbComm check of administrator powers, in those rare occasions when they are subjected to de jure curtailment. GeoBardRap 00:47, 12 July 2011 (UTC)[reply]
  69. sonia♫ 01:23, 12 July 2011 (UTC)[reply]
  70. Jujutacular talk 03:17, 12 July 2011 (UTC)[reply]
  71. Strong Support It is already established policy to remove admins pursuant to an ArbCom decision thus I seen no need to involve a steward in what is essentially an administrative action.  Jim Reed (Talk)  04:15, 12 July 2011 (UTC)[reply]
  72. Support Edgepedia (talk) 05:00, 12 July 2011 (UTC)[reply]
  73. Support. This is as clear-cut a case as it gets (i.e. an Arbitration Committee decision or motion has called for the removal of adminship, and therefore adminship must be removed). Even if this weren't a clear-cut case, I'd still trust a bureaucrat's judgment. szyslak (t) 08:05, 12 July 2011 (UTC)[reply]
  74. Support Of course Jebus989✰ 08:29, 12 July 2011 (UTC)[reply]
  75. Support - Per my reasoning in Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag, I am supporting all four. -Porch corpter (talk/contribs) 10:26, 12 July 2011 (UTC)[reply]
  76. Support there is no harm in adding crats to the list of people who can desysop in such situations, and the slight advantage of a clearer rights log. BencherliteTalk 14:53, 12 July 2011 (UTC)[reply]
  77. Support If 'crats can give admin rights per ArbCom, why can't they take admin rights away per ArbCom? --Whoop whoop pull up Bitching Betty | Averted crashes 13:20, 13 July 2011 (UTC)[reply]
  78. Support – In order to reduce enwiki's dependence on Stewards. --Michaeldsuarez (talk) 16:05, 13 July 2011 (UTC)[reply]
  79. Support Good idea. ~~EBE123~~ talkContribs 22:24, 13 July 2011 (UTC)[reply]
  80. Support. Cla68 (talk) 05:35, 14 July 2011 (UTC)[reply]
  81. Support --Sgt. R.K. Blue (talk) 10:05, 14 July 2011 (UTC)[reply]
  82. Support makes sense -- Alexf(talk) 15:24, 14 July 2011 (UTC)[reply]
  83. Strong Support Lighthead þ 16:42, 14 July 2011 (UTC)[reply]
  84. Support - Bazj (talk) 17:14, 14 July 2011 (UTC)[reply]
  85. Support - Sounds fine. --RA (talk) 19:04, 14 July 2011 (UTC)[reply]
  86. Sensible in its utility and limitations. — Scientizzle 20:46, 14 July 2011 (UTC)[reply]
  87. support doesn't matter who does it as long as arb com says to do it. Takes some of the load off of stewards. Chris (talk) 20:57, 14 July 2011 (UTC)[reply]
  88. Support North8000 (talk) 00:36, 15 July 2011 (UTC)[reply]
  89. Support -- Alex146 (talk) 01:52, 15 July 2011 (UTC)[reply]
  90. Support -- this seems pretty obvious and straightforward. --Alecmconroy (talk) 05:48, 15 July 2011 (UTC)[reply]
  91. Support -- Well-worded, simple, and logical. -RunningOnBrains(talk) 08:37, 15 July 2011 (UTC)[reply]
  92. Support - speaking as a former clerk, this is a very good idea. Manning (talk) 09:13, 15 July 2011 (UTC)[reply]
  93. Support. But the wording?

    "Bureaucrats may remove the "administrator" user right from an administrator by official request of the Arbitration Committee. If a bureaucrat removes the "administrator" user right from any user, they are required to notify the user in question immediately, including an explanation of why the user right was removed and how they may re-gain the user may regain it. Notification is not required if the user was already has already been notified of the removal."

    Sorry to be a pedant, but if the user has already been notified, that was presumably done by ArbCom. If ArbCom can decide by itself to remove the right, why are the crats given the option of removing it or not removing it, in the word "may"? Can't have it both ways. Better: "Bureaucrats may should remove the "administrator" user right by official request of from an administrator if officially requested by the Arbitration Committee. ..." Tony (talk) 13:18, 15 July 2011 (UTC)[reply]

    Remember that this is a wiki. This RfC is not a permanent commitment to the exact wording. Once the material is added to the policy page, non-controversial grammar edits may be made by any editor, and mildly controversial changes can be discussed on the policy talk page. ('May' vs. 'should' has some potential to be controversial, but stuff like "was already" vs. "has already been" most likely would not be.) --RL0919 (talk) 15:10, 15 July 2011 (UTC)[reply]
  94. Support - Any instance where the community has decided admin rights should be removed, this is another one. GB fan please tell me what you think of my editing 14:19, 15 July 2011 (UTC)[reply]
  95. Support - Casliber (talk · contribs) 15:22, 15 July 2011 (UTC)[reply]
  96. Support - increases accountability on the part of administrators within the bounds of Wikipedia. SuperMarioMan 21:27, 15 July 2011 (UTC)[reply]
  97. Support Chaosdruid (talk) 23:59, 15 July 2011 (UTC)[reply]
  98. Support Happy‑melon 00:08, 16 July 2011 (UTC)[reply]
  99. Support execution of proper requests. Jd2718 (talk) 00:32, 16 July 2011 (UTC)[reply]
  100. Support--cc 08:21, 16 July 2011 (UTC)[reply]
  101. Logan Talk Contributions 13:11, 16 July 2011 (UTC)[reply]
  102. Support' Since the bureaucrat is simply implementing the decisions of another body and not exercising discretion of their own. RJC TalkContribs 14:02, 16 July 2011 (UTC)[reply]
  103. ---Balloonman Poppa Balloon 15:24, 16 July 2011 (UTC)[reply]
  104. Support. This action can be taken at this level. No need to be at a higher level. Lightmouse (talk) 16:42, 16 July 2011 (UTC)[reply]
  105. Support. elektrikSHOOS (talk) 19:40, 16 July 2011 (UTC)[reply]
  106. Support. However, I'd rather not have the desysopping crat be on ArbCom. — Waterfox ~talk~ 22:12, 16 July 2011 (UTC)[reply]
  107. Mr.Z-man 00:15, 17 July 2011 (UTC)[reply]
  108. Support. A vital tool for bureaucrats. SteveStrummer (talk) 05:33, 17 July 2011 (UTC)[reply]
  109. Support. Comte0 (talk) 09:26, 17 July 2011 (UTC)[reply]
  110. Support. If Arbcom has decided to remove someone's admin rights, having crats able to do it will simply speed things up -- Boing! said Zebedee (talk) 16:08, 17 July 2011 (UTC)[reply]
  111. Yes, says Ratibgreat (talk) 16:31, 17 July 2011 (UTC).[reply]
  112. Support. -- Ϫ 01:21, 18 July 2011 (UTC)[reply]
  113. Support. Cind.amuse 07:19, 18 July 2011 (UTC)[reply]
  114. Support. Seems procedural. maclean (talk) 15:20, 18 July 2011 (UTC)[reply]
  115. I don't see a problem with this, especially as the decision is made by the arbcom and not ad hoc. Totnesmartin (talk) 17:12, 18 July 2011 (UTC)[reply]
  116. Support - This seems procedural, as the bureaucrats would simply be implementing official ArbCom decisions or rulings. --SoCalSuperEagle (talk) 17:54, 18 July 2011 (UTC)[reply]
  117. I support this only if there is a clear and unmistakable process in place. Ideally, this would involve an ArbCom representative (either an arb or an ArbCom clerk) to post on the 'crat noticeboard with a link to the case that clearly states a userright needs to be removed. The userright log can then just link to the ArbCom case. Voila, no confusion. EVula // talk // ☯ // 21:21, 18 July 2011 (UTC)[reply]
  118. Support. Psychiatrick (talk) 11:03, 19 July 2011 (UTC)[reply]
  119. Support Peter (Southwood) (talk): 12:43, 19 July 2011 (UTC)[reply]
  120. Support - I don't see why not since this should just involve following orders. CT Cooper · talk 20:48, 19 July 2011 (UTC)[reply]
  121. Support - Nick Thorne talk 03:05, 20 July 2011 (UTC)[reply]
  122. Support Clearly defined activity, not likely to produce confusion, abuse, or controversy. I, Jethrobot drop me a line (note: not a bot!) 05:24, 20 July 2011 (UTC)[reply]
  123. Support Jehochman Talk 20:16, 20 July 2011 (UTC)[reply]
  124. Support with a caveat - I would prefer that the sysop be notified on his/her talk page, with at least a few hours' notice, but I can go along with it as worded. Bearian (talk) 18:00, 21 July 2011 (UTC)[reply]
  125. Support Blue Rasberry (talk) 14:22, 22 July 2011 (UTC)[reply]
  126. Support - Makes since as well. --Nathan2055talk 19:20, 22 July 2011 (UTC)[reply]
  127. No reason not to support this. BigDom 21:54, 22 July 2011 (UTC)[reply]
  128. Support: enforcement of arbcom decisions by bureaucrats would be most appropriate. Jezhotwells (talk) 17:29, 23 July 2011 (UTC)[reply]
  129. Support It seems so obvious... - Al Lemos (talk) 23:40, 23 July 2011 (UTC)[reply]
  130. --Cybercobra (talk) 06:24, 24 July 2011 (UTC)[reply]
  131. Support - the power lies with ArbCom, if we give crats the technical ability, they should be able to perform this sort of request. Ale_Jrbtalk 17:23, 24 July 2011 (UTC)[reply]
  132. Conditional support if this is handled only for explicit desysopping remedies, to satisfy concerns brought up in the oppose section below. Titoxd(?!? - cool stuff) 07:11, 28 July 2011 (UTC)[reply]
  133. Support As long as there just parroting arbcon I don't see any harm in it. That being said in the long run we should look into ways that this an be done directly by arbcon. BrandonHoward (talk) 13:28, 30 July 2011 (UTC)[reply]
  134. Support - since arbcom have the ability to desysop someone, then it makes sense to broaden the number of people that can carry through with that conclusion. I would encourage arbcom clerks to seek bureaucrat status to utilise this ability in an efficient manner. Mike Peel (talk) 19:02, 30 July 2011 (UTC)[reply]
  135. Support If ArbCom decide on this, then whether it is a Steward or 'crat does it is irrelevant. PhantomSteve/talk|contribs\ 22:26, 30 July 2011 (UTC)[reply]
  136. Support. —Jclavet (talk) 20:40, 31 July 2011 (UTC)[reply]
  137. Support. Blackvisionit (talk) 02:47, 1 August 2011 (UTC)[reply]
  138. Support allowing the Bureaucrats to do ArbCom's bidding. Huon (talk) 11:49, 1 August 2011 (UTC)[reply]
  139. Support - frankie (talk) 16:52, 1 August 2011 (UTC)[reply]
  140. Support per Phantomsteve. Bureaucrats wouldn't be doing anything requiring any personal judgement at all when they fulfill Arbcom's bidding, so this definitely won't be a problem. Nyttend (talk) 04:42, 2 August 2011 (UTC)[reply]
  141. Support Choyoołʼįįhí:Seb az86556 > haneʼ 06:25, 2 August 2011 (UTC)[reply]
  142. Support Xymmax So let it be written So let it be done 12:50, 4 August 2011 (UTC)[reply]
  143. Support Bejinhan talks 13:40, 4 August 2011 (UTC)[reply]

Users who oppose this proposal

[edit]
  1. -Atmoz (talk) 21:29, 8 July 2011 (UTC)[reply]
  2. Prodego talk 20:08, 9 July 2011 (UTC)[reply]
  3. This is not an emergency; it's not so time critical that we can't wait for a steward, and so common that it will cause an undo burden upon the steward (as inactive administratorship does). Magog the Ogre (talk) 17:34, 11 July 2011 (UTC)[reply]
    Is having a removal of adminship by official Arbitration Committee decision registered in the local userrights log not worthwhile? –xenotalk 18:12, 11 July 2011 (UTC)[reply]
    1) This is something I think the devs should be fixing, not necessarily policy; 2) this policy is pretty broadly worded, and I'm worried there will be too broad of an interpretation by the 'crat. Magog the Ogre (talk)
    Could you explain what you mean by broadly worded? An official request from the Arbitration Committee will be made under the Wikipedia:Arbitration Committee/Procedures#Removal of permissions section, after a formal motion, or as a result of a remedy in a closed case. –xenotalk 19:43, 11 July 2011 (UTC)[reply]
    I do not want a bureaucrat to broadly interpret a ruling form ArbCom (e.g., admins who edit war on protected pages are subject to deadminship): I can actually see this occurring in the right situation. I also don't want, for example, a private email from a single arbitrar to be interpreted this way. I would say only requests from ArbCom on that page should suffice: but the wording of the proposal above doesn't specifically state what exactly a formal request is. Magog the Ogre (talk) 20:47, 11 July 2011 (UTC)[reply]
    Neither of those could be reasonably interpreted as an official request; and a bureaucrat removing administrative rights in either of this situations would likely find themselves relieved of their bureaucrat tools (and the arbitrator in the second case would likely be punted as well). That being said, it may be worthwhile to add a footnoted or bracketed explanation of "official request" for greater certainty. –xenotalk 20:56, 11 July 2011 (UTC)[reply]
    Bureaucrats aren't any more fallible than stewards are. If anything, they know our project's unique culture and policies, so they would be more unlikely to make such a mistake. For example, several stewards immediately got to work in removing userrights from inactive admins after we passed our recent proposal, despite clear instructions saying that at least a month's notification is required. I don't think a local, active crat who was up to date on our policies would make that mistake. NW (Talk) 23:18, 11 July 2011 (UTC)[reply]
    As a former clerk, the procedure for de-sysopping due to Arbcom decision was pretty explicit. A formal notice, along with links to the relevant ArbCom decision (which explicitly named the admin in question) was required. I can't see that procedure changing. No-one ('Crat or Steward) would ever interpret a generalized ArbCom statement about admin consequences as giving them a free rein to make such a decision on their own. Manning (talk) 09:12, 15 July 2011 (UTC)[reply]
    "This is something I think the devs should be fixing" - I believe it's been said that this is surprisingly difficult for something with relatively little benefit, and therefore so low down the list of priorities that in practical terms, it ain't gonna happen. Rd232 talk 22:41, 15 July 2011 (UTC)[reply]
  4. - Unnecessary. Arbcom decisions don't happen in the blink of an eye, and I'm unaware of any evidence that the stewards aren't up to the job. Rivertorch (talk) 22:55, 12 July 2011 (UTC)[reply]
  5. Reasons stated above. Toa Nidhiki05 19:54, 14 July 2011 (UTC)[reply]
  6. Oppose Agree with reasons stated above. NECRATSpeak to me 09:37, 16 July 2011 (UTC)[reply]
  7. Oppose - This is not a time critical scenario. Agree with reasons stated above. Wikiglobaleditor (talk) 14:02, 21 July 2011 (UTC)[reply]
  8. Oppose, if this is an "external" decision, why should somebody from enwp handle the request? mabdul 16:48, 24 July 2011 (UTC)[reply]
    There is nothing "external" about the Arbitration Committee. Dabomb87 (talk) 22:45, 24 July 2011 (UTC)[reply]
  9. The wording of this is wrong, as said below in the discussion section and unhelpfully dismissed. Bureaucrats should never communicate the terms of an arbcom decision--that's the job of arbitrators or clerks. The person who flips the bit--whoever that is--should wait until arbcom has notified the admin. Chick Bowen 00:31, 3 August 2011 (UTC)[reply]
  10. Oppose, for purely selfish and anti-bureaucratic reasons. :) --Kooky (talk) 14:21, 3 August 2011 (UTC)[reply]

Discussion

[edit]
  • I support this in principle, but don't see why it should be the bureaucrat's job to communicate Arbcom's decision. It makes more sense to me to have Arbcom handle that notification. Ucucha 21:21, 7 July 2011 (UTC)[reply]
    That's why it says they can skip notification if the user was already notified. I expect in most of these situations the user will already have an explanation from ArbCom before the 'crat gets to the desysopping. --RL0919 (talk) 21:23, 7 July 2011 (UTC)[reply]
  • Support in principle, but it strikes me as oddly inappropriate for the bureaucrat to be going into detail about the whys and wherefores and whatyoucandos - that's a job for Arbcom. If no notification is made prior to desysopping, the only notification the bureaucrat should leave is to say "per Arbcom request - please await details from them, or in the event that none is forthcoming within 24 hours, contact them." Rd232 public talk 23:04, 8 July 2011 (UTC)[reply]
    A crat wouldn't need to go into detail if he could link to a page describing ArbCom's decision. --Damian Yerrick (talk | stalk) 21:18, 28 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Self-requests

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The overwhelming consensus reached is that Bureaucrats are to treat requests from the administrator to remove their own rights as uncontroversial and remove them pro forma as outlined in voluntary removal. Evidently, the request page will be moved to the Bureaucrats Noticeboard (or a sub-page thereof). Administrators that did not resign in controversial circumstances and whose identity is not in question will be reinstated as per resysopping policy.

Crazynas t 16:35, 7 August 2011 (UTC)[reply]

Wikipedia:Bureaucrats will be expanded by adding the following section
==Removal of adminship==
Bureaucrats may remove the "administrator" user right from an editor's account if self-requested by the administrator.

Users who endorse this proposal

[edit]
  1. Yes; however we should agree on re-sysoping procedures for admins who have the bit removed in this way. I know we have some general approaches anyway, but lets be firm about it. --Errant (chat!) 20:37, 7 July 2011 (UTC)[reply]
  2. Why not. ErikHaugen (talk | contribs) 21:10, 7 July 2011 (UTC)[reply]
  3. As with #1. I don't see why we need additional discussion on re-sysopping, since that process is already in place and I don't see why this proposal would seriously affect it. Ucucha 21:22, 7 July 2011 (UTC)[reply]
  4. This should be the least controversial removal of adminship. -- Atama頭 21:30, 7 July 2011 (UTC)[reply]
  5. Uncontroversial IMHO. Jafeluv (talk) 21:54, 7 July 2011 (UTC)[reply]
  6. Saves the stewards some time and lets us keep the entries in a local log rather than a remote one on meta. --(ʞɿɐʇ) ɐuɐʞsǝp 22:01, 7 July 2011 (UTC)[reply]
  7. No reason why not. --causa sui (talk) 22:12, 7 July 2011 (UTC)[reply]
  8. This is the most obvious case to permit. I support all four points (with the alternative for #4 below), but supporting here as a fallback in case they don't all achieve consensus. --RL0919 (talk) 23:57, 7 July 2011 (UTC)[reply]
  9. No reason not to support this one. Dabomb87 (talk) 00:23, 8 July 2011 (UTC)[reply]
  10. Rschen7754 00:50, 8 July 2011 (UTC)[reply]
  11. The most obvious. /ƒETCHCOMMS/ 03:22, 8 July 2011 (UTC)[reply]
  12. Obviously. —mc10 (t/c) 03:48, 8 July 2011 (UTC)[reply]
  13. jorgenev 04:23, 8 July 2011 (UTC)[reply]
  14. Sounds very reasonable. Graeme Bartlett (talk) 08:32, 8 July 2011 (UTC)[reply]
  15. Seems fair enough. Ironholds (talk) 11:34, 8 July 2011 (UTC)[reply]
  16. Support, this keeps requests on Wikipedia where they belong. --SarekOfVulcan (talk) 18:04, 8 July 2011 (UTC)[reply]
  17. Support Ben MacDui 18:56, 8 July 2011 (UTC)[reply]
  18. Support, uncontroversial and logical change. Jusdafax 19:11, 8 July 2011 (UTC)[reply]
  19. Support per above. No brainer. Regards SoWhy 19:29, 8 July 2011 (UTC)[reply]
  20. Agree with SoWhy, this is definitely a no-brainer. Reaper Eternal (talk) 19:44, 8 July 2011 (UTC)[reply]
  21. Support. -- Ed (Edgar181) 22:41, 8 July 2011 (UTC)[reply]
  22. Support, bearing in mind Xeno's reminder of the existence of WP:RESYSOP provisions. Rd232 public talk 23:06, 8 July 2011 (UTC)[reply]
  23. Support Sir Armbrust Talk to me Contribs 00:48, 9 July 2011 (UTC)[reply]
  24. ...well then. With my concern below addressed, I can support this one. Sven Manguard Wha? 00:50, 9 July 2011 (UTC)[reply]
  25. Support. 28bytes (talk) 01:47, 9 July 2011 (UTC)[reply]
  26. Support Nick-D (talk) 08:05, 9 July 2011 (UTC)[reply]
  27. Support Agathoclea (talk) 09:45, 9 July 2011 (UTC)[reply]
  28. Support Graham87 09:58, 9 July 2011 (UTC)[reply]
  29. Support. WJBscribe (talk) 10:31, 9 July 2011 (UTC)[reply]
  30. Support logical jsfouche ☽☾Talk 15:22, 9 July 2011 (UTC)[reply]
  31. Support. --Tryptofish (talk) 16:33, 9 July 2011 (UTC)[reply]
  32. Support Hut 8.5 16:57, 9 July 2011 (UTC)[reply]
  33. Suport  Ronhjones  (Talk) 17:12, 9 July 2011 (UTC)[reply]
  34. AD 17:15, 9 July 2011 (UTC)[reply]
  35. With reticence towards the inevitable seesawing of dramanaut admins at BN. Skomorokh 17:49, 9 July 2011 (UTC)[reply]
  36. -- Eraserhead1 <talk> 18:41, 9 July 2011 (UTC)[reply]
  37. Support -FASTILY (TALK) 04:40, 10 July 2011 (UTC)[reply]
  38. Support - if they have the technical right, and the situation is clear and self-evident that the user should be de-sysopped, then there is no reason that they shouldn't do it. עוד מישהו Od Mishehu 09:02, 10 July 2011 (UTC)[reply]
  39. - Dank (push to talk) 11:35, 10 July 2011 (UTC)[reply]
  40. Support A 'crat can only act according to consensus, of which a self request is an example. LessHeard vanU (talk) 13:01, 10 July 2011 (UTC)[reply]
  41. Support. I can't see any reason why not. — Mr. Stradivarius ♫ 14:43, 10 July 2011 (UTC)[reply]
  42.  Sandstein  19:15, 10 July 2011 (UTC)[reply]
  43. Support - My76Strat talk 23:45, 10 July 2011 (UTC)[reply]
  44. Support uncontroversial Bob House 884 (talk) 23:50, 10 July 2011 (UTC)[reply]
  45. Support, but email confirmation of the request, conversation on talk page, ... might be appropriate lest some mischief be afoot. htom (talk) 00:49, 11 July 2011 (UTC)[reply]
  46. Supprt — Edokter (talk) — 00:53, 11 July 2011 (UTC)[reply]
  47. Support Obvious and uncontroversial. hare j 01:17, 11 July 2011 (UTC)[reply]
  48. Support. Tiderolls 01:41, 11 July 2011 (UTC)[reply]
  49. Support Clearly. Sending Admins elsewhere for de-sysopping requests has always seemed silly to me. -- Mattinbgn (talk) 02:02, 11 July 2011 (UTC)[reply]
  50. Support demize (t · c) 02:35, 11 July 2011 (UTC)[reply]
  51. --JaGatalk 04:05, 11 July 2011 (UTC)[reply]
  52. Eluchil404 (talk) 04:07, 11 July 2011 (UTC)[reply]
  53. Support Again, something that won't controversial or have need discretion in carrying out. ‡ MAHEWA ‡ • talk 05:00, 11 July 2011 (UTC)[reply]
  54. Support Bentogoa (talk) 06:33, 11 July 2011 (UTC)[reply]
  55. Support Obvious and least controversial reason. — Bill william comptonTalk 06:59, 11 July 2011 (UTC)[reply]
  56. Support Themeparkgc  Talk  07:21, 11 July 2011 (UTC)[reply]
  57. Support, probably the least controversial of the bunch. — Cirt (talk) 07:27, 11 July 2011 (UTC)[reply]
  58. Support, kinda obvious. Provided that re-sysopping is as simple, in the event that the self-request was the result of impersonation, etc. Pesky (talk …stalk!) 07:51, 11 July 2011 (UTC)[reply]
  59. Obvious. T. Canens (talk) 08:10, 11 July 2011 (UTC)[reply]
  60. If an admin requests removal of the tools under uncontroversial circumstances, I see no reason why a 'crat shouldn't be able to remove the tools, like how they already can restore them upon request. SchuminWeb (Talk) 09:33, 11 July 2011 (UTC)[reply]
  61. Support per above. - Burpelson AFB ✈ 12:49, 11 July 2011 (UTC)[reply]
  62. Support Tyrol5 [Talk] 12:52, 11 July 2011 (UTC)[reply]
  63. Support perfectly reasonable. WormTT · (talk) 13:10, 11 July 2011 (UTC)[reply]
  64. OK yes, sure. Herostratus (talk) 13:12, 11 July 2011 (UTC)[reply]
  65. Courcelles 15:26, 11 July 2011 (UTC)[reply]
  66. Support Hekerui (talk) 18:09, 11 July 2011 (UTC)[reply]
  67. Support Common-sense. TotientDragooned (talk) 20:04, 11 July 2011 (UTC)[reply]
  68. Protonk (talk) 20:36, 11 July 2011 (UTC)[reply]
  69. AGK [•] 23:12, 11 July 2011 (UTC)[reply]
  70. sonia♫ 01:23, 12 July 2011 (UTC)[reply]
  71. Jujutacular talk 03:17, 12 July 2011 (UTC)[reply]
  72. Strong Support It is already established policy to remove admins pursuant to a self-issued request thus I seen no need to involve a steward in what is essentially an administrative action.  Jim Reed (Talk)  04:15, 12 July 2011 (UTC)[reply]
  73. Support Edgepedia (talk) 05:01, 12 July 2011 (UTC)[reply]
  74. Support. This is the biggest no-brainer of them all. szyslak (t) 08:13, 12 July 2011 (UTC)[reply]
  75. Support Agree with the above comment Jebus989✰ 08:31, 12 July 2011 (UTC)[reply]
  76. Support - Per my reasoning in Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag, I am supporting all four. -Porch corpter (talk/contribs) 10:26, 12 July 2011 (UTC)[reply]
  77. Support makes sense and keeps the rights log clearer. BencherliteTalk 14:53, 12 July 2011 (UTC)[reply]
  78. YES. If admins want to handicap themselves, I say let them do that. --Whoop whoop pull up Bitching Betty | Averted crashes 13:23, 13 July 2011 (UTC)[reply]
  79. Support – If a sysop is more comfortable asking a bureaucrat to desysop them, then they should have that right. --Michaeldsuarez (talk) 16:03, 13 July 2011 (UTC)[reply]
  80. Support Good idea. ~~EBE123~~ talkContribs 22:24, 13 July 2011 (UTC)[reply]
  81. Support. I thought bureaucrats already had this role. Way overdue. Cla68 (talk) 05:36, 14 July 2011 (UTC)[reply]
  82. Support --Sgt. R.K. Blue (talk) 10:05, 14 July 2011 (UTC)[reply]
  83. Support yes, per #1 -- Alexf(talk) 15:26, 14 July 2011 (UTC)[reply]
  84. Strong Support If they want it done, they should have it done. Lighthead þ 16:45, 14 July 2011 (UTC)[reply]
  85. Support - Bazj (talk) 17:14, 14 July 2011 (UTC)[reply]
  86. Support - Sure, why not? --RA (talk) 19:05, 14 July 2011 (UTC)[reply]
  87. Sensible in its utility and limitations. — Scientizzle 20:48, 14 July 2011 (UTC)[reply]
  88. SupportChris (talk) 21:02, 14 July 2011 (UTC)[reply]
  89. Support. Non-controversial and keeps the logs together. Useight (talk) 22:44, 14 July 2011 (UTC)[reply]
  90. Support North8000 (talk) 00:38, 15 July 2011 (UTC)[reply]
  91. Support I see the point of possible compromise in knowing who, exactly, is requesting the degrade, but I think that if an admin were to walk away from a public computer without logging out, then he or she deserves being degraded. -- Alex146 (talk) 01:52, 15 July 2011 (UTC)[reply]
  92. Support - no-brainer. Manning (talk) 09:32, 15 July 2011 (UTC)[reply]
  93. Support Obviously.--Breawycker (talk to me!) 13:13, 15 July 2011 (UTC)[reply]
  94. Support Tony (talk) 13:26, 15 July 2011 (UTC)[reply]
  95. Support - GB fan please tell me what you think of my editing 14:21, 15 July 2011 (UTC)[reply]
  96. Support - Casliber (talk · contribs) 15:23, 15 July 2011 (UTC)[reply]
  97. Support - why not? This all relates to streamlining a process by avoiding the requirement to cross from Wikipedia to Meta. SuperMarioMan 21:33, 15 July 2011 (UTC)[reply]
  98. Support Chaosdruid (talk) 23:58, 15 July 2011 (UTC)[reply]
  99. Support Happy‑melon 00:08, 16 July 2011 (UTC)[reply]
  100. Support yes, unobjectionable. Jd2718 (talk) 00:31, 16 July 2011 (UTC)[reply]
  101. Support I can see no reason why not, if an admin wants to have the bit voluntarily removed, why shouldn't they be able to get it done locally? Monty845 05:04, 16 July 2011 (UTC)[reply]
  102. Support The reasoning should be justified as to why they wish not to, but ultimately, it is their choice. NECRATSpeak to me 09:35, 16 July 2011 (UTC)[reply]
  103. Logan Talk Contributions 13:12, 16 July 2011 (UTC)[reply]
  104. Support Because there is no discretion involved, simply the responding to an unambiguous request. RJC TalkContribs 14:21, 16 July 2011 (UTC)[reply]
  105. ---Balloonman Poppa Balloon 15:25, 16 July 2011 (UTC)[reply]
  106. Support. I'd even support admins being able to de-admin themselves. It should always be easy to turn off access to powerful tools. Lightmouse (talk) 16:45, 16 July 2011 (UTC)[reply]
  107. Support. elektrikSHOOS (talk) 19:41, 16 July 2011 (UTC)[reply]
  108. Support - uncontroversial, the most obvious. — Waterfox ~talk~ 22:14, 16 July 2011 (UTC)[reply]
  109. Mr.Z-man 00:16, 17 July 2011 (UTC)[reply]
  110. Support. Comte0 (talk) 09:27, 17 July 2011 (UTC)[reply]
  111. Support. I really can't see any reason why crats shouldn't be able to handle a self-deadmin request -- Boing! said Zebedee (talk) 16:10, 17 July 2011 (UTC)[reply]
  112. Yes, says Ratibgreat (talk) 16:30, 17 July 2011 (UTC).[reply]
  113. Support. -- Ϫ 01:23, 18 July 2011 (UTC)[reply]
  114. Support. Cind.amuse 07:27, 18 July 2011 (UTC)[reply]
  115. Support. --maclean (talk) 15:37, 18 July 2011 (UTC)[reply]
  116. Support - This is clearly uncontroversial, so why not? --SoCalSuperEagle (talk) 17:12, 18 July 2011 (UTC)[reply]
  117. It's a self-request; what's the problem? The log splitting can be a pain. EVula // talk // ☯ // 21:15, 18 July 2011 (UTC)[reply]
  118. Support Peter (Southwood) (talk): 12:44, 19 July 2011 (UTC)[reply]
  119. Support - Again, non-controversial. CT Cooper · talk 20:49, 19 July 2011 (UTC)[reply]
  120. Support No brainer - Nick Thorne talk 03:08, 20 July 2011 (UTC)[reply]
  121. Support Clearly defined activity, not likely to produce confusion, abuse, or controversy. I, Jethrobot drop me a line (note: not a bot!) 05:26, 20 July 2011 (UTC)[reply]
  122. Support - why not Ruhrfisch ><>°° 11:47, 20 July 2011 (UTC)[reply]
  123. Support - This is not a complex scenario - this burden may be laid-off from Stewards. Wikiglobaleditor (talk) 14:09, 21 July 2011 (UTC)[reply]
  124. Support per SoWhy. Bearian (talk) 18:01, 21 July 2011 (UTC)[reply]
  125. Support seems like a no brainer Gregtheross (talk) 12:28, 22 July 2011 (UTC)[reply]
  126. Support Blue Rasberry (talk) 14:23, 22 July 2011 (UTC)[reply]
  127. Support - Yep. This makes since, too. --Nathan2055talk 19:23, 22 July 2011 (UTC)[reply]
  128. Support: no-brainer really. Those who are worried about "impostors", should realise that if the account of an admin is compromised then they should obviously be de-sysoped. Jezhotwells (talk) 17:32, 23 July 2011 (UTC)[reply]
  129. Support. SpencerT♦C 20:25, 23 July 2011 (UTC)[reply]
  130. Support It makes sense to me. - Al Lemos (talk) 23:42, 23 July 2011 (UTC)[reply]
  131. Uncontroversial. --Cybercobra (talk) 06:21, 24 July 2011 (UTC)[reply]
  132. Support. mabdul 16:46, 24 July 2011 (UTC)[reply]
  133. Support. Ale_Jrbtalk 17:24, 24 July 2011 (UTC)[reply]
  134. Support, uncontroversial. Titoxd(?!? - cool stuff) 07:12, 28 July 2011 (UTC)[reply]
  135. Support. bd2412 T 18:39, 29 July 2011 (UTC)[reply]
  136. Support. Sure, of course. Kitty DeClaude (talk) 22:35, 29 July 2011 (UTC)[reply]
  137. Support That seems fine but in the long run this really needs to be something people can do for themselves through the My preferences tab. — Preceding unsigned comment added by BrandonHoward (talk • contribs)
  138. Support makes sense, although I agree with the comment above that this would ideally be done through user preferences. Mike Peel (talk) 19:09, 30 July 2011 (UTC)[reply]
  139. Support although with the proviso that if it is 'under a cloud' (e.g. to try to pre-empt a RfC/U or ArbCom decision) then re-confirmation is required; if the self-request is not under those conditions (for example, I know that I will not be online for 6 months as I'm going to the Moon) then merely requesting it back should be sufficient PhantomSteve/talk|contribs\ 22:29, 30 July 2011 (UTC)[reply]
  140. Support. —Jclavet (talk) 20:43, 31 July 2011 (UTC)[reply]
  141. Support. Blackvisionit (talk) 02:48, 1 August 2011 (UTC)[reply]
  142. Support uncontroversial housekeeping. Huon (talk) 11:50, 1 August 2011 (UTC)[reply]
  143. Support - frankie (talk) 16:52, 1 August 2011 (UTC)[reply]
  144. Support - if someone wants to opt out, let them. --Just your average banjo playing, drag racing, cowboy... 20:35, 1 August 2011 (UTC)
  145. Support like with all the others: this is already done by stewards, so I don't see why we should enable the bureaucrats to do it but prohibit them from doing it. Let's just keep the current provisions, that anyone's rights may be removed per self-request, that they may be restored per request at any time if the bureaucrat believe the situation to be noncontroversial, and that an RFA be always permitted and sometimes required. Nyttend (talk) 04:45, 2 August 2011 (UTC)[reply]
  146. Support Xymmax So let it be written So let it be done 12:50, 4 August 2011 (UTC)[reply]
  147. Support Why not, since it is at the request of admin. Bejinhan talks 13:41, 4 August 2011 (UTC)[reply]
  148. Support. This would act to reduce any non-arbitrary backlog. ~AH1 (discuss!) 15:19, 4 August 2011 (UTC)[reply]

Users who oppose this proposal

[edit]
I support this in principle, but language on re-sysoping needs to be put in here specifically. People asking for temporary removal while they spend six months touring Antarctica need to be treated differently from people asking for removal as part of permanent retirement (and then want it back after four years, and both of those need to be treated differently from people asking for removal while there is ongoing allegations of misconduct or ArbCom proceedings related to them taking place. Sven Manguard Wha? 04:05, 8 July 2011 (UTC)[reply]
The process for re-sysopping after voluntary relinquishment (and procedural removal for inactivity) is outlined at WP:RESYSOP; and any desired changes to that procedure should be discussed on the talk page there, or at WP:BN - not here. (And the section already has verbiage that addresses situations where rights were relinquished while there were ongoing allegations of misconduct or arbitration proceedings). –xenotalk 14:04, 8 July 2011 (UTC)[reply]
Ah. Thanks Xeno. Moving to support. Sven Manguard Wha? 00:50, 9 July 2011 (UTC)[reply]
  1. -Atmoz (talk) 21:29, 8 July 2011 (UTC)[reply]
  2. Prodego talk 20:08, 9 July 2011 (UTC)[reply]
  3. - Without evidence that the stewards aren't up to the job, I fail to see the need. Rivertorch (talk) 22:56, 12 July 2011 (UTC)[reply]

Discussion

[edit]

Unlike the other cases, this one has the possibility of an imposter putting in the request. It might be better if in the specific case of a self-request, a seven-day waiting period be imposed between granting the request and actually flipping the bit. Guy Macon (talk) 19:17, 10 July 2011 (UTC)[reply]

How would an imposter put in the request? Only requests from the account itself will be entertained. And if it is someone else in control of the account, it should still be desysopped... –xenotalk 19:20, 10 July 2011 (UTC)[reply]
When dealing with security issues such as this, it is a valid general principle to never assume that something like a bogus request can only have one possible cause. It's easy enough to come up with a scenario that does not involve permanent control of the account: an admin logs on using a public computer and forgets to log off. An imposter the accesses the account, and rather than doing all sorts of annoying things that would attract attention, simply tries to change the password (which would fail -- I just checked and changing my password while logged on requires knowing the old password, nor does it display my current password). He then requests removal of adminship and logs out. Another scenario: someone writes malware that does nothing but monitor internet access for activity on Wikipedia, sends a bogus request for removal of adminship, and erases itself from the system. Guy Macon (talk) 20:00, 10 July 2011 (UTC)[reply]
That then would be a case of "OOUPS can I have my bit back?" Agathoclea (talk) 09:57, 11 July 2011 (UTC)[reply]
Indeed. The hypothetical situations raised seem rather implausible, and I would still be more comfortable seeing the request processed if it was put in by someone other than the account holder. If they return - and find their account has been compromised - they can then take steps to verify their identity and request restoration. –xenotalk 12:52, 11 July 2011 (UTC)[reply]
Absolutely; and in fact in either of the two hypothetical circumstances given the point is moot... because the sysop bit should be removed due to account compromise anyway :) --Errant (chat!) 15:29, 11 July 2011 (UTC)[reply]

Perhaps there should be some sort of grace period where a user could request the authority be returned within 72 hours or some reasonable time. The main reasons I can think of for someone giving up Administrator privileges would be a change of lifestyle or work that demands more of their time. Plans can fall through. Bookbrad (talk) 15:19, 2 August 2011 (UTC)[reply]

Editors who self-request removal of administrative rights can ask to have them restored at any time per WP:RESYSOP. –xenotalk 15:23, 2 August 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Emergencies (closed)

[edit]
Thread retitled from "Emergencies".
SNOW-closed in lieu of #Emergencies (v2)
The following discussion has been closed. Please do not modify it.
SNOW-closed in lieu of #Emergencies (alternative)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Bureaucrats will be expanded by adding the following section
==Removal of adminship==
Bureaucrats may remove the "administrator" user right from a user's account only in an emergency when an administrator account appears to be compromised or an editor has been using the administrative tools to disrupt Wikipedia.
If a bureaucrat removes the "administrator" user right from any user, they are required to notify the user in question immediately, including an explanation why the user right was removed and how they may re-gain it.
Users who endorse this proposal
  1. Potentially vital defensive measure for the encyclopaedia.—S Marshall T/C 08:41, 8 July 2011 (UTC)[reply]
Users who oppose this proposal
  1. I'm not comfortable with the wording about "disruption", because that term includes a large gray area. I don't think the community has clearly expressed confidence in bureaucrats' ability to make this judgement - certainly I can't say I'm sure I trust all of the current crop of 'crats to make it. They were elected to judge consensus in RfA's, handle renames, and flag bots. All of those tasks require much less interpretive judgment than deciding whether an admin is using the tools "disruptively". If this power is extended to the current crop of bureaucrats, I think they should be willing to stand for confirmation to ensure that they have the trust to use it. Such trust was definitely not implicit in any !votes I've ever cast at RfB. I don't really have a problem with the other criteria for removing adminship, since they are much narrower. MastCell Talk 20:16, 7 July 2011 (UTC)[reply]
  2. Clarification required on "disrupt". If the proposer means disruptive editing as described in the linked WP:DE, then I firmly oppose. If proposer means "Admin A has deleted MediaWiki:Mainpage and is trying to get Admin B to delete Main page," then that's a different story, and I would be willing to go along with that. NW (Talk) 20:41, 7 July 2011 (UTC)[reply]
  3. No. I support the idea of allowing the community to de-sysop admins, and I think this whole thing is a great step in that direction. But this is too vague and discretionary - in exceptional circumstances we should allow crats to de-sysop admins. But in the interim we have Arbcom to discuss and ask for such things. MastCell has a sensible concern over the use of the word "disruption"; in this context it is clearly intended to mean "an admin randomly deleting pages willy nilly, or blocking every editor he can find" etc, but could be construed in a very minor way as well. The wording needs tightening and careful discussion. --Errant (chat!) 20:41, 7 July 2011 (UTC)[reply]
  4. No, I don't think we want unilateral desysopping for something as vague as WP:DE. Unless, perhaps, it is understood to be temporary? As in, if an arbcom case to revoke adminship is not opened immediately or does not succeed, the bit should be restored by default? ErikHaugen (talk | contribs) 20:59, 7 July 2011 (UTC)[reply]
  5. No way, per my comment above. We have blocking for this. If an administrator is using sysop tools disruptively, block the admin pending review from Arbcom. It is not okay for any one person, however trusted, to solely make the decision to desysop an admin. --causa sui (talk) 21:08, 7 July 2011 (UTC)[reply]
  6. In a real emergency desysopping should be allowed by anyone with the technical ability IMHO, and the policy should reflect that. However, the wording could definitely be improved to state that it's only allowed in urgent cases where the disruption is obvious and happening currently. It should also be obligatory to notify ArbCom, who would then pass a notion to confirm the desysopping. In short, individual crats should be allowed to use their judgment in emergency cases, but the final decision should not be theirs. Jafeluv (talk) 21:09, 7 July 2011 (UTC)[reply]
  7. I also believe "disruption" and "emergency" are much too ill-defined; I'd probably support if a clear definition was offered, and if only genuine emergencies (meaning absolutely time-critical obvious disruption with a wide scope). Even then, it's fair to ask why this is necessary at all. Admins can already be blocked, and irregularly (and successfully) are, and in extremis stewards can already emergency de-admin (which is needed on EN only extraordinarily rarely). For us to add another layer of policy wonkery I'd want to see multiple clear past cases where the existing capacity of block and steward-desysop have proved to be significantly deficient. -- Finlay McWalter ☻ Talk 21:10, 7 July 2011 (UTC)[reply]
  8. As several people have said, this is too sweeping. I think Xeno's wording below is fine; we shouldn't be preventing anyone with the technical ability to do so from desysopping an admin who is deleting the Main Page, blocking Jimbo, and full-protecting the sandbox. Ucucha 21:25, 7 July 2011 (UTC)[reply]
  9. I'm not comfortable with a crat unilaterally deciding that tools were used disruptively. It's one thing if an account was compromised, but this is too broad. Can a crat remove the tools with a case where an admin was borderline involved? -- Atama頭 21:33, 7 July 2011 (UTC)[reply]
  10. This is a nice idea in principle but it may be too dangerous to implement practically. Certainly this present wording is too vague. --(ʞɿɐʇ) ɐuɐʞsǝp 22:01, 7 July 2011 (UTC)[reply]
  11. Per above, "disrupt" is much too vague. /ƒETCHCOMMS/ 03:23, 8 July 2011 (UTC)[reply]
  12. "Disruption" as stated in this proposal is far too vague. —mc10 (t/c) 03:48, 8 July 2011 (UTC)[reply]
  13. Standard procedure is to block disruptive accounts, admin accounts would be included in that standard procedure. If the disruptive admin unblocks himself, he's only digging his own grave, and such an unblock wouldn't stick anyways. Sven Manguard Wha? 04:07, 8 July 2011 (UTC)[reply]
  14. Too broad and vague. Ruslik_Zero 08:54, 8 July 2011 (UTC)[reply]
  15. Yea .. I'm really having a hard time getting behind this. I don't want to be a gadfly to the wheels of progress, but here's the rub: Having the ability is the entire point. IAR is sooo easy to invoke, and there's just way too many "gray areas" in WP. There's a few crats that I'd likely trust with my very life (WJBscribe is a good example), but many of those names on the list of crats are unknown to me. Considering how much drama occurs on a daily basis on just "admin blocks", makes me wonder if this entire idea might not be fodder for huge drama time sinks. I'm just glad we'll have a bit of time to talk this all out. — Ched :  ?  15:25, 8 July 2011 (UTC)[reply]
Discussion
  • For those opposing based on the "disruption" language, I thought it was clear (but maybe it isn't), that this is only for emergency situations. Most forms of disruptive editing or even abuse of admin tools are not emergencies. Similarly, the disruption is clearly qualified as "using the administrative tools". Regular vandalism wouldn't count. This would be for situations like what NuclearWarfare mentioned. --RL0919 (talk) 20:58, 7 July 2011 (UTC)[reply]
    I would suggest re-wording it to "in an emergency when an administrator account appears to be compromised or is rapidly using administrative tools in a deliberate attempt to compromise the integrity of Wikipedia" - or something along those lines. –xenotalk 21:02, 7 July 2011 (UTC)[reply]
    And don't link to wp:DE, since that is not what you're talking about. ErikHaugen (talk | contribs) 21:04, 7 July 2011 (UTC)[reply]
    Agree with Xeno. In fact, point 4 should be truncated to "In an emergency when an administrator account appears to be compromised" (e.g. clear and obvious vandalism). This should be reflected in a new proposal, before the first one gets shot down needlessly. AD 21:10, 7 July 2011 (UTC)[reply]
    Agree that the link to WP:DE is a distraction, and I'm mostly fine with Xeno's wording suggestion. I'd leave out "deliberate", because incompetence is just as dangerous as malice if someone is doing something majorly disruptive such as deleting vital pages. I'd also be OK with the truncation suggested by Aiken drum. --RL0919 (talk) 21:11, 7 July 2011 (UTC)[reply]
    Most definitely agree with Xeno's wording as better; although I'm far from supporting any of this yet. — Ched :  ?  21:25, 7 July 2011 (UTC)[reply]
    nthing this. The way xeno put it is much more narrow in scope, as it should be. Nobody should be unilaterally desysoping admins except when the account is compromised and/or on a rampage of incontrovertible vandalism. "Disruption" includes a much too wide range of behavior. --causa sui (talk) 21:35, 7 July 2011 (UTC)[reply]
  • If you look at this log you will see how blocking will not work in the case of an admin gone ape. Agathoclea (talk) 21:42, 7 July 2011 (UTC)[reply]
  • My nightmare scenario, and I think the only case I can figure out where blocking+stewards isn't sufficient, is if a wrongdoer got hold of one or several admin accounts and ran bots on them which kept unblocking themselves and their cohorts while performing hard-to-fix mass vandalism automatically. Blocks wouldn't be effective (because they'd unblock themselves and one another) and in the time it takes to rustle up a steward they've done a bunch of very public vandalism. This proposal doesn't help that scenario (as there's still a lag to find a crat), and adds the (small, sure) risk that if a crat account is compromised they can mass desysop the entire admin corp and set about their crimes. Again a steward is needed to fix it, and it's lots of work to unpick. Instead I suggest a purely technical solution (one that doesn't require any judgement or discussion about what is disruption or what constitutes an emergency. It's simply this: if Admin A blocks Admin B, for 24 hours after that block both A and B are automatically deprived of all admin functions - even if the block is reversed. As a block of an admin is a fairly rare occurrence, and a serious one, I suggest there be no mechanism to curtail that 24 hour period. This way even a dozen compromised accounts would quickly ablate their admin-ity and get blocked by the surviving admins, leaving a comfortable 24 hours to steward desysop and tidy up the mess. -- Finlay McWalter ☻ Talk 21:58, 7 July 2011 (UTC)[reply]
    Again, I agree. The fact that admins can unblock themselves is the real cause of the trouble here. If that were disabled, then any administrator could handle a rampaging admin account simply by blocking, and we wouldn't have to do anything so drastic that it requires such careful review and prior consideration. --causa sui (talk) 22:18, 7 July 2011 (UTC)[reply]
    The problem with coding it simply as "blocked admins can't unblock themselves" is that in the above scenario ("The Wikipocalypse"), where the attacker controls two admin accounts (and hasn't someone already been found to have achieved that) the two accounts can unblock one another (at automated rates). Hence my "blocking admins is ablative" idea. -- Finlay McWalter ☻ Talk 22:41, 7 July 2011 (UTC)[reply]
  • I think this has been roundly rejected, further pile-on is probably unnecessary so I've wrapped it up with a pointer to the below alternative. Something similar should probably be done to the "All" request that includes this formulation - maybe just get rid of the "All" altogether and copy ask the supporting votes to instead consider the individual proposals, which can then be merged if and when consensus permits. –xenotalk 15:33, 8 July 2011 (UTC) amended. 19:05, 8 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Emergencies (v2)

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The support here is roughly 75%. This is a tricky one—purely on the numbers, that would be sufficient support for an RfA to pass, but not for an RfB, for example. I am closing this as no consensus, because of the rare commonality in the opposes. The opposers seems to share reservations on the basis of problems caused by over-hasty removal and that a single 'crat may not be best-placed to determine whether an account has been compromised. There is also the suggestion that emergency situations are adequately handled by the Arbitration Committee, who can then request that a bureaucrat enact the removal on which the committee has decided. I would suggest further discussion on this at an appropriate venue. A threaded discussion might produce a more refined proposal or a set of criteria, which can then be put to a straw poll. HJ Mitchell | Penny for your thoughts? 14:44, 7 August 2011 (UTC)[reply]
Thread retitled from "Emergencies (alternative)".
Wikipedia:Bureaucrats will be expanded by adding the following section
==Removal of adminship==
Bureaucrats may temporarily remove the "administrator" user right from a user's account in an emergency when an administrator account appears to be compromised.
Any emergency removal of administrator rights must be referred to the Arbitration Committee for further decision. The bureaucrat performing the emergency removal must notify the user in question to contact the Arbitration Committee to re-gain administrator rights.

Users who endorse this proposal

[edit]
  1. causa sui (talk) 23:42, 7 July 2011 (UTC)[reply]
  2. I think we've addressed the major concerns with the earlier version. --RL0919 (talk) 23:55, 7 July 2011 (UTC)[reply]
  3. Per below. Jafeluv (talk) 00:03, 8 July 2011 (UTC)[reply]
  4. Much more sensible than the above. /ƒETCHCOMMS/ 03:25, 8 July 2011 (UTC)[reply]
  5. ...with the knowledge that there will be hell to pay if this is abused. I can support this one. Sven Manguard Wha? 04:08, 8 July 2011 (UTC)[reply]
  6. With this wording, especially the "temporary", I can support. Thanks, ErikHaugen (talk | contribs) 04:42, 8 July 2011 (UTC)[reply]
  7. with the loss of the word "only" this gets my support.Graeme Bartlett (talk) 08:35, 8 July 2011 (UTC)[reply]
  8. Good idea, I can support that. It lacks the requirement of the user actually disrupting Wikipedia but it compensates it by making it temporary and letting ArbCom decide immediately. Regards SoWhy 11:43, 8 July 2011 (UTC)[reply]
  9. If there isn't support for the first version of emergency desysopping above (and it appears there isn't), I'll support this as an alternative. Robofish (talk) 13:57, 8 July 2011 (UTC)[reply]
  10. Clearer versionthan the above (which i understood to have the same intent) Agathoclea (talk) 13:59, 8 July 2011 (UTC)[reply]
  11. Having "more cooks in the kitchen", as Jafeluv says, is good for when there's an emergency. This wording is specific enough that there's minimal risk to implementing it. --(ʞɿɐʇ) ɐuɐʞsǝp 15:02, 8 July 2011 (UTC)[reply]
  12. No particular reason to oppose this, and in an emergency, I could seriously regret doing so. :-) --SarekOfVulcan (talk) 18:08, 8 July 2011 (UTC)[reply]
  13. This addresses my concerns with the previous version of this proposal, and I think that it is good for a crat to have the ability to act in an emergency. The "rogue admin" who can unblock himself is a bogeyman that we worry about for a good reason, and this is better than having to go to a steward as our only option. -- Atama頭 18:24, 8 July 2011 (UTC)[reply]
  14. This is much better wording than the previous example. MacMedtalkstalk 18:48, 8 July 2011 (UTC)[reply]
  15. A better version indeed. Ben MacDui 18:56, 8 July 2011 (UTC)[reply]
  16. I'm fine with this one. Jusdafax 19:13, 8 July 2011 (UTC)[reply]
  17. This is much better than the one above. Reaper Eternal (talk) 19:45, 8 July 2011 (UTC)[reply]
  18. I think this is a good idea. Peter 19:48, 8 July 2011 (UTC)
  19. OK. MastCell Talk 20:50, 8 July 2011 (UTC)[reply]
  20. Support. -- Ed (Edgar181) 22:41, 8 July 2011 (UTC)[reply]
  21. Support, primarily because (i) blocked admin accounts still have viewdelete privileges - that can only be taken away from a potential hijacker by desysopping (ii) AFAIK admins can still unblock themselves, which gives extra potential for trouble if we assume a possibly compromised admin account is taken care of by blocking (iii) mistaken desysops under this provision should be rare, and not (I think) particularly harmful (iv) where potential compromise is happening, speed is of the essence (v) it's not written in stone; if the provision causes problems, we can change it. Rd232 public talk 23:19, 8 July 2011 (UTC)[reply]
  22. Much better version that clears the ambiguity in the previous version. —mc10 (t/c) 23:26, 8 July 2011 (UTC)[reply]
  23. Support Sir Armbrust Talk to me Contribs 00:50, 9 July 2011 (UTC)[reply]
  24. Support. 28bytes (talk) 01:50, 9 July 2011 (UTC)[reply]
  25. Support - this is a very good idea Nick-D (talk) 08:06, 9 July 2011 (UTC)[reply]
  26. Support Agathoclea (talk) 09:45, 9 July 2011 (UTC)[reply]
  27. Support Graham87 09:59, 9 July 2011 (UTC)[reply]
  28. Support. I take the point about ArbCom, but this can relieve some burden from them in cases that are straightforward. --Tryptofish (talk) 16:36, 9 July 2011 (UTC)[reply]
  29. Support in an emergency such as this one someone should be found to perform the desysop as soon as possible. Hut 8.5 17:00, 9 July 2011 (UTC)[reply]
  30. Support  Ronhjones  (Talk) 17:13, 9 July 2011 (UTC)[reply]
  31. AD 17:17, 9 July 2011 (UTC)[reply]
  32. Something of a leap of faith in the judgement of bureaucrats, but they probably deserve it, and any misjudgements will lead to the usual excoriations I imagine. Skomorokh 17:51, 9 July 2011 (UTC)[reply]
  33. Support -FASTILY (TALK) 04:41, 10 July 2011 (UTC)[reply]
  34. Support A greater pool of authorised volunteers means that the potential damage possible with a compromised or gone bad sysop account can be limited more quickly, and the inbuilt checks means that any errors can be quickly rectified. I should not think that any good admin would be against having the risk of their access to the flags removed in error in the good faith protection of the project. LessHeard vanU (talk) 13:07, 10 July 2011 (UTC)[reply]
  35. Support. This version sounds acceptable. — Mr. Stradivarius ♫ 14:55, 10 July 2011 (UTC)[reply]
  36. Support, but needs copyediting.  Sandstein  19:16, 10 July 2011 (UTC)[reply]
  37. Support, pretty strait-forward. Marcus Qwertyus 23:31, 10 July 2011 (UTC)[reply]
  38. Support I'm sure we can trust buros to make a reversible good faith call about this clearly defined sort of thing. Especially since any admin is already allowed to block a compromised account. Bob House 884 (talk) 23:57, 10 July 2011 (UTC)[reply]
  39. Support — Edokter (talk) — 00:54, 11 July 2011 (UTC)[reply]
  40. Support in the event of an emergency, the quicker we can get someone, the better. Bureaucrats are trustworthy and possibly a better option than having to wait on a steward. hare j 01:23, 11 July 2011 (UTC)[reply]
    Assuming that the proposal for requests from ArbCom (above) is accepted, is this a better option than having ArbCom decide under the current policy and then forwarding the request to the 'crats? עוד מישהו Od Mishehu 11:22, 12 July 2011 (UTC)[reply]
  41. Support. Easily be reversed if misused. Tiderolls 01:49, 11 July 2011 (UTC)[reply]
  42. Support Because of viewdelete still working even when blocked. If viewdelete did not work when blocked, I'd say to try blocking them first to see if they unblock themselves. Gigs (talk) 02:04, 11 July 2011 (UTC)[reply]
  43. Support demize (t · c) 02:35, 11 July 2011 (UTC)[reply]
  44. --JaGatalk 04:06, 11 July 2011 (UTC)[reply]
  45. This is fine wording. Eluchil404 (talk) 04:09, 11 July 2011 (UTC)[reply]
  46. Support Seems reasonable. — Bill william comptonTalk 07:01, 11 July 2011 (UTC)[reply]
  47. Support Themeparkgc  Talk  07:21, 11 July 2011 (UTC)[reply]
  48. Support, seems to have appropriate wording here. — Cirt (talk) 07:28, 11 July 2011 (UTC)[reply]
  49. Support - easily reversed if abused, saves time in any emergency. Abusers to be hacked to death with a blunt teaspoon? Pesky (talk …stalk!) 07:55, 11 July 2011 (UTC)[reply]
  50. Looks reasonable. T. Canens (talk) 08:13, 11 July 2011 (UTC)[reply]
  51. Support - Excellent. Lets move forward. - Burpelson AFB ✈ 12:50, 11 July 2011 (UTC)[reply]
  52. Support appears to be short term damage limitation, I trust the crats to not misuse. Sounds reasonable. WormTT · (talk) 13:14, 11 July 2011 (UTC)[reply]
  53. Support Tyrol5 [Talk] 13:51, 11 July 2011 (UTC)[reply]
  54. Support – If a bureaucrat can react faster to emergencies than stewards, why not? I just hope that those entrusted with bureaucratic rights by the community are able to comprehend which situations are emergencies and which aren't (we need to raise our expectations for bureaucrats). Since this proposal includes reporting to ArbCom as a condition and user rights changes are logged, it's be easy for others to examine the rights removal for misuse. --Michaeldsuarez (talk) 14:33, 11 July 2011 (UTC)[reply]
    Assuming that the proposal for requests from ArbCom (above) is accepted, is this a better option than having ArbCom decide under the current policy and then forwarding the request to the 'crats? עוד מישהו Od Mishehu 11:35, 12 July 2011 (UTC)[reply]
    I guess it would depend on how serious the emergency is. If a sysop account goes on a rampage, there may not be any room for hesitation, discussion, or deferral. I hoping that the users we've entrusted with bureaucrat rights have the sense to determine which situations are emergencies and which aren't. I'm hoping that this community had the wisdom to elect bureaucrats that aren't trigger-happy. --Michaeldsuarez (talk) 15:30, 13 July 2011 (UTC)[reply]
    We actually need to lower the expectations, as they are as high as stewards! ~~EBE123~~ talkContribs 22:24, 13 July 2011 (UTC)[reply]
    You misunderstand. I'm asking each voter to raise their individual expectation of what a bureaucrat should be like. I wasn't suggesting that the threshold for acceptance be increased from the current 85%. Each individual voter needs to think very hard about the candidate's merits and qualifications before making a final decision. --Michaeldsuarez (talk) 23:17, 13 July 2011 (UTC)[reply]
  55. Support Magog the Ogre (talk) 17:33, 11 July 2011 (UTC)[reply]
  56. Support Hekerui (talk) 18:09, 11 July 2011 (UTC)[reply]
  57. Support Reasonable, though I would expect the account to be desysoped and blocked. TotientDragooned (talk) 20:06, 11 July 2011 (UTC)[reply]
  58. But stewards must still be permitted to perform an emergency desysopping. AGK [•] 23:14, 11 July 2011 (UTC)[reply]
  59. I was on the edge for this one, but all of the opposition points have been sufficiently rebutted in my opinion. Jujutacular talk 03:21, 12 July 2011 (UTC)[reply]
  60. Support (Conditional) Bureaucrats are generally much closer to the community "heartbeat" and conscience than stewards in that they tend to be more active in the daily life and activity of the project and community thus a better judge of the current state and needs of them. In this case, I would further define an emergency as being any situation where specific actions have been taken by the potentially compromised account such that a delay in removing adminship would cause serious and significant harm to the nature, product, name or good will of the Wikipedia project or the Wikimedia Foundation. Merely suspecting the compromise of an account without specific facts can be the source of great problems. While bureaucrats tend to be among the most highly respected and proven trustworthy members of our community this is not a situation that should be considered or handled lightly. I support this privilege provided that in the case of a genuine emergency as defined by policy (and hopefully above), the action taken is listed in a special page that logs all details of the transaction including a required explanation by the person taking the action. The explanation should include at a minimum either the specific facts detailing how the actions taken under the suspected compromised account clearly indicate a compromised account and that those actions constituted an emergency; or that a direct communication from someone purporting to be the account owner states that the account has been compromised with sufficient documentary evidence to support a good faith belief that the person is in fact the account owner. Furthermore, an automatic review by ArbCom should occur within twenty-four hours.  Jim Reed (Talk)  04:15, 12 July 2011 (UTC)[reply]
  61. Support I would expect this to to be the consequence if a blocked admin account unblocks itself. (Followed by a further block) Edgepedia (talk) 05:04, 12 July 2011 (UTC)[reply]
  62. Support - Per my reasoning in Wikipedia:Requests for comment/Granting bureaucrats the technical ability to remove the admin flag, I am supporting all four. -Porch corpter (talk/contribs) 10:26, 12 July 2011 (UTC)[reply]
  63. Support, though not necessarily as written here. I would support allowing bureaucrats to remove adminship temporarily in other cases of VERY clear-cut abuse (though not with the wording originally proposed above). This should cover not only hacked accounts, but Wonderfool-style admin rampages. I trust the 'crats to apply the duck test appropriately. Whichever wording we go with, it must be abundantly clear that this is only to be done in emergencies involving severe and unambiguous abuse of the tools. szyslak (t) 10:37, 12 July 2011 (UTC)[reply]
  64. Support. Much havoc could be wreaked with a mop in a very short time, so this does make sense. (Going to vote oppose in the other sections.) Rivertorch (talk) 22:51, 12 July 2011 (UTC)[reply]
  65. Support. When an admin maketh havoc, a crat taketh his admin rights. --Whoop whoop pull up Bitching Betty | Averted crashes 13:26, 13 July 2011 (UTC)[reply]
  66. Support Good idea. ~~EBE123~~ talkContribs 22:24, 13 July 2011 (UTC)[reply]
  67. Support. Cla68 (talk) 05:38, 14 July 2011 (UTC)[reply]
  68. Support: Wikipedians should safeguard their accounts the best they can, especially those whose rights could cause disruption. Allowing local bureaucrats to de-sysop the accounts of compromised admins means a faster response and less damage to have to fix in these hopefully rare instances. I also do not object to the bureaucratic removal of the admin rights of admins clearly abusing their tools to vandalize, disrupt, or compromise the system, though that seems no longer a part of this particular discussion. --Sgt. R.K. Blue (talk) 10:05, 14 July 2011 (UTC)[reply]
  69. Strong Support this is why I supported giving bureaucrats the right to remove admin rights in the first place. It should, however, only be rarely used, and when it's completely obvious that the account is causing problems. JDDJS (talk) 16:44, 14 July 2011 (UTC)[reply]
  70. Support - Bazj (talk) 17:14, 14 July 2011 (UTC)[reply]
  71. Sensible in its utility and limitations. — Scientizzle 20:48, 14 July 2011 (UTC)[reply]
  72. Support After a bit of thought and reading comments and discussion. I say the current wording is good and that having it only be temporary and pending review from ArbCom is the best way of preventing abuse of the power. Chris (talk) 21:09, 14 July 2011 (UTC)[reply]
  73. Support North8000 (talk) 00:39, 15 July 2011 (UTC)[reply]
  74. Support -- Alex146 (talk) 01:52, 15 July 2011 (UTC)[reply]
  75. Support This seems to be simply an extension of what stewards have long done in this situation. I certainly trust crats to do it properly.--Chaser2 (talk) 03:54, 15 July 2011 (UTC)[reply]
  76. Support. This could stop an erratic admin or a compromised account. I see no real downside. --Alecmconroy (talk) 05:51, 15 July 2011 (UTC)[reply]
  77. Support If we trust them to Sysop someone, I think we can safely trust them to de-sysop someone. -RunningOnBrains(talk) 08:48, 15 July 2011 (UTC)[reply]
  78. Strong Support - Speaking as an admin - and I expect most other admins share my sentiment - if a 'crat has any reason to suspect any admin account (including mine) is compromised then I want the account shut down ASAP. As admins our first priority must be the safety of the project. If it is all a misunderstanding then we merely suffer a minor inconvenience for a few hours - no big deal and it is all easily sorted out. Manning (talk) 09:24, 15 July 2011 (UTC)[reply]
    1. Is a single 'crat any better than a single ArbCom member? The current procedures require that at least 3 ArbCom members must support the emergency desysoping before it can take place. עוד מישהו Od Mishehu 05:13, 20 July 2011 (UTC)[reply]
  79. Support. But the wording? "... must notify the user in question to that they should contact the Arbitration Committee to ..." Tony (talk) 13:30, 15 July 2011 (UTC)[reply]
  80. Support - Casliber (talk · contribs) 15:24, 15 July 2011 (UTC)[reply]
  81. Support - this will allow the problems posed by compromised administrator accounts to be addressed with a minimum of hassle. SuperMarioMan 21:38, 15 July 2011 (UTC)[reply]
  82. Support Though I am am a little surprised that we could not trust a crat to decide that an admin-gone-mad, deleting pages willy nilly or blocking people left right and centre after putting "retired" on their own user page, cannot be handled in the same way. Though I agree that disruptive was too grey, this version is a little too white and vandalism by a non-compromised account should perhaps have been left in. Chaosdruid (talk) 23:57, 15 July 2011 (UTC)[reply]
  83. Suppport I'm sorry, but are we seriously saying that we cannot trust a bureaucrat to desysop a compromised account? --cc 08:26, 16 July 2011 (UTC)[reply]
  84. Support NECRATSpeak to me 09:40, 16 July 2011 (UTC)[reply]
  85. Logan Talk Contributions 13:15, 16 July 2011 (UTC)[reply]
  86. Support new version, since it does not require a judgment call as to whether tools are being "abused." I don't think that a good-faith mistake can be made whether an account has been compromised, however. This also relieves the stress from the stewards caseload. RJC TalkContribs 14:25, 16 July 2011 (UTC)[reply]
  87. Support. Wording needs improvement. Lightmouse (talk) 16:47, 16 July 2011 (UTC)[reply]
  88. Support (Moved from oppose) I see little room for abuse of this provision and support that it better serves the interest of Wikipedia than to outright oppose. I would ask for a clearer definition of an "emergency" with perhaps a requirement to link to the diffs which allegedly show cause. My76Strat talk 18:05, 16 July 2011 (UTC)[reply]
  89. Support. elektrikSHOOS (talk) 19:43, 16 July 2011 (UTC)[reply]
  90. Support. Changing it to a temporary action that would be reviewed by ArbCom was a very good improvement to this proposal. Totally support: it can only be good for the system. SteveStrummer (talk) 05:23, 17 July 2011 (UTC)[reply]
  91. Support makes sense. --99of9 (talk) 07:47, 17 July 2011 (UTC)[reply]
  92. Support Comte0 (talk) 09:38, 17 July 2011 (UTC)[reply]
  93. Support. Clearly the most controversial of the proposals, but with immediate referral to ArbCom being mandated, it seems safe - if an erroneous decision is made, ArbCom should be able to overturn it quickly enough -- Boing! said Zebedee (talk) 16:15, 17 July 2011 (UTC)[reply]
  94. Support. This is needed. -- Ϫ 01:49, 18 July 2011 (UTC)[reply]
  95. Support. Cind.amuse 09:47, 18 July 2011 (UTC)[reply]
  96. Support - In an emergency situation involving an obviously-hijacked admin account, we should not have to wait for a steward to de-sysop the account in question. Simply blocking the compromised account would be insufficient because admins have the ability to view deleted material. --SoCalSuperEagle (talk) 18:22, 18 July 2011 (UTC)[reply]
  97. Very, Very Weak Support I'd rather the emergency angle only be a "oh yeah, if major shit is going down, bureaucrats won't get smacked down by ArbCom for intervening" sort of thing (because seriously, that'd be pretty lame; if I stopped a rouge admin and then got slapped by ArbCom, I'd be hella pissed). I see this as only opening up the list of people that can react to an emergency, thereby making it easier to jump on bad situations. EVula // talk // ☯ // 21:27, 18 July 2011 (UTC)[reply]
  98. Support Peter (Southwood) (talk): 12:46, 19 July 2011 (UTC)[reply]
  99. Support - I would not have supported the original wording, but this new version seems okay. The more people able to respond to such emergencies the better in my view, with ArbCom review being a sensible safeguard. CT Cooper · talk 20:54, 19 July 2011 (UTC)[reply]
  100. Support - much better wording than the orginal - this is a reasonable policy with clear limits. Ruhrfisch ><>°° 00:39, 20 July 2011 (UTC)[reply]
  101. Support Sensible, has appropriate limits and double checks. - Nick Thorne talk 03:10, 20 July 2011 (UTC)[reply]
  102. Support Wars have been won because people were authorized to make realtime decisions rather than having to clear every move with Headquarters; and lost because people were still waiting for instructions when the other side went ahead and took immediate action. Ornithikos (talk) 06:57, 20 July 2011 (UTC)[reply]
  103. Support. Bureaucrats should have broad discretion to check apparent compromise on an immediately reviewable basis. This would elevate the response so as to avoid admin-on-admin conflict, blocking and arguing being a dubious response anyway. This would also obviate the need for specific language defining "apparent compromise" in this policy: it is what a bureaucrat deems apparent compromise, subject to review by ArbCom. The bar should be high, but discretion broad. Also, ArbCom should be directly responsible for restoring admin rights to any account provoking such extrordinary concern, leaving a specific stare decisis to guide bureaucrats going forward. -SM 09:28, 20 July 2011 (UTC)[reply]
    Is a single 'crat any better than a single ArbCom member? The current procedures require that at least 3 ArbCom members must support the emergency desysoping before it can take place. עוד מישהו Od Mishehu 09:35, 20 July 2011 (UTC)[reply]
    Is that true even in a emergency? Is that somehow a constraint upon stewards, a guideline used by stewards, or an agreement among arbitrators not to request desysop from stewards unless three arbitrators concur? In any of those cases, I think that is way too high a bar, but take your (implicit) point that this may represent a more significant change than I might have thought.
    Re your earlier question, I am certain that (better or no) ArbCom is much more political than the Bureaucracy, and should be. Given this, I see the ideal rationale for a bureaucrat acting here because in his judgement an admin account is likely being used in a way inconsistent with the community consensus by which the sysop power was granted in the first place, and so requires immediate community review, as represented by ArbCom, the highest authority appointed by the community, who should then take political responsibility for restoring the sysop. Again, for the bureaucrat, the bar should be high, but discretion broad. Have I answered your question?
    -SM 10:57, 20 July 2011 (UTC)[reply]
  104. Support - but the criteria for presuming an administrator account as compromised should be more stringent. Otherwise it'll be like "Too many cooks - spoil the broth". So a better version is required. - Wikiglobaleditor (talk) 14:54, 21 July 2011 (UTC)[reply]
  105. Support - With the caveat that "compromised" be better defined. FurrySings (talk) 23:39, 21 July 2011 (UTC)[reply]
  106. Support - Yet again, this makes since. --Nathan2055talk 19:22, 22 July 2011 (UTC)[reply]
  107. Support - makes sense and the referral to arbcom will provide a route back in case of judgement error. Jezhotwells (talk) 17:35, 23 July 2011 (UTC)[reply]
  108. Entirely sensible. --Cybercobra (talk) 06:20, 24 July 2011 (UTC)[reply]
  109. Support - No issues because an incorrect desysopping can be corrected easily. EngineerFromVegaDiscuss 00:12, 25 July 2011 (UTC)[reply]
  110. Support. If it is an emergency, we should let anyone help who can. Kitty DeClaude (talk) 22:35, 29 July 2011 (UTC)[reply]
  111. Support This works just fine.BrandonHoward (talk) 13:41, 30 July 2011 (UTC)[reply]
  112. Support if it's clearly an emergency, then increasing the number of people are available to do so makes sense. Since mistakes can easily be rectified, then there's no downside here. Mike Peel (talk) 19:16, 30 July 2011 (UTC)[reply]
  113. Support As Mike Peel says just above me, the more people who can do it the better PhantomSteve/talk|contribs\ 22:31, 30 July 2011 (UTC)[reply]
  114. Support. (No concerns if folks want to nail down the language more specifically, however.) --joe deckertalk to me 18:34, 31 July 2011 (UTC)[reply]
  115. Support. —Jclavet (talk) 20:45, 31 July 2011 (UTC)[reply]
  116. Support. Blackvisionit (talk) 02:49, 1 August 2011 (UTC)[reply]
  117. Support emergency powers with due checks and balances. Huon (talk) 11:52, 1 August 2011 (UTC)[reply]
  118. Support - frankie (talk) 16:52, 1 August 2011 (UTC)[reply]
  119. Support This sounds like it would be hard to get around by a malicious bureaucrat, and it's simply common sense. Thinking back to the Robdurbar incident, imagine if the bureaucrats were contentedly and calmly removing rights from self-requesting admins but had to sit on their hands while a rogue admin unprotected the Main Page — if we only permitted bureaucrats to remove admin rights for one reason, this should be it. Nyttend (talk) 04:50, 2 August 2011 (UTC)[reply]
  120. Support with a bit more hesitation than the other proposals. As long as this is reserved for obvious emergencies, and followed with both a ON-WIKI notification to the user about why and ON-WIKI notification to ArbCom, it should be fine. I'm considerably less enthusiastic if this becomes an email/IRC drill. Xymmax So let it be written So let it be done 12:50, 4 August 2011 (UTC)[reply]
  121. Support. This would reduce damage to highly visible pages. ~AH1 (discuss!) 15:25, 4 August 2011 (UTC)[reply]
  122. Support. Of course. ugen64 (talk) 01:49, 5 August 2011 (UTC)[reply]

Users who oppose this proposal

[edit]
  1. This is unnecessary. Normal emergencies are handled by the ArbCom, which can request removal under #2. In rare super-emergencies, when there is no time to contact the Arbcom, this is best left to stewards as they have more experience in such situations. In addition, if a global account is compromised, the sysop (any other) permissions will have to be removed on other projects as well and the account will likely be locked. These actions can be done only by stewards. I also want to remind you of what happens when there are too many cooks in the kitchen. Ruslik_Zero 09:03, 8 July 2011 (UTC)[reply]
    In actual emergency situations I'd say the more cooks in the kitchen the better. Jafeluv (talk) 11:46, 8 July 2011 (UTC)[reply]
    Ahhh .. but perhaps Too many cooks, spoil the soup? .. :) — Ched :  ?  15:32, 8 July 2011 (UTC)[reply]
    It is possible to overcook soup. It isn't possible to overdesysop a (former) admin. Whoop whoop pull up Bitching Betty | Averted crashes 15:49, 31 July 2011 (UTC)[reply]
  2. -Atmoz (talk) 21:29, 8 July 2011 (UTC)[reply]
  3. -- Eraserhead1 <talk> 18:40, 9 July 2011 (UTC)[reply]
  4. Prodego talk 20:08, 9 July 2011 (UTC)[reply]
  5. I'm not sure that a single 'crat can necessarily identify when this need occurs. I think that the proper policy for this situation is that ArbCom make the decision based on current policy, and then forward it to the 'crats (possibly also to the stewards, in case no 'crats are around at the time). עוד מישהו Od Mishehu 07:38, 10 July 2011 (UTC)[reply]
    (Indent and move to support) In any such emergency, the admin should be technically blocked and leave the decision to desysop solely to ARBCOM' My76Strat talk 23:48, 10 July 2011 (UTC)[reply]
    Blocked admins are able to unblock themselves, so if a compromised account is on a tear, the only practical way to stop it is to desysop it. --RL0919 (talk) 00:58, 11 July 2011 (UTC)[reply]
    I am an admin, and I assure you - if a 'crat ever has reason to suspect my account is compromised then I want my account shut down immediately. If it's a mistake then it will be easily cleared up and no harm done. The alternative - there being a rampant admin account creating havoc while we try and get ArbCom together to discuss the situation - is simply not a realistic alternative. Stewards have long been entrusted to act first and ask questions later and that should be the same for crats. The safety of the project always comes first and every admin knows this. Manning (talk) 09:30, 15 July 2011 (UTC)[reply]
    Further consideration has shown that it is more prudent that I support this provision. Per the above comments. My76Strat talk 18:00, 16 July 2011 (UTC)[reply]
  6. I'm concerned by, what I feel is, the lack of clarity in what it will mean to know that an administrator's account is compromised. I also worry that this could be a way to put a burden on an admin to keep his tools when he had misbehaved. I would support something similar with a time frame for restoring the tools absent affirmative action endorsing the removal by ArbCom, but that probably won't be needed since this is going to pass. ‡ MAHEWA ‡ • talk 05:00, 11 July 2011 (UTC)[reply]
    I think that is what the 'temporarily' is meant to imply. If the Arbitration Committee does not confirm a desysop performed under the auspices of "account compromised", they would presumably make some kind of statement to the contrary - and the rights should then be restored. By compromised, I would expect that emergency situations would be few-and-far-between, and would involve obvious cases such as the Zoe/RickK incident [1] [2], and cases where an administrator account is rapidly using administrative tools in a deliberate attempt to compromise the integrity of Wikipedia (e.g.). –xenotalk 17:33, 11 July 2011 (UTC)[reply]
    I think it illustrates my issues nicely that in response to my concerns about vagueness you used the words "imply," "presumably," and "expect." I'd support a policy that wrote out these implications, presumptions, and expectations as you have expressed them. I'm not, afterall, against the idea motivating the policy. But right now it's just too vague for me, especially given the number of people who want to see admins lose their tools for much less than where the current system sets the bar. They might be right, but I don't want a vague policy to open the backdoor to effectuating those desires without consensus. I'm sure the bureaucrats can be trusted, but I don't view it as a breach of trust to take very plausible view of a vague policy and take action that I did not contemplate. But you need not worry about convincing me, you'll get your consensus : ). ‡ MAHEWA ‡ • talk 20:16, 11 July 2011 (UTC)[reply]
    I perhaps too-often couch my statements with such qualifiers - but only because I've been surprised before. I did not expect a steward would act on a request from a user to desysop 250+ admins without verifying that the request in fact met the relevant policy (presumably they know better!), but it happened. Such is as it is... I guess, similarly, you are worried that a bureaucrat might one day wake up and say "Oh this Admin X, he's obviously lost the plot! Clearly his judgment is compromised. Off with 'is head!" =) –xenotalk 20:25, 11 July 2011 (UTC)[reply]
    You're kidding. Did that really happen? And, while acknowledging we're all "equal," was the requesting user a bureaucrat or admin himself? I understand qualifying what you say. It's not as though the individual words actually hurt your argument, just illustrated what I was getting at. I probably look for too much particularity in policies, but that's just what my preference is. ‡ MAHEWA ‡ • talk 20:38, 11 July 2011 (UTC)[reply]
    Yes, see here (perm). (No, the requesting user was not an admin or a bureaucrat. They are sufficiently apologetic, though...). –xenotalk 22:51, 11 July 2011 (UTC)[reply]
  7. - Kingpin13 (talk) 17:23, 11 July 2011 (UTC)[reply]
  8. Crats have managed to avoid the political quagmire that is involuntary desysopping and it has been shown that in an actual emergency, the stewards are much faster in any event. This adds nothing useful and only crafts a political tar-baby onto an otherwise non-political position. MBisanz talk 19:14, 11 July 2011 (UTC)[reply]
  9. No. Get a stewart. If you can't find one you don't have enough stewarts or it isn't enough of an emergency. Protonk (talk) 20:34, 11 July 2011 (UTC)[reply]
  10. No. We don't need this. IAR covers this situation. The crat should only do it when he's sure that despite the wall of wrath that may fall on him, he will be upheld.--Wehwalt (talk) 22:20, 11 July 2011 (UTC)[reply]
  11. No. Get a steward. I don't see the need to change this when I don't see it as broken. -- Alexf(talk) 15:32, 14 July 2011 (UTC)[reply]
    Oppose This seem overly convoluted and bureaucratic response to a relatively simple situation. In this situation described here would it not be more sensible to simply block the account? Also, is it not already covered by WP:IAR? I see the issue relates to "viewdelete", which can be accessed even when blocked. --RA (talk) 19:02, 14 July 2011 (UTC)[reply]
    Additionally, an admin can unblock himself, and theoretically could make a bot to instantly do so. -RunningOnBrains(talk) 08:47, 15 July 2011 (UTC)[reply]
  12. Toa Nidhiki05 19:56, 14 July 2011 (UTC)[reply]
  13. CRGreathouse (t | c) 05:53, 15 July 2011 (UTC)[reply]
  14. Unnecessary. I am much more comfortable with the other circumstances (Bureaucrats carry out decisions made or requested by others). Jd2718 (talk) 00:35, 16 July 2011 (UTC)[reply]
  15. Oppose, while the other policies only authorize crats to act in non-controversial situations, or after community process in the case of an arbcom request, this one is fundamentally different. It gives crats substantial authority to determine whether then consider an account compromised, without providing adequate guidance as to how to make that determination. Removing the general disruption language is ineffective, as it is easy to rationalize that any admin acting disruptively, unless they have a track record of it, is probably compromised. Really we are making crat a super admin... and I don't think that is consistent with the way the community is set up. Monty845 05:12, 16 July 2011 (UTC)[reply]
  16. I'm surprised I'm in the oppose section, but it's the wording here. I don't think a person necessarily should have to go through ArbCom if there has been an emergency desysop. Sometimes desysop's can be done in haste or mistake, what have you. Just like a block can be applied prematurely/erroneously, there should be a mechanism for the wider community to weigh in on the desysop. ArbCom should be a final resort, not the first step. I should also note that in theory, I support the notion of Crat's having the ability and responsibility to step in and stop a rogue admin/crat. I do not oppose their abiliy/right to do so, I just am not comfortable with the stated appeals process for restoring the bit after such a removal. Emergency desysops are meant to be quickly done and reversed. It is better to remove the bit erroneously and it restore it once the dust settles, than to create a national scandal.---Balloonman Poppa Balloon 15:28, 16 July 2011 (UTC)[reply]
    Modify stance based upon reflecting on what Z-Man said below. The 'crats job has usually been one that is devoid of politics and various entanglements. The 'crats who have done the best job as 'crats are the ones who have avoided the area of ANI and the people who have been promoted to 'crats tend to be the one's who don't live on ANI. While some admins see their job as the police force needing to keep the streets of Wikiopolis clean, 'crats traditionally have not held that role. This proposale would force them to get involved in more poltiical matters than they've tended to be involved with in the past.---Balloonman Poppa Balloon 13:53, 19 July 2011 (UTC)[reply]
    I share your sentiment that crats shouldn't be people who are entangled in such politics but I don't think the conclusion that this proposal will create such entanglement is correct. Although the wording was left intentionally vague, I think there is a broad consensus that this proposal is for the "admin X is running a script deleting a thousand random pages per second"-situation and not the "admin X might be involved into something controversial, let's take away his tools just in case"-situation. Even in the vast world of Wiki-politics I think there are few possible cases where an emergency that requires crats to desysop someone is clear-cut and non-political and this proposal aims to provide a policy to allow it. Regards SoWhy 14:19, 19 July 2011 (UTC)[reply]
  17. Oppose. Normal emergencies are handled by ArbCom, which can request removal under #2. In rare super-emergencies, when there is no time to contact the ArbCom, there would be two options: 1) to contact stewards, who have experience with cross-wiki abuse matters, or 2) simply block the abusive admin account until the issue is settled. I especially think that it's convenient for stewards to handle this, because they can remove bits on other projects or lock the account, as needed. — Waterfox ~talk~ 22:19, 16 July 2011 (UTC)[reply]
    sigh - where does this notion of blocking admins come from? It does not work - never has. Check my block log and follow the links from there! That is the case we are talking about. Agathoclea (talk) 22:28, 16 July 2011 (UTC)[reply]
    I was under the false impression that admins couldn't unblock themselves. Perhaps a new proposal could be made to remove the unblockself right from admins, making dealing with this kind of emergencies easier? — Waterfox ~talk~ 19:44, 17 July 2011 (UTC)[reply]
    Admins aren't SUPPOSED to unblock themselves, it is considered an abuse of tools. We've had drama fests in the past wherein an admin was incorrectly blocked and unblocked themselves. Even though the block was clearly in err, it still created a stir because the admin used the tools to unblock themselves. I've also seen admins unblock themselves to make comments then reapply the block then claim that they were following the spirit of the block.---Balloonman Poppa Balloon 13:48, 19 July 2011 (UTC)[reply]
    Strictly as an FYI, there is a proposal ongoing to remove that ability: Wikipedia:VPR#Unblockself permission. –xenotalk 13:52, 19 July 2011 (UTC)[reply]
  18. Procedural desysops are fine, but I think emergencies is stretching the purpose of the crat group too far. And the stewards are usually faster anyway. Mr.Z-man 00:18, 17 July 2011 (UTC)[reply]
  19. Salvio Let's talk about it! 15:08, 17 July 2011 (UTC)[reply]
  20. I, Jethrobot drop me a line (note: not a bot!) 04:57, 20 July 2011 (UTC)[reply]
  21. Oppose per both MBisanz and Balloonman; they said it better than I could. Bearian (talk) 18:07, 21 July 2011 (UTC)[reply]
  22. Oppose this version, I am however broadly sportive of the need, I just feel that since this involves the "unexpected" a more detailed policy is needed, including, under what circumstances they should act (i.e. clear and abusive mass use of the mop, not for example one or two "out of character" actions) also needs to be clearer when removal can or can not be reverted either by the removing crat or another crat. I feel that there is possibility for bad feeling to be created when a crat acting in total good faith makes an honest judgement call, which turns out to be the wrong, lets help avoid that by having a policy that is clearer. For example why not include the requirement to post to the Crat noticeboard asking for another crat to instantly review the removal, the reviewing crat having the power to overturn and restore the bit if felt warranted. Mtking (edits) 01:44, 22 July 2011 (UTC)[reply]
  23. Oppose per Mr.Z-man. BigDom 21:58, 22 July 2011 (UTC)[reply]
  24. Oppose. mabdul 17:00, 24 July 2011 (UTC)[reply]
  25. Oppose per MBisanz. Ale_Jrbtalk 17:21, 24 July 2011 (UTC)[reply]
  26. Oppose, as "appears to be compromised" is far too vague. Arbcom has historically been fast when necessary, and the possibility of a bureaucrat jumping the gun on a case arbcom is already considering seems like a potential megawheelwar nightmare. And, sorry to say it, but based on our history I think that would happen. Chick Bowen 15:31, 27 July 2011 (UTC)[reply]
  27. Oppose, vague wording, and encroaches on the traditional role of stewards. Titoxd(?!? - cool stuff) 07:14, 28 July 2011 (UTC)[reply]
    Everything in this RfC and its companion encroaches on the traditional role of stewards. That's the point, to move the primary responsibility for these removals from stewards to bureaucrats. --RL0919 (talk) 14:36, 28 July 2011 (UTC)[reply]
    I should make my point clearer: When an account is compromised, it is possible that it has been compromised on multiple wikis, making it prudent for stewards to check if the desysopping should be global. In either case, that doesn't change the problem that the wording is vague. Titoxd(?!? - cool stuff) 16:56, 28 July 2011 (UTC)[reply]
  28. Oppose per MBisanz and Wehwalt.  -- Lear's Fool 07:57, 29 July 2011 (UTC)[reply]
  29. Oppose. Involves politicking. Choyoołʼįįhí:Seb az86556 > haneʼ 06:35, 2 August 2011 (UTC)[reply]
  30. Oppose, too vague. Technical evidence for compromised accounts isn't necessarily available to 'crats anyway. —Kusma (t·c) 20:24, 2 August 2011 (UTC)[reply]

Discussion

[edit]
  • I added this section to generate an alternative wording for this point, since the "disruption" wording is clearly controversial. I've collapsed the support/oppose sections for now because I'd prefer to see some input on the wording first. I based the initial wording on Aiken drum's suggestion of truncating it down to just the first part and omitting any mention of "disruption". If folks think this wording is good, feel free to remove the collapse templates. If not, make or suggest changes and we can remove the collapse after we hash out a reasonable alternative. --RL0919 (talk) 21:30, 7 July 2011 (UTC)[reply]
    As above, I still think that a crat should have to notify ArbCom after performing an emergency desysop, and that the committee should confirm such a removal by motion. The final decision shouldn't rest on an individual crats judgment, although they should definitely be allowed to act in emergency situations. Remember that bureaucratship is not supposed to be a decision-maker role but a boring technical one Jafeluv (talk) 21:52, 7 July 2011 (UTC)[reply]
    Reasonable enough. What if we added "The Arbitration Committee must be informed of any emergency removal of administrator rights" to the wording? --RL0919 (talk) 21:55, 7 July 2011 (UTC)[reply]
    Not informed - "refered to for further decision" Agathoclea (talk) 21:57, 7 July 2011 (UTC)[reply]
    Yeah, and I don't think we should just have the "crat is required to notify the user how they may regain adminship" part, the answer to that should be outlined here also. Is it that arbcom will decide? ErikHaugen (talk | contribs) 22:01, 7 July 2011 (UTC)[reply]
    Absolutely. Any "emergency" removal of sysop bits should always be temporary and pending review by the full Arbitration Committee. --causa sui (talk) 22:15, 7 July 2011 (UTC)[reply]
    Reworded above to account for the points made in the discussion. Further feedback is appreciated. --RL0919 (talk) 22:26, 7 July 2011 (UTC)[reply]
    Seems good. -- Eraserhead1 <talk> 22:34, 7 July 2011 (UTC)[reply]
    This wording is fine with me. Jafeluv (talk) 23:21, 7 July 2011 (UTC)[reply]
    Yup, good enough. I've boldly removed the collapse templates so we can start !voting. --causa sui (talk) 23:29, 7 July 2011 (UTC)[reply]
    Is it temporary (meaning the bureaucrat needs to contact the Arbitration Committee to make the loss of administrator rights stick) or indefinite (meaning the user in question needs to contact the Arbitration Committee to re-gain administrator rights)? Guy Macon (talk) 20:08, 10 July 2011 (UTC)[reply]
    It is indefinete in the sense that it is openended until ArbCom decides - it is temporary in the sense that it is only a technical de-sysop - de-jure the editor is still an admin until Arbcom decides. Agathoclea (talk) 21:36, 10 July 2011 (UTC)[reply]
  • If the account is suspected of being compromised, is this not already covered by simply blocking the account? Why do we need to change the admin bit? And why do we need to involve ArbCom? This proposal seems like an over-bureaucratic solution to something that should be relatively simply solved. --RA (talk) 19:10, 14 July 2011 (UTC)[reply]
    I see the issue relates to "viewdelete", which can be accessed even when blocked. Is there no better way or resolving this? --RA (talk) 19:13, 14 July 2011 (UTC)[reply]
    In addition to still being able to use passive permissions such as viewdelete, a blocked admin can unblock themselves, so blocking will only briefly slow down a compromised account that wants to cause damage. --RL0919 (talk) 19:16, 14 July 2011 (UTC)[reply]
  • I wish there were a better sense in the proposal of what constitutes an emergency. FWIW, I liked this language: "is rapidly using administrative tools in a deliberate attempt to compromise the integrity of Wikipedia" - though it is probably late to reinsert. Jd2718 (talk) 14:46, 19 July 2011 (UTC)[reply]
Agreed I am also concerned about the lack of specific language guiding this proposal. Relying on the personal judgment of bureaucrats over what constitutes a compromised account is inevitably going to result in contested blocks, unhappy admins, an unhappy ArbCom, and long, grueling discussions that shouldn't have even occurred in the first place. We need a better description of what guidelines bureaucrats will be using to judge what information or behaviors will suggest a compromised account. Otherwise, this still shouldn't pass IMO. I, Jethrobot drop me a line (note: not a bot!) 05:20, 20 July 2011 (UTC)[reply]
  • Two questions on this one, would it not also be prudent to notify the crat noticeboard on removal, "more eyes on a problem" and all that ? and second what if in all good faith a crat takes action and for what ever reason feels it was in error, it looks to me that the only way the bits removal can be reversed is through Arbcom, is this the intention of the drafter and if so should that be made clearer ? I am a little uncomfortable with a policy that A) allows someone to do something, but does not allow them to fix it later if they have a change of mind and B) is not crystal clear on that point. Mtking (edits) 11:45, 20 July 2011 (UTC)[reply]
    I don't think anyone would object if notifications of emergency desysops were made to WP:BN, but I think you are the first to specifically ask for it. A situation like this would probably be well-discussed on noticeboards anyway. As for self-reversals, the ability would certainly be there, since crats already have the ability to add the right. I expect if it was an obvious unintentional mistake (there was a real emergency, but in haste the crat accidentally desysopped the wrong account, for example), no one would raise a fuss over a person correcting their own goof. If it was a case of reversing a desysopping done in poor judgment when there wasn't really an emergency, then I don't think that would be as well received, but the focus would probably be on the initial removal. The idea is for "emergencies" to be very obviously disruptive situations, such as deleting high-traffic pages or blocking a bunch of active editors without any explanation. If the disruption isn't blatant and pressing, then the situation can wait for a motion from the Arbitration Committee. --RL0919 (talk) 01:04, 21 July 2011 (UTC)[reply]
  • What should be or is done in the (unlikely) event that a bureaucrat's account should be compromised? — Preceding unsigned comment added by Interchangable (talk • contribs) 15:57, 22 July 2011 (UTC)[reply]
    • In an emergency, a steward should be flagged down to remove the rights. –xenotalk 16:02, 22 July 2011 (UTC)[reply]
    • Does the RfC for allowing 'crats to remove the sysop bit also cover removing the 'crat bit? If so, any bureaucrat could also step in. EVula // talk // ☯ // 22:58, 22 July 2011 (UTC)[reply]
      • No. Previous discussions had some complaints about joining admin bit removal with crat bit removal (and I think there are some additional concerns there), so this time RfC was kept as "clean" as possible, focusing exclusively on the admin bit. --RL0919 (talk) 01:31, 23 July 2011 (UTC)[reply]
        • Ah. Personally, I'm a little disappointed, but whatever. EVula // talk // ☯ // 02:27, 23 July 2011 (UTC)[reply]
          • I realize you aren't alone in wanting to see more stuff done in this RfC and it's companion. Indeed, some of the comments, both support and oppose, seem to reflect a misunderstanding that it is more sweeping than it really is. But past experience suggested that highly focused, incremental change would have a better chance of success, and in this regard I prefer modest success over ambitious failure. --RL0919 (talk) 17:48, 23 July 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

General discussion

[edit]
Discussion regarding inactive bureaucrats moved to talk page
I don't understand what the hangup with all of this is (both the admin and now crat removal). Adminship and bureaucratship being lifelong appointments seems crazy, to me. Holding account privileges ought to be a privilege. I hear the excuses being raised to retain the current practices, but... those arguing that things shouldn't change just aren't convincing to me. That, and fracturing these questions among a thousand different RFC's certainly doesn't help anything.
— V = IR (Talk • Contribs) 18:39, 8 July 2011 (UTC)[reply]
The problem with bundling everything into one RfC is that it creates confusions and uncertainties. People will oppose an entire proposal because they dislike one element. Or they will make comments that can be interpreted as only supporting parts of a proposal, leaving the closer uncertain about what they do or don't support. This can result in a "no consensus" result for the proposal even though most of the participants actually favored the general idea. Breaking out the different elements takes up more time and more pixels of discussion, but it gives cleaner results. --RL0919 (talk) 19:16, 8 July 2011 (UTC)[reply]
That makes sense. It's just a bit overwhelming I guess to have these three RFC's all pop up at nearly the same time. That, plus I thought that we covered this already (twice, at least, as a matter of fact). Anyway, I generally support all of this... you guys with a real interest in the minutiae involved with this stuff have my support in hammering all the details out.
— V = IR (Talk • Contribs) 23:17, 8 July 2011 (UTC)[reply]

SUPPORT all. But why is Wiki so hard to edit? Opening four different windows, the tiny edit box, that I have then then scroll through, typing the # symbol. It's unreasonable. Every other forum has commenting and voting without all this wasted manual formatting work.TCO (reviews needed) 13:35, 9 July 2011 (UTC)[reply]

  • I have a question about the emergency clause above. I agree with the wording of the second version, and getting ArbCom to review any emergency de-sysoppings seems like a very good idea. I'm a little wary of giving the Arbs even more work though, and I was wondering how the process works now. Do the stewards have to notify ArbCom in such a case? — Mr. Stradivarius ♫ 15:02, 10 July 2011 (UTC)[reply]
    I'm not sure whether there is any clearly stated policy for these situations now, but I seriously doubt this change would create a noticeable workload increase for the Committee. Emergency desysoppings are rare, and the sort of disruption that would be involved would almost inevitably come to the arbs' attention anyway. For a practical example, in 2007 a retired admin's account was apparently compromised and used to delete the main page, block Jimbo, etc. A request on IRC led a steward to desysop the account, but this was followed up with an ArbCom confirmation of the desysop. --RL0919 (talk) 16:12, 10 July 2011 (UTC)[reply]
  • I would add the edition of removal of Administrators who have shown themselves to be consistently rude. --TimL (talk) 23:04, 10 July 2011 (UTC)[reply]
    And who gets to decide when an Administrator is "consistently rude"? That is what would need to be defined. -- Mattinbgn (talk) 02:00, 11 July 2011 (UTC)[reply]
    This is another nice idea in principle, but then actually getting down a formal definition of what 'consistently rude' is that everyone agrees on would be very problematic. --(ʞɿɐʇ) ɐuɐʞsǝp 09:23, 11 July 2011 (UTC)[reply]
    How rude of you to say that :-P (talk→ BWilkins ←track) 16:05, 11 July 2011 (UTC)[reply]

Two thoughts - what about deceased admins? Also, I'm assuming that de-cratting would still need to go through a steward? --Rschen7754 06:22, 13 July 2011 (UTC)[reply]

Question: has anyone ever been de-cratted? --Whoop whoop pull up Bitching Betty | Averted crashes 13:27, 13 July 2011 (UTC)[reply]
Answer: Wikipedia:CRAT#Former bureaucrats shows that most (but not all) decrattings are voluntary. BencherliteTalk 13:36, 13 July 2011 (UTC)[reply]
Deceased admins would eventually be removed for WP:INACTIVITY. And yes - bureaucrats would still be unable to remove the 'bureaucrat' userright, so that would require m:SRP request. –xenotalk 13:38, 13 July 2011 (UTC)[reply]
According to Wikipedia:Deceased Wikipedians/Guidelines, the guideline is to desyop deceased admins right away upon confirmation of the death. --Rschen7754 18:42, 13 July 2011 (UTC)[reply]
Yes, that appears to be an unintentional omission from the list of policy-based situations given above. Given the obviousness of removing advanced rights from a known-to-be-deceased user, if all of the policies in this current RfC are approved with the sort of margins we're looking at currently (the most controversial has 86% approval), then I doubt it would be controversial to include this additional situation. --RL0919 (talk) 02:20, 14 July 2011 (UTC)[reply]
It's not a very common situation, but it would probably be practical to include it in the RFC if we're having all other enwp desysoppings done locally. --Rschen7754 02:43, 14 July 2011 (UTC)[reply]
  • How about, in the emergency, a sysop who constantly misuses his/her status? ~~EBE123~~ talkContribs 22:37, 13 July 2011 (UTC)[reply]
    A chronic problem is not an emergency. Currently, and under all of the policies outlined above, such a situation would need to be handled by ArbCom because there is no non-ArbCom process for permanently revoking admin status "for cause" (so to speak). --RL0919 (talk) 02:20, 14 July 2011 (UTC)[reply]
    If by "constantly", you mean a person who is currently, actively, and repeatedly abusing their tools (let's say they start deleting articles at random or blocking everyone that ever annoyed them) then they would be behaving in a matter identical to an account that has been compromised (and we can probably assume that they have been compromised if this is out of character). That would already fall under the last provision of this RfC. -- Atama頭 18:26, 14 July 2011 (UTC)[reply]
  • I have noted that there are a few admins who are against what is an extension of the number of trusted accounts able to perform a desysop, under specific circumstances and in all but one case per consensus. I am not sure why, since admins who are active in blocking accounts are surely aware of the potential for making errors and the very simple balances available to ensure that this risk is mitigated. If a 'crat makes a mistake, even such as picking the innocent party to a request for desysop ("Um, sorry Brad, I appear to have removed your admin bit and not that of the account that you requested...!"), then they already have the technical ability to reverse that error. Admins especially should be aware of the potential for human error in these actions, and surely should not be worried about a couple of entries in their privileges log - the 'pedia is not going to fall into the abyss because one admin has had the banhammer and crowbar taken away by mistake for an hour (or even a day). Admins have some expectation that their actions are assumed to be in good faith and to the best of their ability, and I do not see why sysops cannot extend that assumption to the actions of 'crats. Like adminship, being made bureaucrat is not an award or an elevation to higher status but a recognisation that the account may be entrusted to enact policy and determine consensus to a high standard - and if that level of competence is sufficient for the granting of sysop rights then it holds that the same applies for deadminning an account. What is true for admins, that there is the capacity to reverse all actions that the flags bestow, should also be true for 'crats. LessHeard vanU (talk) 19:38, 14 July 2011 (UTC)[reply]
  1. Supportper everyone else who thinks it's an obviously good idea Chris (talk) 20:53, 14 July 2011 (UTC)[reply]
  • Comment I fully support any of the technicalities granted above if agreed. However, my question is don't you guys consider anyone here can sometimes betray public trust which can also be a cause of adminiship removal? With all due respect to all of you. -- Rammaumtalkstalk 07:02, 19 July 2011 (UTC)[reply]
    • Generally, cases like that should be first brought to the Arbitration Committee. The uptake is that this proposal would constrain bureaucrats such that they may only remove administrator rights under a very limited set of circumstances (basically the same as Stewards presently). –xenotalk 14:58, 19 July 2011 (UTC)[reply]
    • We are in very severe and immediate danger of losing this whole project because we are taking it far too seriously. Its just a wikipedia, folks, it doesn't actually move the planet on its axis or anything, it mainly regurgitates otherwise available info about third rate minor league baseball teams and obscure computer games. I would ban everyone who wants to call themselves anything pompous, who tries to create a hierarchy, or take powers to do anything other than edit. One of the reasons the Catholic church has survived so long is because it has only five levels: Pope: Cardinal: Bishop: Priest: Laity. And even with just five, it is struggling to survive. Lets cut out the middle management: totally. We need only two levels: registered contributors, and editors defined as folk who have made more than say 100 posts o0f more than 100 words that have survived for one year.Excalibur (talk)
The Roman Catholic Church may only have five general levels, but there are a wide variety of offices with various powers and responsibilities, such as Acolyte, Adjutant Judicial Vicar, Administrator Sede Vacante, Ambassador of the Holy See, Apostolic Administrator, Apostolic Delegate, Apostolic Exarch, Apostolic Nuncio, Apostolic Prefect, Apostolic Vicar, Archbishop, Archbishop Emeritus, Archdeacon, Archpriest, Assistant Priest, Associate Pastor, Auxiliary Bishop, Bishop, Bishop Emeritus, Canon, Cardinal, Cardinal Bishop, Catechist, Catholic University Faculty Member, Chancellor, Choir Monk, Coadjutor Bishop, College of Consultors Member, Deacon, Dicastery Staff Member, Diocesan Administrator, Diocesan Bishop, Diocesan Synod Member, Diplomatic Corps of the Holy See Staff, Domestic Prelate, Ecclesiastical Superior who heads a Mission Sui Iuris, Eparch, Episcopal Vicar, Exarch, Finance officer, Judicial Vicar AKA officialis, Lay Ecclesial Minister, Lector, Local Ordinary, Major Archbishop, Metropolitan, Metropolitan Archbishop, Military Ordinary, Moderator of the Curia, Monk, Monsignor, Notary to the Diocesan Chancery, Novice, Nun, Ordained Deacon, Papal Chamberlain, Papal Legate, Papal Nuncio, Parish Priest AKA Pastor., Parochial Vicar, Pastoral Care Minister, Pastoral Council Member, Patriarch, Patriarchal Vicar, Permanent Apostolic Administrator, Permanent Deacon, Personal Apostolic Administrator, Personal Ordinary, Personal Prelate, Pontifical Delegate, Pope AKA Pontiff, Postulant, Prefect Apostolic, Presbyteral Council Member, Priest, Protonotary Apostolic, Rector, Roman Curia Official, Seminary Faculty Member, Subdeacon, Superior of an Autonomous Mission, Territorial Abbot, Territorial Prelate AKA Prelate Nullius Dioceseos, Transitional Deacon, Tribunal of the Roman Curia Staff Member, Vicar Apostolic, Vicar Capitular, Vicar Forane AKA Dean, Vicar General, and Vicar Protosyncelli. Looks like Wikipedia has some catching up to do! (smile) Guy Macon (talk) 19:04, 28 July 2011 (UTC)[reply]

I, for one, would not mind seeing most of those assholes fired! The vast majority of admins that I have come across are jerks who are only interested in pushing their own POV. I think that admin powers should expire automatically every six months and then a vote held to see if the dude should get his admin powers back, with a certain number of minimum votes required and if that minimum is not reached, even if the guy has the majority of the votes, he is still denied admin powers. General Zukov (talk) 00:41, 23 July 2011 (UTC)[reply]

With the above, I agree there are a few bad apples amongst the admins. Apparently getting the status granted goes to their head and they are protected by a clique mentality, kind of like the thin blue line, that will not criticize another admin. Not only should administrator right be under a condition of continual renewal, but those making the ultimate decision should NOT be other administrators or stewards--ordinary editors only. And there should be a system to allow ordinary editors to secretly watch the timing of the vote status for problematic admins, so we can know when to voice our opinions or problems with an administrator at the appropriate time--when something can be done. Trackinfo (talk) 18:07, 23 July 2011 (UTC)[reply]
Uh, what, exactly, do you mean by "secretly watch the timing of the vote status for problematic admins?" Beeblebrox (talk) 20:43, 28 July 2011 (UTC)[reply]
He means (I think) to make available the time at which the votes are placed, so people know if a consensus has formed yet and whether new votes, comments or concerns will sway the vote tally significantly, Beebles. Whoop whoop pull up Bitching Betty | Averted crashes 15:54, 31 July 2011 (UTC)[reply]
You do realize that by distinguishing between admins and "ordinary editors", you are exhibiting the same problem, i.e. that admins are somehow different from other editors? Regards SoWhy 16:36, 31 July 2011 (UTC)[reply]
I'll clarify, yes I think that anybody should be able to "watch" when an administrator is coming up for confirmation, so that input can be presented at the appropriate time. Similar to a watched item, the parties doing the watching should not be visible--particularly to a problematic admin. And yes, I do believe that administrators are "more equal than others" and treat their authority accordingly. Most are the benevolent governors we need to keep WP orderly, a few wield their Iron Fist in order to exert their POV. We lowly editors are governed by their decisions. The fact that most internal administrative communication on WP is passed between and decided by administrators, most who hold the thin blue line mentality of never speaking ill of another administrator, those folks should not be involved in the nomination or confirmation of their own kind. They back each other up enough already. We have rules about sock-puppetry, it should be easy enough to track if an administrator is participating in the election. If an administrator is concerned enough of an editor to want to participate in the election or confirmation of an administrator, they should first renounce their position as an administrator and then come join the masses. Trackinfo (talk) 19:00, 1 August 2011 (UTC)[reply]
Without comment on the pros or cons of any of the above, I want to note that it is not anything in the current proposal. All the policy changes proposed above are to allow bureaucrats to remove the admin bit in the situations where stewards already do so today. Presently there is not any sort of systematic administrator reconfirmation process, so the closest any of the proposals above would come to this sort of thing would be if an admin self-requested removal of their bit prior to undertaking a voluntary reconfirmation RFA (as has been done a few times in the past), in which case #Self-requests above would apply. --RL0919 (talk) 19:24, 1 August 2011 (UTC)[reply]
This was a general discussion point originally raised by General Zukov, which I agreed with. I tried to put it into a more concrete frame, rather than just calling them assholes. I would like to see the position of Administrator come up for constant re-appraisal by the editors they oversee. Much as I have seen the wheels of injustice grind through decisions here, I don't know where the core is. So I don't have a clue where such a real proposal could be made, before it was shot down by the alliance of thin blue line members. Perhaps someone would respond here and tell us lowly editors where we might be allowed to speak before the great and powerful. Trackinfo (talk) 06:01, 3 August 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Emergencies (v3)

[edit]

As an FYI, I've initiated a discussion concerning emergency desysopping at Wikipedia talk:Bureaucrats#Emergency desysopping (v3). –xenotalk 01:06, 8 August 2011 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Bureaucrat_removal_of_adminship_policy&oldid=1090450838"