Wikipedia talk:Removing administrator rights/Proposal 2

Straw poll

This straw poll is for granting crats the technical ability to desysop.

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

---

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)
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)
3. Per above. MER-C 08:19, 18 February 2009 (UTC)
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. rootology (C)(T) 08:21, 18 February 2009 (UTC)
5. Makes a lot more sense than what's happening now. Xclamation point 12:00, 18 February 2009 (UTC)
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)
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)
8. Support - Adminship is not a big deal. It should not take a Steward to remove it, seeing as they are supposed to be working on global issues. Yellowweasel (talk) 13:23, 18 February 2009 (UTC)
9. No big change. No big deal. --Deskana (talk) 13:25, 18 February 2009 (UTC)
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. Richard⁰⁶¹² 14:32, 18 February 2009 (UTC)
11. –Juliancolton ^{Tropical Cyclone} 14:46, 18 February 2009 (UTC)
12. Yes, enwiki bureaucrats should/are trusted enough to desysop, and making things more local is not a bad thing. Camaron | Chris (talk) 14:55, 18 February 2009 (UTC)
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)
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)
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)
16. Support - per Od Mishehu, Ironholds and TKD. Crats should have the technical ability to desysop. AdjustShift (talk) 16:12, 18 February 2009 (UTC)
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)
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)
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)
20. Support Sensible idea. Colonel Warden (talk) 16:47, 18 February 2009 (UTC)
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)
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)
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)
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)
25. nice idea, let's see how it works. —_macy 18:14, 18 February 2009 (UTC)
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)
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)
29. Support - Seems logical. — neuro^(talk) 20:54, 18 February 2009 (UTC)
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)
31. I trust en.wp's local 'crats more than stewards actually. Icewedge (talk) 02:39, 19 February 2009 (UTC)
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)
33. iMatthew // talk // 21:17, 19 February 2009 (UTC)
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)
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)
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)
37. Seems an obvious and non-controversial extension of current practices. DGG (talk) 02:08, 20 February 2009 (UTC)
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)
39. — Jake Wartenberg 00:20, 21 February 2009 (UTC)
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)
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. Master&Expert (Talk) 04:52, 22 February 2009 (UTC)
42. Support Good idea.--Patton^t/c 20:10, 22 February 2009 (UTC)
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)
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)
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)
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)
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)

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

    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)

48. Support - I don't see any problem here. Trusilver 16:52, 25 February 2009 (UTC)
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)
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)
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. Beeblebrox (talk) 22:03, 28 February 2009 (UTC)
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)
53. Support. It would be useful for the community. These are already trusted positions. – Quadell ^(talk) 19:47, 2 March 2009 (UTC)
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)
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)
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)
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).
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)
59. Malinaccier (talk) 22:50, 8 March 2009 (UTC)
60. Support Seems reasonable. Mister Senseless™ (Speak - Contributions) 02:34, 9 March 2009 (UTC)
61. Support — it's silly that bureaucrats can give adminship but not take it away. *** Crotalus *** 14:20, 10 March 2009 (UTC)
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)
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)
64. Support this sound and logical proposal.—S Marshall ^Talk/_Cont 00:17, 24 March 2009 (UTC)
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)
66. Suppport as reasonable. Bearian (talk) 23:09, 24 March 2009 (UTC)
67. Support. Can't see a compelling reason not to.--Father Goose (talk) 07:00, 25 March 2009 (UTC)
68. Support - Nsaa stated it well. لennavecia 03:30, 26 March 2009 (UTC)
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)
70. Support It would be foolish to outsource something like this. --Rschen7754 (T C) 19:07, 28 March 2009 (UTC)
71. Support Lots of good reasons already documented above, I won't repeat them. Jclemens (talk) 22:54, 31 March 2009 (UTC)
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)

    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)

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)
74. Obviously. Simple common sense. --Malleus Fatuorum 14:20, 3 April 2009 (UTC)
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)
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)
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)
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!^{$\color {Red}\oplus$} 21:08, 4 April 2009 (UTC)
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)
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)
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)
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)

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)

   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)

   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)

   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)

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)

   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)

   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)

   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)

   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)

3. [1] Avruch ^T 13:15, 18 February 2009 (UTC)
4. Strong oppose per Daniel. — Aitias // discussion 13:45, 18 February 2009 (UTC)
5. No. Not necessary. That is what stewards are for. Apteva (talk) 15:08, 18 February 2009 (UTC)
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)

   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)

   I'd never heard of this WP:AGF essay, thank you for referencing this rarely-linked but always-instructive essay. Well, SoWhy, why don't you 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)

   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)

   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)

   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)

   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)

   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)

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)
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)
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)

   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)

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)
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. RxS (talk) 22:56, 18 February 2009 (UTC)
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)
13. Seems to be a solution in search of a problem. --Regent's Park (Rose Garden) 02:44, 19 February 2009 (UTC)
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)
15. Per JayHenry. Mike R (talk) 13:58, 19 February 2009 (UTC)
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)

    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)

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)
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. -Atmoz (talk) 21:58, 20 February 2009 (UTC)

    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)

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)

    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)

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)

    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)

    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)

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)
22. Oppose per JayHenry (#6 above), Ruslik (#9) and Mailer Diablo (#20). --A. B. ^{(talk • contribs)} 19:07, 24 February 2009 (UTC)
23. Oppose per Daniel, Avruch, Ruslik, Werdna ("removal of an extra check and balance" are my thoughts exactly) and Mailer Diablo. --.:Alex:. 20:24, 24 February 2009 (UTC)
24. Oppose Desysoping is a big step and needs the eye of an external person. Zginder 2009-02-25T00:43Z (UTC)
25. Oppose - per Daniel (talk · contribs), Rjd0060 (talk · contribs), and Mailer diablo (talk · contribs). Cirt (talk) 10:37, 28 February 2009 (UTC)
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)

    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? --Malleus Fatuorum 16:45, 3 April 2009 (UTC)

