RfC: Should bureaucrats be allowed to uncheck the sysop and bureaucrat bit when instructed?[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.
Despite gathering some support, consensus has not been achieved for this proposal. Discussion closed. SilkTork *YES! 19:39, 13 February 2010 (UTC)[reply]
I think I may have erred in looking at this. I was looking at the oppose votes as mostly ivotes with little rationale, and the oppose comments as carrying more justification, and then I did a quick calculation in which I took the oppose votes away from the support and that left 38 which I then held up against the 65 support votes instead of the total participating - 94. I'll look again. SilkTork *YES! 13:43, 14 February 2010 (UTC)[reply]
Given the numerical support for 'crats being able to turn off as well as turn on the admin bit, and looking at the additional comments at Wikipedia_talk:Requests_for_adminship/Archive_194#Unchecking_the_box, there does seem to be both support and justification to take this forward. Given the concerns raised about the possibility of a rogue 'crat turning off all the admins, and also that existing 'crats were not elected under the understanding that they had the power to turn off admins, it would seem appropriate to have a checks and balances discussion on the implications of this proposal. A new discussion, widely advertised, and linking to this and the original discussion, to look into mechanics of the proposal should now take place. SilkTork *YES! 14:03, 14 February 2010 (UTC)[reply]


Per the discussion here WT:RFA#Unchecking the box, is there consensus to allow bureaucrats to manually uncheck the sysop/crat bit when instructed per policy (currently by ArbCom, uncontroversial [not under a "cloud"] request by admin or crat to remove their own bit, in emergency desysop situations that would normally require a steward, and potentially in cases of WP:CDA (should that be implemented at a future date))? -- Avi (talk) 08:34, 10 January 2010 (UTC)[reply]

Support[edit]

  1. Best to keep things local if possible. –Juliancolton | Talk 15:10, 10 January 2010 (UTC)[reply]
  2. As long as "incontroversial" is defined, then definitely I think this is an excellent suggestion. If local 'crats can flick the switch on when they have judged concensus has shown it to be desired, I think they should be able to flick it off if concensus in a community discussion (or as instructed by Arbcom) shows it is desired. -- PhantomSteve/talk|contribs\ 15:19, 10 January 2010 (UTC)[reply]
    It would be defined as it is now "not under a cloud". -- Avi (talk) 15:28, 10 January 2010 (UTC)[reply]
    Thanks for clarifying that, Avi (and adding it to the proposal above for clarity). -- PhantomSteve/talk|contribs\ 15:42, 10 January 2010 (UTC)[reply]
    Re-confirming my support, following the clarification of the CDA situation. (Note that I have italicised the CDA part, emphasising that this is not under discussion here, and it is only a potential possibility in the future) -- PhantomSteve/talk|contribs\ 13:43, 11 January 2010 (UTC)[reply]
  3. Yep. Per JC. Pmlineditor ∞ 15:29, 10 January 2010 (UTC)[reply]
  4. I don't see why they should only be able to make the change one way. This is a quite separate discussion from the perennial "community de-sysop" debate. Guy (Help!) 15:41, 10 January 2010 (UTC)[reply]
  5. Yes. If crats can hand out the admin bit, they should also be able to remove it - there's no reason for it to be a one-way process. As we're limiting the use of this proposed ability to uncontroversial cases, I don't see any problems with it. Robofish (talk) 16:05, 10 January 2010 (UTC)[reply]
  6. Of course. If they can be trusted to give it out, then why not to perform the removal which has a much lower potential for harm. Jim Miller See me | Touch me 16:19, 10 January 2010 (UTC)[reply]
  7. Seems only the logical wiki-way: If you can add something, you should be able to remove it again. And as JzG says above, it's separate from why they should be able to do so. This discussion is only about the "whether" they should be able to do so when desysopping, for whatever reason, is needed. The only reason one could oppose it is that a rogue crat might run amok and desysop all admins or desysop anyone they like but that same risk exists with stewards. But even such actions could be swiftly reverted, so the slight risks involved (which are involved everytime someone is granted any rights) are minimal. Regards SoWhy 16:21, 10 January 2010 (UTC)[reply]
  8. (edit conflict × 2) Absolutely. There is no reason for them to be only able to go one way. People say that if they abuse it and remove all admin bits, we'll be in a deep hole. However, they're already trusted not to sysop people without an RfA. In my opinion, being able to sysop everyone is much more dangerous than being able to desysop someone. This proposal just makes sense. (X! · talk)  · @727  ·  16:26, 10 January 2010 (UTC)[reply]
  9. It's really very simple—if we trust someone to give the bit, we should trust them to take it away again. As Jim Miller said, this has a much lower risk than simply becoming a bureaucrat. Ideally, I'd like this to be combined with a process for actually taking away the bit, rather than on an one-off basis. Regards, --—Cyclonenim | Chat  16:27, 10 January 2010 (UTC)[reply]
  10. This is a no-brainer. Friday (talk) 16:28, 10 January 2010 (UTC)[reply]
  11. Clearly sensible. I would also trust bureaucrats to add and remove oversight and checkuser flags, when requested to do by ArbCom. — Martin (MSGJ · talk) 16:44, 10 January 2010 (UTC)[reply]
  12. Sure, much clearer to have the relevant process in our logs than meta's. The decision mechanism when to desysop is unchanged (ArbCom), just the implementation is nicer. —Кузьма討論 16:46, 10 January 2010 (UTC)[reply]
  13. I think it is commonsense that anyone wanting to give up the mop should simply be able to do so by asking a crat on this wiki, and that a crat should be able to desysop an obviously compromised account. ϢereSpielChequers 17:27, 10 January 2010 (UTC)[reply]
    Also per HappyMelon below and for implementing Arbcom decisions. ϢereSpielChequers 18:23, 11 January 2010 (UTC)[reply]
  14. Clearly a good idea for them to be able to uncheck an admin in certain circumstances - Dumelow (talk) 17:47, 10 January 2010 (UTC)[reply]
  15. Allowing our crats to flip the switch in the other direction will take load off foundation and make the action just that little more responsive.Josh Parris 18:06, 10 January 2010 (UTC)[reply]
  16. I don't see any reason why we can't keep things local. If anyone's worried about bureaucrats desysopping people for no reason at all, I'm sure any bureaucrat who did that would have their bureaucrat rights removed pretty quickly. I'm also not worried about inactive bureaucrats having the feature either: they don't use their current bureaucrat tools, and I don't think that any of them would start using them just to desysop people for fun (I don't remember admins who hadn't been active for years coming back in huge numbers when the ability to give out rollback was introduced). Acalamari 18:23, 10 January 2010 (UTC)[reply]
  17. Certainly. It's a good idea to keep these things local (as opposed to on Meta), and bureaucrats are already considered our most trustworthy users. Jim Miller hits the nail on the head: If we trust bureaucrats not to sysop without consensus, why shouldn't we trust them with the ability to desysop (which does in fact have a far lower potential for destructive effect anyway)? We don't need a community de-adminship process before granting 'crats this ability. For example, when ArbCom decides to desysop someone, why should we need a steward to flip the switch? A bureaucrat could do it. Why should an admin be required to request their own desysopping at Meta rather than simply posting at WP:BN? In my opinion, this proposal makes a lot more sense than the status quo. A Stop at Willoughby (talk) 18:25, 10 January 2010 (UTC)[reply]
  18. As per everyone, it just makes sense. There are plenty of possible scenarios, each very unlikely and not, on the whole, that horrifying. I fully trust the 'crats with this responsibility and furthermore, it seems the community is aching for it as well. A number of the de-sysop mechanisms that have been proposed at least nudge toward a larger role for bureaucrats, and the RfB bar is set so high that it's logical to give them a small tool worthy of that invested trust. This seems definitely in-line with what is desired here. ~ Amory (u • t • c) 18:41, 10 January 2010 (UTC)[reply]
  19. Yes, this really is just common sense. However, per the comment in the discussion section below, I'm not sure about letting Bureaucrats remove fellow Bureaucrats, as opposed to Administrators. --Tryptofish (talk) 18:42, 10 January 2010 (UTC)[reply]
  20. I agree with the same sentiment expressed by most (all?) above: bureaucrats are trusted to determine consensus when adding the bit (in either case—RfA or RfB), so it's a logical step for them to determine when consensus exists for the bit to be removed. I also agree that having local control over this is a good thing, especially in cases of emergency. ···日本穣? · 投稿 · Talk to Nihonjoe 19:18, 10 January 2010 (UTC)[reply]
  21. Strong Support. 'crats are trusted to determine consensus to promote; no reason to suggest they can't determine any consensus to demote. Ironholds (talk) 19:31, 10 January 2010 (UTC)[reply]
  22. As nom. To reiterate, this RfC is not discussing which situations are eligible for unchecking bits, just, when bits are supposed to be unchecked for acceptable reasons (voluntary resignation, ArbCom, etc.) who is able to actually uncheck the box. -- Avi (talk) 20:07, 10 January 2010 (UTC)[reply]
  23. Support - If bureaucrats are trusted to make administrators, they should also have to power to take the mop away. Agree with Amory that the RfB bar is set quite high for the 'crats, so this is a logical duty for them. Talk about having been vetted! Jusdafax 22:20, 10 January 2010 (UTC)[reply]
  24. It has never made sense to me that they should be. Let's take a hypothetical RfA where Crat_A passes the candidate, but that decision is challenged not by just the general community, but by other 'crats. The community disagrees with the 'crat who promoted the canddidate, and eventually the 'crat agrees that a mistake was made. As it stands now, the 'crat cannot simply remove the bit, but has to get somebody else to do it. IMO, if a 'crats decision is challenged by other crats, this would become time for a 'crat chat---during which time the candidate should NOT have the bit. But once granted, the 'crat can't remove them. Various abilities generally come with the ability to reverse the action, this makes complete sense as mistakes may occur or situations may arise requiring the reversal.---Balloonman NO! I'm Spartacus! 22:26, 10 January 2010 (UTC)[reply]
  25. Support If crats are trusted to judge consensus to promote someone to an admin, they should be able to judge consensus to demote someone from an admin as well. The Thing Editor Review 22:30, 10 January 2010 (UTC)[reply]
  26. Why not? The role receiving the extra option is the one that turns on the bit. This accords no new discretion or decision making powers. No big deal. Vassyana (talk) 22:35, 10 January 2010 (UTC)[reply]
  27. Support. Minor change to procedure that will bring a small efficiency gain. Sam Blacketer (talk) 23:39, 10 January 2010 (UTC)[reply]
  28. Makes desysopping local; less chance of a steward doing an action which he is ill-informed about. More transparency. —Dark 23:56, 10 January 2010 (UTC)[reply]
  29. Better log system if we kept it local, and a one-way "flip of the switch" doesn't make much sense. It seems like the logical choice to enable this. Killiondude (talk) 00:21, 11 January 2010 (UTC)[reply]
  30. Seems sensible. Cirt (talk) 00:26, 11 January 2010 (UTC)[reply]
  31. Support I have believed this for a long time. Icewedge (talk) 00:42, 11 January 2010 (UTC)[reply]
  32. Keep it local. I said it at CDA, and I'll say it again: 'crats are elected to judge RfX consensus and grant the +sysop and +crat flags. Let's give them a job they were basically meant to perform. JamieS93 01:19, 11 January 2010 (UTC)[reply]
  33. I've never understood why the bureaucrat toolbox has lacked this ability. I've also been a pretty vocal advocate for there eventually being a community-mandated system in place for removing administrators, and as I consider such a process to be in the (eventual) purview of the bureaucrats, it makes sense for them to have that ability. EVula // talk // ☯ // 01:20, 11 January 2010 (UTC)[reply]
  34. Hell yes. However, the unchecking should only be limited to administrators. ConCompS talk review 02:54, 11 January 2010 (UTC)[reply]
  35. Support. Eliminate unnecessary red tape – more power to the bureaucrats! —what a crazy random happenstance 05:05, 11 January 2010 (UTC)[reply]
  36. Support. If we trust them to grant the bit, we can trust them to remove it as well. Jafeluv (talk) 08:01, 11 January 2010 (UTC)[reply]
  37. Andrevan@ 08:36, 11 January 2010 (UTC)[reply]
  38. --Conti|✉ 08:56, 11 January 2010 (UTC)[reply]
  39. Yes, it would be ideal. Tony (talk) 11:22, 11 January 2010 (UTC)[reply]
  40. Makes abundant sense to me, though it does seem mildly amusing that in order to avert unecessary bureaucracy (having to send de-sysop requests to stewards) we would grant an additional power to bureaucrats :) Shereth 14:39, 11 January 2010 (UTC)[reply]
  41. Cleaner and more rational to keep enwiki stuff on enwiki whenever possible. Mike.lifeguard's assurance (in discussion section below) that in extremis stewards will still do an emergency desysop addresses the only minor concern I had. --Floquenbeam (talk) 15:16, 11 January 2010 (UTC)[reply]
  42. Support - As per last time. I think we should keep things local but I'm sure stewards would still take action in the event of an emergency with a rogue admin. This will also become even more useful if community de-adminship is ever approved. Camaron · Christopher · talk 15:41, 11 January 2010 (UTC)[reply]
    Support -if only to make the rights log make sense for desysopped admins. I would revisit this for deeper consideration if a technical change made the desysopping done at meta reflected in the local rights log. –xenotalk 16:44, 11 January 2010 (UTC) Striking support as some have pointed out that this (rights being removed both here and at meta) might make more of a mess as opposed to less. A technical solution would be ideal. I may revisit this on its merits at a later date. –xenotalk 20:35, 11 January 2010 (UTC)[reply]
  43. Support Frankly, I thought they had this ability already, probably because it makes so much sense to be able to undo what you've done.--Fabrictramp | talk to me 19:03, 11 January 2010 (UTC)[reply]
  44. Support - we should not be relying on stewards, who by their nature may not be particularly familiar with the en-wiki community, to be our sole desysop mechanism. Obviously the methods of when a desysop is appropriate will always be under discussion, but I for one trust our local crats to be more familiar with that than the stewards are. ~ mazca talk 19:38, 11 January 2010 (UTC)[reply]
  45. I really think too much of a fuss is being made of this, but whatever. One of the basic principles of the site is that nearly anything is reversible. Because bureaucrats were elected based on the community's trust in their ability to judge consensus, I would have no issue with them judging consensus at a Request for de-Adminship. And come on, let's face it. How likely is it that we are going to get a rogue bureaucrat? I suppose it is theoretically possible to create a Von Neumann machine of bureaucrats, but there are already so many more ways of causing damage with just the administrator tools. A bureaucrat with the ability to desysop people is no more (and in fact far less) dangerous than a steward. NW (Talk) 20:28, 11 January 2010 (UTC)[reply]
  46. Ucucha 20:36, 11 January 2010 (UTC) Although MBisanz makes some valid points, I believe too many of the arguments against are really arguments from inertia, or attempts to rationalize what is no more than a historic accident. We trust the bureaucrats to promote and rename users in accordance with policy, we should also trust them to demote users in accordance with policy. Ucucha 20:36, 11 January 2010 (UTC)[reply]
  47. Obviously - they should be able to undo if needed to. It makes no sense that it is the only irreversable thing. That's the problem, not that there needs to be a problem to try new ideas. Majorly talk 23:49, 11 January 2010 (UTC)[reply]
  48. Support. Everyking (talk) 00:06, 12 January 2010 (UTC)[reply]
  49. Support It makes sense to be able to undo pressing a button you can push. Bradjamesbrown (talk) 00:14, 12 January 2010 (UTC)[reply]
  50. Support States Rights for Software! @harej 00:58, 12 January 2010 (UTC)[reply]
  51. Support I agree it would be beneficial for an additional pool, to act expeditiously when and if required. Ohconfucius ¡digame! 09:03, 12 January 2010 (UTC)[reply]
  52. Support This seems like a good (and obvious) idea. The recent farrago where it took forever to get the bit taken from Cremepuff at the point where everyone thought the account was compromised is one reason, keeping the records in one place is another.Elen of the Roads (talk) 15:23, 12 January 2010 (UTC)[reply]
  53. Support 'crats should be technically able to desysop. They shouldn't do so unless prescribed to, of course.--Unionhawk Talk E-mail 16:56, 12 January 2010 (UTC)[reply]
  54. Support, per logic put forth by Cyclonenim. Greg L (talk) 01:29, 13 January 2010 (UTC)[reply]
  55. Support I would prefer as fast a response as possible if a crat or admin goes rogue. Of course there's the reverse possibility that a rogue crat can decrat and desysop others, but I think that the former would be more damaging than the latter. Plus if they can give crat or sysop status they should be able to take it away, of course with orders to do so. The crat giveth the crat taketh away. Valley2city‽ 02:32, 14 January 2010 (UTC)[reply]
  56. Support. My only fear is that RFB will be much harder to pass from now on. Users, especially those careless crats, do have the tendency to go rogue after all. bibliomaniac15 04:53, 14 January 2010 (UTC)[reply]
  57. String support. We do need to have strict guidelines for when this can be used (instructions by ArbCom, fixing one's own mistake, and request by user being desysoped/decratted, etc). עוד מישהו Od Mishehu 09:32, 14 January 2010 (UTC)[reply]
  58. Strong support This really isn't a big deal. It should have always been this way. Gigs (talk) 20:05, 15 January 2010 (UTC)[reply]
  59. Support. If we trust crats to not grant +sysop or +crat without prior approval, then we can trust them not to remove them either. King of ♥ ♦ ♣ ♠ 07:58, 16 January 2010 (UTC)[reply]
  60. Support Per JC. LouriePieterse 18:31, 18 January 2010 (UTC)[reply]
  61. Support as per "if they can be trusted to do so & so why not this?", plus additional controls over potentially uppity admin/crats isn't such a bad idea. Semitransgenic (talk) 18:44, 25 January 2010 (UTC)[reply]
  62. Support Christian List (talk) 02:32, 28 January 2010 (UTC)[reply]
  63. Support We trust them to gauge consensus, and we can trust them with this tool. hmwith☮ 21:21, 8 February 2010 (UTC)[reply]
  64. Support but per WJBscribe's concerns, only if bureaucrats automatically loose their privilege on extended inactivity. --SmokeyJoe (talk) 02:23, 9 February 2010 (UTC)[reply]
  65. Strong support. They ought to. Kayau Don't be too CNN I'LL DO MY JOB uprising! uprising! 09:56, 12 February 2010 (UTC)[reply]

Oppose[edit]

  1. There is no current community process that would require bureaucrats (or anyone) to "uncheck the box" on adminship. I think that enabling the technical ability for crats to desysop should be a follow-up step to the creation of such a process. Additionally, bureaucrats have not been selected for any tasks aside from those they already perform. The type of scrutiny applied to candidates when the ability to desysop is at stake is likely to be quite different than what they currently undergo, and I'm not sure we necessarily want to grant this right to all bureaucrats (particularly those who were selected 5 or more years ago). There will be a time to re-evaluate the role of a bureaucrat with respect to any desysopping process; it will be after such a process is developed or even approaches consensus. I am generally opposed to granting bureaucrats expansive new roles, particularly in dispute resolution and in controversial processes, and I don't see a convincing argument here to change my position. Nathan T 16:18, 10 January 2010 (UTC)[reply]
    To address the "emergency/voluntary" situations directly: has there been a problem with such requests through stewards in the past? I'm not aware of any situation where a delay encountered by the inability to reach a steward caused any significant problems in this project. Nathan T 16:20, 10 January 2010 (UTC)[reply]
    I do think that if there is a crat who desysops without consensus, they will be quickly decratted themselves. These crats were chosen to judge consensus fairly, and desysopping fits into the category of consensus-judging as sysopping. (X! · talk)  · @727  ·  16:26, 10 January 2010 (UTC)[reply]
    Add to my oppose the issue about the logs: many supporters have argued that this change will unify rights logs and make them easier to read. In my view, the current log arrangement is simple - all sysops are local, all desysops are at meta. In this new arrangement, some desysops will be at meta, some local, and a search for rights changes will often require checking both places. That doesn't seem like a benefit to me. Nathan T 15:10, 12 January 2010 (UTC)[reply]
  2. Desysopping is not currently based on community consensus (nor should it be), so there it is not relevant to the current or historical purview of bureaucrats. Chick Bowen 19:04, 10 January 2010 (UTC)[reply]
    This proposal has no bearing on community desysopping. –Juliancolton | Talk 21:05, 10 January 2010 (UTC)[reply]
    Then why does it mentioned it in the header?????? --Hammersoft (talk) 21:11, 10 January 2010 (UTC)[reply]
    Huh? I don't think you understand. Stewards already routinely do desysops as instructed by ArbCom or the user's request. This proposal doesn't change when we do desysops, but rather how we preform them. –Juliancolton | Talk 21:15, 10 January 2010 (UTC)[reply]
    The position of supporters is that it has no bearing. I disagree with that position; there is no misunderstanding. They are intrinsically related, whether or not one is strictly dependent on the other. To put it a different way, I do not believe we would be having this discussion if it weren't for CDA. Chick Bowen 22:12, 10 January 2010 (UTC)[reply]
    Also, Hammersoft's point is quite correct: CDA is mentioned at the top of this page, so it's a little strange to claim that there's no relationship between the two. Chick Bowen 00:12, 11 January 2010 (UTC)[reply]
    It is mentioned in as much that if it is implemented, then once the decision is made by whatever process CDA decides upon a crat can flip the bit instead of a steward. Antecedents and consequents. It is there for completeness, because it is in current discussion, but in no way shape or form does THIS proposal allow a crat to "make a decision". Even if CDA is approved, it is still not clear WHO makes the decision. This is solely about who can check and uncheck a box. -- Avi (talk) 00:20, 11 January 2010 (UTC)[reply]
    I think your supporters are confused about that. For example, in #20, Joe says, "it's a logical step for them to determine when consensus exists for the bit to be removed," and in #21, Ironholds says, "'crats are trusted to determine consensus to promote; no reason to suggest they can't determine any consensus to demote." Their rationales suggest that they are indeed imagining bureaucrats determining consensus, not just flipping the metaphorical switch. I believe you that this was not your intention, but I'm not sure it was as clear as it might be. Chick Bowen 00:27, 11 January 2010 (UTC)[reply]
    I think that it's a natural jump to make (one I myself made in my comment), but that doesn't change the fact that this proposal is about the 'crats being able to uncheck a box (and only that). There's a relationship, yes, but not necessarily a direct cause-and-effect between the two proposals. We can have a community-dictated de-adminship system without 'crats unchecking the box, it's just more convenient if they can uncheck, just like we can have 'crats capable of removing bits upon request without having a CDA. EVula // talk // ☯ // 01:26, 11 January 2010 (UTC)[reply]
    I thought it was clear in the description (as did others, see the talk) and I added a clarification nutshell. Other than renting a megaphone, I'm not sure what else I can do 8-). Any ideas? -- Avi (talk) 00:35, 11 January 2010 (UTC)[reply]
    So what are you suggesting, that bureaucrats should only desysop if the CDA being closed is 100% in favor of desysop???? Come on. This proposal IS linked to CDA. You can't tell me we're not going to have bureaucrats making the decisions at CDA. Unless you intend on creating an entirely NEW class of users who are responsible for determining consensus at CDA. That's not going to happen and you know it. No sense in creating a new class when we already have a class that does the same thing (if in reverse). --Hammersoft (talk) 01:26, 11 January 2010 (UTC)[reply]
    No, that when somoene comes to voluntarily relinquish the bit, they do not have to go to meta to get it turned off, but can come to WP:BN the same way they do to get it back (uncontroverisal, of course). When ArbCom decides that such-and-such user needs to be desysopped based on an RFaR, they can ask a local crat instead having to go to Meta. It's rather clear, actually. -- Avi (talk) 01:33, 11 January 2010 (UTC)[reply]
    And has asking a non-local person ever been a problem? Doesn't seem so. Has going to meta to turn off your bit ever been a problem before? I don't recall any incidents. What problem is this supposed to solve that is currently hampering the project? In a word, nothing. That's what. And I'm sorry, I find it odd that a user here with virtually every bit is asking for yet another power to add to his cap. That bothers me. --Hammersoft (talk) 01:41, 11 January 2010 (UTC)[reply]
    You don't happen to know User:JayHenry do you? . I'm sorry you have a personal issue with me, and, if you can find any instance where I abused any privileges, please let both me and the WP:AUSC know, for everyone's sakes. -- Avi (talk) 01:45, 11 January 2010 (UTC)[reply]
    I personally don't care what subordinate-to-me hats you've decided to put on your head. Back to the point, what incidents have happened that this us supposed to solve? --Hammersoft (talk) 01:48, 11 January 2010 (UTC)[reply]
    Responded below at #What problem is this supposed to solve? -- Avi (talk) 01:49, 11 January 2010 (UTC)[reply]
  3. Oppose Solution looking for a problem. First WP:CDA has not achieved acceptance (nor is it likely to), so there won't be some sudden flood of de-adminship requests. Second, ArbCom is well capable of de-adminning someone, and once requested it's not something that needs rapid resolution. Third, the need of a steward's presence to emergency desysop someone has always been met rapidly. The supporters of this should at least show one case where the project was damaged because a rogue admin wasn't removed in a timely manner. Fourth It's already damned difficult to become a bureaucrat. Adding another privilege to the mix is going to make it impossible. --Hammersoft (talk) 20:18, 10 January 2010 (UTC)[reply]
    I believe you are misunderstanding this proposal. This proposal adds no new judgement to desysop someone. Just whenever we would ask a steward to to remove a bit, we can now ask a 'crat. -- Avi (talk) 21:44, 10 January 2010 (UTC)[reply]
    I am misunderstanding nothing. CDA is mentioned in the intro to this proposal. I am not making a mistake. If I am, then you should be addressing the person who formed this RfC, namely yourself, not I. --Hammersoft (talk) 01:26, 11 January 2010 (UTC)[reply]
    See above where I answered you, and yes, you somehow missed the antecedent of the hypothetical syllogism. I've said this a bunch of times on this board already, but for you I'll say it again. IF CDA ever comes around and should it do, IF whatever decision process be accepted in the proposal actually happen (be it a community vote, an RfAR, or the collected writings of a thousand monkeys) ONCE the decision is made by WHATEVER process is decided upon to be valid, THEN you can go to a crat and not a steward. Most often, this will deal with the requests we get at WP:BN for people who want to take a vacation from their bits that right now we have to send to the stewards. -- Avi (talk) 01:33, 11 January 2010 (UTC)[reply]
    We are NOT going to be creating an entirely new class of user to decide CDA. It will be up to bureaucrats. --Hammersoft (talk) 01:41, 11 January 2010 (UTC)[reply]
    That is still up for discussion and completely independent of this. If this fails and that passes, the crats will decide and then contact a steward. If that fails and this passes, arbcom/voluntary/emergency are still the only desysoping procedures but a 'crat could flip the bit. -- Avi (talk) 01:43, 11 January 2010 (UTC)[reply]
    And if they both pass then bureaucrats will be making that call. Sorry, ice this proposal until CDA gets done. Now. For the good of the project. --Hammersoft (talk) 01:46, 11 January 2010 (UTC)[reply]
    I find the argument that this proposal needs to be put on hold until CDA "gets done" to be just as uncompelling as you find this proposal. This proposal very clearly restricts the opportunities that the bureaucrats can remove someone's flag (emergency, mistake, or request [self-request or ArbCom mandate], which are the exact same restrictions that the stewards have). If CDA is accepted by the community, we'll be adding a fourth item to the list of flag removal criteria, but it can exist just fine with the existing three. EVula // talk // ☯ // 01:54, 11 January 2010 (UTC)[reply]
    We don't know what CDA will result in. It is blatantly obvious that this proposal and that are tied together. Far better to do this in serial than parallel, so we know what we are getting ourselves into. --Hammersoft (talk) 02:06, 11 January 2010 (UTC)[reply]
    I really fail to see how that's relevant to this proposal. You're arguing that the bureaucrats may not be the ones to close a future CDA system. Alright, that's fine; perhaps a different group will. What does that have to do with allowing bureaucrats to undo mistakes, or to be the ones to make userright changes locally when the editor in question requests it, or why bureaucrats can't be the ones to execute ArbCom flag-removal dictations? EVula // talk // ☯ // 02:17, 11 January 2010 (UTC)[reply]
  4. Oppose We did not elect 'crats to do this. The discussion at Neutral #1 also convinces me it is a bad idea.--Wehwalt (talk) 02:41, 11 January 2010 (UTC)[reply]
  5. Oppose—those who were made bureaucrats due to trust by the community actually only received trust to make admins. Are we sure that every single one of them also has community trust to remove admins? I don't think so. Would reconfirming every 'crat be a huge waste of time? Yes. Also, this is a solution looking for a problem (as was said above): can anyone point to a specific case where local-desysopping would have provided any advantage at all? ╟─TreasuryTag►cabinet─╢ 10:23, 11 January 2010 (UTC)[reply]
    Why would there be an additional level of trust needed to desysop an admin? It is by far the less damaging of the two. —Dark 11:50, 11 January 2010 (UTC)[reply]
    RfB may very well be more rigorous than the presidential election. I'd say they're trusted to unchecked the same button then checked in the first place. –Juliancolton | Talk 14:28, 11 January 2010 (UTC)[reply]
    In every case of desysopping, it would be preferable to have a local log keeping track of it. As it is, the logs are split between meta and enwiki, which makes them less useful and more cumbersome to review. This is the biggest benefit, IMO. ···日本穣? · 投稿 · Talk to Nihonjoe 15:22, 11 January 2010 (UTC)[reply]
    I posted my thoughts to the "what problem does this solve?" question at #What problem is this supposed to solve?. EVula // talk // ☯ // 17:41, 11 January 2010 (UTC)[reply]
  6. Oppose - it strikes me as a security risk. Currently a compromised Bureaucrat account could create a lot of admins (which could cause some problems), but with this extra power, a compromised account could remove a lot of admins (presumably fairly easily, I don't know what the interface looks like). Unless there's a problem with the work load for stewards that this is meant to solve, it seems to me that the costs outweigh the benefits. Guettarda (talk) 17:50, 11 January 2010 (UTC)[reply]
    The interface is checkbox, the way every userrright is. -- Avi (talk) 17:53, 11 January 2010 (UTC)[reply]
    How many rogue admin accounts have there been, ever? How many rogue bureaucrat accounts have there been, ever? How is there a higher chance for a compromised bureaucrat account than a compromised steward account? (a rogue steward would be far, far more damaging) The idea of a rogue 'crat is always hauled out of the dungeon of wiki-fears whenever this gets mentioned, yet I've never heard any actual rationale for why this would ever likely happen. EVula // talk // ☯ // 17:55, 11 January 2010 (UTC)[reply]
    It could be a problem, but it wouldn't be a new one; as you say, a compromised steward account always has been and probably always will be far more dangerous. Would throttling Special:Userrights to non-bot speeds be helpful? – Luna Santin (talk) 00:39, 12 January 2010 (UTC)[reply]
    I think that would be a fantastic compromise to ensure that the damage done by a rogue bureaucrat (which I still consider unlikely) would be even further minimized. (though that would, in turn, mean that stewards should still be on-hand for emergency de-sysopping, as a 'crat arriving on the scene could potentially find himself hitting that throttle, although it's unlikely) EVula // talk // ☯ // 01:03, 12 January 2010 (UTC)[reply]
    You can see what the interface looks like and play around with it at Special:UserRights/MBisanzBot. MBisanz talk 17:57, 11 January 2010 (UTC)[reply]
  7. oppose per Guettarda and Nathan. No good policy reason to do this, serious security risks and it isn't like this is a substantial workload that is going to be moved over this way. JoshuaZ (talk) 19:21, 11 January 2010 (UTC)[reply]
  8. Oppose As I understand this is another solution in a search of a problem. It was mentioned by some that it can solve the problem with logs. I think this is a bizarre suggestion, because it can only make the log mess much worse. Now all +bits are in the local log, while -bits are in the global one. As a result of this proposal some desysopings will be recorded in the local log, while other in the global (stewards will continue to desysop in some cases). So anyone who wants to know when and by whom an admin 'A' was desysoped would need to check two logs instead of just one now! I think the desire of some bureaucrats to obtain a new powerful userright can lead to a lot of problems. By the way why the previous proposal is not mentioned anywhere? It would be very useful for everybody to re-read it. The present discussion seems to be just a repetition of past one. In fact no new arguments have been made so far. Ruslik_Zero 20:21, 11 January 2010 (UTC)[reply]
    Simple and Meta have their crats doing the removal so there is no "clean" log for all of wikimedia. Furthermore, in an emergency desysop, the steward could just grant themselves the 'crat bit and keep the log on EnWiki, the same way they do emergency OS and CU now. -- Avi (talk) 22:51, 11 January 2010 (UTC)[reply]
    I do not know why simple and meta decided to go that way, but this is irrelevant for this discussion. As to the temporally assigning to themselves the crat's bit before desysosping, I would say that this (a) is impractical in an emergency when a permission should be removed as quickly as possible (b) will create additional workload on stewards thus undermining one of the arguments in favor of this proposal (c) is not allowed by the current policy because stewards are not permitted to suddenly become bureaucrats here (d) will confuse local uses who might think that the acting steward is a bureaucrat. Ruslik_Zero 14:33, 12 January 2010 (UTC)[reply]
  9. Oppose: There's been no compelling explanation provided here demonstrating any kind of problem that requires solving. And, to the contrary, I think the current system of having an impartial person doing the task of de-adminning is a very good idea. De-adminnings are pretty rare. The process for requesting de-adminship (i.e., going to Meta) is fairly standardized among the 700+ wikis and is common knowledge for most admins. Changing it needlessly here hasn't been justified for a number of reasons. The feigned fear of split logs is also a non-starter. The logs are currently fairly consistent. Adminnings are local; de-adminnings are at Meta. Implementing this will only make more of a mess of the logs. How is that a benefit? The stewards are generally available at the same rate as bureaucrats, if not faster—and most of these de-adminnings aren't particular time sensitive anyway. Finally, from reading this page, it seems pretty clear that this is a thinly-veiled attempt to move the "community de-adminnings" process further forward, something that I don't think is particularly wise given the competency of the general Wikipedia community. --MZMcBride (talk) 20:32, 11 January 2010 (UTC)[reply]
  10. I agree with most of the above and see no reason to change anything. Also, I think we could have named this RfC in a way that actually describes what it relates to, and not some obscure title like "Bureaucrat Unchecking" (yes, I know that's technically what happens, but that's the least of what should be noticed when looking over this RfC). - Rjd0060 (talk) 21:38, 11 January 2010 (UTC)[reply]
    Au contraire, that is all what this RfC is about; people who continue to conflate this with CDA or new ways to desysop are confused and incorrect, at least as to what the intent of the proposal was. -- Avi (talk) 22:07, 11 January 2010 (UTC)[reply]
    I'd be willing to guess that most people won't read the title and think "Oh, giving crats the ability to remove rights". I think the title is inappropriate and perhaps intentionally misleading. But I'm not making a big deal about that. - Rjd0060 (talk) 23:13, 11 January 2010 (UTC)[reply]
    Exactly. I'm not saying I haven't used these tactics before myself, but there are definitely some deliberate attempts to downplay this discussion, from the page title to the notification on various noticeboards. Want to bet if I changed the section headers from "Bureaucrat Unchecking RfC" to "Proposal to allow bureaucrats to remove adminship," the opposition here would grow rapidly? --MZMcBride (talk) 23:19, 11 January 2010 (UTC)[reply]
    But that is more misleading, because that implies that 'crats can make a decision, where this proposal is solely one about flipping a bit after an exogenous determination is made. I've tried to be VERY clear about that in both the proposal and the nutshell; if people continue to misunderstand after multiple attempts to clarify, there is nothing I can do. I understand people will choose to misrepresent things for political purposes here in wiki, but reading the two statements at the top of the proposal, to continue to conflate this with CDA or to assume that this gives 'crats any more decisive power seems to take willful thought for whatever motive and there is nothing I or anyone can do about that, unfortunately. -- Avi (talk) 23:27, 11 January 2010 (UTC)[reply]
  11. I find myself in agreement with Ruslik and MZM. —Ed (talk • majestic titan) 21:41, 11 January 2010 (UTC)[reply]
  12. Oppose the_ed17 ditto. As Ruslik and MZM point out there's nothing that this solves that makes any process better or easier. Q T C 23:30, 11 January 2010 (UTC)[reply]
    Sure it does. It allows bit vacations to happen at the same place the restorations occur and keeps the logs on EnWiki. What do you believe is better about the current process, other than inertia? -- Avi (talk) 23:35, 11 January 2010 (UTC)[reply]
  13. I think the current system works well; the proposal doesn't manifest any benefits, while introducing new potential security risks. I also agree with MZM that introducing an uninvolved party is beneficial. Christopher Parham (talk) 23:34, 11 January 2010 (UTC)[reply]
    Sure it does. It allows bit vacations to happen at the same place the restorations occur and keeps the logs on EnWiki. As for uninvolved parties, the stewards who respond here most often are EnWiki contributors (Lar, Cary, Pathoschild) so that is an error as well. -- Avi (talk) 23:35, 11 January 2010 (UTC)[reply]
    Please don't tell me you're going to respond to the majority of dissenters on here individually. Sort of poor form, in my opinion (coming from somebody who supports this idea). Killiondude (talk) 23:39, 11 January 2010 (UTC)[reply]
    I didn't realize you were moving the logs to en.wiki, nor did I realize this was technically possible. I assumed that this proposal would break the log of removals up into two pieces, one on en.wiki and one on meta. Whether they are en.wiki contributors or not, their steward authority comes from a different community, which increases the degree of impartiality. Christopher Parham (talk) 14:35, 12 January 2010 (UTC)[reply]
  14. The reason that crats cannot remove rights is to mitigate a particular attack vector. — Carl (CBM · talk) 03:14, 12 January 2010 (UTC)[reply]
    Which is? Happy‑melon 12:15, 12 January 2010 (UTC)[reply]
    They could desysop many admins. Stewards are a significantly more trusted group (for example, stewards disclose their identities to the WMF, unlike local bureaucrats). The very small number of local desysopings is not enough to warrant the added security risk. In other words, there is a significant downside potential and very little benefit that I see, so I oppose the proposal. — Carl (CBM · talk) 12:44, 12 January 2010 (UTC)[reply]
    Any admin on any project can gain control of a steward or bureaucrat account. The real danger from such a compromised account is that it will then be used to create an army of socks with illegal permissions. Compared to the (disruptive but almost entirely reversible) damage that a thousand admin-vandals rampaging around the site deleting pages and unblocking each other would do, the fact that a thousand legitimate admins were desysopped in the proces is inconsequential. A well-planned attack of that form could not be stopped by on-wiki activity: the sysadmins would probably have to suspend all permissions from the affected groups until we could sort out from the top down who was supposed to have what. Certainly granting -sysop to bureaucrats does not make such an attack either more likely, or noticeably more damaging. Happy‑melon 17:01, 12 January 2010 (UTC)[reply]
    IMHO: The attack vector Carl refers to is someone going rogue, not someone gaining control of an account. Theoretically a Steward is less likely to go rogue than an en:wp 'crat, (if you consider identifying to the foundation and having support from more wikis than just en:wp as factors) although I grant that there is no way to judge whether stewards practice better account security precautions than crats so are not necessarily less likely to lose control of their account. ++Lar: t/c 02:04, 14 January 2010 (UTC)[reply]
  15. Solution looking for a problem. May also be incompatible with WMF rules. Stifle (talk) 09:31, 12 January 2010 (UTC)[reply]
    Bureaucrats having -sysop (and -crat) is the software default and is the case on wikis like meta and simplewiki. It is not in any way "incompatible with WMF rules". Happy‑melon 12:17, 12 January 2010 (UTC)[reply]
  16. No; this does not solve a problem, and obviously attempts to presuppose CDA (or shore up the proposal). I don't believe that there has ever been a problem caused by the hop to meta to request bit removal: the response time there is measured in minutes, and stewards are both careful and measured. Personally, I like having uninvolved outsiders as a buffer to bit removal and the trivial improvements of centralizing logs is most certainly not worth losing that added protection. — Coren (talk) 11:23, 12 January 2010 (UTC)[reply]
  17. Oppose. I've thought about this for a bit and whilst I think the arguments in support are valid - this is only a technical ability, the current position has arisen slightly by accident rather than design, etc - I am not comfortable with this proposal. I think it is premature to expand the scope of bureaucrats before sorting out the fact that inactive bureaucrats appointed long ago with little (if any) community input may now lack its confidence. I am not convinced that we are doing a good job of handling requests for restoration of admin rights at the moment and worry about an apparent increased willingness by crats to exercise discretion over the objection of other crats without seeking consensus. I worry about pressure being placed on crats to desysop without a community process being in place to provide for it - there are merits to the stewards' independence. At the very least, I would like to see a mechanism for the community to remove a bureaucrat who no longer has its confidence before assigning another ability that is likely to prove controversial. WJBscribe (talk) 13:18, 12 January 2010 (UTC)[reply]
  18. Oppose. There is no convincing explanation why the status quo is broken, so per the tried-and-true engineering adage, if it's not broken, don't fix it. Are there any complaints about the response speed of stewards? Usually, when an account is compromised (which is arguably the only situation I can see where it would be useful for local bureaucrats to summary desysop somebody), a steward is available within a minute or so, so I don't see any problems there. Additionally, I find myself agreeing with MZMcBride: we all know that the "desysop log" is in Meta, not here. Titoxd(?!? - cool stuff) 18:13, 12 January 2010 (UTC)[reply]
  19. Oppose Per WJBscribe above, MBisanz and Ruslik concerns below. Sole Soul (talk) 00:19, 13 January 2010 (UTC)[reply]
  20. Oppose - Although some projects allow this, I think for this project I'm not in favor. Going to Meta to ask and having to show that the request is within process seems a good check. Also, per WJBScribe, Titoxd, MZMcBride, et al. ++Lar: t/c 16:07, 13 January 2010 (UTC)[reply]
  21. Oppose - I have read most of the content below, and I still fail to see that there is a problem that requires solving; this seems to me to only be for its own sake. In addition, I dislike the bureaucrat system in general and feel that adding rights would only make it harder for people to get promoted (and it is already far too hard). I would prefer it is the general standards for 'crats were decreased, and we left this to the stewards. Ale_Jrbtalk 12:39, 14 January 2010 (UTC)[reply]
  22. Nope. No Ta the current system works well and I'm opposed to extending 'crat roles into areas in which in the incumbents were not elected to work within. Absent reelecting the whole 'crat cadre I'm not interested in this proposal. Spartaz Humbug! 14:41, 15 January 2010 (UTC)[reply]
  23. Without much compelling arguments to show flaws with the current system, this is extra buttons for the sake of extra buttons. We really don't need those dreadful ANI threads where a user proposes a desysoping (whether frivolous or not) and then a bureaucrat has to decide consensus, which is made worse when consensus could go either way. The current system, which works fine, will have abusive admins have their bits stripped in due course. Spellcast (talk) 09:33, 16 January 2010 (UTC)[reply]
    No one is proposing that a crat desysop based on an ANI thread, any more than we would make someone a sysop based on an ANI thread. There is no current involuntary community based desysop method, and this proposal wouldn't change that. Gigs (talk) 19:03, 16 January 2010 (UTC)[reply]
    The ANI threads are just a prediction of what I think may happen if this passes. ANI probably has threads every now and then about someone claiming admin abuse, so it's not unreasonable to think that someone would eventually propose a de-adminship there, which would result in long-winded discussions like a ban proposal. Spellcast (talk) 13:58, 17 January 2010 (UTC)[reply]
    Which has nothing to do with this proposal; even if a user is community banned on ANI, neither 'crat (proposed) nor steward (current) can do anything to the sysop bit without prior authorization from ArbCom, and any one who does would be brought before ArbCom (or complained to the foundation/stewards wrt stewards) very quickly. -- Avi (talk) 14:43, 17 January 2010 (UTC)[reply]
  24. Oppose I truly don't trust some of the crats enough that are currently active to remove the bit absent of their own POV on the situation, this is why we have stewards do it. --— Coffee // have a cup // ark // 04:10, 21 January 2010 (UTC)[reply]
  25. Oppose I just don't see how this is such an current issue that it needs the energy and attention of developers. Focus energies on more important things. NJA (t/c) 17:34, 21 January 2010 (UTC)[reply]
    I believe it is the matter of making a small change to a text file. -- Avi (talk) 20:18, 21 January 2010 (UTC)[reply]
  26. I oppose this with the current wording. I think this ability should only be given to crats there were promoted after (and if) this gets put into effect. I don't think I've ever commented on an RfB, but I've read some. Some people comment in RfBs based on whether or not they trust the candidate with the "tools". I think changing these tools after a person gets made a crat could be unfair to some people that commented in an RfB. I would support this if it my "suggestion" is incorporated. If anyone has a question regarding my oppose, please let me know on my talk page as I won't have this one watchlisted. Thank you.--Rockfang (talk) 07:49, 4 February 2010 (UTC)[reply]
  27. per Separation of powers. If we want to have this on en.wiki, then it should be given to those who have been elected to do this, and have identified to WMF. -Atmoz (talk) 21:06, 5 February 2010 (UTC)[reply]

Neutral[edit]

  1. See detailed explanation below. MBisanz talk 21:05, 10 January 2010 (UTC)[reply]
  2. Leaning toward WJB Scribe's well-argued oppose, but also inclined to agree with some of the supportive comments. Will continue to monitor this page and may be persuaded either way. --Dweller (talk) 13:26, 12 January 2010 (UTC)[reply]

Discussion[edit]

I think it's the same question. They are after all able to grant +crat as well so it's only logical that they should be able to de-crat as well. Regards SoWhy 18:51, 10 January 2010 (UTC)[reply]
Yeah, basically. It's not exactly a common process, so there's not too much to worry about. Besides, if de-cratting was something that ever needed to be done ASAP, we might as well have the chance for someone here to do it faster, and for nicer logs. ~ Amory (u • t • c) 19:02, 10 January 2010 (UTC)[reply]

All the comments above (in support and here) have said it better than I. In a nutshell, a 'crat can check the box on for another 'crat, after a successful RfB or a return to 'crat status after a vacation (ala WJB Scribe), so it is logical that they should be able to uncheck the box, in situations where the box needs to be unchecked (voluntary vacation, ArbCom, emergency, and, if CDA ever gets implemented, in that case too). This RfC is not about which situations get an uncheck, but given an English Wikipedia valid situation for an uncheck, who may check the box. For symmetry, efficiency, and keeping the logs here, it makes sense, in my opinion, that 'crats are able to do so. -- Avi (talk) 20:06, 10 January 2010 (UTC)#[reply]

  1. Stewards will not act if a local wiki has the ability to do something. That means if crats can deflag an admin, stewards will not do it. This is their policy and not ours, so if we approved this change, crats would become the only people capable of de-adminning. Given that the stewards already have an emergency request system in place and are positioned around the globe to give 24/7 coverage and the crats are biased towards English-speaking countries, this would result in a decrease of coverage.
  2. If someone can do something, they will. We saw how the turning on of the ability to grant rollback was done before we had a policy on granting it, and I believe this is putting the cart before the horse.
  3. While crats would in theory (at least I would) only de-flag on user request or on arbcom decision, this new capacity would put crats in the uncomfortable position of seeing a consensus to do something, but being restrained by policy from doing it. I am thinking of several user conduct RFCs and admin recalls which indicated a broad consensus that someone should resign as an admin and pair that with the moans that arbcom is a cabal refusing to desysop fellow admins quickly. The same complaints would be placed on crats who refuse to implement an RFC or admin recall decision.
  4. Stewards by their nature are impartial since they do not edit enwiki. Crats are by their nature highly involved in enwiki affairs. Desysopping, both due to the social stigma of it and the social consequences for the person performing it, seems better left to entirely uninvolved parties.
  5. Finally, I am aware of at least one crat war at meta-wiki, where a crat closed an RFB as a promotion and another crat disagreed and undid the promotion. As of now this technical feature prevents such an event from occurring and I am not certain that changing it permit such an event to possibly occur is wise.
  6. However, I do agree that the split enwiki and meta logs are annoying and that it would be better if all transactions were placed in the same log.
  7. Additionally, I agree it makes sense that things on the wiki should be able to be undone by the person performing them.
But, I also think that crats should not be seen as aggrandizing more power, even technical, to themselves, so that is why I am neutral on the proposal. MBisanz talk 21:04, 10 January 2010 (UTC)[reply]
Re (1), the hundreds of suppressions by stewards on enwiki suggest this is no longer the case. If we make it clear we are happy for stewards to continue to desysop in emergency cases, I am sure they will to do so even if crats gain the ability to do so as well. WJBscribe (talk) 21:47, 10 January 2010 (UTC)[reply]
I can't refute point two, but points three and four seem to be focused around the same idea of a 'crat being biased towards a decision if they're somehow involved in the "enwiki affair". Why is this any different to any system we have in place today? It has always been a firm advisement that administrators, bureaucrats or arbitrators remain uninvolved in situations where they may have a conflict of interest. I don't see why bureaucrats would not do the same in this situation. I don't have experience in administrative or bureaucratic activities so I may be severely misinformed, but that's how I see it. Regards, --—Cyclonenim | Chat  22:05, 10 January 2010 (UTC)[reply]
I don't think MBisanz is so much saying that an involved 'crat would take an action, but rather that people might perceive it as such (desysops always leave someone unhappy). It could make 'crats more of a target than they are now, as opposed to Stewards, who are decidedly neutral and largely beyond such petty criticisms. ~ Amory (u • t • c) 22:30, 10 January 2010 (UTC)[reply]
Interesting point, but if that is the case then it really is entirely irrelevant, because what Wikipedians percieve is irrelevant. What is true is what counts, at least in theory. We trust bureaucrats to make consensus-based decisions, and if they cannot act impartially, as Avi says below, they should not be a 'crat and that would most likely be picked up by the community/other 'crats. Regards, --—Cyclonenim | Chat  22:44, 10 January 2010 (UTC)[reply]
Hi, Matt. Let me try and address your concerns individually:
  1. That is a policy specific to oversight and checkuser, I beleive, not switching bits, as the steward has to grant themselves the CU/OS on the wiki prior to running the check. This is different firstly, as changeuserrights is something stewards have by nature anyway, and two, all of us are clear that we would like them to be available in cases of emergency (as they are in CU/OS anyway). When it is not an emergency, keeping everyting on EnWIki instead of Meta is sensible.
  2. Which is why this RfC is coming BEFORE any requests to developers to change the 'crat rights package. Only if this has a consensus will the developers be approached to adjust the crat package.
  3. And so? We have strict policies on EnWiki regarding these situations. If a bureacrat cannot be trusted to adhere firmly to the policy and guideline despite personal discomfort, that person should not be a 'crat.
  4. Lar does not edit Enwiki? Bastique does not edit EnWiki? Pathoschild does not edit EnWiki? etc.
  5. So for one instance we should prevent something sensible? And let us say that happens with a bot - which can have its bit removed by crats? That is similar to blocking/unblocking, which we allow even though the potential for a wheelwar exists. If that happens again, ArbCom can be called in. Anyway that is less likely because of chats.
  6. Concur
  7. Concur
-- Avi (talk) 22:31, 10 January 2010 (UTC)[reply]
Ok, but they actually aren't allowed to run CU's in an emergency, as we saw during numerous grawp-attacks when no local checkuser was available or during that weird grawp-attack that required an account to be renamed, in neither case did or could a steward step into the local wikis shoes since we are too large to qualify for small wiki monitoring efforts.
Second, Lar, Cary, and Pathoschild do not do rights changes on enwiki specifically because the steward policy prevents them. MBisanz talk 23:38, 10 January 2010 (UTC)[reply]
Re #1, They would have, I believe, had need been severe enough. Re #2, my point was that stewards edit here frequently and can be trusted to control themselves, so merely being frequent editors of a wiki does not make someone have an inherent COI --either steward or crat. -- Avi (talk) 00:02, 11 January 2010 (UTC)[reply]
I think Matt's point #3 is an excellent one and I don't is adequately addressed by anyone here. After all, the word "consensus" is used frequently on this page even though there is no process to desysop by consensus (since arbcom doesn't work by consensus but by strict voting). This suggests that there is already confusion about what circumstances will lead to desysopping. My concern (and I gather Matt's) isn't that the bureaucrats will succumb to that confusion but that other people will. Chick Bowen 00:11, 11 January 2010 (UTC)[reply]
That is an error on the part of the people using the word then; I think I re-clarified in the nutshell above that there is no decision being made here. There is no change to what causes a desysop, only who implements the valid decision. -- Avi (talk) 00:22, 11 January 2010 (UTC)[reply]

For those who don't know, I am a steward. I was asked by MBisanz to provide an opinion here. Broadly, I think it makes more sense to leave things the way they are, however let me make some comments on the proposed future situation:

Currently, stewards will perform desysops when requested by the English Wikipedia's Arbitration Committee. We will also perform them as requested by administrators themselves. Finally, in clear emergencies, we would remove the administrator tools to protect the wiki. For each of these cases, I'll outline the changes this might bring.

When your Arbitration Committee orders that an administrator be desysopped, a bureaucrat from this wiki would perform the job. I don't anticipate there would ever be a case where a steward would perform the task instead of a local bureaucrat - but perhaps I simply lack imagination :) When users wish to have their own tools removed, they would ask a local bureaucrat. When there is some emergency, a local bureaucrat would intervene.

However, stewards would probably still perform voluntary removals when requested to do so and no English Wikipedia bureaucrat performed the task for some time (there is no such thing as an urgent self-requested removal). This is because there is no policy (nor could there ever be) which forces a user to retain tools against their will. Nonetheless, we'd probably prefer for that to be handled by your bureaucrat team whenever possible. Likewise, in an emergency situation, stewards will do whatever we can that's necessary to fix the situation, in accordance with the m:Steward Policy. Since stewards are specifically elected to provide something closer to 'round-the-clock coverage than the English Wikipedia's bureaucrats are, it wouldn't be unlikely that stewards would still perform that task. Your bureaucrats are not known for high availability.

Let me emphasize that these are my opinions; I expect they'd be discussed on stewards-l as necessary before this is implemented. Of course, if the English Wikipedia community decides that they still wish to have stewards perform Arbitration Committee-mandated removals, we would oblige.  — Mike.lifeguard | @en.wb 03:24, 11 January 2010 (UTC)[reply]

Personally, I think it wiser in cases which are not emergencies to keep the logs all on EnWiki. In emergency cases, all hands are on deck, and I would hope a steward would step in immediately if they were notified of a rogue sysop/crat. -- Avi (talk) 03:32, 11 January 2010 (UTC)[reply]

What problem is this supposed to solve?[edit]

Could someone please answer the simple question of what problem this is supposed to solve? --Hammersoft (talk) 01:31, 11 January 2010 (UTC)[reply]

  1. Having to send requests for bit vacations to Meta and not handling it on EnWiki
  2. Having the +bit and -bit logs on two separate projects
  3. Preventing an accident from being corrected quickly (only happened once though)
-- Avi (talk) 01:35, 11 January 2010 (UTC)[reply]

Ok, in order (1) has this ever been a problem? Requests not handled properly or timely? Backlogged? (2) Does having the logs on separate projects create some problem I'm not aware of? (3) Only happened once and it's a problem to solve? --Hammersoft (talk) 01:38, 11 January 2010 (UTC)[reply]

Can we go on as we are doing now? Of course. However, the purpose of this RfC is to determine whether or not the project and its members believe that we can do things better. Many people believe the proposal is better; you do not. You are more than welcome to both feel that way and to post your opinions as clearly and forcefully as you can to best state your case. That's exactly what the RfC is for. However the mere fact that things are function now is no excuse not to explore what may be better options. Having local people doing local project work and keeping the logs in one place is preferable to me, and apparently many others. -- Avi (talk) 01:41, 11 January 2010 (UTC)[reply]
  • Yet you've so far been incapable of identifying a problem this proposal solves. We've gone for many, many years with the structure as it has been. You want to change that structure for apparently no reason. Why? --Hammersoft (talk) 01:43, 11 January 2010 (UTC)[reply]
  • I also think this proposal should be put on ice until the CDA advocates finish up their work. If (and God help us is it does) passes, we'll have an answer as to who closes CDAs, not a nebulous indecisive cloud that might or might not be bureaucrats. --Hammersoft (talk) 01:44, 11 January 2010 (UTC)[reply]

Your case is made as has been mine. The project's membership, of which you and I are but two individuals, will decide. If there is a consensus that this is not necessary, trust me, wikipedians will let it be known :) -- Avi (talk) 01:47, 11 January 2010 (UTC)[reply]

Answered above, you disagree. This is not an issue where further discussion helps. I think this proposal is more elegant and efficient than what we have now, even though we can live with the current. You do not. We can play "ring-around-the-rosie" back and forth until the cows come home, since it is no longer a matter of logic but of emotion. You like A and I like B. Do you disagree with my analysis? -- Avi (talk) 01:51, 11 January 2010 (UTC)[reply]

There are three situations listed above which will be more elegantly and efficiently addressed by this proposal. -- Avi (talk) 02:00, 11 January 2010 (UTC)[reply]

Responded above yet again. Just because something works does not mean we should not investigate more elegant and efficient methods. -- Avi (talk) 02:06, 11 January 2010 (UTC)[reply]

(edit conflict)You believe having to send a sysop requesting a vacation off-wiki is not a specific problem; I believe it is. You believe having separate logs is not a specific problem, I believe it is. So, you are clear about what you belive, but not about what I do. -- Avi (talk) 02:15, 11 January 2010 (UTC)[reply]

The logs are a problem. If CDA did not exist I would support this proposal because of the added transparency in the logs it would create. Also, I want to say that I'm very disappointed, as one of the dissenters, in the tone this discussion has taken. There is no need for that at all. I believe wholeheartedly that the proposal was intended in good faith. Chick Bowen 05:27, 11 January 2010 (UTC)[reply]

I think EVula's half-buried point above is extremely important: if this proposal is implemented, rights logs will follow the user around with renames. Currently if User:Example is sysopped here, then desysopped, then renamed to User:Foo, the logs for their +sysop follow them to their new name, but their -sysop logs do not, and are hence impossible to find unless the user's former name is known (which may not be the case, and at the least requires a lot of digging to uncover). Not only are the logs on a different project, they may not even remain synchronised with the user. Happy‑melon 10:53, 11 January 2010 (UTC)[reply]

I find it interesting that these oh-so-entrusted users have taken the time and effort to disparage my adamant opposition to this proposal as a form of a vendetta against Avi. Right. <cough> I've asked WHY having the logs on separate servers is a problem, to which there's been no answer. I've asked how the vacation bit suspension has been problem, to which there is no answer. And on it goes. Yet, I'm the one who apparently has a personal problem with Avi. Utter disbelief, --Hammersoft (talk) 15:31, 11 January 2010 (UTC)[reply]

To be fair, You did bring personal issues into the discussion. -- Avi (talk) 15:42, 11 January 2010 (UTC)[reply]
  • I'm sorry if you feel that was a personal disapprobation. It was not. --Hammersoft (talk) 16:01, 11 January 2010 (UTC)[reply]
Hammersoft, I'd be more willing to believe that this isn't a personal dispute between you and Avi if you could address my addressing you, where I did my best to answer your "what problem does this solve?" question. From what I can tell, Happy-melon may be the only person that actually read it. :) EVula // talk // ☯ // 17:40, 11 January 2010 (UTC)[reply]
  • For some reason all your text appears in rot13 :) Seriously, please assume some good faith. I have no axe to grind with Avi. --Hammersoft (talk) 18:05, 11 January 2010 (UTC)[reply]
    • OK, I'll put it down to the heat of the moment; something I am only too well aware of in my own editing . Thanks for the clarification, Hammersoft. -- Avi (talk) 18:36, 11 January 2010 (UTC)[reply]

