Wikipedia talk:Removing administrator rights/Proposal 2

Yes, this proposal should be implemented

1. Strong support - in most areas, if a user makes a change - he can revert it. Bureaucrats should have this ability when sysopping. Additionally, when desysopping is necessary, we should be able to handle it internally. Additionally, the sysoping and desysoping should be in the same log. עוד מישהו Od Mishehu 07:41, 18 February 2009 (UTC)[reply]
2. Support, in the unlikely event a 'crat makes a mistake, they should be able to undo their action. —Locke Cole • t • c 08:18, 18 February 2009 (UTC)[reply]
3. Per above. MER-C 08:19, 18 February 2009 (UTC)[reply]
4. Makes sense from a technical perspective. Not like a mistake or a--good luck with this--"rogue" crat can't be undone, in any event.
   T) 08:21, 18 February 2009 (UTC)[reply
   ]
5. Makes a lot more sense than what's happening now. Xclamation point 12:00, 18 February 2009 (UTC)[reply]
6. Support per X, and because it is bizarre that a crat can be tasked to give tools but not withdraw them; I would've thought being able to give them is a lot more sensitive and potentially damaging than being able to take them away. Locke Cole is right when he calls it an "unlikely event"; I can't see a crat getting confused over which user he is meant to +sysop :P. Ironholds (talk) 12:04, 18 February 2009 (UTC)[reply]
7. If we can trust a bureaucrat to +sysop appropriately, I think that we can trust him/her to -sysop appropriately, on the relatively rare occasions when needed, as well. — TKD::Talk 12:40, 18 February 2009 (UTC)[reply]
8. Support -
   talk) 13:23, 18 February 2009 (UTC)[reply
   ]
9. No big change. No big deal. --Deskana (talk) 13:25, 18 February 2009 (UTC)[reply]
10. Support - I think it would be extremely unlikely that a 'crat would 'go rogue' and start desysopping everyone in sight (and as mentioned above, this can be undone if necessary), and I find the argument about stewards casting an unbiased eye over desysoppings fairly unconvincing. If there is an emergency (i.e. a compromised sysop account) it is fairly obvious to everyone that something needs to be done, and in non-emergency cases the desysopping will be the result of a discussion or ArbCom remedy. In such cases it makes little difference whether a local 'crat or steward flicks the switch, they're still acting on consensus.
    ⁰⁶¹² 14:32, 18 February 2009 (UTC)[reply
    ]
11. –Juliancolton ^{Tropical Cyclone} 14:46, 18 February 2009 (UTC)[reply]
12. Yes, enwiki bureaucrats should/are trusted enough to desysop, and making things more local is not a bad thing.
    (talk) 14:55, 18 February 2009 (UTC)[reply
    ]
13. The concerns raised so far don't seem valid to me. I think moving this process in-house would be a good thing. I trust all of our current crats to use it carefully, and in accordance with the extremely limited circumstances set out in this proposal.--Aervanath (talk) 15:18, 18 February 2009 (UTC)[reply]
14. Yes, but only under carefully controlled circumstances and only by an "uninvolved crat." Examples where I'd go along with it: Where the removal has already been approved by an authority other than a crat, such as arbcom; and according to as-yet-undefined emergency desysop procedures, but only if there are not enough other people with the emergency-off bit available. davidwr/(talk)/(contribs)/(e-mail) 16:04, 18 February 2009 (UTC)[reply]
15. Anyone who the community trusts enough to give the bit ought to be trusted enough to take it away.--Fabrictramp | talk to me 16:10, 18 February 2009 (UTC)[reply]
16. Support - per Od Mishehu, Ironholds and TKD. Crats should have the technical ability to desysop. AdjustShift (talk) 16:12, 18 February 2009 (UTC)[reply]
17. From the "this is a wiki" argument - what can be done should be able to be undone. WilyD 16:22, 18 February 2009 (UTC)[reply]
18. Strong support; the bureaucrats can be trusted with this, the English Wikipedia is large enough to handle this on its own, and the current asymmetric situation alluded to by Fabrictramp above is untenable. Skomorokh 16:26, 18 February 2009 (UTC)[reply]
19. Definitely - even after we come up with an admin-removal process, this will still be a simple implementation of community consensus, or an emergency action. Bureaucrats are trusted to implement consensus and behave rationally, so I have no qualms about getting them to do the job instead of the stewards - in general, an en-wiki bureaucrat should be more aware of a given situation than most stewards, who in many cases aren't particularly familiar with the specific project. ~ mazca ^t|c 16:37, 18 February 2009 (UTC)[reply]
20. Support Sensible idea. Colonel Warden (talk) 16:47, 18 February 2009 (UTC)[reply]
21. Support: We trust them to grant the bit, which can do more damage than removing it, so why not remove it too? It would help to prevent the damage that can be done by compromised accounts / rogue admins. Opposing because the stewards do a good enough job is like opposing at an RfA because you think we have enough admins or not granting rollback because the rollbackers we have keep it under control. Dendodge Talk^Contribs 16:57, 18 February 2009 (UTC)[reply]
22. SupportIt would give the crats no further "power" it would just speed up current practice by bringing it in-house. I also prefer the idea to have voluntary de-sysoping logged on our pages rather than at meta for transparency. Poll are evil therefor this will need wider discussion but this poll can give an idea of the communities thoughts. Agathoclea (talk) 17:10, 18 February 2009 (UTC)[reply]
23. I have always wondered why bureaucrats don't have the ability to desysop, and the reasons against implementing this feature are almost always "we don't need it" (which was also said about rollback for non-admins), "it's redundant to stewards", or "can't see any reason to implement it". By allowing bureaucrats to remove admin rights, it'll mean that bureaucrats will be able to do their entire job rather than only half of it (whoops, taking Friday's lines there). There won't be bureaucrat battles over admin rights...look how many battles are there over rollback rights, bot flaggings, and renames (very few for the first one, none that I'm aware of for the last two). I think that this is a good idea. Acalamari 17:46, 18 February 2009 (UTC)[reply]
24. Support Would just be in the wiki spirit, i.e. that mistakes can be reverted. As the proposal says, it's just a technical thing, nothing more. But I'd rather have one of the trusted crats here take care of such changes than a steward who is removed from the project and might have to first read a lot of discussion before making the change. Admins can remove rollback, AAC or ip-exempt as well as granting and noone ever thinks that's a bad thing. Same should apply to crats and the flags they hand out. Admins have to follow policy in aforementioned cases and crats would have to follow policy in these cases. If they don't, it's just a case of abuse, nothing more.
    WP:UNINVOLVED applies to them just as it applies to admins. SoWhy 18:11, 18 February 2009 (UTC)[reply
    ]
25. nice idea, let's see how it works. —
    macy 18:14, 18 February 2009 (UTC)[reply
    ]
26. Support - This will have no effect on emergency decisions, and would keep other stuff like ArbCom desysoppings to the English Wikipedia, rather than us having to outsource them to meta. NuclearWarfare _(Talk) 19:04, 18 February 2009 (UTC)[reply]
27. Support -- No-brainer. The benefit of course is that in a situation where it's necessary, there will be more people available to do it. And it shows a real sad state of affairs that this has turned into a whole big "thing", and is a testament to just how
    special admin rights have become. It's just a technical ability that can only be carried out following an arbcom decision or some similar cause that doesn't require much judgment. At the very worst, what, you get your super-powers revoked temporarily by mistake? You shouldn't care this much. And if you do care, you have no business being an admin. Equazcion •✗/C •
    19:12, 18 Feb 2009 (UTC)
28. Support If they can promote you to admin status they should be able to revoke admin status.--DFS454 (talk) 19:37, 18 February 2009 (UTC)[reply]
29. Support - Seems logical. —
    neuro^(talk) 20:54, 18 February 2009 (UTC)[reply
    ]