27. Per the tests below, getting a steward is actually easier than getting a bureaucrat. Stifle (talk) 09:51, 6 March 2009 (UTC)
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)
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)

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

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)

    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)

31. Oppose - Per Letsdrinktea; sums it up well. Scarian^{Call me Pat!} 18:04, 25 March 2009 (UTC)
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)

    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)

    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)

    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)

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)

    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)

    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)

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

    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)

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)
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)
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. --Anthony.bradbury^"talk" 21:32, 27 March 2009 (UTC)
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)
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)
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)
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)

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)
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)

   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)

   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)

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)

   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)

   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)

   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)

   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)

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

   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)

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)

   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)

   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)

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

   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)

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... user:Majorly is a prime example. A few months ago, he antagonized enough people that he gave up the bit during a nasty RfC that was on its way to ArbCOM. Majorly was a solid admin, but was just not himself. He's now working to redeem himself, and IMO should be given the bit back. Unfortunately, that won't happen in the near future because if he goes through another RfA people will fear a repeat of what happened last fall. If giving and taking away the bit were easier, then we wouldn't have the paranoia about giving it away that currently exists.---I'm Spartacus! ^{The artist formerly known as Balloonman} 15:47, 18 February 2009 (UTC)

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

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)
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)
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)

• 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)
  • 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)
  • 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)

• 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)
• 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. Jd027 (talk) 23:54, 25 March 2009 (UTC)

Polling this early is a bad idea

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

   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)

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

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)
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)
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)

   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)

7. Protonk. Nail. Head. - Dan Dank55 (push to talk) 19:54, 18 February 2009 (UTC)
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)

   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)

   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)

   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)

   ←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)
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)
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)
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)

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

Questions

Before !voting I wonder if anyone has answers to the following questions:

(A) Can anyone remember a specific instance in which this proposal would have affected the outcome or timing of a decision (e.g., there was a valid need to desysop someone immediately but the available stewards refused and a bureaucrat would have done it, or there was an undue delay in implementing a desysop because a steward couldn't be found)?

(B) How many stewards currently have a reasonable activity level on this wiki? Is the number likely to change materially after the current election?

(C) Is there any rationale for the current set-up, i.e. that bureaucrats can sysop but not desysop, or did it evolve for purely technical and historical reasons?

I'm not sure how I feel about this proposal, or whether I have real feelings one way or the other for that matter, but the above strike me as the relevant questions for folks to think about. Newyorkbrad (talk) 03:35, 19 February 2009 (UTC)

Question B should be answered for every minute of the clock. If there are no stewards available and aggressively monitoring noticeboards for more than a few minutes on any given day, but the rest of the day is covered by 10 stewards apiece, that's worse than if every minute is covered but most are only covered by 1 or 2 stewards. In other words, we need people with desysop capability spread around the clock. We may already have this, we may not. davidwr/(talk)/(contribs)/(e-mail) 05:15, 19 February 2009 (UTC)

I think that is excessive. Since steward presence or absence is functionally unobservable, all we need is enough active stewards distributed well enough about the day to make it likely that one is around. I don't think we need to imagine a scheming admin data mining steward contribution habits to find an optimum lull time and do something nefarious for 7 minutes instead of three minutes. Protonk (talk) 05:22, 19 February 2009 (UTC)

If there are occasional, unpredictable holes in the schedule, that's not a big deal. But if we know that 5 days out of 10 the time period from 0021Z to 0042Z is stewardless, then this should be addressed. I agree, data mining to find this answer is excessive. It's probably sufficient to poll stewards and ask "what times of day are you usually reachable, and what's the best way to reach you during that time" then set up a bot to alert them if someone makes an all-call for emergency steward action. If the results of the poll indicate holes, either ask the existing stewards to fill in the gaps, recruit additional stewards who can, add that duty to another trusted position so the hole can be patched, or create a position with the sole authority to do emergency desysopping so the hole can be patched. The first option is probably best but may or may not be doable depending on people's schedules, and last one is not a viable option. The third option, adding the duty to another group/'crats, is what we are discussing here. davidwr/(talk)/(contribs)/(e-mail) 14:26, 19 February 2009 (UTC)

User:DerHexer and user:Pathoschild come to mind for B. I can't remember an instance for A, in all honesty, and I think that fact is the cause of the assertions that this proposal is "looking for a problem", or is a "solution looking for a problem" and such. I respond to these arguments by saying that improvements to processes or norms "that ain't broke" are not necessarily superfluous or to be shunned. This proposal was never drafted in response to a problem or a recent drama; rather, it was written with the ambition of improving that which does, admittedly, already function to a certain degree of efficiency. It is my impression that many people are opposing this proposal because it appears to constitute change "for the sake of it", but these nay-sayers largely fail to explain why this would be damaging. On the other hand, a relatively small proportion of the participants express concern that the desysop function would actually come to abuse or clumsy usage, which is probably the issue that should be contemplated when partaking in the poll. As an aside, I've no answer to C and would be interested if someone could bring an answer or relevant links to the table. —Anonymous Dissident^Talk 07:53, 19 February 2009 (UTC)

As regards question C, there is no technical reason I'm aware of for the current situation, and there wasn't originally any real rationale for it. It's just that the bureaucrat right was originally created solely to ensure that a trusted group on the local wiki could create administrators; a task which was becoming increasingly frequent and inconvenient for developers to do. There was always an intention that other tools might be added later, and bot flagging and changing usernames were added, but de-sysoppings have been rare and there has not in the past been much call for local bureaucrats to take this role over from stewards (or, earlier, developers). Warofdreams talk 15:52, 19 February 2009 (UTC)

With regard to question B, any time that an emergency desysopping is required, there are some users who ask why it wasn't quicker. It usually takes a few minutes to alert a steward; for example, this case [3] took 17 minutes. I doubt anyone knows whether bureaucrats would be quicker to respond. Warofdreams talk 16:22, 19 February 2009 (UTC)

I hope that 17 minutes is an outlier. If my local police or fire dept. took that long to respond to a "highest priority" emergency, they would be reamed in the media. Granted, wikipedia isn't life or death but if it's an "emergency" vs. just "very urgent" no more than a couple of minutes is ideal. What's the worst an admin can do that could be fixed with an emergency-off button? Mass-deletes and mass-blocks are the only things I can think of. I doubt that has ever happened and I doubt it every would, but unless the software rate-limits these actions, it is possible. davidwr/(talk)/(contribs)/(e-mail) 18:12, 19 February 2009 (UTC)

The most recent emergency desysop response time was 4 minutes, and in my dealings with the stewards for things like interwiki account locks, the response time has been 1 to 2 minutes. Given there are 25 active stewards in all timezones and about a dozen crats active mainly in English speaking time zones, I think the steward response time tends to be much quicker and comprehensive. And don't forget that stewards, as part of their job, are expected to be highly available, crats as a general rule are not expected to maintain a minimum availability level (hours per week, etc). MBisanz ^talk 18:39, 19 February 2009 (UTC)

I hope that steward that took 17 minutes to respond to an emergency desysopping request got a pay cut. Protonk (talk) 01:19, 20 February 2009 (UTC)

In my mind, I see the bureaucrats being granted the right to de-sysop as being less a "it's out of the stewards' hands in an emergency," and more of a "there will now be roughly thirty more people who can handle such an emergency" situation. Protecting the project from rogue sysops is vastly more important than making sure political boundaries aren't crossed by stewards; an argument could be made that WP:IAR would apply in such a situation. EVula // talk // ☯ // 05:36, 20 February 2009 (UTC)

What influence will this proposal have on RFB? It is difficult to pass it now, and will even more difficult if this proposal is implemented. It can lead to deficit of bureaucrats. Ruslik (talk) 06:38, 20 February 2009 (UTC)

RfB is difficult to pass, yes. But it should be. I can't honestly foresee a time where the community adamantly refuses to promote additional bureaucrats in the face of a severe shortage. When we have a shortage of active 'crats, that's when RfBs tend to pass more readily. EVula // talk // ☯ // 06:47, 20 February 2009 (UTC)

I did not say that community would adamantly refuses to promote additional bureaucrats. I only said that fewer candidates will pass. Ruslik (talk) 06:52, 20 February 2009 (UTC)

But until we're facing actual problems related to a small number of bureaucrats (ie: RfXs go forever without closing, bots don't get flags, CHU requests go unfulfilled), it's not an actual issue. The exact promotion rate at RfB shouldn't be (in my opinion) a deciding factor in this. EVula // talk // ☯ // 06:54, 20 February 2009 (UTC)

Policy

I'd like to hear some thoughts and suggestions about a policy for this proposal. The policy, ideally, should only include the situations at which a crat can remove an admins bit. Synergy 21:21, 20 February 2009 (UTC)

Gee, the proposal we are voting on is that they would have no authority to use the tools, just the technical means. I doubt all the supports would be there if it was also a proposal to give them the authority to desysop. I say that our current methods of desysoping, either through arbcom or from on-high, works fine.

One of the great things about one group giving the power and a different group taking it away is that it prevent wheel warring between two 'crats who disagree. I know, they don't have a history of wheel warring, but they never really have had the chance before.

I want to see a demonstrated failure of the desysoping before I support anything like this. And I don't mean "wrong decision" failures, because we are not going to change how we make our decisions by putting the button in another persons hand. I really don't get what is meant to be accomplished here.

As it is, the stewards will accept any desysoping proposal that we have come to a consensus as a community about. So why do we need crats to do this? I wonder if people think that the crats will be more likely to accept a new method of desysoping than the stewards?

This whole things reminds me of "asking the other parent"(and I could be way off on this) in that people have been trying for an alternate method of desysoping without success for years and are now trying to give the power to a closer group, perhaps in the hopes they will judge consensus differently.

I suggest we first come to a consensus as to how people should be desysoped(even if we decide that it is just fine now), and secondly and only if there is a need consider giving more people the ability. This is all backwards. Chillum 14:53, 23 February 2009 (UTC)

Actually, as outlined here, they would have the authority to remove the bit in the same way a steward removes it, and nothing further. And I do hope the supporters read this proposal before supporting. When I asked the above question, I was thinking more along the lines of defining it further (i.e. how may one request removal, limitations such as the who, where and when, etc). In other words, by supporting this proposal, you are granting them not only the technical ability to desysop, you are granting them the authority to use it like a steward.

Prevention of wheel warring seems logical at first, and I'd agree with you. But upon closer inspection, we then would have to theoretically worry about steward wheel warring based on a disagreement. I also doubt that, with this proposals implementation, it would give cause to wheel war. Putting it another way... if a crat wheel wars, remove the crat, not the tool.