I expect the reason why no one has expanded on the question "why having the logs on separate servers is a problem" is that they consider it to be blindingly obvious. As an example, please give me the log summary for the desysop between these two +sysops on enwiki. In the meantime, I will write a paragraph of sourced prose for Hustle (TV series), my current article project, or maybe a whole section if you don't know off the top of your head Harej's previous username. Then give me the log summary for the desysop between thesetwo +sysops on metawiki, which is a wiki where bureaucrats can desysop. In the meantime I will maybe have time to check my watchlist, if your internet connection is particularly slow. That is the problem: it is genuinely difficult to view the past history of enwiki users. Happy‑melon 20:50, 11 January 2010 (UTC)[reply]

And this proposal would not fix that, as Ruslik0's opposed (currently #8) shows. In fact, it would make it worse. --Hammersoft (talk) 22:43, 11 January 2010 (UTC)[reply]
Which is already the case on simple and meta, IIRC, which all have crats doing the + and minus. -- Avi (talk) 22:45, 11 January 2010 (UTC)[reply]
How does it "make it worse"? I simply do not agree with Ruslik's reasoning. If this proposal is enacted, then in maybe 90% of cases going forwards, you wouldn't need to look in the global rights log because it would be right there in front of you in the local log. If you see two sequential +sysops, you know that there's a -sysop sitting in the global rights log which you need to find, but if there's no break in the logs, then problem solved. As opposed to now, when you are guarranteed to have to look in both logs. In a few cases, the situation is the same as the status quo, and in the vast majority it is better. How is that "making the problem worse"?? Happy‑melon 12:14, 12 January 2010 (UTC)[reply]