30. Support - the proposed grounds for crat desysopping are limited enough that it should never be controversial, and I think our crats are trustworthy enough to have that additional power. Maybe there's not a great need for it but I certainly don't see any this proposal causing any harm. Robofish (talk) 00:30, 19 February 2009 (UTC)[reply]
31. I trust en.wp's local 'crats more than stewards actually. Icewedge (talk) 02:39, 19 February 2009 (UTC)[reply]
32. Support with some reservations. First, the use of this would naturally have to be restricted to the right situations, and second, I would not support crats having -crat (they have +crat). The use of -crat is rare enough that restricting it to stewards is probably worthwhile, especially as bad use of it would lead to much drama. I do agree with those who suggest that this poll is somewhat ahead of itself, but I don't want to shoot this idea down for process reasons: bureaucrats being able to desysop would be a good step towards a reasonable policy for removing administrator rights. {{Nihiltres|talk|log}} 16:26, 19 February 2009 (UTC)[reply]
33. talk // 21:17, 19 February 2009 (UTC)[reply
    ]
34. Keeping all aspects of userright changes in house is rather appealing to me. I also think it's something that we should definitely be allowed to do in a very limited number of circumstances, especially now that we're starting to experiment with sysop bots more. Bureaucrats being able to remove the sysop and bureaucrat flags also goes hand-in-hand with my ideas on an "RfDA" system, where abuse of the sysop tool would be handled entirely on-wiki, rather than farming the dirty work back out to Meta. EVula // talk // ☯ // 23:22, 19 February 2009 (UTC)[reply]
35. Support. I do not find it entirely suitable to separate our desysopping to Meta Stewards. Not that I do not trust them, but I feel that we must keep these affairs within our own en.wiki sphere of influence. bibliomaniac15 01:52, 20 February 2009 (UTC)[reply]
36. Trust them to turn the bit on and likewise to turn it off. If my account starts flailing about I want the bit turned off as fast as possible and perhaps this will help to ensure - just as
    WP:AIV works for people poorly editing - Peripitus (Talk) 02:01, 20 February 2009 (UTC)[reply
    ]
37. Seems an obvious and non-controversial extension of current practices. DGG (talk) 02:08, 20 February 2009 (UTC)[reply]
38. Support. We shouldn't have to get a steward every damn time someone is desysopped. The idea of a rouge crat seems pretty whacky. Jonathan321 (talk) 21:10, 20 February 2009 (UTC)[reply]
39. — Jake Wartenberg 00:20, 21 February 2009 (UTC)[reply]
40. Support As EVula mentioned, it would be nice to keep userright changes on-wiki. While I do understand MZMcBride's concern about logs being on both places, it will be nice to at least have more of them here in the future. hmwithτ 22:07, 21 February 2009 (UTC)[reply]
41. It just seems like common sense to give local bureaucrats the ability rather than having to go through all the effort to get the attention of a steward in order to desysop.
    Talk) 04:52, 22 February 2009 (UTC)[reply
    ]
42. Support Good idea.--Patton^t/c 20:10, 22 February 2009 (UTC)[reply]
43. Support - Especially since they would be merely acting as the one flipping the switch in response to request from one or more other bodies. Any abuse can and should be dealt with swiftly by
    Arbcom/User:Jimbo Wales. - jc37 22:19, 22 February 2009 (UTC)[reply
    ]
44. Support The current system (allowing promotion but not demotion) doesn't make sense. I would be in favor of it being the default on all wikis. Dovi (talk) 06:42, 23 February 2009 (UTC)[reply]
45. Support Not a big deal, crats are already responsible for grating rights. I also think that we should have a formal process to desysop admins by the community.--J.Mundo (talk) 22:04, 23 February 2009 (UTC)[reply]
46. So long as desysoppings are only carried out in the same rare and extreme cases as they are currently — that is to say, only in the case of compromised rogue admin accounts and ArbCom sanctions. I wouldn't ever want to see a desysopping in a case where even one of the other bureaucrats disagrees that it is appropriate. --Cyde Weys 02:44, 24 February 2009 (UTC)[reply]
47. Strong Support If they are trustworthy enough to give adminship, there is no reason why they aren't trustworthy enough to take it also. Alexfusco⁵ 02:50, 24 February 2009 (UTC)[reply]

    Judging by Wikipedia:Bureaucrat_removal they appear not so trustworthy. Ruslik (talk) 07:09, 24 February 2009 (UTC)[reply]

    Well if the bar for RfB is as high as 85-90% they obviously have the community's trust to be able to perform a tast very similar to what they can already do. Alexfusco⁵ 22:46, 25 February 2009 (UTC)[reply]

48. Support - I don't see any problem here. Trusilver 16:52, 25 February 2009 (UTC)[reply]
49. Support - I honestly see no reason why not, there is no reason we shouldn't be able to do this locally rather than having it at meta. Worst thing that happens is that another crat reverts the removal of permissions. —
    Nn123645 (talk) 00:29, 27 February 2009 (UTC)[reply
    ]
50. Support. It's just logical to give crats the two halves. No one would think, for example, that admins should be allowed to protect pages but not unprotect them. Cool3 (talk) 19:10, 27 February 2009 (UTC)[reply]
51. Support Despite certain other active proposals, crats are among the most trusted members of the Wikipedia community, and as the above remark explains, it's only logical that they have this ability.
    talk) 22:03, 28 February 2009 (UTC)[reply
    ]
52. Thought I'd already voted here. Support - every other bcrat action can be reversed, why not adminship? Seems silly. Majorly talk 12:34, 2 March 2009 (UTC)[reply]
53. Support. It would be useful for the community. These are already trusted positions. – Quadell ^(talk) 19:47, 2 March 2009 (UTC)[reply]
54. Support If the 'crats are not trusted to do this, then I think we have a bigger problem. --rogerd (talk) 04:12, 6 March 2009 (UTC)[reply]
55. Support. Should have worked like that from the start. Implement until a problem arises. Worry about an old bureaucrat returning to create chaos when it happens. --SmokeyJoe (talk) 11:42, 6 March 2009 (UTC)[reply]
56. Support - Sysopping is far more dangerous than desysopping, so it makes no sense that we trust 'crats to do the former but not the latter. -kotra (talk) 21:03, 6 March 2009 (UTC)[reply]
57. Support, as it's not like this will allow bureaucrats to desysop anyone at any time. It just provides another avenue when a desysop is needed quickly, and it leaves the Stewards to concentrate on other tasks where they're needed more. Lankiveil ^{(speak to me)} 00:15, 7 March 2009 (UTC).[reply]
58. Support. I appreciate the concern of some !voters that the tool could be misused, but given the generally reliable behavior of 'crats it seems this oppose rationale would be an example of "bad cases making bad law". The other main oppose reason is "solution in search of a problem"; I think the reasons on principle (we should take care of our own housekeeping, 'crats should be able to reverse their actions) justify the change whether or not it will bring about efficiency gains. Baileypalblue (talk) 18:18, 8 March 2009 (UTC)[reply]
59. Malinaccier (talk) 22:50, 8 March 2009 (UTC)[reply]
60. Support Seems reasonable. Mister Senseless™ (Speak - Contributions) 02:34, 9 March 2009 (UTC)[reply]
61. Support — it's silly that bureaucrats can give adminship but not take it away. *** Crotalus *** 14:20, 10 March 2009 (UTC)[reply]
62. Strong support, there is no reason to depend on meta to perform such a simple action. After the decision of desysopping is made, pressing on the bottom isn't a big deal. Lechatjaune (talk) 22:11, 13 March 2009 (UTC)[reply]
63. Support - COI - I'm a Steward. I think that all large and very active projects should have the ability to decide if their crats can desysop, at least on an emergency basis. En.wikipedia fits that bill. Stewards should still be able to monitor the situation to make sure abuse does not occur. --mav (talk) 15:53, 15 March 2009 (UTC)[reply]
64. Support this sound and logical proposal.—S Marshall ^Talk/_Cont 00:17, 24 March 2009 (UTC)[reply]
65. Support per symmetry. If you can add a flag, why shouldn't you be able to remove it? My second argument is that to be chosen as an Stewards you need to have broad language skills and then disqualifies strong candidates. And thirdly why should an Steward with a lot of strong opponents be able to desysop on en-wiki? A first step will be to let en-wiki start handling this. Nsaa (talk) 23:06, 24 March 2009 (UTC)[reply]
66. Suppport as
    reasonable. Bearian (talk) 23:09, 24 March 2009 (UTC)[reply
    ]
