This RFC is purely about giving bureaucrats the technical ability to remove the admin flag. Use of this ability would be governed by whatever policy the community determines. A potential policy is under discussion at Wikipedia:Requests for comment/Bureaucrat removal of adminship policy
Currently, bureaucrats on the English Wikipedia have the technical ability to grant the administrator user privileges (variously referred to as the 'bit', 'flag' or 'user group'), but do not have the ability to remove the administrator privileges. Instead, removal of the admin flag must be performed by a steward, typically in response to a request placed at meta:Steward requests/Permissions. However, the ability to allow bureaucrats to remove the admin flag is available within the MediaWiki software and is enabled on some other Wikimedia projects.
Members of the bureaucrat user group are granted the technical ability to remove the group "administrators" from users using the interface at Special:UserRights.
Since the question can be answered as either "yes" or "no", this RFC is structured like a straw poll. The existence of support/oppose sections does not mean that discussion is discouraged. General discussion should be added in the designated section.
Support
Support - If a bureaucrat can grant the admin buttons, they should have the power to remove the buttons as well. Bureaucrats are among the most trusted members of the Wikipedia community, and giving them this technical ability corrects an obvious flaw in the structure Wikipedia uses to operate with. Jusdafax08:28, 7 July 2011 (UTC)[reply]
Support - Misuse can be handled by ArbCom as per any other tool misuse, and in any event is easily reversible. I trust ArbCom to come down like a tonne of bricks on a bureaucrat who abused the additional right. Pedro's concern on the talkpage is a valid one. If have no objection to a reconfirmation process for all bureaucrats if this gains approval. WJBscribe(talk)11:29, 7 July 2011 (UTC)[reply]
Support. I've supported this before, and since desysoppings are now going to start happening more frequently with the inactive admin removal process, it makes even more sense to have trusted local users do it. We can assume bureaucrats to have better knowledge about the details of the local policy and standard procedures than stewards (remember that stewards who are active community members here aren't supposed to perform any enwiki desysoppings in the first place). Many Wikimedia projects have already added this right to the bureaucrat package: meta, simple.wikipedia, en.wikinews, hi.wikipedia, fi.wikipedia, etc. While bureaucrats weren't exactly selected for this task, I have no problem trusting them with an additional responsibility which is closely related with their current job. Jafeluv (talk) 11:53, 7 July 2011 (UTC)[reply]
Support - it's the logical counterpart of Bureaucrats' ability to create new admins. How and when they should use such a power is a matter for discussion, but I can't really think of any good argument why they shouldn't have it. At the very least, it could be used when an admin is ordered to be desysopped by ArbCom. Currently, as I understand it, if ArbCom wish to remove an administrator's tools, they must contact a Steward; granting bureaucrats the technical ability to desysop would make the process quicker and easier, and allow it to be conducted entirely within the English Wikipedia. Robofish (talk) 14:59, 7 July 2011 (UTC)[reply]
Support This technical ability should be a part of the permissions of Bureaucrats, as long as there is clear policy on when it is appropriate to use. -- Ed (Edgar181) 20:14, 7 July 2011 (UTC)[reply]
Support as the person who started this RfC. As people said already, it's the usual system that a "higher" group can grant or remove all rights below that group. Admins can grant or remove rollback, autopatrolled etc. and they can remove it again. No-one so far claimed that this might lead to problems. The only exception so far is bureaucrats, who can add two rights but not remove them. This proposal would just create a situation that one would expect to find. How and when the crats should be allowed to use this right is a question for the parallel RFC about a policy to govern this. Regards SoWhy20:21, 7 July 2011 (UTC)[reply]
Support one of the last bits of "dependance" on outside help to administer the project, also opens the way for better de-sysoping procedures. Also given that inactive admins are now to be de-sysoped this gives the crats something to do :) --Errant(chat!)20:32, 7 July 2011 (UTC)[reply]
Support Should have been there all along. The ability should be added no matter what happens in the other RfC. If there is no policy governing it's use, 'crats can be trusted to not use it outside of policy anyway. Jim MillerSee me | Touch me20:43, 7 July 2011 (UTC)[reply]
Support. To me this seems like an obvious change to make, for several reasons:
Allowing the same group to both grant and remove the flag centralizes the process, which provides maximum transparency. Anyone wishing to monitor requests for adminship removal could watch our own bureaucrats' noticeboard, rather than a Meta noticeboard that also contains requests from other wikis. Also, going forward, logs regarding a user's admin status would no longer have to be split between here for granting and Meta for removing. (Unfortunately, past logs would not be unified by this change, but that is not a reason to perpetuate the problem into the future.)
We already entrust bureaucrats to perform the much riskier task of giving admin permissions, and potential bureaucrats are scrutinized very closely as a result. In contrast, having removals done by stewards means the task may be performed by someone who has little or no experience with English Wikipedia and has never been vetted here for so much as being a rollbacker. Although I expect it would be very rare, if a bureaucrat were to abuse the privilege, they would be answerable to the local community and Arbitration Committee.
Bureaucrats have successfully been given additional responsibilities in the past. The original 'crat role was just for promoting admins. Everything else was added later. This is just one more addition, and it is more closely related to their current function than past additions were. Additionally, this is already implemented for some other projects with no apparent problems. --RL0919 (talk) 20:49, 7 July 2011 (UTC)[reply]
Support a higher level of independence for enwiki. Also, bureaucrats will no doubt need this ability with the new inactivity policy in place. Regards, MacMedtalkstalk20:51, 7 July 2011 (UTC)[reply]
Weak support based off the new inactive admin policy. Were this policy not in place, giving 'crats the ability to remove the admin bit would have no real use. demize(t · c)20:54, 7 July 2011 (UTC)[reply]
It makes sense that the same people can flip on and off the admin bit, and it also makes sense that enwiki handles its rights changes autonomously, without the need for help from stewards. Ucucha21:19, 7 July 2011 (UTC)[reply]
Support - Yes yes, please yes. It seems like the most difficult thing to do on Wikipedia is to de-sysop someone. Now, it shouldn't be easy to do so, but just the same the hoops we have to go through to do so are silly. We've tried for years to have some formal de-adminship procedure, or mandatory recall, etc. But the most reasonable suggestion is to put the ability in the hands of bureaucrats, the same people who make the ultimate decision to grant adminship in the first place. Another reason to do this now is because of the new policy to remove the admin bit when an administrator becomes inactive for a year or more, and giving crats the ability to do this will make that smoother as well. -- Atama頭
Support I think the level of scrutiny crats receive at RfB is enough to qualify them to operate with this capability. Qrsdogg (talk) 21:41, 7 July 2011 (UTC)[reply]
Giving bureaucrats the ability to also remove administrator rights seems logical if they are presently trusted to give it out in line with policy. --(ʞɿɐʇ) ɐuɐʞsǝp21:59, 7 July 2011 (UTC)[reply]
Support this will help as the desysop action would appear in en.wikipedia logs; and it would enable a reversal of a mistake, if that ever happened! It will also reduce the impression that adminship is irreversible. Graeme Bartlett (talk) 22:13, 7 July 2011 (UTC)[reply]
Obviously, we still need to get the rest of the crat policy rolling, but ErrantX has got the ball rolling with the first vital part (see discussion at the bottom of this page). Ncmvocalist (talk) 01:27, 8 July 2011 (UTC)[reply]
Support. Despite the fact that Pedro has a valid point, I don't think tehwiki will break. WJBscribe is also correct - all sorts of nasty things would rain down upon any who misuse this right, which I think is a low probability anyway. Net positive. In addition, it's already well-nigh impossible to become a crat anyway. Frank | talk 01:33, 8 July 2011 (UTC)[reply]
Weak support Despite the ongoing hullabaloo about hacked admin accounts, I think it would be slightly hypocritical to on one hand desysop inactive admins while on the other hand granting bureaucrats the ability to desysop anyone—making them more of a target for password guessers. However, I don't see why this is a real bad thing, and this would give stewards a little less to deal with. /ƒETCHCOMMS/03:15, 8 July 2011 (UTC)[reply]
Support. I rather have bureaucrats who are among the most trusted users of the English Wikipedia desysoping admins than Stewards who are by definition less familiar with our culture and processes. Eluchil404 (talk) 07:06, 8 July 2011 (UTC)[reply]
I trust our 'crats more than the stewards. Not because stewards are untrustworthy (they're very good at what they do), but because I know our 'crats. I !voted in several of their RfBs and I see their work on a daily basis. I imagine many admins feel the same and, even though most of the actions with this new ability would be uncontroversial, it's nice for it to be done by someone you know. I think it's daft that, if I want to hand my bit back, I have to go and ask someone I probably don't know, on another website. Having all the logs in one place is also an advantage. HJ Mitchell | Penny for your thoughts? 12:52, 8 July 2011 (UTC)[reply]
Support. I really thought they already had this ability and if I had needed to ask someone to do it would have gone looking for a 'crat. Rmhermen (talk) 17:34, 8 July 2011 (UTC)[reply]
I agree with Edgar181, it of course needs to be worked out when this ability should be used. But I'm sure there are some cases when it's appropriate, so support.
Oppose
Weak Oppose As far as I know, Stewards are not so hard to come by that in the rare cases where we need to desysop someone, one can't be found. I understand that we have a new policy on de-bitting (is that a word) inactive admins, but in general I'd like to see it figured out beforehand how the new powers are to be used before we grant them. See Wikipedia:Requests for comment/Bureaucrat removal of adminship policy, where there is some disagreement about this. --causa sui (talk) 21:03, 7 July 2011 (UTC)[reply]
Whether stewards are "hard to come by" is not really relevant. redundancy is good and the more trusted people can do something, the better for the project. And the fact that keeping things local makes life easier for all involved should not be ignored. As for the policy, the reason we created two RfCs to run parallel is exactly to address this concern. Had we first discussed how crats should use this right, people would have argued whether they should have it at all. Had we discussed whether they should have it first, the RFC would have been full of discussion on the "how?". This RFC can be successful without a policy to govern the right, since we can trust crats not to use it in that case. I don't think you or anyone really wants to argue that crats cannot be trusted not to use something without consensus to do so? Regards SoWhy21:28, 7 July 2011 (UTC)[reply]
Not sure if we should start threaded discussion here or in the below section - if someone thinks this is wrong, please be bold and move it. :-) That said, I don't have strong opinions about this and won't be squawking if it gets implemented, because I think bureaucrats are a clueful enough lot to know that they shouldn't use tools like this recklessly. And hopefully my oppose won't bother you too much since it looks like this will pass over my mild opposition. Still, I'll respond to your points.
On the issue of redundancy, it is not a good security practice. According to the principle of least privilege, the lack of a real-world need for the access is a strong argument against granting it.
It's a fair point that there is a procedural Catch-22 here, but it remains that I think the scope of the power ought to be defined before the power is granted. Sorry :-) You might understand my concern better in the context of the linked RFC, where there is some significant support for the proposal that bureaucrats should be permitted to unilaterally desysop users because they are using tools "disruptively". This is unacceptably vague, and I would want to know that that won't pass before I support granting the power at all.
On the (somewhat rhetorical) question of whether I want to argue that crats cannot be trusted to do something without consensus, you are correct that I do not want to argue that.
A wiki is not a computer system. If we that train of thought to its logical conclusion, we would have to desysop everyone not completely necessary for the project and have a staff of crats ready to resysop them iff the needs change on short notice. Obviously, that's not a working model. Wikipedia does not operate on this principle. We have hundreds of things that are redundant. We have more admins than we would need (if everyone of those used the tools all the time), we have a number of crats who have the tools but don't use them etc. It might not be a good security practice but I didn't claim it was. But granting crats the right to desysop does not create a bigger security problem than we already have (a rogue steward can do much more harm already than a rogue crat with the right could ever do but crats need to pass a higher bar than stewards).
You are free to think so. Unfortunately, the Catch-22, per definition, cannot be solved, so the parallel RfCs modus operandi is probably the best "solution" here. I don't think there is another one that would address the problems that arise of having one before the other...
Strong Oppose (Procedural) I know there is precedent for having parallel discussions, but I dislike the idea of giving them the technical ability when I don't know ahead of time what the policy that binds their actions is going to be. I'd support this if the procedural proposal finishes and I like how it reads, but not before that happens. Sven ManguardWha?03:38, 8 July 2011 (UTC)[reply]
Oppose. I see no reason for this, and none has been offered. Is there a backlog of admins that need to be de-admined? Unless a good case for the change is made, I'd rather not open another level for wheel wars. --91.221.120.78 (talk) 11:59, 8 July 2011 (UTC)[reply]
There are several reasons mentioned above, such as having the logs at the same place, crats being more familiar with this project than stewards, the fact that it's a core wiki-principle that things that can be added by one person should be removable by them as well, etc. "Need" is never a good argument for or against anything after all (see my response to #1). Arguing with the risk of wheel-war is imho wrong, since unlike with admins, I don't think there was ever a case of crats wheel-warring about anything crat-related, so the argument is based on the faulty assumption that crats would wheel-war (which we have no reason to believe they will). Regards SoWhy12:27, 8 July 2011 (UTC)[reply]
Oppose - this is a solution looking for a problem. In emergency situations that have come up before, stewards have been available. Handing this ability to bureaucrats is just adding to the number of people who have the ability to perform a function that potentially has a very high risk of damage if the account is compromised or the crat goes rogue. This isn't an issue of trust - it's an issue of security best practices. --B (talk) 17:37, 8 July 2011 (UTC)[reply]
While the tail end of your comment could probably stand on its own, there are problems that have been identified to go with this solution. Perhaps the most frequently cited complaint is the counter-intuitive split in the rights logs (where additions are in the local log and removals in the meta log). Another problem is that stewards permitted to act on en.wp requests are those whose home wiki is not en.wp - and therefore they are generally less familiar with local policy. This lead to a recent issue where over 250 administrators were desysopped out of process (see [1] and [2]). –xenotalk17:47, 8 July 2011 (UTC)[reply]
General discussion
Awaiting further input, and considering all views before I either support or oppose. It certainly does/would change the power structure on the site if this is a go. I'm not saying that's a bad thing, perhaps it could give a "checks and balances" to what some refer to GovCom; if not in practice, then certainly in perception. — Ched : ? 22:00, 6 July 2011 (UTC)[reply]
I'd also like to note that there was recent discussion about lowering the bar for RfB, (which I supported). THIS certainly would make me want to rethink that. Hopefully the reasons are obvious. — Ched : ? 22:03, 6 July 2011 (UTC)[reply]
That's an interesting point actually Ched. I was suprised that discussion was closed in the way it was - I thought it was fairly clear the percenatge that was been debated, but there we go. Is granting desysop to 'crats going to make RFB even harder? I can't see it's going to make it easier after all :). Given there was clear consensus that the RFB bar should be lowered at that debate (permalink) there is a ramification here. However I'm not sure in myself how strong this is as an argument against not adding desysop to the crat tools. Certainly food for though. Pedro : Chat 15:16, 7 July 2011 (UTC)[reply]
Any de-adminship is going to be well scrutinised, and I don't think we have such a large pool of crats (or the potential for so many more) that it gets to the stage that such things bypass scrutiny in the way that, say, "normal" admin actions do. --Errant(chat!)20:33, 7 July 2011 (UTC)[reply]
My reservation is that the user conduct rules are weak (virtually unwritten) when it comes to the bureaucrats. Although it may turn out that a lot of the pronouncements in a crat policy can be lifted from admin policies, with some tweaks, it all takes time (and other user groups have most things written out as policy). At least for now, there continues to be a requirement that crats must remain admins (so the admin conduct umbrella applies at minimum). But nothing is forever, and attention will need to be given to this sooner rather than later, particularly as the bar gets lowered. Ncmvocalist (talk) 20:57, 7 July 2011 (UTC)[reply]
As far as I know, there is no "requirement that crats must remain admins"; and in fact, as we speak, there are two bureaucrats who are not admins (albeit bothinactive). –xenotalk20:59, 7 July 2011 (UTC)[reply]