To return to User:Hammersofts original question, the problem that this is meant to solve is that this entire process, from implementation, has been broken. Like many of our procedures, removing the sysop bit relies on an ability that is not an integral part of our processes here at wp-en. The process has been broken from the beginning. It is just wrong that our 'crats can grant the ability without being able to take it away. The process by which the community allows them to do so is completely irrelevant to this conversation. The wp-en community grants adminship, the wp-en community must be able to remove it without requiring intervention from outside. We are a self-policing communtity. Going to outsiders to implement our already policy-based decisions flies in the face of what a wiki is supposed to be. To me, any process that must be implemented outside of the community, other than for legal reasons, is broken to begin with. That is the problem we need to fix. Jim Miller See me | Touch me 21:49, 12 January 2010 (UTC)[reply]


Some procedural questions[edit]

  1. Why this discussion is held on rather an obscure subpade, but not on the Village Pump?
  2. Why the title of this page is so misleading? What is Bureaucrat unchecking RFC supposed to mean: (a) Bureaucrats unchecking some RFC; (b) RFC about a need to uncheck all bureaucrats; (c) RFC about bureaucrats unchecking something?
  3. Why the previous discussion was not mentioned? And why a wrong impression was created that this a new proposal never discussed before?
  4. Why in the first 24 h after this RFC was started (at 8:36, 10 January) 36 users !voted support and 4 oppose, while in the next 24 h 14 supported and 13 opposed? Were the former WP:CANVASSed? (Especially taking into account that some of the supporters did not understand what they voted for.)
  5. What will be the significance of this strange and poorly organized RFC? (I suppose close to zero.)