67. Support. Can't see a compelling reason not to.--Father Goose (talk) 07:00, 25 March 2009 (UTC)[reply]
68. Support - Nsaa stated it well.
    vecia 03:30, 26 March 2009 (UTC)[reply
    ]
69. Support Whatever position one has on Wikipedia, one should be able to undo whatever they can do. Kingturtle (talk) 15:04, 27 March 2009 (UTC)[reply]
70. Support It would be foolish to outsource something like this. --Rschen7754 (T C) 19:07, 28 March 2009 (UTC)[reply]
71. Support Lots of good reasons already documented above, I won't repeat them. Jclemens (talk) 22:54, 31 March 2009 (UTC)[reply]
72. Strong support. This is Wikipedia's elephant in the living room. It is becoming increasingly evident that the "job for life" model for admins, combined with a totally inadequate regime for ensuring that admins follow the key policies that govern their behaviour—in particular
    WP:ADMIN—is damaging the project. Bureaucrats already have rather too few roles, and giving them the job of overseeing admin behaviour would be one step in the right direction. It is appalling that desysoping is done by these external stewards, who do not have the specific skills necessary to apply procedural fairness to admins who are the subject of complaints. ArbCom, populated entirely by admins, is not the right body to do this (police investigating police just does not work). Tony (talk) 13:51, 3 April 2009 (UTC) PS As Voter 14 points out ... gotta be an "uninvolved" crat. In addition, we need a proper, uninvolved process for examining and judging complaints against admin behaviour. ANI is just the wrong place to do this, since it is dominated by fellow admins—that's a no-brainer. Tony (talk) 13:58, 3 April 2009 (UTC)[reply
    ]

    Comment It certainly was the case last year that admins were too hard to remove, but with the expanded new approach Arbcom it's actually rather easy now. We're already getting our removal system, it's just been coming too slowly for many to notice. Deacon of Pndapetzim (Talk) 16:17, 3 April 2009 (UTC)[reply]

73. Support: Per Tony's Elephant in the room, although this poll could do with a bit more advertisement, watchlist anyone? Ryan4314 (talk) 14:05, 3 April 2009 (UTC)[reply]
74. Obviously. Simple common sense. --
    Fatuorum 14:20, 3 April 2009 (UTC)[reply
    ]
75. Support: I have some respect for admins who are open to recall. Unfortunately, there are too few of those. The system, which generally lacks adequate checks and balances, creates admins lacking in accountability and responsiveness. This "untouchability" in turn corrupts when coupled with the self-reinforcing club which is the Admins' IRC, and cultivates a tolerance of abusive admins. This is a welcome move. Ohconfucius (talk) 15:17, 3 April 2009 (UTC)[reply]
76. Support - Bureaucrats are accountable to the community for their decisions. I am not worried about allowing most of them this power. It would give the community a little more input into removal of admin privileges. The current menthods are inadequate. However, I think the community should keep an eye open for the concerns expressed below by JayHenry and react accordingly, as his concerns are valid. The quality of appointees has improved. Those appoint pre 2007 were not held to the same standard of community accountability. —Mattisse (Talk) 01:08, 4 April 2009 (UTC)[reply]
77. Support Administrators (like Ryulong) who promised to be open to recall during their RFA but who then reneged on that promise as soon as they were annointed are the poster childs for why this is necessary. Tennis expert (talk) 07:16, 4 April 2009 (UTC)[reply]
78. OF COURSE: There should be a stronger checks and balances system; however, the Crat should be univolved and I would propose that there be a Request for desysop discussion first. You know, due process and all.--It's me...Sallicio!^{${\displaystyle \color {Red}\oplus }$} 21:08, 4 April 2009 (UTC)[reply]
79. Support. It is easy to give admin status to people without evidence of admin actions. It is difficult to remove the power even when the community has the evidence of their actions and can see they are not adding value (or worse). Good admins will have continuing support of the community. Lightmouse (talk) 11:27, 5 April 2009 (UTC)[reply]
80. Support But another option is to grant suspension of admin privileges for a specified timeframe until the entire community can provide feedback and
    WP:CONSENSUS with Bureaucrats implementing the final "verdict". — BQZip01 — ^talk 01:11, 6 April 2009 (UTC)[reply
    ]
81. Support - although, I might add, the side effect is that Steward becomes less important over all (but still important). Ottava Rima (talk) 01:19, 6 April 2009 (UTC)[reply]
82. Yes. This won't increase at all the situations where desysopping can occur. It merely adds flexibility to whom can do it. The most compelling oppose argument is that the logs will become slightly more complicated and that's hardly a strong argument. JoshuaZ (talk) 16:12, 6 April 2009 (UTC)[reply]

No, this proposal should be tagged rejected

1. I don't see any appreciable benefit and it makes the logs even messier than they already are. --MZMcBride (talk) 09:05, 18 February 2009 (UTC)[reply]

   Ah what? It will make the logs easier not messier. At the moment you have to go to the metawiki to see if an admin has been desysopped while the sysopping takes place on this project's logs. Cheers 211.30.98.227 (talk) 04:13, 20 February 2009 (UTC)[reply]

   Currently all desysopings are recorded in the meta log. If crats are given ability to desysops, some actions will be recorded in the local log, while some others in the meta log (as steward will continue to desysop in emergencies). This will make logs messier than now. Ruslik (talk) 06:23, 20 February 2009 (UTC)[reply]

   Eventually, something has to be done; all bureaucrat logs before 2004 are in a different place than the rest. Do we continue to have messy logs, or do we make a break with the old system so that the future logs will be neater? EVula // talk // ☯ // 06:28, 20 February 2009 (UTC)[reply]

2. I like how stewards have to cast an eye over all desysopping requests, if only as a set of uninvolved eyes to make sure everything is in order. Daniel (talk) 09:49, 18 February 2009 (UTC)[reply]

   What situation are you thinking about, that a crat would need a second set of eyes? The only desysoping this would carry out, are common sense requests (self requests, mistakes made by a crat, and by order of Arb Com). The only thing a steward has to do, is verify the request is accurate with a diff. This is, however, easier if its on the same wiki. Synergy 14:51, 18 February 2009 (UTC)[reply]

   You left out "emergencies", which is not something I trust all bureaucrats to judge fairly with regards to all administrators - it is a subjective decision, and can easily be influenced by project politics, which stewards (by virtue of their rule on not taking action on home projects) are immune to. Daniel (talk) 22:13, 18 February 2009 (UTC)[reply]

   I don't see the bureaucrat's additional ability to demote users as being an impediment to a steward responding to an emergency situation; we should be more interested in protecting the project than in enforcing cross-wiki bureaucracy. I honestly don't care who responds in such an emergency, just as long as someone does. EVula // talk // ☯ // 05:16, 20 February 2009 (UTC)[reply]

   I know at least one bureaucrat who thinks that blocking a certain content contributor constitutes an emergency; I don't think I can find a steward who thinks that. Daniel (talk) 10:27, 21 February 2009 (UTC)[reply]

