Wikipedia:Requests for adminship/Bureaucrat Unchecking

Following two discussions on the subject, in February 2009 and then January 2010, some believe (although this is under dispute) that there is consensus for bureaucrats to be given the technical ability to remove the admin and bureaucrat user groups as well as grant them. This means that removal of the admin flag ('desysopping') will generally take place on enwiki rather than at meta; and those actions will be logged in the local rights log rather than the global log at meta.

There are currently two processes for desysopping which have consensus: resignation by individual users (for whatever reason), and removal by ruling from the Arbitration Committee. There are currently no other processes which have community consensus. This discussion seeks to clarify the circumstances in which bureaucrats will remove admin and bureaucrat permissions, and establish any knock-on effects on other areas of Wikipedia.

Comments have been solicited from the three groups who will be most affected by this change: the Arbitration Committee, the Stewards, and the Bureaucrats themselves. Contributions from all editors are also encouraged.

Comments from Bureaucrats
Entries in this section should be comments from, or direct responses to, enwiki Bureaucrats.


 * As with anything to do with 'crat abilities, I would do things according to consensus. As consensus is outlined above, I see no issues with implementing it as outlined above. Not sure what else people are looking for here. ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 05:38, 15 February 2010 (UTC)
 * As per what everyone has said. I think everyone needs to be clear that this is a straightforward change that has nothing to do with CDA until, and unless, it passes - and whether or not it passes just relates to who hits the button once the decision is made.  -- Pakaran 06:07, 15 February 2010 (UTC)
 * All seems fine and clear to me. I find Mike.lifeguards comments (linked to below) clear and sensible, too. --Dweller (talk) 09:39, 15 February 2010 (UTC)
 * Given that when users participated in RfBs they did so in the knowledge that bureaucrats had the technical ability to grant sysop rights but not to remove them (and we do not know if their opinion would have been the same had the later ability also been on the table), I think enabling this is problematic absent a procedure for bureaucrat removal or reconfirmation. WJBscribe (talk) 13:48, 15 February 2010 (UTC)
 * Surely the participants in the RfC knew this? --Dweller (talk) 14:24, 15 February 2010 (UTC)
 * It's probably because it's late here, but I'm not exactly sure what you're asking... WJBscribe (talk) 23:09, 15 February 2010 (UTC)
 * The decision to allow bureaucrats (and, by immediate extension, the current cohort) to "uncheck the box" was made by the current community, whose consensus (if such a consensus exists) renders inconsequential the opinions (and possible reservations) of an older community – consensus can change and all that. That's Dweller's point. However, I do think that increased responsibility will introduce a need for some kind of bureaucrat review. Too many of our number are too inactive to be sufficiently acquainted with present community norms. — Anonymous Dissident  Talk 12:21, 16 February 2010 (UTC)
 * It is true that the bureaucrats were elected without the technical ability to remove the sysop flag, but we all know that consensus can and does change. Wikipedia isn't liquid enough for drastic changes, but it does slowly evolve. The threshold for electing bureaucrats has been under scrutiny for some time now, and some would say that the threshold has been lowered from 90% to 85%. If that can be changed without too many being up-in-arms as to the non-promotion of past RFBs, like Riana, for example, that was unsuccessful at 85.9%. The "rules" can be changed over time if community consensus changes. Ergo, if the community decides to add desysopping to the bureaucrat toolbox, then so be it. We can't go back in time and retroactively remove our support for bureaucrats that we wouldn't trust with the desysop tool. We can only do two things: 1) add the desysop tool; or 2) don't add it. Option 2 is the status quo, while option 1 does actually allow for two sub-options: 1a) Give the desysop tool to all existing bureaucrats; or 1b) Reconfirm all bureaucrats with those passing given the desysop tool and those failing losing their bureaucrat bit altogether. Given my experience on Wikipedia, I really don't see option 1b happening, but I wouldn't be opposed to it. I would expect the outcome of the community consensus to be either 1a or 2, as I've outlined. Also, I want to be very clear on this point: should the desysop tool be added, I want it very clearly outlined as to when I should use it. I would be fine with desysopping the "oops, didn't mean to add the bit", "'crat chat decided the RFA should've failed", or "'crat went rouge and started sysopping everyone, let's remove the bits". Stuff like that. But if you want me to start sorting out dramafests of "he said this and she said that, but then he deleted it so she blocked him, but then he unblocked himself...", I'm not interested in that. There's a reason I leave RFC, ANI, and ArbCom alone. So, overall, I would be supportive of implementing the desysopping tool, but only to be used in a limited set of circumstances. Useight (talk) 17:06, 15 February 2010 (UTC)
 * I am still very hesitant in granting the crat corp this new ability and would insist on a new specific WP:POLICY on when crats may use it (including emergencies, accidents, etc) before I would exercise it.  MBisanz  talk 02:13, 16 February 2010 (UTC)
 * Interesting. How do you think that will work with several crats' stated desires to avoid codifying bureaucrat activity in a formal policy?  Happy ‑ melon  10:41, 16 February 2010 (UTC)
 * Well, of the two things to be added to the crat set since its invention, one has a policy (granting +bot) and the other doesn't (renames), so I don't see either position as totally incongruous. And just because I would have the ability to desysop doesn't mean I am required to act on a request. I could simply decline to use that crat power until such time as a policy develops, since there are sufficient active crats that my failure to act wouldn't endanger the wiki. There are admins who don't do things like WP:AE or WP:RFR on their own principles and crats who don't handle WP:BRFA requests on the same basis, so I don't think it is an unreasonable position.  MBisanz  talk 14:19, 16 February 2010 (UTC)
 * That's entirely reasonable. Happy ‑ melon  14:49, 16 February 2010 (UTC)
 * Comment: I've distilled what I see as consensus in this proposal. Please come and share your thoughts. ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 02:15, 17 February 2010 (UTC)
 * That looks great; I've shamelessly copied it below; as I think it's helpful to keep everything on one page.  Happy ‑ melon  10:41, 17 February 2010 (UTC)