You and I both want to see a de-adminship process evolve, and one the community agrees on. But this could take a "very" long time (I'm almost tempted to predict RfA will go through a reform before a request for de-adminship takes shape).

Why do we need the crats to do this? Well, its not exactly like you say( perhaps in the hopes they will judge consensus differently ). Its really only to keep it here, on this wiki. I had been toying with the idea for some time, and noticed quite a few editors expressing an interest in seeing this happen.

As for your suggestion, its not feasible. We've already tried it, and its now rejected. Besides, a de-adminship process is not needed for this process to work. Synergy 02:49, 24 February 2009 (UTC)

Efficiency test

I just ran a random, unscientific test to compare the steward and crat response times at Wikipedia:Bureaucrats'_noticeboard#Crats_response_time. The first crat was on the scene 31 minutes after posting and I had a steward in the #wikimedia-stewards channel less than a minute after posting. MBisanz ^talk 23:09, 20 February 2009 (UTC)

I'm not sure if that was very useful though. Stewards are expected to be on call 24/7; bureaucrats are not. I don't think anyone is proposing to implement this to improve efficiency (at least, I hope not). NuclearWarfare _(Talk) 00:05, 21 February 2009 (UTC)

See this part of the proposal that was removed right before I started the "firedrill" [4] and Newyorkbrad's question above. MBisanz ^talk 00:18, 21 February 2009 (UTC)

As I've pointed out here, this test is without value. — Dan | talk 01:52, 21 February 2009 (UTC)

Did you also look for a bureaucrat on IRC and fail to find one? EVula // talk // ☯ // 22:18, 21 February 2009 (UTC)

Well Rdsmith popped up a couple minutes before you on IRC, but given that he's also a steward, it is sort of a wash in testing en-wiki-crat response time, but yes there were no users with only en-wiki-crat rights on IRC when I did the test. MBisanz ^talk 23:02, 21 February 2009 (UTC)

Do another test. Delete the main page and block Jimbo, see how long it takes for a response(grin). Chillum 14:56, 23 February 2009 (UTC)

• This is not a scientifically credible sample or methodology. Tony (talk) 13:43, 3 April 2009 (UTC)

...current bureaucrat cohort passed the grueling RfB procedure...

No offense to the bureaucrats, but I don't consider Wikipedia:Requests for bureaucratship/Pakaran or Wikipedia:Requests for bureaucratship/Bcorr to be "grueling" endeavors. How do people feel about the large number of semi-active crats and crats who are inactive in administrative matters being given this tool? I'm thinking for instance of Cprompt (talk · contribs) who has never made a crat action and TUF-KAT (talk · contribs) who last made a crat action in March 2004 (despite still being active editors). MBisanz ^talk 00:49, 21 February 2009 (UTC)

I feel they are extremely unlikely to use it. Skomorokh 00:52, 21 February 2009 (UTC)

To me, that is more related to WP:Requests for bureaucratship (reconfirmation), which the community is still against. In any case, it is no more different than those bureaucrats closing an RfA, which for some the community does not have a problem with. NuclearWarfare _(Talk) 00:54, 21 February 2009 (UTC)

Honestly... inactive crats should go. They were given the tools to help. This concept is really easy to understand. If you don't wish to help with these tasks, don't request the tools. If you're bored, and not interested, request their removal (they should not have them for status or trophy, obviously). On any other project I've edited on, its very easy to get rid of inactive bit-holders. Its harder here (on en.wiki), because we have many more users, and just can't get a single thing acomplished (you'd think it would be the opposite; more editors = more work done) with all the politics. Synergy 00:57, 21 February 2009 (UTC)

I don't see your point heere. There is no harm done by people holding the bit and not using it and the crat job isn't exactly something which often changes, which would require constantly getting up to speed. Admiral Norton ^(talk) 23:00, 24 February 2009 (UTC)

Its more directed toward the crats who have gained access to the tools, and either never used them, or no longer use them. We could fill those spots with energetic admins, eager to help. Why request access and not use the tools? Why request access, and no longer help? The tools do not exist to not be used. Its common sense that if you don't "need" it, and don't "use" it, you should not "have" it. Its extremely harder now, than it was in 2003-04 and before, to gain access to it. I could fully understand, for instance, situations such as TRM on vacation, etc. But what I can't understand, is that members of the community approve of letting crats exist just to "be there", stagnating. To me this is just another example of hanging on to a trophy, while never working for the status (yes, I will go this far and say that an RfB in 2003-04, which may have received 8-19 !votes does not stand up to an RfB with over 200). Synergy 00:54, 25 February 2009 (UTC)

Before someone says it: WP:PEREN. But I completely agree with removing bureaucrats who never bother using the tools, especially ones who passed in 2004 with 7 votes of people who aren't even active anymore... that's hardly trusted in the community is it? Majorly talk 01:00, 21 February 2009 (UTC)

There's always the Commons method: you have to perform x number of 'crat actions per six months or a year to keep the 'crat bit. rootology (C)(T) 01:01, 21 February 2009 (UTC)

Someone ought to just be bold and create a confirmation page for every bcrat who was promoted up to, say, 2007, to see if we're still confident with them. Majorly talk 01:03, 21 February 2009 (UTC)

Majorly.... that bold editor is you. :) Synergy 01:05, 21 February 2009 (UTC)

I think that's a very good idea. One who got a few number of support !votes from users who are not even active anymore a long time ago can not be deemed cummunity trusted. — Aitias // discussion 10:36, 21 February 2009 (UTC)