3. [1]
   ^T 13:15, 18 February 2009 (UTC)[reply
   ]
4. Strong oppose per Daniel. — Aitias // discussion 13:45, 18 February 2009 (UTC)[reply]
5. No. Not necessary. That is what stewards are for. Apteva (talk) 15:08, 18 February 2009 (UTC)[reply]
6. Not for old 'crats. although the proposal's heart is in the right place, I do not trust the legacy crats who were appointed before 2007-08 to use this power appropriately. The old 'crats did not go through heavy scrutiny (it was only after their dubious calls - ryulong, carnildo, danny, etc - that scrutiny was ratcheted up so high) and I do not believe they have the level of trust I'd want to see for desysopping. --JayHenry (t) 15:39, 18 February 2009 (UTC)[reply]

   But shouldn't we

   assume good faith? If they abuse the tools they have now, they will be "prosecuted" (for the lack of a better word) for it and if they get a new tool, they will be handled the same way, if they abuse it. SoWhy 18:14, 18 February 2009 (UTC)[reply

   ]

   I'd never heard of this

   assume good faith and give me the new tool to desysop administrators? Is it perhaps because I've never demonstrated having the level of trust that you would expect for the use of such a tool? --JayHenry (talk) 04:04, 19 February 2009 (UTC)[reply

   ]

   No need to

   sarcastic, I just wanted to link it for other, less experienced editors (yes, they do exist). Anyway, that's not the point. Unlike you, they have been trusted with all the shiny crat buttons already. So if you think they are incompetent to remove admin flags, why do you think they are competent to flag bots or make admins? By your argument, we should just de-crat all those crats - but that's no reason to oppose those "newer" crats getting another button, is it? SoWhy 11:20, 19 February 2009 (UTC)[reply

   ]

   If the proposal were for new crats to get the button then yes, I would feel differently. But that's not the proposal. The proposal is to give it to all 'crats. I am opposed to giving it to all 'crats. I think it requires an extremely high level of demonstrated trust. The standard did not used to be high, however, and all crats are permacrats. I don't feel like I'm saying something logically complicated, so I'm not sure why you're struggling to follow. --JayHenry (talk) 00:23, 20 February 2009 (UTC)[reply]

   What I fail to understand is why you think those old crats will run havoc with such a ability if they clearly don't with the current buttons they have. Which indications do you have that they will act differently with this feature than they do with the current ones? SoWhy 11:15, 21 February 2009 (UTC)[reply]

   Are you simply refusing to read what I'm writing? I cited specific examples of where I felt they've clearly misused their current buttons (not to mention indirect misuse like Cla68's RFA). So 1) I specifically am arguing that some of the old 'crats have misused their current buttons 2) I don't think they'll act differently. I think the old 'crats are the ones most likely to misuse these buttons as well, partially because 3) the old 'crats never demonstrated a high level of trust because standards were lower back then. --JayHenry (talk) 16:49, 22 February 2009 (UTC)[reply]

   This is clearly not a question of AGF. What JayHenry is saying is he doesn't trust the competence of the older 'crats - and this is a different question. עוד מישהו Od Mishehu 07:13, 19 February 2009 (UTC)[reply]

7. No. Stewards are easier to get a hold of, contrary to what the proposal says. Regardless, the current process is fine and there is no need to change it. On an additional note, I'm not confident that there would be no "questionable" actions done by crats if they had the ability to do this. Despite that, my first two reasons are the main influence in my opposition. - Rjd0060 (talk) 15:40, 18 February 2009 (UTC)[reply]
8. Stewards are much easier to get a hold of, and a bureaucrats job (judging consensus) has absolutely nothing to do with removing rights. Prodego ^talk 17:35, 18 February 2009 (UTC)[reply]
9. Oppose I have several reasons to oppose this proposal:
   1. The proposal is a solution in search of a problem, because, in my opinion, no problem currently exists that can justify giving this new right to crats. I do not think that change for the sake of change is a good idea.
   2. Contrary to what this proposal says it may profoundly effect how wikipedia functions in the future. Every new tool will eventually be used, and I am not sure I will like how it may be used. Currently there is no policy that regulates the use of this new tool by crats. Such a policy should be discussed simultaneously with the technical change itself (not after). The serious change, that is really discussed here, should not be disguised as a minor technical fix.
   3. This proposal looks like a back door implementations of one proposal for desysoping (see User:EVula/opining/RfA_overhaul). A quote from this discussion: I don't think polls are needed. If the crats decided among themselves to entertain requests for removing adminship, that's all that is needed. Certainly they shouldn't do so over significant and reasonable objections from the community, but I think that trying to get the community to actively approve such a thing will only lead to paralysis. Currently, the only obstacle that remains is stewards. If they are removed everything will be possible.

   Ruslik (talk) 20:07, 18 February 2009 (UTC)[reply]

   As an obvious proponent of that idea (you know, being the author and all), I don't consider it a back door implementation; all we're talking about is the technical ability for bureaucrats to remove some of the same flags that they can apply. My idea is for a community-driven de-adminship process, which can be done without bureaucrats being able to remove the rights directly (I just think it would be easier and better, in the long run, if it were all handled on-wiki). My RfDA idea can be implemented without this proposal, just as this proposal can be implemented without my RfDA idea; they are not intrinsically tied together. EVula // talk // ☯ // 05:22, 20 February 2009 (UTC)[reply]

10. I see no problem with stewards having the sole ability to desysop. The reason why some people are unhappy about difficulties achieving desysoping has nothing to do with who has the technical ability and who doesn't; it is because we do not currently have a consensus about what qualifies as sufficiently bad admin behavior to warrant desysoping. Anything else is just a distraction from the main issue.
    Chick Bowen 22:27, 18 February 2009 (UTC)[reply
    ]
11. No, not sure what problem this is addressing. Is there one? The recent efforts to lower the standard of promotion at RFB, scope creep and uncertain judgement from some current bureaucrats all combine to make this a bad idea. No real need for it.
    talk) 22:56, 18 February 2009 (UTC)[reply
    ]
12. Oppose We already have mechanisms in place to do these things and that there does not seem to be an excessive demand on these resources. This is a solution looking for a problem. Has anyone asked the crats if they even want this power?
    Chillum 02:29, 19 February 2009 (UTC)[reply
    ]
13. Seems to be a solution in search of a problem. --Regent's Park (Rose Garden) 02:44, 19 February 2009 (UTC)[reply]
14. Gain consensus on the circumstances and process for deciding removal is necessary, in non emergency cases, first, else this is going to cause far more problems than it solves. Stewards do fine now, by virtue of not deciding. Emergencies are handled fine, and clearcut requests are handled fine. Other cases should not be handled at all. ++Lar: t/c 03:55, 19 February 2009 (UTC)[reply]
15. Per JayHenry. Mike R (talk) 13:58, 19 February 2009 (UTC)[reply]
16. Unnecessary removal of an extra check and balance, I don't want to validate people who spend their time coming up with things like this. Can we get back to doing useful things now? — Werdna • talk 06:34, 20 February 2009 (UTC)[reply]

    What is that meant to mean, "I don't want to validate people who spend their time coming up with things like this"? Since when did this become personal? —Anonymous Dissident^Talk 00:17, 21 February 2009 (UTC)[reply]