Comments from Arbitration Committee members
Entries in this section should be comments from, or direct responses to, sitting members of the Arbitration Committee.


 * This is an interesting proposal and, providing the parameters are clearly and firmly established, could be beneficial. However, it has great potential for drama-fests and a politicisation of the bureaucrat role.  Roger Davies  talk 10:52, 16 February 2010 (UTC)

Comments from Stewards
Entries in this section should be comments from, or direct responses to, existing Stewards.

General discussion
All are welcome to comment in this section.

I think that it is important that the bureaucrats have a clear idea of, and are able to give a clear indication of, when they will remove these flags. I think it's clear that the consensus extends only to the situations where deflaggings already take place: resignation, or removal by ArbCom; but this should be made clear from the outset. We also need thoughts from ArbCom about whether they will use this system to impose remedies, and whether they will make requests publicly, or whether one of the ArbCom members who are also bureaucrats will perform Committee deflaggings. Finally, a consensus for the Stewards about what rights changes we still wish them to perform on enwiki, and in what circumstances, will be required. Happy ‑ melon 22:56, 14 February 2010 (UTC)
 * Personally, I think the only situations in which Stewards would be needed for userright modifications would be in granting/removing the Oversight and CheckUser flags (similar to how things are done now), or in an emergency situation (the logic being that an emergency desysopping being done in a timely fashion is more important than jurisdictional bureaucracy). For other situations (ArbCom-dictated flag removal and voluntary resignation), requests need to be made on enwiki and performed only by enwiki bureaucrats. EVula // talk // &#9775;  // 23:38, 14 February 2010 (UTC)
 * Mike.lifeguard, a steward, made these comments in the poll that would probably be of interest. NW ( Talk ) 23:40, 14 February 2010 (UTC)


 * Like their other tasks 'crats will need clear guidance when it is expected and to what extent they are assessing consensus or making any judgment. Essentially this is just moving the technical task from global rights (stewards) to local rights (crats), it doesn't change the well-established criteria or circumstances when de-admin might take place or the evidence needed for a request: - 1/ User voluntary request, 2/ Arbitration Committee decision or formal temporary removal of permissions by ArbCom, 3/ Consensus following a formal community de-adminship (if a communal process becomes used). Should not be contentious. Usual proviso about "involved crats" is commonsense. No objection to stewards continuing to help if appropriate. The main case a steward might be needed would be temporary level I removal of permissions. None of the others are that urgent. User requests need to go on-wiki anyway (WP:BN is the best-centralized venue), community deadminship would be closed by 'crats anyway, and formal RFAR decisions are non-urgent and can be posted to BN rather than Meta when the case closes.  FT2 (Talk 23:50, 14 February 2010 (UTC)
 * Absolutely. And it needs, I think, to be made clear that stewards at least are free to act on an emergency basis in cases of bona fide emergency (one example, not the most harmful but the most obvious and therefore least BEANSy, would be a compromised sysop rapidly re-adding inappropriate content to a high-visibility page).  It is not at all clear that crats should act in such cases (and, personally, I would be very reluctant to even if the community explicitly approved the practice - which it has not).  -- Pakaran 00:59, 15 February 2010 (UTC)