I was hoping someone who was more "respected" like MBisanz would... I might get accused of being "obsessed" with removing rights again LOL... Majorly talk 01:06, 21 February 2009 (UTC)

Most of them are harmless, but it would be more a housekeeping effort, the same as we have admins that have been inactive since, oh, 2003 and stuff. Just do a tiny "I'm alive!" threshold--do 6 admin actions every 6 months (absurdly trivial) or 6 crat functions in per 12 months, or you lose the bit, without a cloud, and can ask for them back. If anyone protests when you ask for them back, you reconfirm. Easy as can be. rootology (C)(T) 01:08, 21 February 2009 (UTC)

I have no trust whatsoever with a bureaucrat who has never, ever used a bureaucrat tool, and hasn't participated in an RFA since 2004. I can't imagine most people do. It makes no sense for such a user to continue with such abilities. Majorly talk 02:22, 21 February 2009 (UTC)

Agreed. — Aitias // discussion 10:36, 21 February 2009 (UTC)

As do I. I also like the idea of creating a confirmation page for every 'crat promoted before 2007, but I doubt that will happen. –Juliancolton ^{Tropical Cyclone} 23:10, 21 February 2009 (UTC)

• See Wikipedia:Bureaucrat_removal. MBisanz ^talk 10:16, 21 February 2009 (UTC)

cart before the horse

Shouldn't the discussion have happened before the straw poll? I don't know how useful the results of the poll will be in judging consensus. Chillum 17:17, 22 February 2009 (UTC)

The consensus will be that there is no consensus. Ruslik (talk) 18:27, 22 February 2009 (UTC)

The poll was started/opened to gauge consensus. There was already discussion about this in Oct 08 (see first proposal). The only difference is that there isn't a community de-adminship process tacked on. I wanted all available input with respect to this idea at its base core (implementation only). Where our community stands on this issue is something that interests me. Synergy 02:17, 24 February 2009 (UTC)

It seems that giving 'crats the tool and then later deciding if they should use it is a bit like buying a cart to later make it more justifiable to buy a horse. It is also entirely possible I have misread the intention of the proposal. Chillum 02:25, 24 February 2009 (UTC)

Giving 'crats the power to desysop does not imply that we will implement a new de-adminship system. Even if no such system is put into place, the policy still has benefits in that stewards can work on global problems, not local ones, which is what they should be doing now, and de-adminship logs would now be here, instead of on Meta. Yellowweasel (talk) 02:35, 24 February 2009 (UTC)

Right. If it happens that a process is created to request -sysop, then thats fine. If not, thats fine as well. I also realized I may have confused the situation in my remarks above. When I say implemented, I mean the tool is given, and crats are able to use them as stewards. Not that its a right given-only proposal. Synergy 02:53, 24 February 2009 (UTC)

Venue for desysopping requests

There have been various de-adminshipping process ideas in the past and all of them had failed, but this one also comes with a possible process. In this idea, if someone thinks a crat should de-adminize, a posting could be placed at the beuracrats noticeboard. People could argue if they like, then the crat may decide to remove the admin rights at their discretion. The idea is similar to the process on ANI where users may comment, bu it's up to the admin to decide what to do.--Ipatrol (talk) 23:09, 27 February 2009 (UTC)

No. That isn't really a process. Someone can point out an admin account currently mass deleting FA's for example, and the account can be blocked/bit removed, or whatever, but this is still not a process. We won't be holding witch hunts on BN, and this is also, not in the proposal. Synergy 19:57, 2 March 2009 (UTC)

Disappointed to see that the opposers are so dominated by admins

About three-quarters of the opposers are admins, and although it's pleasing to see that a few admins—and even one of the steards—are represented in the Support section, there is a significant skew.

Although it is natural that a class of people in a position of power are on the whole reluctant to be newly accountable to a transparent, community-endorsed system, I believe that most admins can be persuaded of the urgent need for this reform, including a half-decent process for complaints that is not itself dominated by admins. AdminReview is such a process, but remains under development; together with a new bureaucrat responsibility, within the eng.WP, this might be the kind of measure that delivers transparency, fairness, and a significantly enhanced WP culture.

It is beholden on all of us to convey to the community how the 9 out of 10 admins who currently do an excellent job will be unaffected by this change. Tony (talk) 13:33, 4 April 2009 (UTC)

As the proposal now stands, this change is somewhat like asking an expert dart thrower to chuck a dart at one of twenty different targets, blindfolded, without telling him which target is the right one. No matter how good the judgment of these people (the 'crats) is, without some sort of description of the norms and policies, we're asking for trouble. A 'crat is, like any other person, going to to be affected by the perceptions of their role, and conform at least somewhat to that role. Right now, I feel the 'crat role is poorly defined already, and not one that implies any sort of oversight, dispute resolution, or problem prevention which should be the focus of any admin controller.

I might as well bring it up here, since its on my mind, but the people I want watching admins - and the people I think others want watching admins hae the exact same quality as good administrators themselves: practical, principled, farseeing, and focused in the management, containment and resolution of disputes, and focused on protecting the project. The unstated and necessary (but not sufficient) cause of such a person is that they have the interest, drive, and what we might call ambition to take on this role.

Thus, our best qualified admin controllers, are frequently going to be from the admin corps themselves - cops watched by supercops, which if this 'crat proposal leads to any sort of fruition, will be the direction we're headed in. This does not however, solve the power imbalance problem that exists, but shifts it. The only illusion of check and balance here, is the democratic process for electing 'crats, and I say illusion because I don't particularly feel that the process by which we determine community consensus for 'crats is all that representative. I'm not sure how the problem is solved, but I'm fairly convinced that this isn't it - yet.--Tznkai (talk) 14:15, 4 April 2009 (UTC)

Folks. I don't want to come off as rude (as I've actually grown tired of repeating myself in each of these threads), but you haven't read this proposal at all. Please reread the proposal. Thank you. Synergy 18:32, 4 April 2009 (UTC)