17. I'm not aware of any situation in which damage of any consequence was caused because someone was not desysopped quickly enough. Solution in search of a problem?  Sandstein  18:12, 20 February 2009 (UTC)[reply]
18. Whilst I agree that the idea of having the desysoping handled in-house is in principle better than being handled by the stewards, I cannot support this idea as it represents a concentration of the power with regards to user rights solely to the bureaucrats. If desysoping is decided needs to be done on en.wiki instead of meta, proper separation of powers must be maintained. The proper authority to have the technical ability to desysop are those that are elected to adjudicate complaints—Arbcom. -
    talk) 21:58, 20 February 2009 (UTC)[reply
    ]

    Until there's a system in place that authorizes bureaucrats to desysop in additional situations (chiefly, an RfDA), the authority will still remain just as much with ArbCom as it is now. EVula // talk // ☯ // 22:16, 21 February 2009 (UTC)[reply]

19. Oppose, as having the mop isn't a big deal, right? Well, then letting a select few decide who can or cannot have the mop misses that point. -- Kendrick7^talk 05:50, 22 February 2009 (UTC)[reply]

    I am afraid that you missed the purpose of this proposal. It is not to give bureaucrats power to judge who should or shouldn't have adminship, but to give them the technical ability to take it away, not community support to take adminship away willy-nilly. NuclearWarfare _(Talk) 17:12, 22 February 2009 (UTC)[reply]

20. Stewards have to undergo an annual confirmation process. Crats don't. Until there is a process that brings the standards of rights management up to at least meta, this looks like a carte blanche. If implemented, it's only a matter of time pitch forks and torches waiting outside ArbCom becomes a more frequent affair. -
    Mailer Diablo 19:12, 22 February 2009 (UTC)[reply
    ]

    I felt the same way when the community wanted oppose sections for the CU/OS elections. And I must admit, the drama was kept to a minimum and I was wrong. But don't you think Arb Com would decline the "witch hunt" cases? Synergy 20:00, 22 February 2009 (UTC)[reply]

    ArbCom will decline the "witch hunt" cases, but I doubt it would actually end there. When a crat's position becomes untenable (Assuming that only ArbCom can fire crats and there are no other avenues of recourse) as a result of a controversial action, the drama would just simply spill over elsewhere and will keep occuring until he/she resigns. Confidence in the RfA system is pretty fragile these days due to cases as brought up by JayHenry. Even having a simple election process (one-time for purpose of this proposal or periodical) would help to remove crats we think that we do not trust today while keeping drama, during the election and in future RfAs, to a minimum. -

    Mailer Diablo 06:54, 23 February 2009 (UTC)[reply

    ]

21. I am not convinced of the merit of enacting this measure at the current time. The stewards have done a good job thus far and the current pool of bureaucrats have no remit to carry out this type of action. This seems to me to be a solution looking for a problem. Rje (talk) 15:23, 23 February 2009 (UTC)[reply]
22. Oppose per JayHenry (#6 above), Ruslik (#9) and Mailer Diablo (#20). --A. B. ^{(talk • contribs)} 19:07, 24 February 2009 (UTC)[reply]
23. Oppose per Daniel, Avruch, Ruslik, Werdna ("removal of an extra check and balance" are my thoughts exactly) and Mailer Diablo. --
    :. 20:24, 24 February 2009 (UTC)[reply
    ]
24. Oppose Desysoping is a big step and needs the eye of an external person. Zginder 2009-02-25T00:43Z (UTC)
25. Oppose - per
    Mailer diablo (talk · contribs). Cirt (talk) 10:37, 28 February 2009 (UTC)[reply
    ]
26. Strong Oppose per
    moving goalposts. This proposal gives me some satisfaction as I've said before on wiki to be careful of who you vote for in RfBs, because they can always change the rules to give them actual power. This proposal illustrates how right I was and how short sighted the people who didn't listen to me were. o;) So while all those innocent short-sighted people were judging past RfBs by competence on name change procedure, closing RfAs and such like, little did they realise they should have been considering a wide range of other things. Preposterous. Bureaucrats were elected to perform a few intricate procedures needed to be done by a few people. Not to form a corps of Judge Dredd mini-arbitrator/super-admins. If the community feels they need a more powerful group of judge dredds in addition to the new Arbom, they should ask that question first and only then come up with way to achieve it, a way that doesn't involve hoodwinking previous users and changing the meaning of their good-faith participation in past RfBs. Deacon of Pndapetzim (Talk) 18:36, 28 February 2009 (UTC)[reply
    ]

    The same point could be made about administors though. To take a recent example, which of the present admins were chosen because of their skill or competence in writing abuse filters? --

    Fatuorum 16:45, 3 April 2009 (UTC)[reply

    ]

27. Per the tests below, getting a steward is actually easier than getting a bureaucrat.
    talk) 09:51, 6 March 2009 (UTC)[reply
    ]
28. Strong Oppose Giving crats this power can well cause big problems if we have one to go power hungry. Don't fix something thats not broken. I would write more but Deacon of Pndapetzim covered it for me. —Preceding unsigned comment added by Shawnpoo (talk • contribs) 01:12, 8 March 2009 (UTC)[reply]
29. Strong Oppose. I see no reason for this action to be taken. This will undermine the authority of stewards (of which I am not, so I have no conflict of interest). I think it is better to keep the current user rights to have a more fair balance of powers. -Axmann8 (Talk) 04:09, 13 March 2009 (UTC)[reply]

    comment This user has been indef blocked from Wikipedia. — BQZip01 — ^talk 01:12, 6 April 2009 (UTC)[reply]

30. Oppose The ability to de-sysop needs to be held to an even higher standard to someone unbiased like stewards. LetsdrinkTea 15:31, 15 March 2009 (UTC)[reply]

    Its interesting you specify "the ability" only is to be held to a higher standard (implying that a crat is biased somehow in this process). You do realize that this is an impartial act in and of itself, that crats would not be using discretion or judging consensus, right? I'm wondering how you think a crat is biased and a steward is not. Because this doesn't seem to make a whole lot of sense. Synergy 20:24, 25 March 2009 (UTC)[reply]

31. Oppose - Per Letsdrinktea; sums it up well.
    Scarian^{Call me Pat!} 18:04, 25 March 2009 (UTC)[reply
    ]
32. Oppose - Per Letsdrinktea; I suppose the major reason proposed for this is to enforce campaign pledges regarding recall but the stewards can see what was promised and whether the conditions for recall have been met without having been "involved" in any of the issues themselves. Carlossuarez46 (talk) 20:07, 25 March 2009 (UTC)[reply]

    How did you come to that conclusion? No where in this proposal is there any mention of enforce campaign pledges. Synergy 20:30, 25 March 2009 (UTC)[reply]

    In several recent RFAs the issue of recall pledges and are they enforceable has come up and why would the 'crats need this power independent of the arbcom? The arbcom has done some very quick desysopping when someone goes bezerk, but the real reason to my mind is to make admins who promised to be open to recall actually recallable without resort to the arbcom to determine whether the conditions precedent to recall have or have not been fulfilled. Carlossuarez46 (talk) 23:55, 26 March 2009 (UTC)[reply]

    I believe you misunderstand something here. When arbcom has someone -sysoped, they bring it to the stewards. The difference in this situation is that they would bring it to

    WP:BN or a similar noticeboard watchlisted by crats (keeping it on this wiki). This proposal has no addage or policy discussion revolving around an avenue to have someone -sysoped (clearly mentioned on the proposal page). This proposal is only to allow crats the ability to perform the actions, and use it the same way a steward would. Nothing more. Synergy 00:03, 27 March 2009 (UTC)[reply

    ]