I'm not sure where the consensus supposedly is, but 65 for and 27 against certainly isn't anything like the consensus this proposal requires - it's less than the margins (70%) we use to promote administrators so it certainly shouldn't be used to claim consensus for a considerable change in how we operate.  Ryan Postlethwaite See the mess I've created or let's have banter 13:41, 15 February 2010 (UTC)
 * Ditto Ryan. I would like to see a little more analysis of the discussion by those asserting that it contains a consensus, which I do not think is by any means obvious. Is it being suggested that the arguments offered by those opposing were weak (and that the numbers are therefore a misleading indication of the underlying discussion)? If so, I think that needs to be explained clearly. WJBscribe (talk) 13:54, 15 February 2010 (UTC)
 * The assertion that the raw number (a smidgen over 70%) is axiomatically inadequate, is stymied by our inability to form a proper definition of what margin is required, and by our general principle that !votes are not votes. Your personal feeling, Ryan, seems to be that 90% should be the threshold; I'm sure I'm not alone in feeling that to be totally impractical.  To compare raw numbers, the poll that brought us rollback closed with 67% support, and that is unquestionably a hugely more significant change to enwiki, with an appropriately larger number of participants.  You don't believe that consensus exists, fair enough; but your tone implies that that is blindingly obvious, which is unfair on the closing admin.
 * @WJBscribe Some of the opposing arguments are weak; the "security risk" argument (6, 13, 14, et al), the "bureaucrats will be unable to resist" argument (23, 27), etc. #15 ("solution looking for a problem"/"random FUD") is a personal pet-hate of mine; especially when the problems (especially log fragmentation) are explained extensively in the discussion section.  The "the problems are not serious because X" argument would be valid; the "the problems do not exist" argument is not.  As I explained in the discussion section, Ruslik's thoughts on log fragmentation (O#8) simply do not make sense: the change will fix the problem in the vast majority of cases, while leaving the status quo for the remainder; the argument that that somehow makes the overall problem worse is paper-thin at best.
 * I think the strongest argument, which you pick out especially, is the the concern over our older bureaucrats whose RfBs are not good mandates from the community to serve as a 'modern' bureaucrat. I was very vocal in pushing that point at Wikipedia talk:Bureaucrat removal, and raised it as a serious stumbling block in the path of CDA.  I would very much like to see some progress on the issue of grandfathered bureaucrats.  Are you interested in working on a new proposal in that area?  Happy ‑ melon  16:23, 15 February 2010 (UTC)
 * That it is a personal pet-hate of yours does not mean that it is a weak argument. In my opinion, it is the strongest of all arguments: if it are't broken do not fix it. Change for the sake of change is always bad, because there are always unintended consequences. Ruslik_ Zero 19:34, 15 February 2010 (UTC)
 * No, I present it as a weak argument because I can provide strong justification (vote from inertia, the fallacy of claiming that "not totally and irreperably broken" == "not broken", and the corrosive nature of FUD) to support the assertion. You are certainly entitled to feel that the argument is strong, but I expect you to be able to provide similar justification for that position, or I will disregard it and be quite right in doing so. Happy ‑ melon  20:33, 15 February 2010 (UTC)


 * There were valid points raised by those in support and by those who opposed, and a judgment would come down to an assessment of numerical consensus. The support was just over 70% in favour, and 70% is in the region we generally consider to be consensus. I was an uninvolved admin with no views either way in this debate and was making a judgement call as I saw it. (Indeed, I originally closed as rejected because I had made an error in maths.)
 * However, as it was close, and there were concerns raised, I asked for a widely advertised discussion on the implications of this proposal to look at the areas of concern. This, as far as I am aware, is that discussion, though the opening statement may make clearer that this discussion is to look at the implications of implementing this change; also, the opening statement should link to this discussion, not to a failed poll from nearly a year ago - I think that might just confuse people.
 * This is a discussion to examine concerns about the proposal - both mechanical and philosophical, and to see if those concerns are justified enough to stop this proposal being implemented. I think that is fair and reasonable.  SilkTork  *YES! 19:09, 15 February 2010 (UTC)
 * I want to ask two simple questions:
 * Did you read my procedural objections?
 * The support was just over 70% in favour. In favour of what exactly? a) Creating some CDA process (a few people actually voted for this) b) giving crats an ability to remove sysop bit only or c) giving crats an abolity to remove crat/sysop bit. (Some users explicitly objected to 'c' why voting for 'b', while others supported 'b' but did not expressed any opinion about 'c'). So 70% for what? Ruslik_ Zero 19:48, 15 February 2010 (UTC)


 * I have every confidence that SilkTork did indeed read your comments; do you have reason to believe otherwise? They are hardly earth-shattering.  Did you ever read my comment of 12 January?  You never made any response, despite it being a direct refutation of your argument.
 * If people support CDA, it's not unexpected that they would support this change. Nonetheless this change is not CDA, it is the "c" option in your list.  To suggest that people are somehow not allowed to support both CDA and bureaucrat deflagging is like saying that those who support the Democratic party are not allowed to support a referendum on gun control because gun control is 'part of' the Democratic party.  There is no reason to distinguish between those who supported this change and also support CDA, and those who support independent of CDA.
 * The question posed was whether there was "consensus to allow bureaucrats to manually uncheck the sysop/crat bit when instructed per policy", so support for both flags is assumed. There are indeed precisely two users who made their support conditional on bureaucrat flags being excluded.  I've directly requested their input on this discussion.   Happy ‑ melon  20:21, 15 February 2010 (UTC)
 * Since the closer initially made such a very simple (math) error, I suspect that he did not. Ruslik_ Zero 20:47, 15 February 2010 (UTC)
 * Tryptofish has clarified their concerns, and the fact that they are no longer overly concerned, on their talkpage. I think those comments are very constructive.   Happy ‑ melon  22:34, 15 February 2010 (UTC)
 * How do sending messages to users who opposed this change and pressing them to change their position comport with WP:CANVASS? Ruslik_ Zero 08:25, 16 February 2010 (UTC)
 * Please clarify where in the discussion I "pressured them to change their position"?? That statement seems to be... loosely... connected to reality, at best.   Happy ‑ melon  10:40, 16 February 2010 (UTC)
 * Stating that there is a consensus for a change (which is not true) and then asking if the user has changed his opinion is a (thinly veiled) pressure. Ruslik_ Zero 19:36, 17 February 2010 (UTC)


 * I'm with Ryan and WJBscribe on this one... I don't see the consensus, and I certainly don't agree with this becoming policy. &mdash; Coffee //  have a cup  //  ark  // 00:59, 19 February 2010 (UTC)
 * As I stated here, if this proposal gets enacted, only users who become crats after this should have it. Not current crats by default.  If current crats want it, some other method should be used.--Rockfang (talk) 20:06, 20 February 2010 (UTC)
 * So... all the bureaucrats would have the technical ability to remove flags, but none of them would be allowed to do so? Sounds like all the current 'crats would have to be reconfirmed. EVula // talk // &#9775;  // 19:42, 2 March 2010 (UTC)
 * Regarding your question, is there any technical way to only give this ability to new crats? If not, there should be if it is feasible.  If there is no feasible way to do that, I don't think a whole new RfB would be needed.  Honestly though, I can't think of a suitable alternative method.--Rockfang (talk) 23:04, 2 March 2010 (UTC)
 * Not without the creation of a new user group that only has the "remove rights" permission. Tito xd (?!? - cool stuff) 07:08, 12 March 2010 (UTC)