I did not oppose based on a need for power, but rather because this is an action without a plan. The idea of giving buttons to a group of people and not deciding why or how they should use it is just asking for trouble. This idea is not fully formed in my opinion. The whole electoral nature of this page gives me doubt that it will reach a consensus. It is a big vote with a bit of discussion on the side. Chillum 18:44, 4 April 2009 (UTC)

The wording of the particular proposal is alterable by edits from any editor, and permanently changeable by any determined group of editors. So the only important part is the bestowal of new powers on crats, who from the voting above are definitely in favour of this extra button. A few changes and suddenly crats can form some "consensus" about whether some admin who blocked their friend for rampant incivility should be desysopped. It's a completely pointless alteration. And bad too, as none of the crats were elected to do this, and their selection algorithm mostly favours much-friended uncontroversial and by extension inexperienced figures -- probably the one group of people you don't want having such a role. The development of the role and power of ArbCom has made the days of irremovable [actually] troublesome admins a thing of the past. Deacon of Pndapetzim (Talk) 19:27, 4 April 2009 (UTC)

To Chillum:What do you mean exactly? The plan is to proceed with normal desysopings, but instead of stewards pushing a button, a crat would (although in emergencies, a steward would still be able to push this button) push it. Anything else, related to witchhunt -sysopings, rfc bit removal, and recalls are left out for good reason. I wrote this porposal to avoid the drama that ensues from opening up something of that nature. In my opinion, this is far less controversial (unless you think all the crats are unable to act impartial when pushing said button, then this is a whole different story).

To Deacon: Yes, the wording is alterable, obviously. Yet no matter how you word it, its not a proposal for community desysopings. I also seriously doubt that the crats would band together to begin desysoping admins who "blocked their friend" (unbelievable assumption I'd say; given that it would be grounds for dismissal). Let me ask you a question. Were admins prior to the implementation of rollback "elected" (I say elected because its the word you used for the crats; bad choice of words although I'll stay on the same page for this sentence) to give out rollback? No, they weren't. So why should it matter that a crat was not promoted to undo their actions, and further this pedia by the addition of this implementaion? It shouldn't really, as this proposal seeks to change this absurd norm. Synergy 19:55, 4 April 2009 (UTC)

The intentions behind an action and what it is likely to be used for after the fact are two different things. I think the divide between giving the bit and taking it away is an important division.

Deacon, once people starting voting support/propose on the content of this proposal, then editing the page would have invalidated all the votes to date. That is why it is far better to hash out the content of the page with discussion before putting up a poll. Chillum 20:01, 4 April 2009 (UTC)

Well, that's not a realistic view Chillum of how process on wikipedia actually evolves in practice. Once you got the change made, it can abe transformed by "salami tactics" (-- "slice by slice"). @ Synergy, no matter what your intentions are, it is alterable. It is also listed at [Wikipedia_talk:Removing_administrator_rights]], and much of the support coming is clearly (read them) envisioning something broader than just a minor alteration of software. The hypothetical scenario I put is an illustration of why we don't need and shouldn't alter the status quo by opening this to community drama. There are enough people already to carry out the not exactly intense routine of enforcing ArbCom desysops and carrying out admin resignations. Deacon of Pndapetzim (Talk) 21:34, 4 April 2009 (UTC)

To Chillum: What exactly is there to hash out? The majority of my edits to this talk page have been to alleviate confusion, and correct misinterpretations. You either want crats to have this button or you don't. Instead of Meta there is BN.

To Deacon: Its not only my intentions, but the intentions of the proposal. If the intention for this proposal is changed in a manner in which implies a back door for witch hunts then it will be removed with a kind request to create yet another community based sysop removal process. Its as simple as that. Yet, you appear to harbor the idea that the very act of implementing this button will grant them the rights to do with it as they please. That is untrue. A policy will have to be written, tweaked, and consensus formed upon implementation if crats wish an extension on the usage. I don't see a point in arguing this, since it has yet to be implemented. I don't see any drama (or a significant amount) besides the "oh, but this could cause x, and we don't like x, even though we could stop it." Synergy 22:22, 4 April 2009 (UTC)

One of my favourite Dr Johnson quotes may be appropriate here: "Nothing will ever be attempted, if all possible objections must be first overcome." --Malleus Fatuorum 22:46, 4 April 2009 (UTC)

You're probably right. Synergy 23:34, 4 April 2009 (UTC)

I've read the proposal now in detail - and I'm still concerned. Giving a technical ability without creating a controlling policy is a bad idea - saying "this is better than arbcom asking on Meta - and thats all that will happen unless we get a community process" is not reassuring in the least. Policy, or at least norms first, technical implementation immediately afterwards. Afterall, if this is no addition except getting local stewards, lets give the all admins the ability to desysop each other. They can only use the ability if Arbcom asks them to! --Tznkai (talk) 00:26, 5 April 2009 (UTC)