33. This is a solution in search of a problem. Do we have a desysopping backlog that we need more people with the ability? No. Then there is no problem to solve.--Scott Mac (Doc) 21:51, 26 March 2009 (UTC)[reply]

    This is not a solution in search of a problem Doc. As I've said before. Just because something isn't broken, doesn't means we cannot have a proposal to change a specific situation. Synergy 00:03, 27 March 2009 (UTC)[reply]

    When something isn't broken, then there is no point in fixing it. One should only change things when there is a reason to - this is the classic definition of a solution in search of a problem. It isn't broken, so no problem. So why a solution?--Scott Mac (Doc) 00:45, 27 March 2009 (UTC)[reply]

    Thats the problem here. This isn't a solution. Its a suggestion. Synergy 01:14, 27 March 2009 (UTC)[reply]

    Synergy, we now have an larger power-expanding ArbCom that is desysopping by motion. To the extent that there was ever a problem, it's actually just about solved. Anyone who understands the current ArbCom will surely realise this, I think. Deacon of Pndapetzim (Talk) 16:24, 3 April 2009 (UTC)[reply]

34. Same than Doc above, is there an emergency desysoping epidemic that we should be aware of? Otherwise, I prefer having desysopings done by people outside of the en.wp community. -- lucasbfr ^talk 13:56, 27 March 2009 (UTC)[reply]
35. Weak oppose Don't think it is necessary. Any desysoppings we need done can be easily and quickly done through Meta. Also, there is also the potential risk of an b'crat account being hacked into, and I feel that desysops need to be carried out by someone who has an even higher amount of trust -- I agree with Letsdrinktea above. ♪Tempo di Valse ♪ 20:22, 27 March 2009 (UTC)[reply]
36. Oppose as an admin I would accept desysopping by any qualified officer if I deserved it. But I do not see any need to change the existing system. If it aint broke, don't fix it. --
    ^"talk" 21:32, 27 March 2009 (UTC)[reply
    ]
37. Oppose We need a outsider to confirm requests, as removing sysop is much more of a big deal then getting it, and for that, we have stewards. Techman224^Talk 20:34, 30 March 2009 (UTC)[reply]
38. Conditional oppose: We do not have a controlling policy for crat' desysopping, and while I know we like to fly by the seat of our pants on Wikipedia, in this case this is cart before the horse. Thus I oppose unless there is at least rough consensus, on a rough outline of a controlling policy.--Tznkai (talk) 15:22, 3 April 2009 (UTC)[reply]
39. Oppose I fail to see how this would benefit Wikipedia. Anti-admin crusaders make it seem like desysopping an admin is some Herculean task. It really isn't. And like Daniel above, I like the idea of an uninvolved party casting an eye over these things, just to make sure everything is running smoothly. I see no benefits, but I do see drawbacks. faithless (^speak) 17:22, 3 April 2009 (UTC)[reply]
40. Oppose Bureaucrats have limited and finite powers, voting for someone as a bureaucrat to take care of details is a far cry from voting for someone to make far-reaching decisions for the community. --KP Botany (talk) 06:35, 7 April 2009 (UTC)[reply]

Comments/Discussion

1. This is an interesting proposal and I'm curious as to how the consensus will resolve. Personally, as an active Crat, I feel it inappropriate to weigh-in, but please be aware that this is not an advance criticism of any Crat who does choose to opine! --Dweller (talk) 12:24, 18 February 2009 (UTC)[reply]
2. Just on the note of a crat messing up and needing to undo a promotion, of the 1,000+ promotions at enwiki, only once has a promotion been undone because of crat error, and this was in 2005 during the formation of the % standards for RFB, so it is rather infrequent. MBisanz ^talk 14:02, 18 February 2009 (UTC)[reply]

   I agree that its rather infrequent, but there was an accident just last month that needed to be corrected (when Rlevse had the problem of renaming Xenocidic), through no fault of Rlevse. Accidents happen, and I'm sure all crat would want to correct these small mistakes themselves. Synergy 15:31, 18 February 2009 (UTC)[reply]

   That was a technical error, and required technical intervention (which I performed). I'm not sure where bureaucrats being able to desysop would be able to help there... — Werdna • talk 23:07, 20 February 2009 (UTC)[reply]

3. Further comment; stewards cannot involuntarily remove rights on wikis where they are involved, so for instance, DerHexer who is an admin here and has 75,000 edits here, cannot desysop someone when arbcom passes a desysopping finding. How would such situations (involuntary v. voluntary) be handled, since crats are inherently involved in the English Wikipedia. Also, the steward policy has an explicit section preventing stewards from enforcing arbitration decisions if they are an arbitrator at the wiki where the decision was made. We have one current and four former arbs who are also crats. How would their role work in this policy? MBisanz ^talk 14:57, 18 February 2009 (UTC)[reply]

   About the first issue - if I understand correctly, stewards are forbidden from "changing rights" on wikis they are active on. If a 'crat who is also a steward is allowed to promote a user to adminship, and this decision passes, he should also be allowed to use his 'crat ability to revoke adminship. עוד מישהו Od Mishehu 15:37, 18 February 2009 (UTC)[reply]

   The easiest answer is that Stewards are not Crats, and En.wiki is not Meta. I'm not sure what you mean by "involuntary" (but if its what I think you are getting at, I will ask all of the crats). As to how this would be handled, I believe it would be the same as promotion. Its not a personal action to +sysop or -sysop. A crat can recuse himself from taking action, and leave it for a less involved one. And again, a steward is not a crat; so former arbs who are also crats would mean very little when removal of access is needed. If the arbitration committee passes a motion to remove a sysop bit, it can be addressed on

   WP:BN and crat can remove the access. Synergy 15:44, 18 February 2009 (UTC)[reply

   ]

   I mean something like what happened when a crat did have the ability to desysop (in the ancient era), see Wikipedia:Wikipedia Signpost/2005-03-07/Block war and desysoping. Do we really want to have that sort of thing happen again? MBisanz ^talk 16:42, 18 February 2009 (UTC)[reply]

   As I told you on irc, I must have more confidence in our crats if you need to pull out a situation from 2005. So much has changed since then, I seriously doubt our crats would be wheel warring. But even if they did, a RfAR would be filled and actions would probably come to a halt. Synergy 19:43, 19 February 2009 (UTC)[reply]

   Ok, and this, this, this, this, and this? MBisanz ^talk 19:59, 19 February 2009 (UTC)[reply]

   Please be kind enough to explain which case(s) listed above show crat wheel warring because I don't see it (and I only skimmed a few, the others I knew about). What I see though, is exactly the thing I would expect. Someone disagrees with an action (whether it be editing, admin actions, or crat actions), there is discussion, discussion, discussion. Synergy 00:59, 20 February 2009 (UTC)[reply]

4. More questions; Sometimes crats disagree on a promotion, at Meta there was one "crat war" I can think of [2] involving the cratting and de-cratting of a user whose RFB was disputed. How would such disputes be handled under this policy? MBisanz ^talk 15:04, 18 February 2009 (UTC)[reply]

   I'm having trouble finding a situation in which another crat would disagree with: a self request to remove the bit, obvious mistakes, and arb com requests. If there is "doubt" in the air, I suppose the crats can talk it out, like any other editor. Disputes would be handled the exact same way a promotion would. One thing to remember, is that since we have no process for revoking the bit (such as recall, reverse RfA's or RfC's), there is no room for disagreement (unless a crat contests an arb com decision). Synergy 15:51, 18 February 2009 (UTC)[reply]

   What about emergency desysops? Even arbcom is struggling to define what sort of emergency is worthy of desysop. Can crats who may know the admin in question or may have been involved in editing with them be relied upon to judge what sort of emergency requires action? MBisanz ^talk 16:15, 18 February 2009 (UTC)[reply]

   That wasn't an RFB. That process is similar to the RFR process here. Majorly talk 16:18, 18 February 2009 (UTC)[reply]

   Emergency desysops will sooner or later be defined by either the community or ArbCom. And wouldn't that be the same as "arb com requests" then? Regardless. After discussion, if it was found that a crat removed someones bit innapropriately they can reverse it, just as easily through a consensus or agreement. Synergy 19:43, 19 February 2009 (UTC)[reply]