Policy proposal
As Nihonjoe suggests, it seems there is considerable call for a clear policy on this issue. Copied from User:Nihonjoe/Desysopping:

Bureaucrats may remove the administrator or bureaucrat rights from an editor in the following specific instances: Should a community desysopping process receive consensus and be implemented as a policy or accepted procedure, these rights may be removed from an editor according to the consensus reached in such a discussion. I've tweaked it a little, consolidating the two ArbCom clauses into one that covers all Committee business. I think that this section should in fact be added to Administrators, which is already policy; this is in keeping with other bureaucrat policies being spread around other policy pages rather than centralised at WP:Bureaucrats, which is not currently policy or guideline. Thoughts? Happy ‑ melon 10:41, 17 February 2010 (UTC)
 * 1) An administrator or bureaucrat makes a request on the Bureaucrat noticeboard to have their own right(s) removed.
 * 2) The Arbitration Committee makes a formal request on the Bureaucrat noticeboard in the course of the Committee's operations, including final remedies to Arbitration Cases, and temporary removal of rights according to approved Committee procedures.
 * Evidently I oppose this, as per above, I don't think this has consensus - not by a long shot.  Ryan Postlethwaite See the mess I've created or let's have banter 10:45, 17 February 2010 (UTC)
 * I second this. There is no consensus. Ruslik_ Zero 19:37, 17 February 2010 (UTC)
 * Agreed, there are several crats who I would want to not be crats if crats had this ability; and there wasn't any consensus for this at the last few discussions. &mdash; Coffee //  have a cup  //  ark  // 00:57, 19 February 2010 (UTC)