I can understand the concerns, but the controlling policy thus far would only be under the terms in which stewards use this function (maybe I should copy it over here? just a thought). An additional usage would be beneficial, but strenuous, tedious, and probably full of drama. You can therefor see why I opted to go this route instead. Anything to cut down on some of the drama. But I'll have to disagree with the (possibly just kidding, but I'd like to state it for the record anyway ;p) need or want for admins to desyop themselves. I believe that would cause more problems than allowing the promoted users who, while trusted with the ability to grant, would allow them the ability to remove, yet not necessarily revoke (therein lies the heart of this). I also think you're forgetting that most requests will be self requests for -sysop, which isn't really a big deal. Synergy 00:45, 5 April 2009 (UTC)

@ Malleus, that's the funny thing, nothing needs attempted here. There's no desysopping backlog ... we don't need to extend this function based on Synergy's premise. Based on the premise of most of the !voters above, we don't need it either, as justifiable desysopping can now be done as quick as an ArbCom motion. If anyone should get this extra button, it's not crats, but ArbCom clerks. Deacon of Pndapetzim (Talk) 02:17, 5 April 2009 (UTC)

Clerks? Um ... no. Their role is to act as neutral parties for ArbCom, not to take on a contentious job such as this. ArbCom should probably form a subcommittee, including a few arbs, bureaucrats and especially, non-admins. There also needs to be a complaints and investigation process that might refer bad or repeated cases of wayward admin behaviour to the subcommittee (very occasionally, one hopes). Non-arbs should be well-represented at both levels. The police cannot possibly dominate a process for examining and judging police behaviour. It sounds bureacratic, but it's necessary. (ArbCom isn't bureaucratic? WP isn't bureacratic?)

But the expectation would be that in the medium term, there would be a shift in behaviour by the small minority who does not treat the policy requirements of their behaviour seriously. These processes would be likely to being less active, and that would be a very good thing. Much of the problem now is the mere absence of an effective process. Tony (talk) 02:49, 5 April 2009 (UTC)

I have many thoughts on this subcommittee idea, but could we fork this discussion elsewhere, perhaps the main removing administrator rights talk page? Lets give the proposal some breathing space.--Tznkai (talk) 16:07, 5 April 2009 (UTC)

The proposal, as it stands at least, gives crats the power to desysop if ArbCom tells them to, it doesn't give them the power to decide desysopping; i.e. it's not going to be "a contentious job such as this" (well, not as Synergy envisages anyway). If there is a manpower need for more users with this ability, clearly ArbCom clerks are the ones who should get it [for their period in office] as they close the cases. Deacon of Pndapetzim (Talk) 02:59, 5 April 2009 (UTC)

The editors who supported in the last few days clearly had had not read the proposal. Ruslik (talk) 14:52, 5 April 2009 (UTC)

Ohh, one more thing. Tony may want to check his math. I don't think he got the ratio of opposers being admins correct. Also, how many of the supporters are admins? Lets be accurate now. Chillum 14:55, 5 April 2009 (UTC)

Concerning the role of Arbitration clerks: A clerk who is also a Steward (yet to occur, but very well may someday) may carry out a non-discretionary remedy as part of case closure. This is a zero input, purely ministerial act. In political theory, the Office itself is carrying out the act, not the officer. If we're looking at some sort of discretionary desysopping (sub) committee, I am firmly against the clerks having any representation on it. We don't select clerks for that kind of judgment and our roles are focused on the procedural, ministerial, and maintenance of the Arbitration process as a whole. I see no way such a high drama job is compatible with our main mission. --Tznkai (talk) 16:07, 5 April 2009 (UTC)

I counted 11 non-admins of 39, a few days ago. I may be out by one or two, but not significantly. It's true that my assessment of the ratio among the supporters was arrived at less formally. Any volunteers? I think there is a significant difference. Tony (talk) 16:04, 5 April 2009 (UTC)

Good luck with the count. I tried using a script from .js and it was difficult because some of them have signatures that override the admin highlight. Overall, there are more admins who are opposing per non admin opposes. Yet there is a significant amount also supporting (best count was around 30-34 admin supporting, while non admins supporting are around 43 or so). What could come out of the statistics is better left for someone else. I don't see a significant number to suggest anything other than confusion over the purpose this proposal. :) Synergy 01:44, 6 April 2009 (UTC)

Despite what the lead says, this does seem like a solution in search of a problem to me. While I don't see anything wrong with giving Beaurocrats the rights to desysop, I have to ask what's the point? Is there some big desysop backlong that I'm not aware of? Now, maybe you could argue that there should be a lot more desysoppings taking place, but that is an entirely separate issue. -Chunky Rice (talk) 17:22, 6 April 2009 (UTC)

The main idea, was to keep all activities local. To see how many editors thought this was a good idea. Hence, its not a solution in search of a problem. Synergy 22:11, 6 April 2009 (UTC)

But is there a reason that we should make all activities local other than just to do it? What is the problem with the current set-up that this needs to happen? -Chunky Rice (talk) 22:15, 6 April 2009 (UTC)

Chunky, I just said there wasn't a problem. This proposal if to see if its a good idea. Just because there isn't a problem, doesn't and shouldn't mean we cannot express a change. Synergy 22:38, 6 April 2009 (UTC)

So, the idea is to change just for the sake of making a change? This is almost alwasy a bad idea. Why fix what isn't broken? -Chunky Rice (talk) 23:54, 6 April 2009 (UTC)

It's one and the same, isn't it? Tony (talk) 04:25, 7 April 2009 (UTC)

Is what one and the same? -Chunky Rice (talk) 14:19, 7 April 2009 (UTC)