5. I am a strong supporter of making it easier to remove the bit, which means granting more people (such as crats) the ability to remove it. IMO, if we could find a way to make moving in and out of adminship easier, then RfA would become less of an ordeal than it is right now. I'd like to see a process that is more streamlined in the vein of giving Rollback to people. We can give rollback out without much thought because if the person abuses it, an admin can quickly revoke that priviledge. One of the problems with RfA right now is that it is for life. Once you get the bit, it is easier to get somebody to go to the Dentist than it is to get it away from them. And it requires so much drama to remove the bit, because once it is removed it is that much tougher to get it back. We should make it easier and as pain free as possible to give and take the bit away...
   ^{The artist formerly known as Balloonman} 15:47, 18 February 2009 (UTC)[reply
   ]

   I share your concerns, but that is not what this proposal is about. Synergy 15:53, 18 February 2009 (UTC)[reply]

6. As I read this it's regarding the technical ability, not the authority to make the decision. IMHO except for emergencies, this should be two different people or groups of people. Even in emergencies it's nice if you can have two people involved as a sanity-check, but that's not always possible. For example, if an admin created a runaway bot that blocked people a few per minute, there's no time to find help, the first person with desysop power should desysop the account ASAP and ask questions later. davidwr/(talk)/(contribs)/(e-mail) 16:38, 18 February 2009 (UTC)[reply]
7. I'd note that this straw poll is, I think, somewhat preliminary. As several others have mentioned, this proposal concerns the granting of the technical function; the policy that will need to surround its usage has not been formulated, yet. Such formulation will probably be the result of further discussion, and, depending on what happens, possibly another straw poll. I'm not sure. But the importance of making this policy should not be forgotten. —Anonymous Dissident^Talk 21:07, 18 February 2009 (UTC)[reply]
8. Currently, sysoping of users and desysoping are in different logs. This, in my opinion, reduces the overall purpose of the logs - transparency. עוד מישהו Od Mishehu 09:11, 19 February 2009 (UTC)[reply]

• I'm not too clear on the opposing arguments. Is there really a problem in need of a solution, yeah, that's a legitimate question. But as for the possibility of erroneous use, I don't see the issue. Obviously if the ability is overused then this change will be rethought, but I doubt it'll come to that with crats. And even if on occasion a mistaken de-op occurs and is reversed -- let's say -- a day or two later, does that really cause some kind of harm? I thought admin rights aren't supposed to be a big deal. Equazcion •✗/C • 20:25, 18 Feb 2009 (UTC)
• In addition: In the grand scheme of things, there's already nearly two thousand people who can (legitimately or erroneously) block you from editing altogether. This proposal would basically give 30 of them the additional ability to invoke a limited blockage of admin rights alone. Does this really even constitute any additional risk at all? Equazcion •✗/C • 20:57, 18 Feb 2009 (UTC)

• The sole advantage this brings to our community, where, unlike other projects, there is no regular reconfirmation of the entire administrative community, would be to bring to the local sphere certain requests that currently have to be taken to the Stewards.
  As for the Stewards' response time, which also speaks to the question of emergency desysopping, it is true that they used to take quite a while to take care of requests. But that has changed considerably since 2006. Considerably. Requests are now usually attended to very quickly, and emergencies are dealt with accordingly. In that sense, it is a non-issue to assume that we need to localize the handling of desysoppings because we need it to be done in a timely fashion.
  So here are the answers I see to some basic questions: 1) Is there a true need for the Bureaucrats to hold the technical ability to desysop? No. Not really. 2) But could it not bring the project some kind of advantage? Yes, in the sense that ArbCom members and resigning admins will be able to post their requests on this Wikipedia, instead of going to another one, where they might be less familiar with procedures and such. But considering that having to make the request to the Stewards is not a problem, this is not really problem-solving, just a different, arguably more practical system. And the huge bottom line: 3) So should Wikipedia-en have Bureacrats with the ability to desysop? Strictly a matter of opinion. There is no policy that demands it, and there is no policy or other barriers that prevent it. But this is as much about the Stewards as it is about the local Bureaucrats. If the community feels that it is more convenient for us to localize the desysopping procedure, then have the local Bureaucrats do it when and as instructed; if we feel that the Stewards are able to do the job, and this is the actual point, with the expeditiousness we see as necessary, then there is no need at all to change the current role of Bureaucrats. Simple as that. Redux (talk) 18:16, 19 February 2009 (UTC)[reply]
  • I think you've hit the nail on the head. Completely. This is for improvement, not because it is necessary. That is to be conceded. —Anonymous Dissident^Talk 23:10, 19 February 2009 (UTC)[reply]
  • For as much of a supporter of this proposal as I am, I'd like to point out that I in no way think this is a pressing, dire need; I acknowledge that there's nothing inherently broken about the existing system (aside from the fact that it's a bit more fractured than I think it needs to be), or that I think the end of Wikipedia is near if we don't implement this proposal. I just think it's a good idea in the long run; I pretty much just agree with Anonymous Dissident (but in a far more verbose way). EVula // talk // ☯ // 05:27, 20 February 2009 (UTC)[reply]

• Sticking to what I said about this bringing a purported logistical advantage to the project, but not being a necessity, perhaps it would be possible to bring a measure of objectivity to this: we should ask the people who would be more directly affected by this. And no, that does not mean the Bureaucrats. Considering that emergency desysopping is more of a rare affair, the bulk of the work would be coming from voluntary resignation from Administrators and carrying out eventual ArbCom decisions to remove Admin rights. That means that the people who stand to be affected more directly (although this does affect the entire project, obviously) are exactly the Admins and the Arbitrators. Obviously, we can't predict who will be resigning their adminship in the future, but any administrator can carry the hypothetical exercise of asking oneself: "if I ever were to resign my adminship, would I consider it more practical to be able to ask the local 'crats or is it just the same to take this to the Stewards?" (taking into account that we now have SUL, so it is now considerably easier to go over to the Meta-Wiki to make this request). As for the Arbitrators, there's less conjecture, we might simply ask them if they think that their work would be made easier in RfAr's where adminship is revoked if they were to make requests to the local 'crats, instead of the Stewards.
  As for emergency desysopping, it is perhaps worth stressing out that none of what is being discussed here completely prevents the Stewards from intervening. Foundation Policy provides that the Stewards can act on any project if it is an emergency and local users with the tools to resolve the situation, if there are any, are not immediately available. So even if the 'crats were to be given desysopping abilities, that does not mean that the Stewards can no longer act, and if no crat is available the emergency desysopping will have to wait for as long as it takes. This change, if it were to take place, would only add one task to the Stewards: making sure that the local 'crats could not be reached immediately before the request can be attended to by a Steward. If it's an emergency and no 'crat is on call, the Stewards are in fact obliged by policy to intervene. So one thing doesn't really preclude the other, at least not completely. Redux (talk) 22:07, 26 February 2009 (UTC)[reply]
• In my opinion, this proposal has a chemistry with the proposed calls for reform for admin recall. I feel that, yes, bureaucrats should the ability to de-sysop, but only in the case of self-request or ArbCom order. Stewards will obviously be able to handle runaway requests faster, and should be more unbiased than bureaucrats when it comes to some type of recall consensus process, if passed. At this point, I don't feel comfortable supporting or opposing.
  talk) 23:54, 25 March 2009 (UTC)[reply
  ]

1. talk) 14:41, 18 February 2009 (UTC)[reply
   ]