At a first view, I can't see a ready way this would get abused. Under #1 a user must make a self-request, which they do already at meta; not abusable. At #2 Arbcom must make a request which they already can and do at Meta. Unless someone is suggesting a bureaucrat might unflag people out of process, which seems extremely unlikely (given the user themselves must ask or a formal Arbcom request must be made). Can someone sum up what the actual risk is that's objected to? FT2 (Talk 21:55, 24 February 2010 (UTC)
 * I agree, and I'm inclined to remove the bit about CDA, as it seems to be like fusion and FlaggedRevs: always the same distance down the line. We should stick to the areas that are genuinely uncontroversial.  Happy ‑ melon  22:53, 24 February 2010 (UTC)

I don't see why giving bureaucrats the technical ability to remove these bits, accompanied by a small bit of policy saying that they do so only on personal request by the editor concerned, or on the basis of Arbcom requests, is at all controversial. Given this policy - which I see no reason why it should change - no additional decision-making is being required. It is a trivial extension of housekeeping ability which keeps user rights logs on enwiki. Rd232 talk 18:46, 2 March 2010 (UTC)
 * Except that user right log will not be kept on enwiki. :) Ruslik_ Zero 19:32, 2 March 2010 (UTC)
 * Sorry, what?? That is exactly what will happen. Your comment makes, as far as I can tell, no sense.  Happy ‑ melon  23:02, 2 March 2010 (UTC)


 * Yeah, there are some bureaucrats that are totally unqualified to remove someone's bit when they ask for it to be removed. *sigh* EVula // talk // &#9775;  // 19:40, 2 March 2010 (UTC)
 * Yes, it requires someone eminently qualified, with years of training and multiple grueling exams, to be able to click a mouse twice. I get pale just thinking about it. *faints* ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 00:46, 10 March 2010 (UTC)
 * Wait, you guys get to use your mouse? Useight (talk) 00:57, 10 March 2010 (UTC)
 * Well, being the touchy-feely kind of guy I am, I use a touch pad or an Intuos tablet. I very rarely use mice. ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 06:25, 10 March 2010 (UTC)

This is the second take:

Bureaucrats may remove administrator or bureaucrat rights from an account in the following specific instances: Essentially just removing the CDA stuff, as it's clear that that's still a long way down the line, if ever. Happy ‑ melon 23:07, 2 March 2010 (UTC)
 * 1) An administrator or bureaucrat makes a request on the Bureaucrat noticeboard to have their own right(s) removed.
 * 2) The Arbitration Committee makes a formal request on the Bureaucrat noticeboard in the course of the Committee's operations, including final remedies to Arbitration Cases, and temporary removal of rights according to approved Committee procedures.


 * Support. Keeps user rights log on enwiki; does not require new decision-making by bureaucrats - it's mere housekeeping. Rd232 talk 23:12, 2 March 2010 (UTC)
 * Oppose. Nothing whatsoever wrong with the current process. Stifle (talk) 20:06, 6 March 2010 (UTC)
 * Support; the stewards have always been responsive, but I admit that having our own logs centralized is appealing. &mdash; Coren (talk) 20:09, 6 March 2010 (UTC)
 * Oppose. Per Stifle. Ruslik_ Zero 20:19, 6 March 2010 (UTC)
 * Strong support.[typo fixed] 'Crats should also be allowed to fix their own mistakes of giving the admin or 'crat flags to a user. I believe that this will give us 2 major advantages - 'crats can fix their own mistakes immediately; and everything will be in a single log. עוד מישהו Od Mishehu 09:17, 9 March 2010 (UTC)
 * String support? Does it mean a support with strings attached? :) Now a more serious question. How many mistakes have crats made since this position was created on 17 February 2004? Ruslik_ Zero  15:59, 9 March 2010 (UTC)
 * Since this implementation doesn't endorse bureaucrats correcting mistakes, the answer (about a dozen including tests and other non-legitimate promotions) is not really relevant. I agree that correcting mistakes is a much less important justification than the consolidation of the rights log, which at 900 entries and climbing is a serious problem that we definitely want to stop getting any worse.   Happy ‑ melon  20:56, 9 March 2010 (UTC)
 * Well, everybody knows strings give very little support. :-) &mdash; Coren (talk) 00:37, 10 March 2010 (UTC)
 * (ec) Support in order to keep all the logs in one place. I obviously support the other version as well if 'crats are ever given the rights to desysop. ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 00:43, 10 March 2010 (UTC)
 * Oppose - If the current system works... why fix it? Not only are there are several crats who I don't trust or want to have this... I also think that this just furthers the illusion that the crat flag is some esteemed super-sysop role... which it isn't (in case you were wondering). &mdash; Coffee //  have a cup  //  ark  // 03:35, 10 March 2010 (UTC)
 * I'm just curious since you seem to be beating this drum so much. Please point me to one 'crat (including myself) who would use this ability in a way not consistent with policy. I don't know of even one instance where a 'crat used any of the three "powers" they have in a manner inconsistent with policy. ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 04:12, 10 March 2010 (UTC)
 * I don't see a need to name names unless this proposal comes to fruition. &mdash; Coffee //  have a cup  //  ark  // 05:47, 10 March 2010 (UTC)
 * Well, that makes it a little hard to address your concerns, doesn't it? If you have issues, you are welcome to email me and I'll see what I can do to address the concerns (or maybe offer suggestions on how to get them addressed in a productive manner). ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 06:24, 10 March 2010 (UTC)
 * I didn't ask for you or anyone else to address my concerns in any way other than this not becoming policy. &mdash; <big style="color:#ffa439">Coffee //  have a cup  //  ark  // 06:57, 10 March 2010 (UTC)
 * You don't have to ask for someone to offer to help. The offer stands whether you want to accept it or not. ··· 日本穣 ? · 投稿  · Talk to Nihonjoe 09:41, 10 March 2010 (UTC)
 * Oppose I see no need for this and several of the crats are not cut out for this button. Spartaz Humbug! 03:44, 10 March 2010 (UTC)
 * I'm confused by this sentiment. Any bureaucrats who we do not trust to follow the proposed very straightforward policy (no decision-making requirement, purely a mop function) should have the bit removed immediately. And any that we do trust but that one day go nuts and end up acting contrary to the policy would surely lose the bit very quickly. I'd understand if there was any decision-making involved - but there isn't. Rd232 talk 10:00, 10 March 2010 (UTC)
 * You never heard of instruction creep? Spartaz Humbug! 04:54, 13 March 2010 (UTC)
 * Only every time a policy proposal is made. "Let's learn to make fire! - Nah, sounds CREEPy to me, let's stick with eating raw food." Rd232 talk 21:52, 20 March 2010 (UTC)
 * Support Nothing whatsoever wrong with the proposed process. Shubinator (talk) 04:43, 13 March 2010 (UTC)