Ruslik_Zero 19:48, 12 January 2010 (UTC)[reply]

  1. Similar to RFB Bar, it is a bit related issue. The pump was notified immediately by the way.
  2. As an (obviously failed) attempt to prevent conflation with anything resembling 'crats making a decision. This is solely regarding once a decision is made in the regular wiki way, who unchecks the box (see the interface - it is a checkbox)
  3. I plumb forgot about it, mea culpa.
  4. Statistically, that means that the opposers were more likely canvassed. The initial respondents likely saw it pop up on their watchlists of either WP:BN, WT:RFA, WP:ANor WP:VP(policy) where this was publicized, and soon after (I presume) on the RfC page. Most likely opposers started to spread the word late, which was why their response was so delayed, but, what can you do. I cannot control canvassing by opponents :( .
  5. If there is a consensus that approves, the developers will be approached to add the userrights package to 'crats to allow unchecking of sysop/crat boxes.
What is interesting, at least to me, is that I am on record opposing CDA (although I have taken part in the conversation in regards that IF it comes about, there are safeguards I would want to see put in) so, at least for me, this continued conflation is frustrating :D -- Avi (talk) 21:30, 12 January 2010 (UTC)[reply]
You misunderstood the item 5—it was not really a question but a statement. Ruslik_Zero 12:51, 14 January 2010 (UTC)[reply]
Perhaps; you listed it as a question, it was only polite to respond. -- Avi (talk) 14:08, 14 January 2010 (UTC)[reply]

WP:CDA will have bureaucrats deciding outcomes[edit]

Just to be clear, since there seems to be some disagreement on this point, please read Wikipedia:Guide_to_Community_de-adminship#Closure. In the current proposal, bureaucrats will indeed be responsible for determining consensus on deadminship requests. --Hammersoft (talk) 16:18, 11 January 2010 (UTC)[reply]

Another thing to consider[edit]

Another thing to consider when looking at RfA's we often hear that the system is broken. There have been numerous suggestions in the past about ways to fix it or approaches we might take to tweak the process. Various models of "temporary adminship" or "mentorship" are killed (in part) because we can't burden the Stewarts with that responsibility. If we granted 'crats the ability to remove the bit, then we will open up the doors for actual reform at RfA. Plus, if adminship really isn't that big of a deal, then it needs to be easier to move into and out of.---Balloonman NO! I'm Spartacus! 16:17, 20 January 2010 (UTC)[reply]


Closing[edit]

It's clear that this poll is winding down, with only two contributions in the past week. Is it time for closure? If so, I'll poke AN for an uninvolved administrator. Happy‑melon 08:50, 28 January 2010 (UTC)[reply]

It should run for 30 days. Ruslik_Zero 10:15, 28 January 2010 (UTC)[reply]
Why? That's not a rhetorical question. Happy‑melon 10:17, 28 January 2010 (UTC)[reply]
The boilerplate text says that RfCs get automatically delisted after 30 days, but that does not mean it cannot be closed earlier. Perhaps the uninvolved admin should make the decision if it warrants being open longer? -- Avi (talk) 15:53, 28 January 2010 (UTC)[reply]
The participation in this discussion has been very low, so far. Why it has been so low is explained above (See Some procedural questions). Participation is actually much lower than in the previous poll (89 against 122). So, this poll can not be used to gauge consensus. At best it can serve as the first stage of a long process, which needs to be followed by a better organized and advertised discussion. Ruslik_Zero 19:29, 28 January 2010 (UTC)[reply]
Your procedural questions have been responded to, Ruslik. An uninvolved admin will make the decision, neither you or I are uninvolved. -- Avi (talk) 20:07, 28 January 2010 (UTC)[reply]
Why can this poll not be used to gague consensus? That's not a rhetorical question. Happy‑melon 20:59, 28 January 2010 (UTC)[reply]
What if we were to ping the previous respondents that haven't weighed in here as yet? –xenotalk 21:01, 28 January 2010 (UTC)[reply]
I've been meaning to work out how great the overlap is between the two groups; haven't got round to that yet. Do you fancy doint it? Happy‑melon 21:04, 28 January 2010 (UTC)[reply]
Sure - see http://en.wikipedia.org/w/index.php?&oldid=340594877 –xenotalk 21:14, 28 January 2010 (UTC)[reply]
Your first list seems to have as many people on it as contributed to the old discussion at all; I assume there's some issue there... :D Happy‑melon 21:36, 28 January 2010 (UTC)[reply]
I used a crude method (links on page, convert from talk pages, eliminate duplicates and pages with a /) and that gave 151 pages with only 32 who also showed up in this discussion. And yes, I know there's 1 missing. I was never a good mathematician ;p –xenotalk 02:09, 29 January 2010 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Category