2. –Juliancolton ^{Tropical Cyclone} 14:46, 18 February 2009 (UTC)[reply]

   I'm wondering if (Stifle and Julian) you could expound a bit on why you think this is "early". We've already had a proposal in October that would have granted the same right, while also attaching a process for using the tools. Removing the process, and letting crats reverse an action only needs a vote. Its a pretty clear idea (unless of course an editor doesn't understand the process through Meta, etc). Synergy 14:48, 18 February 2009 (UTC)[reply]

   m:Voting is evil (although I already supported the proposal). –Juliancolton ^{Tropical Cyclone} 14:57, 18 February 2009 (UTC)[reply]

3. While I am in favor of this idea, I have to agree, discussion needed to happen first, to reach a reasonable idea of what we were talking about and iron out some of the issues.
4. Would be good to see some definition of what the -sysoped user's appeal avenues would be if they felt they were wrongly -sysoped by a 'crat.
   Townlake (talk) 16:19, 18 February 2009 (UTC)[reply
   ]
5. The authority question comes before the technical question. You don't give a group of users the technical right to make a change and leave unclear the norms surrounding the change. If we say "crats should never desysop", then we have no reason to give this right (at all). If we say "crats should desysop", then we can have this discussion (whether we want them to or want them to ask a stewart or want them to be temp-stewarts or whatever). If we say "we don't know whether or not crats should desysop", then the technical question is completely inappropriate. Who wants to have a crat desysop JzG (just for an example) and then defend the decision by saying that no one forbade it? Do we want to have that dramafest? Cart must not come before horse. Protonk (talk) 18:48, 18 February 2009 (UTC)[reply]
6. To answer Protonk's question, not me :-) If this is an attempt to override the current system for desysopping by the back door, then no thanks. If it is fixing an actual problem - meaningful numbers of emergency desysoppings delayed due to lack of availability of a steward - then it's worth considering. What is the actual present problem it fixes? How many desysoppings in an average week, and what's the delay for emergency desyoppings? Guy (Help!) 19:18, 18 February 2009 (UTC)[reply]

   I believe the delay for the last emergency desysopping was 4 minutes from a compromised account editing in a compromised manner to the steward desysopping it. MBisanz ^talk 19:46, 18 February 2009 (UTC)[reply]

7. Protonk. Nail. Head. - Dan
   push to talk) 19:54, 18 February 2009 (UTC)[reply
   ]
8. No offense to all the admins but I really don't see the big deal here. Seriously. You're worried about 30 people getting to ability to de-op? Why? 1,700 people already have the ability to block you altogether. Just humor me. What is the big freaking deal? Equazcion •✗/C • 22:36, 18 Feb 2009 (UTC)

   Actually giving crats the authority (after whatever process we pick) isn't a big problem with me. Giving them the technical right to desysop me without first clarifying when they should do it is a recipe for drama. I supported whatever the last de-admining proposal was (can't keep track of them), not sure how others here feel. Protonk (talk) 22:43, 18 February 2009 (UTC)[reply]

   When they should do it seems to be outlined well enough at the proposal page. Disregarding that though, how much more drama would a block create? The crats can already block you. Now they'd additionally be able to merely de-op you while letting you contribute normally. Besides which, if we're concerned about de-opping causing drama, then we all really need to re-think who we make into admins. Equazcion •✗/C • 22:56, 18 Feb 2009 (UTC)

   How we make admins is another question. People seem to think that there is some magical process by which no admin will ever cause drama and that if we merely rework RfA into that process our problems will be solved. I've got some news for those folks. There exists no such magic process. Apart from that, the normative expectations and constraints for the crats using this (specifically, that they would only do it as directed a la a steward/t...w/e)are part of the proposal, not agreed upon already. Honestly what we need is some system by which de-adminning requires more than an angry mob and less than an act of god. That will offer some tangible benefit. Technically changing the rights of a crat to lower the compromise to desysop time from 4 minutes to 3:30 is less of a gain. Protonk (talk) 04:01, 19 February 2009 (UTC)[reply]

   I shouldn't have mentioned the "RfA sucks" thing. Regardless of it being a small part of my point, it was asking to be pigeonholed. So again, my main point was that a big deal is being made about giving people who can already block you from editing altogether the additional ability to just de-op you. I don't see how this isn't a no-brainer. Equazcion •✗/C • 04:11, 19 Feb 2009 (UTC)

   That's fair. I shouldn't have jumped on it. My main point is that this is useless (if crats are just going to stand in for stewards), undefined (if we haven't agreed what they should be doing), or dangerous (if some feel this lets them desysop for reasons not explicitly agreed upon). Again, we are probably on the same side vis a vis admin recall. I think we need to get a decent "non emergent" desysopping procedure down. However, absent that, we don't really have much reason to flip a bit for the crats. Protonk (talk) 04:19, 19 February 2009 (UTC)[reply]

   This is a rare argument for me but under the circumstances I'm going to say there's no reason not to. I'd be more likely to share your concerns over misuse if it weren't just crats we were talking about. As far as I understand the Usage section of the proposal, they'd basically be acting in a technical capacity to de-op once a decision has been made elsewhere, the same as stewards do currently. And given the fact that they can currently grant adminship, it makes sense that they should be trusted to handle revocation as well. Newyorkbrad makes a good point below, that we should examine what led to their current half-capacity as granters but not revokers, however I suspect that this is by chance rather than by design. I also need to repeat my point that a block is a de-op plus, which they can already do, so I don't see the harm in granting them the lesser de-op ability as well. Community de-op seems like an issue that wasn't meant to be part of this proposal and needs to be discussed separately in a larger venue. Equazcion •✗/C • 04:41, 19 Feb 2009 (UTC)

   I'm not worried about technical misuse. I think we are selective enough with crats (ask anyone about RfB rants) to generally avoid that. I'm worried about us giving them a right and then saying "we still haven't figured out when you can use this" For example, I have the technical ability to take rollback from you. Let's pretend that there wasn't some community consensus about when it would be ok to take rollback from you (Let's say admins can hand it out but crats can take it back...or whatever). If the consensus is, "Never, ever take rollback away from a user", giving me the technical ability to do that is not a problem. But if the consensus is somewhat more murky and we give me the tool, the situation is different. Do I take it from you and risk an uncertain response? What if I do and you protest? I could block you, but blocking you and taking away rollback are two different things. Just like blocking an admin and taking away the tools are two different things. Besides, I can block an admin. :) I agree that in the event that the community says "de-sysopping is only for cases where stewards would be asked to do it anyway", my complaint is minimized. Protonk (talk) 05:19, 19 February 2009 (UTC)[reply]

   ←Do we have community consensus on when stewards, specifically, can de-op? My understanding is we already have consensus on the situations in which an admin can be de-opped. I don't think which specific rights group is responsible for the technical bit-switching was a part of that consensus, and doesn't require a separate discussion. As you say, "...de-sysopping [by crats] is only for cases where stewards would be asked to do it anyway" -- I see that as being exactly the present proposal -- but someone should either correct me if I'm wrong or modify the proposal page to state this more clearly. Equazcion •✗/C • 05:28, 19 Feb 2009 (UTC)

9. My honest view. I think it'd have been nice to take a longer time to consider the policy, to draw it up and to have general discussion before taking it to such a sobering, such a straight-forward and black and white process. —Anonymous Dissident^Talk 10:25, 19 February 2009 (UTC)[reply]
10. I think that this needs more discussion and more people before we do a poll again. Techman224^Talk 00:36, 3 March 2009 (UTC)[reply]
11. I don't believe polling is currently warranted. A community discussion period is needed, which must be much more widely advertised. Espresso Addict (talk) 00:07, 4 March 2009 (UTC)[reply]
12. Where is the discussion on why turning on this flag for 'crats is desired? I am not going to !vote either way until I have some understanding in how a 'crat may use this ability in accordance with some new process which I may or may not support. LessHeard vanU (talk) 19:42, 3 April 2009 (UTC)[reply]