This is a bit of a semantic dispute, but it seems to me that what Synergy has been trying to convey all over this page is that this proposal is an "improvement" or "streamlining", not a "fix". We have a car, it runs on gas (or petrol, if you prefer). Currently our gas is imported from (semi-random country) Nigeria. No big deal; it's a good price, it's generally always available, it combusts in an engine. There is no specific problem with Nigeria's oil. But what if we built oil mines in our own countries, so we could get oil from both sources? Just in case? Would this not be an improvement (ignoring environmentalism for a moment)? What if we already have trained, generally trusted personnel who can run these oil mines, if we decide to give them permission? If you've followed my overextended analogy this far, perhaps the distinction between this proposal and a "solution" will be more apparent: it's not a solution, it's just an improvement. -kotra (talk) 06:05, 7 April 2009 (UTC)

To play with your analogy here, what if our local supply of petrol is completely unregulated, while the Nigerian oil supply has robust and well enforced safety and quality regulations? That is my basic concern here.--Tznkai (talk) 13:24, 7 April 2009 (UTC)

I'm not sure how stewards are more regulated than crats, unless you mean by their term limits. But in the context of desysopping, it seems to me like both stewards and crats would be regulated about the same: this proposal explicitly describes how they only would only be authorized to perform desysoppings according to community consensus (in the form of arbcom decisions, self-removals, accidental sysoppings, etc). These are the same limited criteria we restrict stewards with. Crats would not be authorized to make judgments outside of consensus (in fact, bureaucrats were designed to be nearly the most impartial, consensus-obeying user group in wikimedia, only second in impartiality to clerks). -kotra (talk) 20:25, 7 April 2009 (UTC)

Rejected

Honestly, I was going to suggest this proposal be closed last month, but editors still kept coming by to offer their opinions. I'd like to thank each and every one of you for providing feedback on this issue, and raising your concerns. I still entertain the idea that one day we will be able to keep these actions on wiki; which usergroup has the access is really unimportant to me (as it was suggested off wiki that arbs might have a better chance, given they are subject to re-elections, as stewards are, where crats retain their status for an unkowkn period of time), aside from admins having it! I won't raise any issues with this being closed now. And again, to all, thanks for weighing in. :) Synergy 15:57, 7 April 2009 (UTC)

Am I missing something? This has significant support, and the general tone of the opposes is "I don't really see the point". Skomorokh 15:59, 7 April 2009 (UTC)

The original intent, was to file a buzilla report to implement this feature. If you think there is consensus to do this, by all means. But I don't see it. Best. Synergy 16:02, 7 April 2009 (UTC)

It has over two to one support. As far as it's possible for us to quantify consensus, that's the boundary we usually use. I think a bug wouldn't be inappropriate. Happy‑melon 16:34, 7 April 2009 (UTC)

T20390 Let's see how it plays out. Happy‑melon 16:43, 7 April 2009 (UTC)

You forgot to count those who were unhappy with early polling without discussion. In addition, a standard criterion for consensus in RFA discussions (which are relevant here) is 75%. Ruslik (talk) 18:36, 7 April 2009 (UTC)

How is that any more pertinent to the level of support required to implement rollback or autoconfirmation? This is a change in policy/procedure, not an individual appointment. Say, why not make it 90%, since it's relevant to RfBs too? Skomorokh 18:50, 7 April 2009 (UTC)

I am unaware of a poll, or consensus forming conversation prior to the implementation of rollback. And RfBs have one of the highest thresholds for passing, so that doesn't make much sense. Synergy 19:12, 7 April 2009 (UTC)

First, rollback was an insignificant issue as compared to this proposal. Second, how many editors did participate in that poll about rollback? As I can remember several hundreds. Here we have only 100+. So this poll may not be representative, and therefore a stronger majority is required. Third, Rollback passed with ~ 2/3 in support, but here support is weaker than 2/3 (counting those who oppose the poll as premature). Ruslik (talk) 19:20, 7 April 2009 (UTC)

Oh so there was a poll for rollback? Hmph. I guess I missed that one. Regardless, there is no consensus here for a bugzilla request. So I disagree with its filing unfortunately. Synergy 19:23, 7 April 2009 (UTC)

See Wikipedia:Non-administrator_rollback/Poll. Ruslik (talk) 19:31, 7 April 2009 (UTC)

I've closed to poll, since the request was filed. I tagged it as rejected, since I didn't know the correct tag to say polling is over. If anyone finds the proper template, can you please add it. Also Skomorok, I don't need to "chill" as you say in your edit summary. I am quite calm. We can't have editors changing the consensus now that its filed. Synergy 19:41, 7 April 2009 (UTC)

Seems like a reasonable course of action. I suggest that if consensus is assessed here, it be done by an uninvolved editor. I meant "chill" in the sense of "let's not be hasty"; sorry for the misunderstanding, English is not my first language. Regards, Skomorokh 19:44, 7 April 2009 (UTC)

No harm done. :) Synergy 21:21, 7 April 2009 (UTC)

As long as this proposal is still getting active discussion, I think the poll should stay open; after all, a common objection to interpreting this poll as consensus seems to be that there aren't yet enough votes to draw an actionable conclusion. Closing the poll while there are still votes being added seems contrary to the goal of getting more participation. -kotra (talk) 21:08, 7 April 2009 (UTC)

I'd very surprised that this has come and gone without very significant advertising. This is the first I have heard of this being seriously discussed and I have been on wiki every day for the last couple of months. sorry but if this were open I would firmly oppose on the basis of a) being redundant to the stewards and b) being something inappropriate to the 'crat group as something they weren't elected to do. Spartaz ^Humbug! 16:25, 11 April 2009 (UTC)