Wikipedia talk:Community de-adminship/Draft RfC/Archive 1

Archiving this disucussion was a complex process and took place over a period of time. Some section descriptions may be awol, some numbering may be out of kilter and some discussions may not be in the order they originally appeared. If anyone is interested and can't figure out the relationship between this archive and the original page (now in summary form) I'll be happy to assist. Ben MacDui 22:02, 4 January 2010 (UTC)

Ten editors to open

Existing wording

• Nomination by the Community at large requires the signatures of no fewer than 10 editors in good standing (defined below), within a period not longer than 3 days. Signatures must be placed in the nomination area of the requests, as a simple signed bullet point.

Poll finding

• Some editors believe that requiring this number of editors sets the bar too high. (NB that the issue of the "period not longer than 3 days" is discussed separately below).

Possible option(s)

• 1.1 Replace "10 editors to open" with "7 editors to open"

Oppose 1.1

1. The existing Guide wording includes: "Tip for editors who are not in good standing: If you cannot convince 10 independent editors in good standing of the merits of your request, such that they take it up themselves, then your request is probably without merit and should not be pursued" and I agree with this sentiment. Ben MacDui 11:10, 22 November 2009 (UTC)
2. This links in with the question at the end about alternative resolutions. I think guidance could clarify that deadminshire is a last resort – after discussions, maybe even an RFC/U. In that context, I think it should require a fairly high threshold – if someone can't find ten people to support him, they should raise it at RFC/U first – after discussion there, if a case remains, they can then bring it here and then there will be enough people aware to nominate if appropriate. AndrewRT(Talk) 11:43, 22 November 2009 (UTC)
3. Per Ben. 10 editors is not too high of a bar. In comparison with how many editors participate at RfAs and RfC/Us, this number is not unreasonable, and it's a good way to prevent frivolous requests. JamieS93 13:55, 22 November 2009 (UTC)
4. Agree that 10 is the right number. A De-admin should have wide support. Jusdafax 18:37, 22 November 2009 (UTC)
5. Yes, 10 is a reasonable number. However, as discussed below, I would extend the period for more than 3 days, require fewer than 500 edits to be "in good standing", and tweak how the process is publicized. --Tryptofish (talk) 21:54, 22 November 2009 (UTC)
6. Agree, 10 seems reasonable. –Juliancolton | ^Talk 22:18, 22 November 2009 (UTC)
7. With thousands of editors using WP regularly, garnering the support of 10 editors wouldn't be hard (if your concern is valid). — Oli ^OR Pyfan! 23:42, 22 November 2009 (UTC)
8. Agree. Like it or not, there will be some faction action. Seven makes it too easy for a faction to make mischief. I wouldn't might mind a slightly higher number, but ten is acceptable.--SPhilbrickT 01:13, 23 November 2009 (UTC)
   • Comment I think it should be made clear that the ten names will be coming under close, if not severe scrutiny. Edit histories will be examined for agendas, revenge motives, etc., and in heated cases any appearance of impropriety will hurt the overall effort to de-admin, even lead to possible sanctions against those trying to oust an admin for less-than-pure motives. Jusdafax 01:58, 23 November 2009 (UTC)
9. If the incident is big enough to warrant a de-sysop, then it's a no brainier that 10 would be small enough. This prevents small isolated incidents becoming de-sysops. --Coffee // have a cup // ark // 13:40, 23 November 2009 (UTC)
10. I don't support this whole idea much at all, but if there's going to be something like it, it has to err on the side of the bar being high to prevent gaming and disruption. Seraphimblade ^{Talk to me} 06:51, 24 November 2009 (UTC)
11. I concur that 10 is a good number to get the ball rolling. If an admin deserves to be de-sysoped, there should be at least 10 editors that would want to start the process. Angryapathy (talk) 16:24, 24 November 2009 (UTC)

    Comment Should there be a provision about canvassing for start-up votes, either negative or positive? Angryapathy (talk) 16:24, 24 November 2009 (UTC)

    I've been thinking hard about that question. I tend to think it's better to leave it for the community to assess as the process goes forward, rather than to try to craft language that will end up being gamed. If a few editors communicate along the lines of "You were involved along with me in such-and-such incident, and you may want to look at this nomination page", I think that is appropriate. On the other hand, a mass spam appeal is clearly inappropriate, but is also sufficiently transparent that it will be quickly exposed. --Tryptofish (talk) 16:50, 25 November 2009 (UTC)

    So we'll let WP:CANVASS cover the issue? Angryapathy (talk) 17:16, 25 November 2009 (UTC)

    Yes, that would make sense to me. --Tryptofish (talk) 19:44, 25 November 2009 (UTC)

12. As long as the word independent is involved, ie, editor clique A cannot get angry at one of their own being sanctioned and roll over the admin involved.. 10 is fine, if we have to have this at all, which I don't think we should. SirFozzie (talk) 22:29, 24 November 2009 (UTC)
13. Oppose reducing from 10 -- plenty of RFAs get more than 10 opposes, even the successful ones. --SarekOfVulcan (talk) 23:42, 27 November 2009 (UTC)
14. If you're going to choose an arbitrary number, it might as well at least be a round one. Mr.Z-man 00:31, 28 November 2009 (UTC)
15. As above, 10 is a reasonable number. De-adminship is no small matter, and it is important that the community truly believes there is a valid reason to open. Much like a grand jury, for any meaningful complaint this should be easily attained, even in situations where it won't pass in the end. --Mpdelbuono (talk) 06:21, 28 November 2009 (UTC)
16. Even 10 is probably too low. Stifle (talk) 11:53, 30 November 2009 (UTC)
17. At least 10. ThemFromSpace 09:08, 2 December 2009 (UTC)

Neutral 1.1

1. I oppose lowering to 7 because I think the bar should be very much lower, like 1 or 2 editors. We haven't had any trouble developing speedy close procedures for frivolous nominations in other forums. While I understand the concern, I think that setting a threshold of 10 will just lead to backchannel canvassing in order to attempt to rally enough people against a target. Public attempts to gather 10 supporters would lead to massive peer pressure that will intimidate potential challengers. This will push the debate underground and is counter to our culture of transparency. Getting the grievance out in the open as soon as possible would be the best way for it to quickly be dealt with. Gigs (talk) 14:45, 24 November 2009 (UTC)
2. I agree with Gigs. The bar should be lower than 7 with speedy close options or else this will lead to canvassing. I see the opposite side where any two or three disgruntled editors can start nominating administrators, but I would hate that to stop two or three good standing editors from nominating a very poor and abusive admin because the admin targets them and no one else. If we enact such a high threshold, than all an admin has to do is be careful not to tick off anymore than X number of editors at any one time.--TParis00ap (talk) 14:20, 25 November 2009 (UTC)
3. Three editors more or less do not make much of a difference.  Sandstein  21:34, 25 November 2009 (UTC)
4. I would support either 7 or 10 editors as a starting point, but I think it's very probable that 10 may be too low for the policy to pass. There are concerns about gaming / vindictiveness, and increasing the number might help assuage those concerns. --Alecmconroy (talk) 13:13, 26 November 2009 (UTC)

2. Definition of "editor in good standing"

See also: section below.

Existing wording

Editors in good standing:

• may not be subject to Arbitration enforcement editing restrictions, Arbitration Committee restrictions, or Community restrictions, including, but not limited to, topic bans, project bans, and paroles.
• must be active editors on the English Wikipedia, with accounts more than three months old and with no fewer than 500 edits.

Note: WP:CDA wording amended during this discussion at circa 00:33, 23 November 2009 to include "without the permission of the arbitration committee" at the end of the first bullet point. It was restored to its original wording circa 21:32, 23 November 2009. See "See "Arbcom sanctions" and "11. Clarify that ARBCOM and others who sanction can restore rights to nominate" below.

Poll finding

Some editors believe that this needs clarification.

Possible options

2.1 Replace/Add current definition with... "Except where such sanctions were enacted (or were caused to be enacted) by the admin being subject to this process, and the editor is otherwise in good standing".

Support 2.1

1. This stops an abusive admin from sanctioning potential complainants – "I wish to complain about being subject to abuse by Admin X" "Sorry, you are not an editor in good standing because you are currently under sanction by Admin X" It sort of defeats the purpose, no? It obviously needs the other 9 editors in (otherwise) good standing anyway. LessHeard vanU (talk) 12:08, 22 November 2009 (UTC)
2. Support per LessHeard vanU. <>Multi‑Xfer<> (talk) 08:13, 4 December 2009 (UTC)

Oppose 2.1

1. I think the current wording is appropriate – last thing you want is admins getting these requests after blocking someone involved in an ArbCom case. The wording should be tightened to say someone named in an ArbCom restriction as ArbCom, I understand, sometimes says "all users who edit ... must do xyz" AndrewRT(Talk) 11:45, 22 November 2009 (UTC)
2. Oppose. I'm very sympathetic to the spirit of the proposal, but think it creates the potential for messy bureaucracy. What if an editor is sanctioned, and the administrator provided some minor evidence. Did the sysop cause these sanctions to be enacted? There's a potential for derailing side arguments about who is eligible. Keep it cleaner, it's very unlikely it will turn on one editor's signature.--SPhilbrickT 01:26, 23 November 2009 (UTC)
3. If an editor was sanctioned by an admin, it should be required that someone else who disagrees with that sanction initiate these proceedings. Otherwise, we'll see frivolous proceedings from anyone an admin blocks. (On the other hand, if you're stupid enough to block someone after they're initiating or certifying proceedings against you, I imagine you'll not help your cause...) Seraphimblade ^{Talk to me} 06:53, 24 November 2009 (UTC)
4. If Arbcom is involved, than plenty of other editors have eyes on the situation to nominate the admin. There is no need for the receiving editor to have another way to cause trouble (sorry for the prejudice).--TParis00ap (talk) 14:23, 25 November 2009 (UTC)
5. Agree with AndrewRT and Seraphimblade.  Sandstein  21:33, 25 November 2009 (UTC)
6. Good sentiment, but an unneeded process. It's fair to ask sanctioned users to get one more signer-- if you can't convince even one more person, you had a snowball proposal anyway. --Alecmconroy (talk) 13:17, 26 November 2009 (UTC)
7. This is just asking for wikilawyering. Mr.Z-man 00:32, 28 November 2009 (UTC)
8. Wikilawyers-R-Us. Might be worth amending to state that the ArbCom exclusion applies only to users actually named in a decision, per AndrewRT. Stifle (talk) 11:55, 30 November 2009 (UTC)

Neutral 2.1

1. I partially support this, in that I agree that we don't want a bad admin to game the system by blocking the accuser. However, we also want to be careful about blockees using the system to get payback against admins who blocked them for good reasons. Perhaps change this to say that the admin cannot block any nominator after the CDA process has begun? --Tryptofish (talk) 22:06, 22 November 2009 (UTC)

   To the former part, this is why I commented that there still needs to be 9 other accounts. As for the latter – do we need admins that brave/insensitive? ;~) LessHeard vanU (talk) 23:19, 22 November 2009 (UTC)

   Comment Should the CDA have a section where people who are unable to vote can bring evidence? People are smart enough to see when an agrieved editor is being petty, but one of the non-voters might have useful evidence for others to see. Angryapathy (talk) 16:29, 24 November 2009 (UTC)

   We can just copy the way RfA is, with a comments section at the top. We shouldn't reinvent the wheel here. Gigs (talk) 17:15, 24 November 2009 (UTC)

2.2 Change second bullet point from 500 edits to 150 edits.

Support 2.2

1. Support as proposer. In last year's ArbCom election, 150 edits were the threshold for eligibility to vote. It makes no sense to set a higher requirement here than for voting for Arbs. We should strike a balance between being open to relatively inexperienced users, and protecting good Admins against charges by first-time editors who did something wrong and are looking for payback. Setting it at 150 gets it right. --Tryptofish (talk) 22:02, 22 November 2009 (UTC)
2. Support. We don't require nominators in other forums to be familiar with our policies. If they do not make a nomination based in policy, we speedily close their request or we just universally reject it. What's next, "If you can't afford a wikilawyer, one will be appointed to you"? Gigs (talk) 14:53, 24 November 2009 (UTC)
3. Support. I appreciate all the sense that newbies might not have a sense for often complicated rules and policies and thus might give botched or unjustified opinions. But human mistakes like that are the furnace in which rules and policies are tempered into more accessible and understandable forms.

   Furthermore, I think "corrupt" or "abusive" admins is the major bee in the bonnet of many new, would-be long-term editors. Even if half imagined, there is a frustration among most newbies that because they have not sat down for hours reading every single one of the dozens of pages of policy and guidelines, they cannot even make a well-meaning edit without the threat of being blasted for it. The abuse of admin power is most often the abuse of social and technical status gained by being an "old timer" to arbitrarily shut out, exclude, or berate those new to the project.

   A "200 edit newbie" will thus have much more keen eyes for abuses of power than someone who more likely than not does not remember the last time they felt confused, alone, or disenfranchised on a new and exciting website. --Lyc. cooperi (talk) 06:35, 25 November 2009 (UTC)

4. Support. In general, edit counting is a terrible criterion to use here, because admins shouldn't have a free pass to treat less-seasoned users like crap. Note that I'm not even saying "newbies". If you've made 100 edits, you're not really a newbie anymore. If you've made 400 edits, you're far from being a newbie, and yet the proposal as it stands would say that such editors don't count. But we do need some way of preventing people from making stealth sockpuppets to open one of these requests. (That is the reason, right? Not just an inherent feeling that people don't count until they've made a lot of edits?) The three months of editing is the most important part, but I'm okay with a requirement for a reasonable number of edits in that time, such as 150, so you can't just let the account sit there. rspεεr (talk) 01:29, 29 November 2009 (UTC)

Oppose 2.2

1. I vote to keep it at 500. 150 edits isn't enough to understand the maze of policy that is Wikipedia, and in many cases that same policy will be the basis of discussion and !vote to De-admin. Respectfully, Jusdafax 22:19, 22 November 2009 (UTC)
2. I agree with Jusdafax. There are over 30 policies in the English Wikipedia, it'd be pretty impressive if an editor with less than 500 edits knew about them all, or even just some of them, sincerely — Oli ^OR Pyfan! 23:47, 22 November 2009 (UTC)

   I asked an administrator to help me write an index of the policies but he essentially told me to fuck off. Recently, I saw in the newspaper where a Wikipedia trustee has exactly the same idea. His name is Frank Schulenburg and is mentioned here http://wiki.riteme.site/w/index.php?title=Wikipedia:Administrators%27_noticeboard&diff=prev&oldid=327741541 Suomi Finland 2009 (talk) 20:22, 28 November 2009 (UTC)

3. Agree with 500. I wrestled a bit with the notion that less experienced editors can weigh in regarding arb com, but I convinced myself that electing arb com members is assessing whether someone with a large body of experience shows good judgment. In contrast, this decision will almost certainly involve in depth understanding of policy nuance, and a "target" with probably less of a track record than an arb com candidate.--SPhilbrickT 01:32, 23 November 2009 (UTC)
4. 150 is way to small for an editor to truly understand what the point of being an administrator really is, I personally think the bar needs to be much higher. --Coffee // have a cup // ark // 13:42, 23 November 2009 (UTC)
5. Leave it at 500. 150 is generally quite underexperienced to understand Wikipedia process at this level, per Coffee and Jusdafax. JamieS93 15:29, 23 November 2009 (UTC)
6. Quite agree. Ben MacDui 19:58, 23 November 2009 (UTC)
7. 500 minimum. Leaky Caldron 16:14, 24 November 2009 (UTC)
8. I agree with the 500 edits on the grounds that it is simply too ease to achieve 150 edits especially with automated tools.--TParis00ap (talk) 14:27, 25 November 2009 (UTC)

   But it's also easy to achieve 500 edits with automated tools. I think you need to weigh that against the number of legitimate editors you're discounting. rspεεr (talk) 01:32, 29 November 2009 (UTC)

   What about 500 non-automated edits - would that be better?--SPhilbrickT 13:37, 30 November 2009 (UTC)

   I think you'd be surprised what a small percentage of Wikipedia users have made 500 non-automated edits. (And of course "automated" here means scripts like TWINKLE and Huggle, it of course doesn't mean they're a bot.) Since the original problem was that it was too easy to get 150 edits through scripts, why not 150 non-automated edits? rspεεr (talk) 05:48, 1 December 2009 (UTC)

9. Per Coffee, though placing the bar substantially higher would be arbitrary.  Sandstein  21:36, 25 November 2009 (UTC)
10. No; in fact, I would suggest far more than 500 to avoid gaming by sophisticated puppetry and the like. Ncmvocalist (talk) 06:18, 28 November 2009 (UTC)

    Interesting. I too have reservations about 500 being enough, but could accept it. What minimum number of edits would you support? Jusdafax 22:15, 28 November 2009 (UTC)

11. 500 is probably too low. Stifle (talk) 11:54, 30 November 2009 (UTC)
12. 500 is about right. 150 can be achieved in a busy day, even by a newbie who doesn't know the complexities of what makes a problematic administrator. ThemFromSpace 09:12, 2 December 2009 (UTC)

    150 in a single day? I'd be reluctant to let that person in even after 500! :-) --Tryptofish (talk) 20:09, 3 December 2009 (UTC)

Neutral 2.2

1. I think the problem with this (admittedly arbitrary) number is that it is far too dependent upon how the edits are actually occurring. For example, a vandalism fighter like myself can probably hit 500 edits over 24 hours easily due to automated tools. On the other hand, someone who's creating new pages full with cited content, etc., would take some time even to hit the 150 mark. The problem is that these are two completely different classes of users, and never the twain shall meet. I don't think a policy could be created that could satisfy both of these demands. Because I value that person that made 150 content edits over the person that did 250 reverts + 250 warnings, if I had to choose between 500 and 150, I would lean towards 150, but I would prefer a different policy (or none at all). A concept to consider: would simply "autoconfirmed" be enough instead of edit count? I fear it might be too lenient, however it's something to consider. Perhaps, spinning off the "autoconfirmed" concept we could consider something like: (1) has had at least 10 edits in the last month and (2) is at least fourteen days old. Note that this is slightly modified from the true concept of WP:Autoconfirmed in that someone can become "temporarily not good standing" by having disappeared for a month. Unfortunately, I don't think this would work out either because it harms users that have a very slow edit rate (such as someone who creates 1 new article a week). Long story short, I have thrown a couple of ideas out. Some work at taking this and turning it into a way we can specify a "seasoned user" without using an arbitrary number that wildly varies based on the work the user is doing would be preferable. Naturally, feel free to sway me to either side. --Mpdelbuono (talk) 06:41, 28 November 2009 (UTC)

2.3 For clarity, proposed wording - "Nomination by the Community at large may be initiated by any registered user, though requires the signed support of no fewer than 9 editors in good standing"

Support 2.3

1. Support as proposer. Editors under ArbCom editing restrictions are just as likely to observe or be subject to inappropriate behaviour from an admin as editors in good standing. Just need to make it clear that they can nominate. SilkTork *^YES! 17:06, 4 December 2009 (UTC)

Neutral 2.3

1. I understand the point, but editors in that situation can (unless blocked) ask users in good standing to start the process, and the draft document does a good job of discussing what would-be nominators should think about if they can't get good-standing support. Ultimately, I think this would diminish community faith in the process, and decrease the likelihood of acceptance of the proposal by the community. --Tryptofish (talk) 18:21, 4 December 2009 (UTC)

   A nomination has to be supported by another nine "editors in good standing" - that is already a solid enough requirement to ensure there aren't frivolous complaints by aggrieved users. If a person has been wronged, let that person speak for themselves. Let's not have silly rules where user X has to get friend Y to cut and paste X's words into a form because X is not allowed to do it directly themselves. It will be the same complaint and the same words, but under a surrogate name. No - that's not transparency and a clear, simple system - that's pointless bureaucratic obstruction. The reason that user X was sanctioned may have nothing to do with the current complaint, so the sanction is being extended to the user not being able to air a genuine grievance. A topic ban means that a user is seen as able to conduct themselves properly throughout Wikipedia, apart from that particular topic only. The current wording automatically extends that topic ban. I'm not sure such an extension occurs elsewhere on Wikipedia - why should it occur here? SilkTork *^YES! 19:52, 4 December 2009 (UTC)

3 Publicity required

Existing wording

• Nomination by the Community at large requires the signatures of no fewer than 10 editors in good standing (defined below), within a period not longer than 3 days. Signatures must be placed in the nomination area of the requests, as a simple signed bullet point.
• Nominations are not valid unless all of the following apply:
  • The Arbitration Committee has passed a motion, or the requisite number of signatures have been collected.
  • A notice of the de-adminship request is currently placed on each of Wikipedia:Village pump (miscellaneous), the Wikipedia:Administrators' noticeboard, and the Wikipedia:Bureaucrats' noticeboard. (Anyone may post such a notice.)
  • A notice of the de-adminship request is currently given to the account whose rights are to be changed.

and

• Discussion and polling proceeds for at least 7 days after discussion opens. Discussion and polling may be summarily closed ahead of that 7 day deadline at the discretion of Bureaucrats and the Arbitration Committee.

Poll finding

• There were questions about the number of days of prior publicity required and how the information would be publicized to the community.

Support 3.1

1. Support as proposer. It may be unrealistic to expect 10 editors to show up in only 3 days. Extending it to 7 is much more workable, while not prolonging it unreasonably. --Tryptofish (talk) 22:13, 22 November 2009 (UTC)

   Something else just occurred to me. Extending the time beyond 3 days does more than just give more time for the nominators. It also gives the admin being nominated more time to prepare a response before the process opens up to the community as a whole. Would a good admin who is unfairly but believably accused, who perhaps is off-site for a few days, always be able to make his/her case in a fair way in only 3 days? --Tryptofish (talk) 23:36, 3 December 2009 (UTC)

2. Support seven days. I take it as obvious that the end of the signature phase ends when the tenth one appears. The time for the signature phase is a maximum, while the time for the discussion phase is a minimum (subject to 'crat override).--SPhilbrickT 02:00, 23 November 2009 (UTC)
3. Support Agree that a week is better than three days for this type of thing. Jusdafax 02:11, 23 November 2009 (UTC)
4. Support as per SPhilbrick. It starts on a Friday, it's a public holiday, no one comes back until Tuesday. At least 7 days. HarryAlffa (talk) 17:24, 24 November 2009 (UTC)
5. Support A de-adminship is a complicated issue that requires thorough investigation. I'd be hard put to say that all the information that needs to or is important to come up will do so within three days, with enough time left to discuss that information. --Lyc. cooperi (talk) 06:49, 25 November 2009 (UTC)
6. Support per my neutral vote at the lowering from 10 editors to 7. I feel 10 editors would be tough to round up even for a very poor and abusive admin and ample time should be allocated to contact and investigate.--TParis00ap (talk) 14:29, 25 November 2009 (UTC)
7. To allow moderately active editors to contribute. We don't want such matters to be decided only by the relatively few very active editors.  Sandstein  21:38, 25 November 2009 (UTC)
8. 7 days is sufficient to ensure that in all cases, moderately active users such as those that only edit one day a week will still be able to participate. While it is arguable that 10 signatures should be attainable in 3 days anyway, it is equally arguable that an editor that is only moderately active should not run the risk of missing such a case simply because it was during the time of the week that he/she is not active. --Mpdelbuono (talk) 06:55, 28 November 2009 (UTC)
9. Three days is too short. It would support behind the scenes vote counting, which is already done too often in dispute resolution. ThemFromSpace 09:14, 2 December 2009 (UTC)
10. Support per nom and above. <>Multi‑Xfer<> (talk) 08:14, 4 December 2009 (UTC)
11. Support, as this procedure is not being used in an emergency, therefore there is no need for haste. I think it is appropriate to allow people time to reflect properly on a nomination before supporting it, and not feel they have to rush their investigation into the background problem. 7 days allows everyone involved in the matter time for reflection, to examine evidence, and perhaps for the admin in question to make appropriate amends to satisfy the nominator. Sometimes events are misunderstood, and people do sometimes have a tendency to pile-on with emotional reactions, especially when there is a short deadline that doesn't encourage background reading of the problem. SilkTork *^YES! 16:45, 4 December 2009 (UTC)
12. Support, per SilkTork. No reason to rush a community process. –blurpeace ^(talk) 22:57, 14 December 2009 (UTC)
13. Support, mainly per SilkTork and blurpeace. I see no need to rush a community process like this, especially since this isn't for emergencies. A Stop at Willoughby (talk) 03:01, 15 December 2009 (UTC)
14. 'Support, most of our extant venues that require community input run for a minimum of 5-7 days precisely to accommodate all editors, including those interested parties who may have editing routines that don't see them participating on a daily basis. Unomi (talk) 07:32, 23 December 2009 (UTC)
15. Support - Most processes have a seven day running period, the same for community de-adminship is not unreasonable. Camaron · Christopher · talk 10:14, 23 December 2009 (UTC)
16. Support - I think 7 days is a reasonable amount of time, without dragging out the process. -- Atama頭 23:18, 23 December 2009 (UTC)
17. Support Some people only edit significantly on certain days of the week. 7 days seems like a reasonable number. Hobit (talk) 01:48, 25 December 2009 (UTC)
18. Support. Some editors in good standing don't even log in every 3 days, and there are other times when many good-standing editors are on a Wikibreak. ~Amatulić (talk) 05:00, 25 December 2009 (UTC)
19. Support. As others have stated above. Three days is far too short for those who have much in the way of real-life duties. Greg L (talk) 05:38, 26 December 2009 (UTC)
20. Support - allows some time to look at the history of the person in question to see if there have been similar issues in the past (pattern) or if the issue is a one-off on a specific/narrow issue. --71.54.72.44 (talk) 06:10, 3 January 2010 (UTC)

Oppose 3.1

1. No. This makes the de-sysop period too long. And allows for people to walk by and throw their name in for an unrelated reason. It's more likely that the people requesting it be opened, are actually concerned with a recent problem, if there is only 3 days for the word to get around about it opening. --Coffee // have a cup // ark // 13:47, 23 November 2009 (UTC)

   Comment: Please note that this proposal is not about single recent problems, in the sense of bright-line violations that ArbCom already can deal with. --Tryptofish (talk) 15:16, 23 November 2009 (UTC)

   To clarify this issue further, it may be helpful to look at this essay, as well as at the discussions at Wikipedia talk:WikiProject Administrator. It's really an important point in the discussion that has come before. --Tryptofish (talk) 16:11, 24 November 2009 (UTC)

2. Don't see the point. If the issue is really that serious, getting ten people to certify within three days should be trivial with all the allowable notice. If not, it shouldn't be drug out. We're not using the same standard here as RfC, where the certifying parties must have actually spoken to the subject of the RfC about the problem, this is just ten people agreeing that a problem potentially serious enough to warrant desysopping exists. If the problem is that severe, finding those ten ought to be quite easy. Seraphimblade ^{Talk to me} 06:57, 24 November 2009 (UTC)

   Comment:To repeat the point of Trypofish, if it is a single incident (say, discovery that the admin is a sock), I assume that ArbCom may continue to deal with it (or perhaps this process will become the right venue), but this proposal AFAIK, wasn't developed with single incidents in mind. My impression is that the main target is an admin who may be straying from the path - taking a number of small actions that together, represent a breach of policy and trust. Consequently, in those situations, it is unlikely that everyone will know about it and be prepared to sign or not within three days. --SPhilbrickT 13:23, 24 November 2009 (UTC)

   if its not a single incident but an on going issue then ARBCOM is where it needs to be. Gnangarra 04:06, 28 November 2009 (UTC)

   It seems to me that, in this part of the discussion, editors are not always understanding what one another means. There are different kinds of ongoing problems. Please see Wikipedia:WikiProject Administrator/Five Problems with a Single Solution for an explanation of what I mean. --Tryptofish (talk) 17:02, 29 November 2009 (UTC)

3. As I'm redaing this the 3 day period is only to have the process opened, its the time frame for the process itself so its 3 day plus, or 7 days plus as such 7 days plus is too long, in reality if you cant get ten independent people to agree there is a problem within the 24 hours then the arbcom process is where its needs to be. If the period is 7 days anyone can organise a concerted effort of like minded editors one only needs to look at AFD discussion on contentious subjects like Pseudo Sciences, Religious or political article as a demonstration of how long seven days is and what can be achieved. Gnangarra 04:06, 28 November 2009 (UTC)
4. 3 days to get the 10 certifying editors should be plenty. In practice, the person opening a CdA is going to want nine others to show up and get the process opened, so they will likely not be started just before a holiday or long weekend. As it is, the process has a 10 day total. Extending this to a week of nominations plus a week of debate is excessive. Jim Miller ^{See me | Touch me} 15:38, 29 November 2009 (UTC)
5. 3 days is fine; if the users haven't come by then, they're unlikely to. As JimMillerJr states, the person opening the CDA won't choose a "bad" day. Stifle (talk) 11:56, 30 November 2009 (UTC)
6. CDA should only be on the table if all else has failed: that infers the matter has already been discussed with the admin, perhaps on a relevant policy page and maybe even in an RFC/U. In that context, the debate should already be "live" and there should already be 10 people teed up to respond in short order. I think 3 days is the right time, if not 2. AndrewRT(Talk) 22:15, 7 December 2009 (UTC)
7. Before being able to request a formal de-adminship, I think that an editor should be required to start a community discussion about the admin's behavior. If this step is taken and the discussion is held at a high-traffic venue (e.g., WP:AN or WP:RFC), then three days should be more than enough to have 10 users certify. –BLACK FALCON ^(TALK) 04:16, 13 December 2009 (UTC)
8. In line with my overall opinion that there is more to break than to fix when changing the current system, should any changes be made, I want to minimize the possibilities of potential gaming and clique-ganging. The shorter the time frame for implementing an RfDA the less prone it is for improper manipulation. -- Avi (talk) 06:32, 15 December 2009 (UTC)
9. Three days (72 hours) should be sufficient. If the issue were truly new to people, the admin under discussion must not have been a big problem. Conversely, if the community has already lost faith in the admin, sufficiently to require de-mopping, then presumably there's already public awareness of the issue, and people are just waiting for the opportunity to respond. Within three days, it will be clear which is the case. — Sizzle Flambé (☎/✍) 14:59, 23 December 2009 (UTC)

Neutral 3.1

1. 7 days is too long a process. 3 days is insufficient. Given we have a safeguard at RfC/U for 2 editors to certify within 48 hours, perhaps 4 days (if 7 users) or 5 days (if 10 users) is better? Ncmvocalist (talk) 06:26, 28 November 2009 (UTC)
2. I agree with Ncmvocalist. I would suggest 5 days (as the average of 3 days and 7 days). -- PhantomSteve/talk|contribs\ 23:16, 14 December 2009 (UTC)
3. I have no strong preference among the proposals of 3, 5, or 7 days. But I think the general structure is good. -Pete (talk) 23:07, 22 December 2009 (UTC)
4. Agree with what Ncmvocalist suggested above: 4 days for seven editors, or 5 days for ten editors. Personally, I lean towards the former (4 in 7d). //Blaxthos ( t / c ) 22:27, 23 December 2009 (UTC)

3.2 Modify the second bullet point about publicity. (Still being thought through; please see just below.)

Support 3.2

1. Support as proposer. I'm not convinced Admins and Crats need to be notified each time, since editors should be equal in this process. Obviously, it's essential that the Admin being accused needs to be informed. Also, it would be very desirable to have something like User:X!/RfX Report include this process. --Tryptofish (talk) 22:19, 22 November 2009 (UTC)

   Some editors have pointed out to me that I've been too vague about this point, and they are right. Sorry, I'm still thinking about it myself. If consensus develops for keeping the notices to Admins and Crats, that's not a big deal to me. But there are also other possible modifications to increase notice, and let's not lose track of those. I still think something like User:X!/RfX Report is important. Also, maybe the miscellaneous section of the Village Pump is too inconspicuous, so would other sections be advisable? --Tryptofish (talk) 16:18, 24 November 2009 (UTC)

   Another thought: will this process have a centralized page that users can watchlist? --Tryptofish (talk) 20:06, 3 December 2009 (UTC)

Oppose 3.2

1. Again no. There are hundreds of regular editors that watchlist, or frequently check on the Admin noticeboard, and it's probably a good thing for the crats to know about something regarding changing of rights. --Coffee // have a cup // ark // 13:48, 23 November 2009 (UTC)
2. Strongly agree with Coffee. The more notice the better, not less. I don't understand why this is being considered. Jusdafax 14:05, 23 November 2009 (UTC)
3. Oppose per Coffee and Jusdafax. Ben MacDui 20:00, 23 November 2009 (UTC)
4. Oppose. Removing an admin should be a very community wide discussion and as open and transparent as possible. With the "10 editors" requirement and the almost encouragement of canvassing, advertising needs to be a priority.--TParis00ap (talk) 14:32, 25 November 2009 (UTC)

4. A minimum 50 supporters for desysop

Existing wording

• No request shall be closed as a de-sysopping if fewer than 50 editors supported the desysopping.

Poll finding

Some editors believed that the then wording requiring 100 votes total was likely to be ineffective. The wording was subsequently changed to the above.

Possible option(s)

4.1 Replace current minimum (50) with 100.

Oppose 4.1

1. I think the change to 50 supports addressed the concerns. AndrewRT(Talk) 11:46, 22 November 2009 (UTC)
2. I agree, 50 is reasonable. --Tryptofish (talk) 22:20, 22 November 2009 (UTC)
3. I think 50 is fine. To be honest I don't think we need a quorum requirement in the first place. It will surely never be an issue, as these highly contentious debates will draw wide participation. Gigs (talk) 15:06, 24 November 2009 (UTC)
4. Agree that 50 is enough. Angryapathy (talk) 16:31, 24 November 2009 (UTC)
5. Per the above.  Sandstein  21:39, 25 November 2009 (UTC)
6. The minimum number of editors should apply to the whole discussion, not just one side. Mr.Z-man 00:36, 28 November 2009 (UTC)
7. Not sure having this is effective to begin with. Ncmvocalist (talk) 06:29, 28 November 2009 (UTC)
8. I don't feel this will be an issue, per Gigs, but I also feel that 50 is a reasonable number. --Mpdelbuono (talk) 07:02, 28 November 2009 (UTC)
9. 50 is enough, it is hard to get 100 votes at an RFA, so even a 99 for desysop versus 0 would not make the 100 limit. 50 is usually exceeded at RFA so it should be enough. Graeme Bartlett (talk) 10:47, 28 November 2009 (UTC)
10. Too high. Some RfA's don't even get 100 voters total. ThemFromSpace 09:15, 2 December 2009 (UTC)

Neutral 4.1

1. I doubt it will become an issue. Anyone who gets a proportion high enough to be desysopped will almost certainly have 50 (or 100) against them. Stifle (talk) 11:57, 30 November 2009 (UTC)

5. Need more concrete percentages for de-sysoping

Note: Given how central this issue is to the proposal, this section will not be archived until the period for commenting has ended.

Existing wording

• Bureaucrats are given the same discretion, and determine the community consensus in exactly the same manner, as at Requests for Adminship, with one added restriction. In unclear cases, multiple Bureaucrats may be involved. The added restriction is that no request shall be closed as a de-sysopping if fewer than 50 editors supported the desysopping. (The point of the process is determining the consensus of the Community at large.)

Poll finding Some editors were not clear if this meant that an existing Administrator needed to:

• receive 70% community support to continue in their role, or
• receive 70% community opposition to be de-sysopped.

Possible options There are presently four options: 5.1 would require 70% to desysop. 5.2 would require 70% to retain administrator status. 5.3 would require majority sentiment to desysop. 5.4 would require consensus to desysop.

5.1 Add to the current wording:

• "Thus, for an Administrator to be de-sysopped, a minimum of 50 editors and 70% of those expressing an opinion must support the desysopping."

Support 5.1

1. Partly Support – The first (at least 50 editors) is an important safeguard to de-admin, making reasonable yet considerable community involvement a requirement, and discouraging fence-sitting 'neutral' votes. However, I strongly oppose the second part requiring 70% as a firm basis to de-admin, and feel the final call in the 60-80% range should be a 'crat call, see below. Jusdafax 22:42, 22 November 2009 (UTC)
2. Support - Look if you can't find that many editors that want the person de-sysopped then do they need to be de-sysopped? However, just like in RFAs there should be a little wiggle room with the 70%. --Coffee // have a cup // ark // 13:52, 23 November 2009 (UTC)
3. Support 70% who favor desysopping/70% against keeping the bit for clarity. "No consensus/default maintain status quo" should be the order of the day here. I think 50 is on the low side - 50 out of 72 is pretty low participation for something this serious, 70 out of 100 is reasonable participation. davidwr/(talk)/(contribs)/(e-mail) 16:02, 23 November 2009 (UTC)
4. Support, if something like this were enacted, arbitration would be the proper avenue if the community does not come to a clear consensus either way. Seraphimblade ^{Talk to me} 06:59, 24 November 2009 (UTC)
5. Weak Support Second choice I prefer 5.4 below, which is the logical extension of 5.1. -- Avi (talk) 06:38, 15 December 2009 (UTC)

   I'm in the group who preferred the status quo. However, if something else is going to be implemented, at the very least, changing an editors current sysop-maintenance-tool status should require the same basic level of consensus, whether that is to give the tools or take them away. -- Avi (talk) 03:31, 25 November 2009 (UTC)

6. Support I think we need at least a concrete percentage. 70% is good, showing that a large majority of editors think the admin should not have the tools. Angryapathy (talk) 14:27, 25 November 2009 (UTC)
7. Partial support What is the point of having Bureaucrats involved if you're going to set hard limits? I think 70% should be a guideline (i.e. you need consensus to make a change, but consensus != strawpoll.). --Thinboy00 @904, i.e. 20:41, 25 November 2009 (UTC)
8. To clarify the meaning of the provision, per the opposes to 5.2 below.  Sandstein  21:42, 25 November 2009 (UTC)
9. This is a very clear cut decision, and would be seen as non controversial if used. Graeme Bartlett (talk) 11:21, 27 November 2009 (UTC)
10. Conditionally support on the condition that it does not become a hard vote, and still has some room for debate. For example, any reasonable bureaucrat should be able to identify when 70% of the support for de-sysop was by malicious users and still be able to nullify the vote. Hopefully this would never happen, but I am in support of the requirement of 70% plus certification. --Mpdelbuono (talk) 07:17, 28 November 2009 (UTC)
11. Support If it takes a 70% ratio to decide consensus exists to grant at RfA, then this must require a mirror-image of determining consensus to remove. The other options would allow less-than-consensus levels to undo something that has already been done by the community. We cannot allow something to be undone by a lower threshold than is required to make the change in the first place. This is not a reconfirmation RfA where we are looking to see if consensus still exists, but is rather a process of determining whenther consensus exists for action to be taken. That decision to act needs to have clear consensus to be seen as legitimate in the eyes of the community. Anything less is to suceptible to gaming. Jim Miller ^{See me | Touch me} 16:07, 29 November 2009 (UTC)
12. General support. Stifle (talk) 11:59, 30 November 2009 (UTC)
13. Consensus is to change. It takes about 70% to become an admin, so it should take about 70% to have it removed. This is taking revenge votes into account, which will undoubetly happen just as it has at RfA, if not more so. ThemFromSpace 09:19, 2 December 2009 (UTC)
14. Support - it should only be done if there is clear consensus. However, as others have already said, 70% should be a guideline subject to discretion at the margins. AndrewRT(Talk) 22:19, 7 December 2009 (UTC)
15. Support. This gives a reasonably accurate reflection of consensus. If only 30% support you, you have probably alienated even the moderates in the community. Sjakkalle (Check!) 13:41, 11 December 2009 (UTC)
16. 2nd preference, see proposal 5.4. –BLACK FALCON ^(TALK) 04:49, 13 December 2009 (UTC)
17. Support I think if 70% is the level at which you get adminship, it should be a similar percentage to remove it. I also agree with Sjakkalle's comment. -- PhantomSteve/talk|contribs\ 23:24, 14 December 2009 (UTC)
18. Why not? Let's keep it simple. –MuZemike 22:54, 22 December 2009 (UTC)
19. Support. The other percentages don't work for me. And “consensus” is poorly defined on Wikipedia. Greg L (talk) 05:44, 26 December 2009 (UTC)

Oppose 5.1

1. Partly Oppose – Agree with 50 minimum, however I strongly disagree with the the concept of a firm 70% being a requirement. Just as in an Rfa, final judgement should be left at Bureaucrat discretion. Jusdafax 22:43, 22 November 2009 (UTC)
2. Mild oppose. Better than nothing, and I do recognize that, by setting a very high barrier to desysop, this helps protect good admins, and incidentally will probably make it easier for the proposal to be adopted by the community. But I feel that it is awfully easy for certain drama-magnets to round up a dozen or so friends, and retain the tools in the face of general consensus to the contrary. If one needs around 70% to pass RfA, then one should still need around 70% to retain the community's support. --Tryptofish (talk) 23:02, 22 November 2009 (UTC)
3. Again, (erm, I am working back up the list), 15 votes out of 50 is far too gameable. LessHeard vanU (talk) 23:52, 22 November 2009 (UTC)
4. A RfA doesn't require 70% to pass, it is only recommended. Rami R 09:17, 26 November 2009 (UTC)
5. Strongly oppose 70% is way too high a bar. If 60% of editors think an admin should go, it's way past the point where an admin should go. Ray^Talk 21:28, 27 November 2009 (UTC)
6. Way too high. Ncmvocalist (talk) 06:31, 28 November 2009 (UTC)
7. Oppose. If an admin is simply taking on the difficult actions, they are more likely to loose support for many editors. They should not be penalized for taking on the difficult tasks and making the difficult decisions. Vegaswikian (talk) 03:02, 13 December 2009 (UTC)
8. Oppose, largely per Jusdafax. Final judgement on community consensus ought to be left to the discretion of the closing bureaucrat. A Stop at Willoughby (talk) 03:27, 15 December 2009 (UTC)
9. Hard limits are not the way to go. NW (Talk) 10:27, 23 December 2009 (UTC)
10. I prefer 5.4. Camaron · Christopher · talk 10:28, 23 December 2009 (UTC)
11. Oppose as too high: to be adminned requires consensus support (not merely the absence of consensus opposition); once it's clear the consensus no longer supports adminship, that's reason enough to withdraw it. — Sizzle Flambé (☎/✍) 15:08, 23 December 2009 (UTC)
12. Oppose both on the concept of having statutory percentages generally (see Judasfax above), and on the 70% number specifically (RayAYang's point); I am not opposed to language providing rough guidelines, but I think we're better served by letting the 'crats use discretion. //Blaxthos ( t / c ) 23:28, 23 December 2009 (UTC)
13. Oppose. Someone who is retained as an admin with less than 50% support casts a shadow on all other admins. It would then be technically correct to say that not all admins have majority support of the community. Lambanog (talk) 04:30, 24 December 2009 (UTC)
14. Oppose in several respects. First, we don't know whether 70% is a realistic number and it may not be possible to get a 70% majority to desysop anyone. Second, I don't like the message conveyed by having people vote to desysop an admin - it seems like we are punishing or taking something away, when admin status is neither a right nor a privilege, or a trophy, it's more like a volunteer job. Better to pose it as a re-confirmation, vote of confidence kind of thing. And finally, I agree with others who are uncomfortable with setting a hard target, best for the closing official to weight all the arguments than to count them. - Wikidemon (talk) 09:56, 24 December 2009 (UTC)
15. Oppose - 70% is too high a threshold given a perceived tendency of some Admins to support other Admins on solidarity grounds. Sarah777 (talk) 13:11, 24 December 2009 (UTC)
16. Oppose on the grounds of being inconsistent with the consensus support required for becoming an admin in the first place. When consensus doesn't support the admin position anymore, that should be enough to de-sysop someone. ~Amatulić (talk) 05:03, 25 December 2009 (UTC)
17. Oppose any hard numbers. — Bility (talk) 20:36, 31 December 2009 (UTC)

Neutral 5.1

5.2 Add to the current wording:

• "Thus, for an Administrator to be de-sysopped, a minimum of 50 editors must express an opinion, and fewer than 70% of those expressing an opinion must oppose the desysopping."

Support 5.2

1. Support. If you need 70% support to receive the tools at RfA, then you need 70% support to retain them here. --Tryptofish (talk) 23:02, 22 November 2009 (UTC)

Oppose 5.2

1. 15 votes out of 50 to get desysopped? That provides an effective vote of around 1 to 3 for every "deadmin" vote. Far too high, and gameable. LessHeard vanU (talk) 23:41, 22 November 2009 (UTC)
2. Too low for a process that will typically be initiated at the peak of opposition. Christopher Parham (talk) 05:47, 23 November 2009 (UTC)
3. Sorry, but a lot of admins become more controversial as they stay around. To easy to game if you try and make it a second RFA. --Coffee // have a cup // ark // 13:54, 23 November 2009 (UTC)
4. As LessHeard vanU, far too subject to gaming. Admins by the nature of what they do step into controversial situations, and may not necessarily have everyone like them. Seraphimblade ^{Talk to me} 07:00, 24 November 2009 (UTC)
5. Way too open to gaming. -- Avi (talk) 03:28, 25 November 2009 (UTC)
6. Per Seraphimblade.  Sandstein  21:43, 25 November 2009 (UTC)
7. A RfA doesn't require 70% to pass, it is only recommended. Rami R 09:17, 26 November 2009 (UTC)
8. If the test for desysop is so close to the amount required to be sysoped, then it is a bit unstable, and minor changes in opinion could swing the vote. Some one scraping in on 71% could be scraped out with a 69% a week later. Graeme Bartlett (talk) 11:18, 27 November 2009 (UTC)
9. Strongly oppose admins are going to stir up a little trouble with those that deserve blocks, etc., as they use their privileges. Often times (we hope) these are with perfectly reasonable intent. Actioned users and users that didn't get their way will tend to get angry at those who stopped them, even when they deserved it. I honestly feel this wording will only result in admins that are afraid to use their powers because of backlash from those that deserved it. I feel the concept of the silent majority could weigh in far too strongly with this proposal. --Mpdelbuono (talk) 07:12, 28 November 2009 (UTC)
10. This is not an issue of consensus can change, but a community process to take action. The standard is whether consensus exists to change the staus quo. Jim Miller ^{See me | Touch me} 16:16, 29 November 2009 (UTC)
11. Dear me, no. Several dozen of our best sysops would be history if this passes. Stifle (talk) 11:59, 30 November 2009 (UTC)
12. Oppose. This would make adminship into a revolving door. The moment you do anything at all that makes you less popular than you had to be to pass an RfA, you're out. rspεεr (talk) 06:04, 1 December 2009 (UTC)
13. Way too high. ThemFromSpace 09:20, 2 December 2009 (UTC)
14. Oppose since Trypto wanted more feedback on this, here it is... no this will not fly. The community doesn't seem to want reconfirmation RfA standards, they want it to be easier to keep the sysop bit. Gigs (talk) 18:32, 7 December 2009 (UTC)

    :-) --Tryptofish (talk) 18:42, 7 December 2009 (UTC)

15. I don't think this was ever the intention. AndrewRT(Talk) 22:21, 7 December 2009 (UTC)
16. Oppose. Adminship needs a modicum of stability, and some tolerance in making controversial actions. If the actions are so uncontroversially intolerable that the entire community turns away from you, that is a different matter, but at a higher percentage than implied here. Sjakkalle (Check!) 13:39, 11 December 2009 (UTC)
17. Too low. Admins often need to make decisions about controversial issues, and as long as they act in good faith, respect consensus, and use common sense, they should not have to worry about being de-sysopped so easily. I can think of several excellent admins who were instrumental in resolving (or at least containing) major nationalist disputes and who in the process drew the ire of many editors on both sides who felt that the admin had suppressed the truth of their side. –BLACK FALCON ^(TALK) 04:56, 13 December 2009 (UTC)
18. Oppose Admins tend to attract enemies as they perform essential duties which those on the 'receiving end' do not like. Expecting almost 3/4 of those voting to support keeping the bit is too high an expectation. -- PhantomSteve/talk|contribs\ 23:29, 14 December 2009 (UTC)
19. Oppose, largely per Jim Miller, Sjakkalle, and Phantomsteve. We must take care to protect our admins from suffering de-adminship due to the votes of those who are angry about their correct admin actions. A Stop at Willoughby (talk) 03:27, 15 December 2009 (UTC)
20. The others above said it better than I can. –MuZemike 22:56, 22 December 2009 (UTC)
21. Too low, 70% opposition needed to avoid de-sysoping would be a tall order for some admins which have created enemies but still generally do a reasonable job. Camaron · Christopher · talk 10:20, 23 December 2009 (UTC)
22. Oppose: While I agree in theory with Tryptofish's "support" argument #1, I worry about the gaming potential for a relatively small but determined group of the admin's opponents, among a less determined general community. Simple majority seems a safer level, to be sure the admin actually lost consensus support. — Sizzle Flambé (☎/✍) 15:23, 23 December 2009 (UTC)
23. Oppose - this sort of wording would effectively neuter our administrators, who would be understandably wary of making any sort of controversial decision (which we often ask them to do). While I don't always agree with every admin decision, I do believe we must take exceptional care to protect administrators' ability to make that tough (and sometimes unpopular) decision. //Blaxthos ( t / c ) 22:34, 23 December 2009 (UTC)
24. Oppose: Apart from anything else, raises the spectre of mutually assured destruction, where all controversial admins get targetted. Slowjoe17 (talk) 04:25, 25 December 2009 (UTC)
25. Oppose any hard numbers. — Bility (talk) 20:36, 31 December 2009 (UTC)

Neutral 5.2

1. I think we don't want repeated RfA do-overs for admins who are likely to be at the height of controversy. That said, I do think that if a significant fraction of editors (possibly over a third, definitely by a half) do not have trust in an admin, then it's way past the point where the admin needs to resign the bit. Ray^Talk 21:30, 27 November 2009 (UTC)
2. Would prefer something similar to this as more of a recommendation though. Ncmvocalist (talk) 07:03, 28 November 2009 (UTC)
3. Support idea but not the number. As per my opposition to 5.1 above I support posing this as a reconfirmation rather than a vote to desysop. However, the other two concerns remain, that the number is untested (and probably way too high). Also, I don't like the idea of a fixed number. A better idea would be for the reviewer to take into account all of the arguments why the person has or has not been an effective administrator and an asset to the project, and if there is sufficient evidence that their adminship is worthwhile they would pass. - Wikidemon (talk) 09:58, 24 December 2009 (UTC)

5.3 Add to the current wording:

• "Thus, for an Administrator to be de-sysopped, a minimum of 50 editors and a majority of those expressing an opinion must support the desysopping."

Support 5.3

1. Support as first choice. This option charts a middle ground between the other two, by setting the threshold at 50%+1 (with the closing Crat evaluating the case when in the fifties). Unlikely for a bad Admin to game the system with the help of a few friends, as in 5.1, and unlikely for a small number of bad editors with grudges to oust a good Admin, as in 5.2. (If I recollect correctly, there were some proposals worded this way in the previous poll, and there were positive comments about it.) We need most of all to get this part right, and I think this option does. --Tryptofish (talk) 23:02, 22 November 2009 (UTC)
2. Simple majority – 26 out of 50/51 participants. It would be difficult to meatpuppet either way. LessHeard vanU (talk) 23:48, 22 November 2009 (UTC)
3. Support If an admin can't get a simple majority at a highly publicized discussion, then there's no community trust in the admin. Ray^Talk 21:27, 27 November 2009 (UTC)
4. Support per Ray; simple majority is sufficient to show lack of consensus support for an admin, yet less vulnerable to gaming than the 30% set by 5.2. — Sizzle Flambé (☎/✍) 15:15, 23 December 2009 (UTC)
5. Support. To become an admin requires 70%. To be retained according to this proposal the admin need only get 50%. It is a low threshold, especially considering that other admins are among the most active participants in forums such as RfA and likely this proposed one. If the admin cannot even get 50%, how can he/she claim to be supported by the community? Lambanog (talk) 04:20, 24 December 2009 (UTC)
6. Support. While I have sympathy for the idea that 70% support at Rfa should mean 70% support to maintain that status I think this is a reasonable compromise where people fear that 15 votes might remove Admin powers. I reject the view that there should be an in-built bias in favour of retaining Adminship and don't really see why maintaining Sysop powers should be easier than getting them in the first place. That argument smacks of the club protecting it's members. Sarah777 (talk) 13:15, 24 December 2009 (UTC)

Oppose 5.3

1. Too low; process should require a robust consensus in favor of removing adminship. If it's a marginal case even in the aftermath of the admin's worst mistake, it's probably not necessary to remove adminship. Christopher Parham (talk) 05:50, 23 November 2009 (UTC)
2. Agree that 50% +1 is too low; in my view it should be in the 60-80% range as a consensus and at bureaucrat final judgement if it falls in that range. We have got to trust the community to guide a decision and the 'crats to make the final call... at least, that's how I see it. Jusdafax 07:23, 23 November 2009 (UTC)
3. As I said somewhere above, if you can't find 35 people out of 50 that want someone de-sysopped, why should they be de-sysopped? --Coffee // have a cup // ark // 13:56, 23 November 2009 (UTC)

   I think it is 50 support desysopping not 50 participating. Sole Soul (talk) 04:11, 29 November 2009 (UTC)

4. Still too gameable, and shouldn't be a majority vote. As I said above, if the community doesn't develop a clear consensus either way, the situation probably requires arbitration. Seraphimblade ^{Talk to me} 07:01, 24 November 2009 (UTC)
5. Too open to gaming. Changing the status quo requires the same level of consensus, whether that is to give the tools or take them away. -- Avi (talk) 03:29, 25 November 2009 (UTC)
6. Agree as above. A situation like this requires consensus, not majority. --Mpdelbuono (talk) 07:15, 28 November 2009 (UTC)
7. As noted in my support of 5.1 above, this is a community decision to take action, and reverse prior community consensus. There must be at least as much support to remove the bit as there was to grant it at RfA. Jim Miller ^{See me | Touch me} 16:12, 29 November 2009 (UTC)
8. Fine as-is. Stifle (talk) 12:03, 30 November 2009 (UTC)#
9. Jusdafax sums it up well for me. AndrewRT(Talk) 22:22, 7 December 2009 (UTC)
10. Better than 5.2, but still sets the bar for de-sysopping too low. –BLACK FALCON ^(TALK) 04:57, 13 December 2009 (UTC)
11. Oppose, largely per Jusdafax and Jim Miller. It should be up to the closing bureaucrat to determine consensus; de-adminship should not be a majority vote, and there moreover must be more than a simple majority supporting de-adminship. A Stop at Willoughby (talk) 03:27, 15 December 2009 (UTC)
12. Per Jim Miller. –MuZemike 22:57, 22 December 2009 (UTC)
13. Too low, bureaucrats should have more of a role here as well, and if the community is divided it is probably best taken to arbitration. Camaron · Christopher · talk 10:25, 23 December 2009 (UTC)
14. This proposal would just turn it into a majority vote ... a !(!vote). //Blaxthos ( t / c ) 22:36, 23 December 2009 (UTC)
15. I agree with others that this makes it too easy, and simple majority rule is not a good way to make important decisions. - Wikidemon (talk) 10:02, 24 December 2009 (UTC)
16. Oppose any hard numbers. — Bility (talk) 20:36, 31 December 2009 (UTC)

Neutral 5.3

1. It's reasonable to forbid desysoping w/o a majority endorsing it. However, I still don't like explicitly stating a minimum. Rami R 09:17, 26 November 2009 (UTC)

   My understanding is that this would be like an RfA, in that the closing Crat would assess close cases, in all 3 options. --Tryptofish (talk) 22:31, 26 November 2009 (UTC)

   I understand that, and I want to keep it that way. I mostly worry that a set-in-stone limit would undermine that. Rami R 21:58, 29 November 2009 (UTC)

   You are right. We ought to word it so that it says that explicitly, no matter which of the options we choose. --Tryptofish (talk) 22:12, 29 November 2009 (UTC)

Additional Comments 5.3

1. I would propose adding a restriction of a user in good standing being able to only nominate an admin for de-adminship once a month, but the number of hurdles that those seemingly opposed to any change in the status quo wish to introduce are making a mockery of the fundamental motivations behind this process and the notion that being an admin is nothing special. If the hurdle was 50% I would say include such a restriction. But with people deeming a 70% hurdle as required then additional hoops for nominators to jump through are not necessary. Lambanog (talk) 06:49, 31 December 2009 (UTC)
2. Comment: English Wikisource already has a process for CDA - similar to what is proposed here. See wikisource:Wikisource:Restricted_access_policy#Votes_of_confidence. The percentage they use is 50%. AndrewRT(Talk) 17:57, 1 January 2010 (UTC)

5.4 Add to the current wording:

• "Thus, for an Administrator to be de-sysopped, a bureaucrat will review the discussion to see whether both a minimum of 50 editors and a general consensus supports de-sysopping. Consensus is sometimes difficult to ascertain and is not a numerical measurement, but as a general descriptive rule of thumb, above ~80% support for de-sysopping would be acceptable; while support below ~70% would not be, and the area between is subject to bureaucratic discretion."

Support 5.4

1. Support as proposer. Wording largely taken from Wikipedia:Requests for adminship. Lengthy, but fairly clear. SilkTork *^YES! 19:08, 4 December 2009 (UTC)
2. I like the wording and the way it infers a principles based rather than numbers based decision. It's my second prefered option! Although the symmetry is neat, I'm not quite sure that 70-80% is the right level, given that a well connected admin will always be able to round up a few friends to fight his corner. AndrewRT(Talk) 22:25, 7 December 2009 (UTC)
3. Only wording I can agree with. The exact numbers, particularly 70%, are a bit high, though. Maybe 60% would be better. Rami R 14:57, 11 December 2009 (UTC)
4. I agree that crat discretion should essentially be limited to the 70-80% range, but I prefer trusting a bureaucrat's evaluation of consensus to specifying a particular percentage threshold. There is no qualitative difference between 69.93% support and 70.03% support. 2nd preference is proposal 5.1. –BLACK FALCON ^(TALK) 04:49, 13 December 2009 (UTC)
5. Support Since de-adminship is going to be a sort of reverse RfA, this wording makes the most sense to me. A Stop at Willoughby (talk) 03:27, 15 December 2009 (UTC)
6. Weak support While my overall position is that there is more to break than to fix when changing the current system, should any changes be made, I think that an RfDA should be symmetrical to an RfA, in that changing the status quo would require the same level of consensus. -- Avi (talk) 06:36, 15 December 2009 (UTC)
7. This provides for an appropriately strong consensus. Christopher Parham (talk) 15:58, 17 December 2009 (UTC)
8. I'd suggest 60-80% to be within the bureacrats range, but it's the best suggestion so far. Angryapathy (talk) 19:45, 22 December 2009 (UTC)
9. As an alternative to 5.1. –MuZemike 22:59, 22 December 2009 (UTC)
10. Pete (talk) 23:05, 22 December 2009 (UTC)
11. Best to keep it as similar to the current RfA system as possible. We can adjust it later if need be. NW (Talk) 10:19, 23 December 2009 (UTC)
12. A mirror process to RfA makes sense, as a de-sysopping process effectively reverses it, and bureaucrat discretion is particular important in a process open to gaming. The requirements are rather high, but it will probably make the process more easily get community approval. I would support lower numbers if the numbers at RfA were also reduced. Camaron · Christopher · talk 10:34, 23 December 2009 (UTC)
13. I'd also prefer 60-80%, but this is acceptable. I certainly don't want a hard number, but about 70% should be enough. Hobit (talk) 01:51, 25 December 2009 (UTC)
14. Support - given the other suggestions made, this one seems closest to the mark (IMHO). I personally wouldn't object to softening the language a little bit to strengthen the understanding that ultimately the determinate factor is the consensus (not the !count), but in the interests of forward progress I think this is the clear winner. //Blaxthos ( t / c ) 05:13, 25 December 2009 (UTC)
15. Spotting consensus is certainly the road to go down. This could well be the only type of solution (eg a bureaucrat makes the final decision) that gets a genuine consensus for change too. I would leave the percentage as loose as possible - exact numbers rather contradict the idea. When these proceedings are as fair and open as they should be, bureaucrats etc will want to be seen making the right decisions, no matter how messy they might seem, to show their capacity to do their job. In a sense, it will make them more responsible too. I genuinely think that having a CDA process will provide benefits across Wikipedia. How can it not? It's just a question of ironing things out - specifically gaming. Difficult and complicated decisions will no-doubt have 'smoke' of some kind or other, so other 'observations' can be handily made by bureaucrats at the final stages, in the cases where de-sysoping is too extreme perhaps. Matt Lewis (talk) 21:46, 26 December 2009 (UTC)
16. Now that I really read it, this is essentially what I was supporting by !voting for 5.1, earlier.
    — V = I * R (talk to Ω) 22:23, 27 December 2009 (UTC)

Oppose 5.4

1. Oppose It puts the burden on the bureaucrat to make the de-adminning decision, precisely when the community is divided — not at all like the gladsome job of giving someone admin buttons due to consensus support. If a bureaucrat has to take those buttons away again, give him or her the basis of a clear hard objective support level (whether simple majority or another percentage), so his/her own "discretion" doesn't become another issue. — Sizzle Flambé (☎/✍) 15:34, 23 December 2009 (UTC)
2. Oppose. This is basically proposal 5.1 because of the second sentence and is opposed for that reason. Bureaucrat role not the problem for me. Lambanog (talk) 04:38, 24 December 2009 (UTC)
3. Oppose. Police policing the police never works in RL or on Wiki. Sarah777 (talk) 13:21, 24 December 2009 (UTC)
4. Oppose. “Consensus” is not well defined on Wikipedia and just begs for vitriol and conflict. Keep it unambiguous. Greg L (talk) 05:45, 26 December 2009 (UTC)
5. Oppose any hard numbers. — Bility (talk) 20:36, 31 December 2009 (UTC)

Neutral 5.4

1. There's actually a lot that I support about this version. In spirit, the wording is similar to what I intended in 5.3, but better-communicated. Regardless of which % we end up going with, this is the sort of wording that should be employed. My only (and increasingly mild) reason for not supporting is my concern under mild oppose to 5.1. --Tryptofish (talk) 19:30, 4 December 2009 (UTC)
2. I definitely like the consensus approach. However, I think we should require a consensus to keep the tools, but with the nature and wording of consensus geared towards a realistic, fair evaluation that the admin is a net asset to the project, rather than a contest to get people desysopped. - Wikidemon (talk) 10:04, 24 December 2009 (UTC)

WARNING NOTE

Numeric/percentage based systems are game-able/can be gamed/have been gamed in the past.

A numeric-based system for de-adminship, in combination with the current percentage-based requests for adminship opens a potential exploit:

A sufficiently well informed and motivated party (be it for the lulz, or for more serious reasons), would be able to perform a hostile takeover of Wikipedia, at least temporarily. As follows:

• place a sufficient number of supporters on wikipedia for a long enough period to become established, similar to the methods now used for making stealth-socks (but no actual socking is required)
• +admin supporters
• -admin detracting admins
• one now has sufficient power to subtly alter wikipedia's behaviour as one sees fit.
• With sufficient admins on attacking side, one could speed up the process, and simply start blocking all detractors outright, wheel-warring as necessary. This would -however- attract a lot of attention to the takeover, and thus might lead to foundation intervention.

--Kim Bruning (talk) 14:41, 16 December 2009 (UTC)

I think a lot of us are coming to agree that the point you raise is a good one, to the extent that strict numerical wordings are a bad idea. In fact, I think a lot of the late interest in 5.4 comes from the recognition that whatever we end up with should be more like RfA in the way that it determines consensus. Regardless of what, at the end of the discussion period, we end up deciding on amongst the first three proposed options, it is becoming increasingly clear that we will need to structure the wording of the final language more like 5.4. --Tryptofish (talk) 18:07, 18 December 2009 (UTC)

---Fairly wild conspiracy theory there! The more reasonable proposals such as 5.2 would also make it easier to get rid of stealth Admins involved in any such "takeover" plot. An equally valid WARNING here is that proposals such as 5.4 effectively do nothing to tackle bad Admins whose activities undermine the project. Sarah777 (talk) 13:29, 24 December 2009 (UTC)

Sarah, I think your point about bureaucrats not being able to 'police the police' (whether valid or not) needs to be re-assessed after a CDA process like 5.4 has come into being - because I think simply having a CDA will make all of Wikipedia more accountable. We've all seen aiming 'too high' get nowhere at all on Wikipedia. 5.4 is a compromise that could work, and be improved upon in the future if the need ever comes apparent. Providing it is flexible on consensus, it also at least offers a solution to 'percentage gaming'. Matt Lewis (talk) 22:31, 27 December 2009 (UTC)

I wouldn't say that I'm known for conspiracy theories. I used to experience things like channel wars on irc back in the '90s . I've also helped deal with attacks and other diverse emergencies on wikipedia.

Proposal 5.2 actually lowers the barrier so you only need to inject 30% of your own people into the de-admin process to effect a hostile takeover. If we project that ~100 people might participate on "discussing" any particular admin, that mean you need only ~30 accounts and ~6 months to take over the wiki. Less if you're smart about socking, or use other loopholes or cracking. I don't think that that is an insurmountable obstacle by any means.

Some more about the use of cracking: I was once adminning/chan-opping an IRC channel that was lost in under 24 hours due to the fact that one of my not-so-smart colleagues managed to accept a trojan from an attacker. I'm sure wikipedia is slightly less vulnerable than irc channels were (before use of chanservs became common). Assuming 30K active accounts -and a bit of luck-, you would need to attack a whopping 0.1% of active accounts to be able to effect a takeover in the shorter term using the loophole created by option 5.2 alone. I'm pretty sure that only a fraction of wikipedians really are that security-conscious though, so I would project rather higher success rates. (Has your virus-scanner caught a virus on your PC in -say- the last 12 months? If so, you would be susceptible to this attack vector.)

It might be fun to have a demo-wiki on a vm; We could set up 2 teams and have wiki-wars ;-) We could even tweak the rules to make attacking easier. But on wikipedia itself: this is an encyclopedia, WP:NOT a battlefield; and we do need to keep an eye on who controls the wiki.

--Kim Bruning (talk) 09:15, 28 December 2009 (UTC) And now you know why I'm such a hard-core fan of IAR. It might sound ironic to some; but IAR allows us to close the loopholes caused by incautious bureaucratic types.

This process seems to be showing an inherent bias in administrators supporting their own. Gaming is likely to work in an admins favor. I favor an implementation of nominators restricted to one nominee per month but a 50% threshold for removal subject to bureaucratic discretion. I don't see that proposal anywhere. By the way the CdA process does have the potential benefit of possibly serving as bait to expose user accounts created for sabotaging purposes that currently silently eat away at the project. Lambanog (talk) 07:03, 31 December 2009 (UTC)

6. Should not have the Bureaucrats involved at all

Existing wording

• Bureaucrats determine the consensus of the community, using both the opinion poll and the discussion on the talk page.

Poll finding

Some repondents felt that this put too much onus on Bureaucrats. Note that input from Bureaucrats is being/has been sought.

Possible option(s)

6.1 Replace current wording with...

Result

At date/time of this edit:

Support 0

Oppose

Neutral

Details archived per above.

Oppose 6.1

1. No, this bit shouldn't change. Bureaucrats were elected to judge adminship-related consensus. Since this process has a similar format as RfA, albeit in reverse and with the necessary requirements, a crat should be the one to judge the result of these cases. It would simply be their job at RfX carried over. Besides, I don't know what other trusted users would be fit for the position – Arbitrators are elected to make standalone decisions, while crats are elected to judge consensus. This is a community decision, so it falls in the latter category. JamieS93 13:45, 22 November 2009 (UTC)
2. Oppose per Jamie, who pretty much nails it. (Well done, Jamie.) However, I've been calling for the 'crats to speak up on this point since I first voted for Option 4, 'Community de-adminship'. We have now reached a critical phase; I will now ask them directly on their page. Jusdafax 17:23, 22 November 2009 (UTC)
3. I agree with the above. We would only be asking the Crats to make the same kind of determination that they make after an RfA, and we do need someone designated to perform this role. --Tryptofish (talk) 22:23, 22 November 2009 (UTC)
4. Agree as well, crats were made crats to judge who should be an admin or not. Asking them to do this isn't out of line. Gigs (talk) 15:11, 24 November 2009 (UTC)
5. If the bureaucrats are trusted to judge RfA's, then they can judge CDA. The 'crats can also objectively see if the system is being gamed. Angryapathy (talk) 16:33, 24 November 2009 (UTC)
6.  Bureaucrat note:<-- to ensure any potential conflict of interest is immediately recognized. As Jamie says, for better or for worse, the bureaucrats are the ones who were selected by the community for their ability to judge and recognize community consensus or lack thereof. If the project is going to move the authority for desysopping from ArbCom to the franchised editor body, then it should be similar to the the methods used to grant the tools. Again, I should note, I prefer to keep the desysopping power in the hands of ArbCom, with, perhaps, a streamlined process and possibly larger subcommittee, but that is another story. -- Avi (talk) 03:37, 25 November 2009 (UTC)
7. Oppose I can't say it better than Jaime but she and Avi have hit it. It's the 'crats job.--TParis00ap (talk) 14:44, 25 November 2009 (UTC)
8. Per Avraham.  Sandstein  21:43, 25 November 2009 (UTC)
9. Strongly Oppose as specified in 5.1, bureaucrats are vital to this process in ensuring it is truly what the community wants. No amount of numbers mangling can compensate for a solid head. The bureaucrats were selected by the community, and we should be able to trust them to do what we said they should be able to do. --Mpdelbuono (talk) 07:20, 28 November 2009 (UTC)
10. Oppose Bureaucrats are elected for consensus-judging abilities so it makes sense that they'd be the best to close these sensitive matters. ThemFromSpace 09:24, 2 December 2009 (UTC)

Neutral 6.1

1. My initial take was that the CDA process was flawed because this was asking a lot of the Bureaucrats. However, a feature of CDA that found a lot of support in the earlier poll was that it was simple to grasp as it was a "mirror image" of an RfA, and clearly the 'crats role is thus an important feature. Furthermore, no alternative idea seemed to get much support. I await Bureaucrat input with interest. Ben MacDui 11:15, 22 November 2009 (UTC)
2. Agree with Ben, I'd like to see what the crats have to say. If they'd be unwilling to take on this role, we'd have to find an alternative, like it or not. Seraphimblade ^{Talk to me} 07:02, 24 November 2009 (UTC)

7. Too easy to game the system

Existing wording

A general comment and specific wordings may not apply.

Poll finding

Some editors believed that Administrators would find the system too easy to beat, even if there was widespread opposition to their continuing in the role, while others felt that it would be too easy to bring frivolous charges against good Administrators.

Possible option(s)

7.1 Replace current wording with...

Support 7.1

1. Honestly, I'd replace the text with "Matters involving alleged administrative abuse are complex and should be handled only through arbitration." But if there is going to be something like this anyway, let's make it as robust and resistant to gaming as possible. Seraphimblade ^{Talk to me} 07:04, 24 November 2009 (UTC)

Oppose 7.1

1. Oppose This proposal is not meant to be an end to resolution for the community. ArbCom is the next step. This is simply a streamlined process to avoid the long and complex ArbCom process. If, once approved and enacted, this proposal doesn't work out in a specific case, it can be brought to the next level.--TParis00ap (talk) 14:47, 25 November 2009 (UTC)
2. If an admin is really gaming the system, then ArbCom should be able to take care of the situation. The amount of work that would be necessary to protect against something like this is severely outweighed by the simplicity of "just take it to the next level." --Mpdelbuono (talk) 08:03, 28 November 2009 (UTC)

Neutral 7.1

Comment. Some editors will oppose any proposal such as this, and that's the way the system works. If we get everything else right (especially the percentage to desysop), then this question takes care of itself. --Tryptofish (talk) 22:26, 22 November 2009 (UTC)

Comment – Agreed, well said. Besides, eternal vigilance is the price of Wikipedia. Jusdafax 23:04, 22 November 2009 (UTC)

Suggestion. Something else occurs to me. It would be at least somewhat helpful, to this end, to spell out as clearly as possible what are the valid and the not-valid reasons to bring action through this process. The current draft does this fairly well, but Option 3 of the previous poll (written by Beebelbrox) did what I think is a superb job here of elaborating on it. How about we merge that text into the proposal here? --Tryptofish (talk) 23:18, 22 November 2009 (UTC)

I agree - but with the caveat that I think it is going to get complex if the wording of CDA gets amended numerous times during this process. Could I suggest drawing up a merged version, creating a sub-page or linked page to this one so that interested parties can see what is intended? It could then appear above as an option for comment. Ben MacDui 20:13, 23 November 2009 (UTC)

I don't like this suggestion. Just as we don't have hard RfA requirements, I don't believe we should have hard CDA requirements. I think if we develop a hard policy, it should be related to only speedy closes. I think that developing a robust set of speedy close criteria would help concerns about frivolous actions and would make people hesitate less about lowering the barriers to entry here. Gigs (talk) 15:14, 24 November 2009 (UTC)

• It would be useful, in my opinion, to have some other DR (3O, ANI, anything) as a prerequisite to filing a CDA. Stifle (talk) 12:04, 30 November 2009 (UTC)

8. Possible outcomes short of full desysoping

Possible options

8.1 Replace current wording with... An admin may be desysopped indefinitely, and may only regain the flags by making a new Request for Adminship, or for a period to be determined during the process, of not more than one year. LessHeard vanU (talk) 11:51, 22 November 2009 (UTC)

Support 8.1

1. A bad admin is a bad admin and should be removed from the corp. A good admin who is going through a bad patch should have the flags removed for as long as is necessary to avoid ongoing misuse. This also stops poor admins from not having their rights removed because they were good previously, but allows them to return when refreshed (without needing to go through RfA). A sanction of more than one year is a clear indication that they should not have the flags until they can prove they will not abuse them – so the indefinite tariff is more appropriate. LessHeard vanU (talk) 11:51, 22 November 2009 (UTC)

   Comment/question. Not an unreasonable idea, but by what method would the determination take place – it would need something consistent. Ben MacDui 13:12, 22 November 2009 (UTC)

   If adopted it would grow organically out of the discussion. "Put the mop back in the cupboard and throw away the key" might be the conclusion, or "These were bad decisions and actions, which is a pity because previously you were doing fine. Your perspective will likely have returned in a couple of months time, when the buttons will be returned". Both valid, and permits flexibility. LessHeard vanU (talk) 23:29, 22 November 2009 (UTC)

2. We need a way to deal with a pattern of bad admin decisions that would be effective, but so so drastic that people would be over-reluctant to convict. For example if someone is more than just very rarely using his own private opinion to speedy articles, and has not responded to request for improvement, something needs to be done about it. I'm not at all sure we could get the necessary percentage to desysop totally in a case like this, whereas we might if the period were limited to a month or so, enough to make a solid impression that would prevent further abuse of the rules. DGG ( talk ) 05:13, 3 December 2009 (UTC) .

Oppose 8.1

1. The simplicity of the idea strikes me as being a big advantage. If too many other options were on offer this might result in unseemly plea bargaining. On the other hand I believe there is a possible role for WikiProject Administrator in offering assistance to admins who are in need of some mentoring. We all have off days, we all make mistakes and we seem to have lost no few good admins through some kind of process of attrition. I take my hat off to admins who engage in complex and particularly controversial tasks and a support mechanism for admins who are feeling the stress would not go amiss. Ben MacDui 11:22, 22 November 2009 (UTC)
2. As I mentioned above, deadmin should be considered a last resort after other things have been exhausted. in practice it might be sensible to have, for instance, an RFC/U or ANI discussion first, and only come here if there is a clear case for removal. Likewise, if someone brings a case here before exhausting other possibilities, I would personally vote No – and perhaps the guidance should be expanded to make that clear. In that context, having just two options for this process makes sense. AndrewRT(Talk) 11:49, 22 November 2009 (UTC)
3. Administrative supervision is the only thing I can think of that might work instead of full desysopping, and I don't believe that would be applicable here. Temporary desysoppings are not such a good idea – if we don't trust them with the tools today, why would be trust them enough in six months to give the tools back to them without review? NW (Talk) 20:38, 22 November 2009 (UTC)
4. I oppose this option. The correct !vote for cases where full desysoping is not justified is to !vote for keeping the tools, while commenting that a lesser action such as mentoring should take place. --Tryptofish (talk) 22:29, 22 November 2009 (UTC)
5. Desysopping is warranted or not. If the administrator has made errors but not yet to the point of being desysopped, provide feedback to them—hopefully, being told by several editors/fellow admins "Look, you've really screwed up here" is enough to cause them to reexamine their actions (and for clarity, I would not support any request of this nature where feedback to the admin had not been attempted and failed multiple times). If they have gotten to the point of involuntary desysop, they should be subject to some type of review before the tools are regained. Seraphimblade ^{Talk to me} 07:08, 24 November 2009 (UTC)
6. If the CDA becomes contentious, but the admin prevails, the admin will see that the community has some serious qualms about their abilities, and hopefully would serve as a wake-up call. Having a dedicated forum to people complaining about your actions can be a sobering day. Angryapathy (talk) 16:38, 24 November 2009 (UTC)
7. I am sympathetic to the idea of this proposal, but simplicity simply is best here.--TParis00ap (talk) 14:48, 25 November 2009 (UTC)
8. Unneeded complexity.  Sandstein  21:46, 25 November 2009 (UTC)
9. After chewing this over, I agree with Sandstein. It might be nice to have a range of options, but in the end simpler is better here. If you mess up, you lose the buttons. In conjunction with adoption of a 60 - 80% consensus vote to deadmin (should this become an accepted part of the overall proposal) then it seems a black or white choice is in order. Jusdafax 03:02, 28 November 2009 (UTC)
10. More complex solutions can be handled by the ArbCom after this process fails. Assuming 5.1 is implemented, if the community votes 70% in disfavor, then there's probably a serious problem that needs serious resolution. Desysopping is that solution; there's nothing that says he/she can't work around the community for a few months and file a new RfA later after he/she feels community support has been regained. --Mpdelbuono (talk) 07:30, 28 November 2009 (UTC)
11. I agree with Mpdelbuono and many other opinions above, that more nuanced decisions should be made through other processes. What I would expect to see at CDA are either general user complaints about misuse of the Admin position (either status or tools) or proposals where the community wishes to override an ArbCom decision that is felt to be too lenient. CDA should be for clear-cut up or down decisions to remove the bit. CDA is about community consensus, and that is far more complex to determine if multiple options for the outcome are allowed. Jim Miller ^{See me | Touch me} 20:41, 3 December 2009 (UTC)

Neutral 8.1

8.2 Instead, allow for more discussion and not simple bulleted !votes.

Support 8.2

1. Support as proposer. The current version of the draft says that the first nominator gives a short explanation, and the remaining nine nominators give only a numbered signature with no comments, and subsequent participants make only brief comments, with longer comments "mercilessly" stricken. That's a bad idea. As with RfAs, editors should be encouraged to give reasons, not just !vote "me too". We might even want the closing Crat to de-emphasize !votes that lack explanations. A benefit of allowing discussion is that it makes it easier for editors who do not want to see full desysoping explain what actions they might prefer instead. --Tryptofish (talk) 22:37, 22 November 2009 (UTC)
2. Per Tryptofish (irony alert!) – if the process seeks to emulate RfA, insisting on "as per" arguments instead of considered rationales seems a bit backward. LessHeard vanU (talk) 23:33, 22 November 2009 (UTC)

   Per LessHeard. :-D --Tryptofish (talk) 15:36, 23 November 2009 (UTC)

3. Agree I think this is one area that I strongly diverge from original writer, Uncle G, who mostly came up with a fine document. I think encouraging comment, within reason, is important in something of this gravity and fail to see the point of restricting it under the draconian language used in the original document. Jusdafax 23:37, 22 November 2009 (UTC)
4. Yes indeed. CDA should be similar to RfA in that votes are !votes, since there ought to be an exchange of reasons and arguments for why an admin should(n't) be desysopped. That way, we stick with the heart of WP:CON, and crats can properly judge a possibly difficult situation, and discount certain rationales if needbe. JamieS93 15:49, 23 November 2009 (UTC)
5. Support allowing discussions - without discussion I'm voting half-blind. I can't be expected to read every edit in a person's edit history. davidwr/(talk)/(contribs)/(e-mail) 22:03, 23 November 2009 (UTC)
6. Absolutely. Even where numbers may matter to some degree, discussion should always be paramount. Even if that's true for no other reason, we would certainly want a discussion of this nature and gravity to indicate why someone either was desysopped (for both their knowledge and the knowledge of others who may come into similar situations), or why they were not (both for the knowledge of the person it was attempted on to know what some did object to, and for the knowledge of those considering initiating a request under similar circumstances). Seraphimblade ^{Talk to me} 07:12, 24 November 2009 (UTC)
7. Community consensus should always be discussion and not votes. A voter may not have seen all perspectives and cannot change their vote if they are not given the other point of view.--TParis00ap (talk) 14:50, 25 November 2009 (UTC)
8. I assume this is a proposal to allow short comments in the nomination, with which I agree. The actual deadminship poll already allows comments: "The poll contains three sections, support, oppose, and neutral. An opinion is registered with a signed numbered list entry (the # markup), exactly as is done at Requests for Adminship. A short comment may be made." I also assume that threaded discussion may occur on the talk page, as with RfA.  Sandstein  21:53, 25 November 2009 (UTC)
9. Certainly allow comments, as many as are necessary. They can be contained in a hide show box if one !vote's discussion becomes too big. Graeme Bartlett (talk) 11:24, 27 November 2009 (UTC)
10. Support as above. Discussion promotes more accurate !voting and discussion of opinions between participants. --Mpdelbuono (talk) 07:34, 28 November 2009 (UTC)
11. I should have read the proposal better, as I assumed this was already the case. Anyway, I think the discussion can gauge consensus better than plain votes. This should definately be in the proposal. Angryapathy (talk) 07:31, 29 November 2009 (UTC)
12. Support. We need an alternative wording to allow the same sort of discussion as takes place at RfA. SilkTork *^YES! 19:16, 4 December 2009 (UTC)

9. Nominators with conflicts of interests

Current wording: Where nomination is made by editors in good standing, those editors:...

Proposed wording: Where nomination is made by editors in good standing, those editors: ... should not be nominating in a manner which is or appears to be related to a content dispute. Editors which have had recent or well-known content disputes related to the administrator are strongly encouraged to act as if they are ineligible to nominate.

Comments 9.1

• This cuts down accusations of payback and the resulting drama, even when the grounds for nomination are solid. The wording "should not be nominating" rather than "must not be nominating" is deliberate - failure to adhere to this is grounds for verbal flogging but not grounds for removing the nomination. davidwr/(talk)/(contribs)/(e-mail) 21:56, 23 November 2009 (UTC)

Oppose 9.1

1. I partially oppose this, because it can be too gameable. It's too easy to imagine a bad Admin saying: "This editor can't count, because s/he has a COI resulting from a disagreement we once had." The sky's the limit for how that could be played. In fact, there will almost always be some degree of past disagreement about something in these cases. It is appropriate for that to come under scrutiny, and for the community to assess it while the process goes forward, but not for it to be a unilateral veto from the start. I'm sympathetic to protecting admins from payback, and I agree that all noms should be scrutinized rigorously for COI, but this approach is too heavy-handed. --Tryptofish (talk) 15:48, 24 November 2009 (UTC)
2. I oppose this for the simple fact that the wording is too non-commital. Anyone could make an argument on both sides on whether or not they have a COI. Angryapathy (talk) 16:40, 24 November 2009 (UTC)
3. Needless complication. If a request is simply motivated by content disagreements, it will likely fail at the polling stage or be closed as abusive by a bureaucrat.  Sandstein  21:55, 25 November 2009 (UTC)
4. Keep it simple, although it get the RfC in the door, the COI nominators should be over whelmed by others. Graeme Bartlett (talk) 11:27, 27 November 2009 (UTC)
5. No. Who else is going to call an admin to account, if not those who've had conflict with the admin in some way? I assure you, Wikipedia does not have a surplus of editors who avoid getting into conflicts, and yet go around seeking to police the behavior of others. The one tends to preclude the other. Ray^Talk 21:35, 27 November 2009 (UTC)
6. Concerned that this will be gamed. Also per Sandstein. Ncmvocalist (talk) 06:59, 28 November 2009 (UTC)
7. Oppose per just about everyone, but especially Sandstein.--SPhilbrickT 13:54, 30 November 2009 (UTC)
8. I support this but only as part of robust "speedy close" criteria that I believe we should develop. As stated above, I believe the threshold for bringing these kinds of actions should be low, and we should develop a set of speedy close criteria. This reflects what we do with other processes in order to handle malicious or frivolous nominations. Gigs (talk) 15:18, 24 November 2009 (UTC) Moved to oppose because speedy close criteria which seem to be developing would include this sort of thing anyway. Gigs (talk) 18:25, 7 December 2009 (UTC)

Neutral 9.1

1. Protecting admins against illegitimate "Ax-to-Grind" complaints needs to be covered by something bigger and broader than this. This particular clause is, I think, too restrictive: sometimes admin abuses have to do with content conflicts that not many people know about and that's just the situation. I feel that this document should have a more generalizable clause to the effect of: "case(s) of de-adminiship where there is evidence of a conspiracy or ganging-up to de-admin sysop(s) for inappropriate reasons require further examination and discussion beyond meeting statistical requirements" or some other kind of stop mechanism. (cont.)

I would be loathe, for example, to hear about a herd of hundreds of free-market libertarians systematically de-admining those who prevent them from making their favorite pages one-sided odes to Ayn Rand. Even worse though, would be hearing that bureaucrats and other wikipedians do not have any formal mechanism to prevent this even though they picked up the pattern.

There is no question that de-adminning someone for strategic purposes (such as regaining control of an article) and not because of an actual flaw or POV problem in their adminning is a Very Bad Thing. And there is no question that when it is a personal/political ax to grind, or a group of people working against any admin who does or says this or that, it is all the much worse. The discouragement of dishonest numbers-game de-adminship should not exist in this document as a technicality built into who can nominate, it should be an important general principle. --Lyc. cooperi (talk) 07:33, 25 November 2009 (UTC)

10. Allow non-eligible nominations but don't count them as such

Current wording:

Nomination by the Community at large requires the signatures of no fewer than 10 editors in good standing (defined below), within a period not longer than 3 days. Signatures must be placed in the nomination area of the requests, as a simple signed bullet point.

Proposed wording:

Nomination by the Community at large requires the signatures of no fewer than 10 editors in good standing (defined below), within a period not longer than 3 days. Editors not in good standing or who wish to claim a conflict of interest may nominate, but their nominations will not count toward the minimum. Signatures must be placed in the nomination area of the requests, as a simple signed bullet point. Nominations by editors who have a real or apparent conflict of interest or who are not in good standing must be clearly identified as "ineligible to nominate or conflict of interest" or similar wording.

Comments 10.1

• Editors who for whatever reason are not in good standing or who have a conflict of interest or an apparent conflict of interest should not be forced to use user talk pages or other means to round up support for a nomination. It's far better to let them make the nomination and/or lend their name to an existing nomination on the nomination page itself. davidwr/(talk)/(contribs)/(e-mail) 21:57, 23 November 2009 (UTC)

Support 10.1

1. I support this idea, but I think this is bordering on instruction creep. Surely it can just be a gentleman's understanding that such co-noms will be indented like RfA comments from IPs. Gigs (talk) 15:20, 24 November 2009 (UTC)
2. My primary justification for supporting this is simply because it will help others determine if there is a need to allow this process to move forward. Ineligible nominations may be able to show how widely the issue affects users and whether or not it even warrants investigation time. For example, by listing an COI nomination, I may be prompted to investigate why the user is in a COI condition and make a decision to nominate from there. Otherwise, I may not have even looked. --Mpdelbuono (talk) 07:42, 28 November 2009 (UTC)

Oppose 10.1

1. I would rather not have the process balloon out like that before the nominations are even complete, before it has even been determined that the process will go forward. I can envision a situation where a bunch of invalid complaints against a good Administrator get sprayed across the nomination page, only to result in a decision that there is no basis to go forward with a community discussion. On the other hand, after the 10 nominations are set, the "good standing" requirement does not apply to !votes 11 and higher, so inputs such as these can come in at that step. How much or little weight they are given will then be determined by the community, and in close cases, by the closing Crat. --Tryptofish (talk) 15:40, 24 November 2009 (UTC)
2. If editors aren't eligible to start a, RFdA, they could start a discussion on a relevant policy talk page instead or indeed start an RFC/U. AndrewRT(Talk) 22:28, 7 December 2009 (UTC)
3. Oppose I worry about wordiness in a final draft, and I think the original wording is fine. Jusdafax 22:48, 13 December 2009 (UTC)
4. Oppose The original wording seems fine to me. -- PhantomSteve/talk|contribs\ 23:33, 14 December 2009 (UTC)
5. Oppose, largely per Tryptofish and AndrewRT. I have no qualms about the current wording. A Stop at Willoughby (talk) 03:30, 15 December 2009 (UTC)
6. Oppose Minimize complexity and potential for gaming. -- Avi (talk) 06:39, 15 December 2009 (UTC)

Neutral 10.1

• What's the point? Stifle (talk) 12:05, 30 November 2009 (UTC)

I agree - unless I'm missing something, this is only relevant if 13 9 is accepted, and that appears unlikely.--SPhilbrickT 13:57, 30 November 2009 (UTC)

11. Clarify that ARBCOM and others who sanction can restore rights to nominate

Current wording: Where nomination is made by editors in good standing, those editors:...

• may not be subject to Arbitration enforcement editing restrictions, Arbitration Committee restrictions, or Community restrictions, including, but not limited to, topic bans, project bans, and paroles.

Proposed wording: Current wording: Where nomination is made by editors in good standing, those editors:...

• may not be subject to Arbitration enforcement editing restrictions, Arbitration Committee restrictions, or Community restrictions, including, but not limited to, topic bans, project bans, and paroles, without the permission of the Arbitration Committee or another person or group empowered to lift those restrictions.

Comments 11.1

• Those who have the power to lift a sanction totally should have the ability to remove this restriction. davidwr/(talk)/(contribs)/(e-mail) 21:54, 23 November 2009 (UTC)

Support 11.1

1. I will venture out of the norm from all of the Neutral !votes and supply the first support on the same grounds. While ArbCom could already do this anyway, I think wording it like this might prompt users whom would otherwise be unaware of this possibility to consult ArbCom in preparation for a nomination. Otherwise users might think they are simply out of luck and cannot do anything. Strictly unnecessary wording, yes, but it is potentially helpful. --Mpdelbuono (talk) 07:47, 28 November 2009 (UTC)

   Since the current proposal requires 10 nominations and 50 desysop votes... I don't really see sanctions as a huge barrier for a sanctioned person to take action against a sysop that is clearly out of line. It just means you have to convince 10 people instead of 9. Gigs (talk) 20:24, 28 November 2009 (UTC)

Neutral 11.1

1. ArbCom could do this anyway, whether or not it's explicitly specified. Not necessarily opposed, but seems unnecessary to spell out. Seraphimblade ^{Talk to me} 06:40, 24 November 2009 (UTC)
2. Yes, more instruction creep. Gigs (talk) 15:22, 24 November 2009 (UTC)
3. I'm having trouble understanding why this would be needed, what problem it would solve. --Tryptofish (talk) 15:34, 24 November 2009 (UTC)
4. I agree with Tryptofish. seems unnecessary. Angryapathy (talk) 16:41, 24 November 2009 (UTC)
5. Per above.  Sandstein  21:55, 25 November 2009 (UTC)

12. Not to be used during arbitration

Current wording: None.

Proposed wording: This process may not be initiated while the administrator is the subject of an arbitration case concerning the use of his or her administrative tools, or while such a case is pending acceptance by the arbitration committee. If this process is already underway, it is strongly encouraged that anyone considering filing such an arbitration case refrain from doing so until this process is concluded.

Comments 12.1

• If the matter is already in arbitration, I think using this would be unnecessary and quite possibly counterproductive. It would also bring up the very awkward possibility of ArbCom not finding sufficient grounds to desysop but a community whipped up by the case finding that it should happen, which would really give the poor closing crat and evaluating steward a headache. Seraphimblade ^{Talk to me} 06:48, 24 November 2009 (UTC)

Support 12.1

1. Support. That's a good point. --Tryptofish (talk) 15:31, 24 November 2009 (UTC)

   Neutral per Sandstein, below. --Tryptofish (talk) 22:10, 7 December 2009 (UTC)

   How about, as an alternative: Nominations during an active arbitration process may be initiated only with the permission of the Arbitration Committee. --Tryptofish (talk) 19:55, 15 December 2009 (UTC)

2. Support, not as CREEP-y as Gigs has suggested. It's a clear sentence to let editors know that if Arbcom is involved, the issue might be solved there. Angryapathy (talk) 16:43, 24 November 2009 (UTC)
3. Agreed. We've enough swords of Damocles going around as is. Stifle (talk) 12:06, 30 November 2009 (UTC)
4. Agree, after much thought. I think this proposed Cda has to make it clear that two processes regarding one admin (or one group of them) should not be going on at the same time. The way I see it, a Cda would be a safety valve/final resort for times, hopefully few, when the community was deeply unsatisfied with lack of ArbCom action, or with their decision in an admin's case. Two processes at once is circus-like and conflictual. Jusdafax 22:24, 13 December 2009 (UTC)
5. Support, largely per Jusdafax. One process at a time is the way to go; no need for a circus-like spectacle. A Stop at Willoughby (talk) 03:33, 15 December 2009 (UTC)
6. Support For reasons shown below. -- Avi (talk) 06:44, 15 December 2009 (UTC)
   1. I prefer RfAr to be the de-adminship method. -- Avi (talk) 06:44, 15 December 2009 (UTC)
   2. Even should we have a RfDA process, unlike RfA, it is not voluntary on the part of the "candidate", and we should not be putting people in the position of having to address major concerns over multiple venues. At the least, it is courteous and respectful to allow the potential DA candidate to focus on the Arbitration case prior to having to defend him or herself at an RfDA. -- Avi (talk) 06:44, 15 December 2009 (UTC)
7. Support – if ArbCom gets there first, then they should have it. Also keep in mind that the Arbitration Committee is a body voted in by the community which should (I use should loosely) be respected. Finally, if opposed, we're going to get cases in which the community, who may disagree with a decision by ArbCom not to desysop a user, to end-run around that decision by initiating an RFDA. Perhaps that's the inevitable clash between the rest of the community and ArbCom, and perhaps we should discuss that more. –MuZemike 23:04, 22 December 2009 (UTC)

   Again, I misread "during arbitration". The one sentence struck. –MuZemike 23:05, 22 December 2009 (UTC)

8. Support. From my understanding CDA is not the sole route to removing an admin. ArbCom can too. They should be co-equal processes in this matter. It is going to create an awful scandal if ArbCom decides to remove an admin but a CDA doesn't. CDA is an additional option not a replacement for ArbCom. I will go further than this proposal: ArbCom should be explicitly stated as a perfectly legitimate alternative venue for admin removal. That is very important. Lambanog (talk) 05:50, 23 December 2009 (UTC)

Oppose 12.1

1. How many what-if scenarios should we put into the instructions? The further I get down the list, the more this stuff just seems like instruction creep. Gigs (talk) 15:24, 24 November 2009 (UTC)
2. Where RfAr and deadminship processes conflict, the ArbCom is best suited to decide whether the RfAr should be suspended to await developments or not. No specific instructions are required.  Sandstein  21:57, 25 November 2009 (UTC)
3. As above. Sandstein hit the nail on the head. --Mpdelbuono (talk) 07:52, 28 November 2009 (UTC)
4. Agree with Sandstein but suggest that's made explicit - otherwise it could be a formula for conflict. Some will inevitably see the community process as mroe legitimate that the ArbCom process. Perhaps something like "ArbCom may suspend an RfDA where the subject is subject to an Arb case or a caes is pending...." AndrewRT(Talk) 22:33, 7 December 2009 (UTC)
5. Agree with Sandstein. I also don't think the "awkward possibility" is that much of a problem. ArbCom and the community don't always see eye-to-eye. Even though Wikipedia:Requests for adminship/MZMcBride 2 took place during the voting stage of the arbitration, MZM still had > 50% support. If you took out the "bad timing/too soon" opposes to focus purely on the issues, it might have even passed. Mr.Z-man 23:32, 7 December 2009 (UTC)
6. Oppose Agree with Sandstein. -- PhantomSteve/talk|contribs\ 23:44, 14 December 2009 (UTC)
7. Per Sandstein; ArbCom has no special power to evaluate community trust, which is, I believe, the core issue this proposal aims to address. -Pete (talk) 23:10, 22 December 2009 (UTC)
8. Agree with all above. NW (Talk) 10:20, 23 December 2009 (UTC)
9. Oppose - Conflicts are probably best dealt with on a case-by-case basis, per Sandstein. Camaron · Christopher · talk 10:40, 23 December 2009 (UTC)
10. Oppose: These are two separate venues for deciding two separate questions; ArbCom determines whether specific policy violations were committed (and, if so, what to do about that); this process determines whether or not the community still gives consensus support to an adminship. ArbCom have made clear in past decisions that they are not "the community", e.g. by specifically asking "the community" to decide policy issues, and by leaving re-adminship (of those they've de-adminned) up to future RfAs. — Sizzle Flambé (☎/✍) 15:48, 23 December 2009 (UTC)
11. Oppose If the community that gave the admin his or her powers is sick and tired of the admin and doesn't have the stomach for all the wikidrama associated with ArbCom (which can go on for a long time), then the community should be able to revoke the powers if it wants to. If someone wants to jump up and down in the desysoping RfC to say that the admin is the subject of an ArbCom hearing and the community should sit back and wait until that is resolved, they have that right. And, perhaps, many will heed that advise. But if the community wants to go ahead and desysop anyway, by all means. Greg L (talk) 06:03, 26 December 2009 (UTC)
12. These are two separate issues, policy violations and community consensus, and they shouldn't be mutually exclusive. — Bility (talk) 20:38, 31 December 2009 (UTC)

Neutral 12.1

1. Both arguments seem good so I can't add. However, there are a number of situations in which a recall is a bad idea. If an admin has just laid down the law in a particular area against a group of like minded editors, they should not be able to gang up by nominating that admin. If canvassing or sockpuppetry is found in the process it may get derailed. We can't play too many what-if scenarios, and common sense should prevail. As this matures I think we may have to develop standards for speedy / snowball closes and process closes of bad faith nominations, incomplete or out-of-process ones, wikigaming and repeat nominations, etc., just as we do with other processes like RfA, AfD, and so on. - Wikidemon (talk) 10:11, 24 December 2009 (UTC)

13. Repeat attempts at CDA

Current wording: none.

Proposed wording: This process may not be restarted against an admin who fails to be de-sysoped by the community for a period of three months. However, Arbcom may recommend a new process within 3 months of a failed de-adminship.

Comments 13.1

There needs to be a limit so that the same problems aren't brought up all over again in a few weeks by vindicative editors. I also thought about making it 6 months, or required that at least 5 of the nominating editors for the second CDA must be different than the first CDA (but that may be too CREEP-y)

Support 13.1

1. Support as creator. Angryapathy (talk) 16:57, 24 November 2009 (UTC)
2. Yes, support. (I thought it already said this, but it doesn't!) Very unfair to an admin who was kept, to keep repeating the process out of spite. But, should there be an exception for genuinely changed circumstances? --Tryptofish (talk) 20:17, 24 November 2009 (UTC)

   Actually, there should be an exception if new circumstances arise and all 10 nominators are different than the previous 10. --Tryptofish (talk) 20:20, 24 November 2009 (UTC)

   I prefer, instead, the alternative approach in proposal 16. --Tryptofish (talk) 19:57, 15 December 2009 (UTC)

   Your exception defaults to 10 new nominators as the only objective criteria, "new circumstances" being subjective. I prefer this explicit immunity AND the tightening of the wording in item 16. Lambanog (talk) 05:24, 23 December 2009 (UTC)

3. Good idea. Stifle (talk) 12:07, 30 November 2009 (UTC)
4. Support with two caveats:
   • There is a hard minimum for a re-RDFA (like 3 months, which I agree with), and
   • There is additional evidence of administrative abuse or different circumstances that would warrant further investigation. It's just like it's bad taste to re-run for RFA if said candidate didn't address the issues in the previous RFA, and likewise it's bad taste to renominate pages for deletion when no additional cogent arguments for deletion come up. –MuZemike 23:09, 22 December 2009 (UTC)
5. Support. CDA is only one of two routes for admin recall. There is still the ArbCom route. I don't want to see CDA thought of as the only acceptable means for admin recall. If it fails at CDA there is ArbCom. Currently ArbCom is the only route and while not ideal it hasn't been a total disaster either. Supporting this idea is a more incremental step. Lambanog (talk) 05:24, 23 December 2009 (UTC)
6. Support. I’ve seen editors who are like pit bulls and can't let it go. Three months is a nice cooling off period. Greg L (talk) 06:05, 26 December 2009 (UTC)

Oppose 13.1

1. Again, this is absolutely what WP:CREEP was written about. AfD, RfA, and many other forums and processes have no written threshold for bringing up the same matter again, yet we manage to deal with it when it comes up just fine. I see no reason why this process should be so massively heavy weight when we get by just fine with lightweight processes everywhere else. If anything, this could be loosely codified into some kind of non-binding speedy keep guideline. Gigs (talk) 17:22, 24 November 2009 (UTC)

   I disagree with your intrpretation of CREEP. RfA has not codified re-RfA's because that is the choice of the admin. This, on the other hand, is a community decison against a single person. We should desire to avoid abuse of the system. As this is a very serious subject in determining whether to strip an admin of their tools, which has never been codified before, we should strive to keep the matter as specific and on-task as possible. We are creating a new policy, not trying to add another rule to a policy, so I see no harm in attempting to see all the angles. Angryapathy (talk) 19:15, 24 November 2009 (UTC)

   Trying to predict all the ways that someone might abuse something is exactly what WP:CREEP and WP:BEANS are about. Being an admin is no big deal. Creating some lumbering process shrine to how big of a deal it is isn't the way to go. That's why we are here in the end, to make adminship less of a big deal. Best not to lose sight of that goal. Gigs (talk) 20:38, 24 November 2009 (UTC)

   Just because something is being discussed here does not mean it will be added to the proposal. The proposal was actually written primarily by one editor, so this discussion is gauging the community critiques. Stating that new suggestions to a brand new proposal is CREEP doesn't help us improve it. Angryapathy (talk) 14:33, 25 November 2009 (UTC)

   The newness of the suggestion is not relevant to my opposition. The assumption that this scenario would cause so many problems that we need to explicitly write about it, even though the lack of written instruction about similar matters hasn't caused problems at other forums is the basis of calling it creep. We can always amend this process later based on actual problems that arise once we start using it. Gigs (talk) 20:12, 28 November 2009 (UTC)

   I do not think instruction creep is a problem. There should be an explicit rule in the proposal to dissuade frivolous complaints and to remove any gray area in what one can already anticipate is a potentially contentious topic. CDA is not the same as RfA in that the ones bringing about the action do not necessarily have much prestige to lose. Someone can in good faith repeatedly bring up a CDA going by the current rules. If it's a close decision and consensus is not clear, even if it is finally sorted out, people may have been unnecessarily offended in the meantime. Making it explicit that an admin that has gone through a CDA has some measure of immunity for a certain duration reduces that since it is now "the rules" and not "those stupid idiots" that prevent a repeat CDA. Even one repeat CDA can be disheartening to an admin who has already gone through the process once. The ArbCom route still exists for egregious cases. Lambanog (talk) 05:10, 23 December 2009 (UTC)

2. Instruction creep, though bureaucrats should speedily close clearly meritless repeat requests.  Sandstein  21:58, 25 November 2009 (UTC)
3. Unnecessary change. Repeat attempts are likely to just provoke community response against those whom are making the proposals. Eventually nominations won't be sustained. There isn't a problem with this now, and I feel it will stay this way. --Mpdelbuono (talk) 07:55, 28 November 2009 (UTC)
4. Trust the community! And of course apply snowball if it failed last time and nothing significant has changed. AndrewRT(Talk) 22:37, 7 December 2009 (UTC)
5. Oppose as unneeded, per above. Jusdafax 22:29, 13 December 2009 (UTC)
6. Oppose. Everything I was going to say has been said above (plus a couple of things I wouldn't have thought of!) -- PhantomSteve/talk|contribs\ 00:02, 15 December 2009 (UTC)
7. Oppose, largely per Sandstein and Mpdelbuono. I agree that this is an example of WP:CREEP; there's no problem currently with immediately re-submitting XfDs or RfAs. WP:SNOW can be applied, if needed. A Stop at Willoughby (talk) 03:36, 15 December 2009 (UTC)
8. Oppose With the caveat that repeated submissions for RfDA may require actions to protect the project from the frivolous actions of the repeat proposers. -- Avi (talk) 06:46, 15 December 2009 (UTC)
9. Oppose pre-emptively. Other processes have managed without such restrictions on re-nominations, however if repetitive re-nominations become a problem, with WP:SNOW and bureaucrat discretion unable deal with them, then proposals to introduce this kind of wording can be considered. Camaron · Christopher · talk 10:44, 23 December 2009 (UTC)
10. Oppose as unnecessary. I'd rather implement something similar to a "deletion review" in which an AfD decision to delete an article can be reversed upon review. In this case, the decision to keep or delete an adminship could be reviewed rather than go through the renomination process again. ~Amatulić (talk) 05:10, 25 December 2009 (UTC)
11. The process already handles this, as repeated nominations will become consistently weaker and more quickly defeated. Constant nominators can be dealt with through other venues if the nominations appear to be attacks or time wasters. — Bility (talk) 20:45, 31 December 2009 (UTC)

Neutral 13.1

1. I support the idea in principle, but I would prefer to leave it to bureaucrat discretion to speedy close inappropriate repeat requests. If there is consensus to specify a particular timeframe rather than letting bureaucrats judge the merits of CDA requests, then I would prefer that we avoid half-measures and set a minimum of 6 months instead of 3 months. –BLACK FALCON ^(TALK) 05:05, 13 December 2009 (UTC)
2. As discussed above with respect to 12.1, I think we should leave this open to evolve over time, and let the community and the beurocrats managing the process handle these process problems as a judgment call as they come up. We can't predict in advance all the problems, or which method will be best to deal with them. - Wikidemon (talk) 10:13, 24 December 2009 (UTC)

14. Allow Bureaucrats to directly desysop

Proposals to allow 'crats to desysop users through Special:UserRights have been rejected in the past due to lack of a community desysoping process. If we go forward with this I think that including a request from the community to the devs to allow this would make a lot more sense. If the 'crat is making the decision there isn't really any reason not to allow them to implement it. ⇌ Jake Wartenberg 20:52, 27 November 2009 (UTC)

14.1 Support

1. ⇌ Jake Wartenberg 20:50, 27 November 2009 (UTC)

14.1 Oppose

1. Oppose. I think that it continues to be reasonable for ArbCom to have this role, and I think that the clear message from the previous poll is for the community to have this ability too, albeit with significant safeguards. It's hard to envision a situation where Bureaucrats might do this short of emergency desysoppings, and ArbCom already has that covered. But putting the power to do this into the hands of Crats for situations that should require community discussion really represents a paradigm shift in what Crats have traditionally done, and there is no reason to do that when community-wide discussion is so much better. --Tryptofish (talk) 21:08, 27 November 2009 (UTC)
2. Oppose per this can be best handled as its own proposal, independent of this one. Also, barring a specific proposal that I could live with, I'm probably going to oppose anyways. davidwr/(talk)/(contribs)/(e-mail) 21:18, 28 November 2009 (UTC)

14.1 Neutral

1. I would support this, but can we have the discussion some other time? I don't want the issues of Wikipedia:Removing administrator rights/Proposal 2 blocking what looks like a solid proposal. NW (Talk) 01:51, 28 November 2009 (UTC)
2. As above, I feel this is (as we would call in the Software Engineering world) an implementation detail, and completely irrelevant to this proposal. The fact that a Crat is making the decision is important, but how he/she implements that decision is not. --Mpdelbuono (talk) 08:00, 28 November 2009 (UTC)
3. I agree with the sentiments here. This can be a separate discussion for a later time. Gigs (talk) 20:14, 28 November 2009 (UTC)
4. Sorry I agree - too much to talk about here, without complicating it unnecessarily! AndrewRT(Talk) 22:39, 7 December 2009 (UTC)

15. Spell out expectations about canvassing

15.1 Add the following sentence: "Parties to the CDA process may legitimately contact other editors to provide input, but must at all times do so in strict accordance with WP:CANVASS."

15.1 Support

1. Support as proposer. This issue keeps coming up in discussion here (see, for example, #A pause to look at the numbers), so maybe the current draft needs to say it explicitly. In particular, it has been noted that this process should not exactly mirror RfA. But rather than try to reinvent the wheel (instruction creep), I think just following WP:CANVASS covers it. (RfA is actually stricter than CANVASS.) --Tryptofish (talk) 20:07, 8 December 2009 (UTC)
2. Yes, I think this is both reasonable and necessary - helpful to point people in the right direction before they go off and inadvertantly fall down a hole. I would suggest making the wording more explicit to refer to what you should and shouldn't do - maybe along the lines of the introduction to WP:CANVASS. AndrewRT(Talk) 23:13, 11 December 2009 (UTC)
3. Support - This makes it clear how the Cda can and can't be handled. Good proposal. Jusdafax 22:34, 13 December 2009 (UTC)
4. Support I prefer the link to WP:CANVASS to avoid reinventing the wheel, per Tryptofish. A Stop at Willoughby (talk) 03:38, 15 December 2009 (UTC)
5. Support - A reminder of WP:CANVASS seems appropriate, though I am sympathetic to the idea of giving more leeway to the admin facing nomination for their own defence. Camaron · Christopher · talk 10:53, 23 December 2009 (UTC)
6. Support. Common sense. Greg L (talk) 06:06, 26 December 2009 (UTC)

15.1 Oppose

1. Too prone to misuse per Gigs (see "Neutral" section) and unnecessary if the editors requesting de-sysopping take a few appropriate steps—such as starting an informal community discussion at a high-traffic location such as WP:AN—before initiating the CDA. –BLACK FALCON ^(TALK) 05:10, 13 December 2009 (UTC)
2. Oppose Unlike RfA which is a voluntary process, the RfDA is shaping up to be an involuntary process on the part of the "candidate", who should be allowed to craft the best possible defense, which may need to include directed messages to people who know said candidate well on wiki, or are in possession of exculpatory information. -- Avi (talk) 06:49, 15 December 2009 (UTC)

   Question, in response to Avi's comment: What, then, should the document say? I actually agree completely with Avi's reasons, but thought the proposed language would help with that. If we say nothing, either CANVASS applies anyway, or the very strict discouragement of contacting editors at RfA would be assumed by some to carry over. I think that CANVASS does allow contacting editors who can exculpate etc., but it wards off doing such things behind the scenes, out of the sight of the community. I do think we need to get this worded right. --Tryptofish (talk) 19:37, 15 December 2009 (UTC)

   Perhaps we should say CANVASS explicitly does not apply. -- Avi (talk) 16:52, 17 December 2009 (UTC)

3. Unnecessary. CANVASS applies whether or not we say here that it does.  Sandstein  23:52, 15 December 2009 (UTC)
   • I disagree, Sandstein. I think that someone undergoing the RfDA should, nay must, be allowed to contact whomsoever may have exculpatory information or who disagrees with the request. While the standard RfX's are all voluntary on the part of the candidate, this is not, and so we should not hinder the involuntary "candidate"'s ability to defend his or herself. -- Avi (talk) 01:57, 17 December 2009 (UTC)

   Hmm, I'm still trying to get a handle on this. I think there are two facets, one of which is the very legitimate need of the administrator to obtain defense material. I think I'm persuaded by Avi that we need to let that person get in touch with whomever s/he feels is necessary. But, at the same time, I think we still need to apply CANVASS with respect to the need to do so on-site (as opposed to by e-mail, IRC, or other non-transparent methods), and probably to do so with some note at the CDA site that these users have been contacted, again for transparency. But the other facet is potential canvassing by the nominators and by others who favor desysopping. I would think we would want the same canvassing restrictions as above to apply there, as well as prohibiting mass-spamming of users. If we simply say CANVASS does not apply at all, we lose all of that. --Tryptofish (talk) 17:43, 17 December 2009 (UTC)

4. Oppose as unnecessary — CANVASS already applies. The admin's contributions should speak for themselves and voters have the obligation to do appropriate research. If no one shows up at the nomination voting, the community's lack of notice for the admin's actions would imply there's no sufficient reason to desysop. — Bility (talk) 20:50, 31 December 2009 (UTC)

15.1 Neutral

1. My concern is that it is impossible to do this. You need to find 9 other editors that would be willing to put their name and reputation on the line in order to take someone's sysop bit away. I submit that it's not possible to do that without canvassing a biased audience, or as an alternative, canvassing a very large audience, both of which run afoul of our guidelines. Gigs (talk) 03:08, 11 December 2009 (UTC)

   My reading of CANVASS is that it allows contacting a biased audience, so long as it is moderate in number and done in the open. I would think the contacting editor (and this also includes the admin seeking defenders) would be well-advised to state, right there on the CDA page, the contacts that have been made, and then the community could evaluate that, along with everything else. Really, CANVASS still applies by default even if we do not add this sentence, but adding it draws attention to the need to not canvas surreptitiously, or off-Wiki. --Tryptofish (talk) 16:50, 11 December 2009 (UTC)

   Regarding selective canvassing of a biased audience of people that you know agree with you... I don't think that is acceptable today, even if the guideline doesn't make it clear. Someone who pinged only those who agree with them about an RfA or AfD would easily draw censure. Gigs (talk) 19:12, 11 December 2009 (UTC)

2. I suppose it really doesn't matter which way. In any community venue WP:CANVASS is supposed to be followed diligently. On the other hand, most community venues (such as XFD, RFA, etc.) already have this provision in somewhere. –MuZemike 23:11, 22 December 2009 (UTC)

15A. Violation of rules result in desysop if admin is stubborn and refuses to admit breaking the rule and does it multiple times

If an administrator violates a rule, they will be desysoped ONLY if they don't have a reasonable excuse that has widespread support and violates a rule in a way that doesn't actually concretely improves Wikipedia (if they do, they can invoke the IAR (ignore all rules). Such clear rule may eliminate the contentious desysop process. There will be some leniency, such as breaking a rule AND refusal to correct the mistake when notified is permitted a maximum of once every calender year.

15.1 Comments

If this proposal is defeated, it will look like Wikipedia people support administrators breaking rules for no good reason. This will support the other people's premise that admins are a cabal and are corrupt and collude, which I don't agree. Even a neutral vote winning is better. I have not voted because I would need to study the issue more. Suomi Finland 2009 (talk) 21:42, 29 November 2009 (UTC)

15.1 Oppose

1. Why don't we just skip desysopping and institute a permanent ban of anyone who ever makes an error, admin or not? Really, we're expecting perfection? We allow mistakes, so long as people are willing to learn from them and improve. Behavior only becomes problematic when someone won't accept feedback regarding it. Seraphimblade ^{Talk to me} 20:29, 28 November 2009 (UTC)
2. Oppose per Wikipedia:WikiProject Administrator/Five Problems with a Single Solution. --Tryptofish (talk) 20:46, 28 November 2009 (UTC)
3. Oppose per nobody's perfect all the time. However, blatant and repeat rule-violations can use existing procedures to result in a bit loss, or, preferably, a change in behavior. davidwr/(talk)/(contribs)/(e-mail) 21:22, 28 November 2009 (UTC)
4. The process should be contentious, really. The community needs to decide, not the rules. This proposal would turn WP into moot court. Gigs (talk) 13:10, 30 November 2009 (UTC)
5. This assumes far too much bad faith and puts unrealistic demands on volunteers. Rules violations are not always clear either. Mr.Z-man 18:44, 30 November 2009 (UTC)

16. Improve language

Improve the language about when to use or not to use the process

16.1 In light of discussion that keeps coming up here about concerns that the process can be "gamed", I suggest expanding some passages in the current draft proposal, by adding some text that was well-received in this proposal written by Beeblebrox. The existing text is in regular font, and the suggested additions are in green.

Under "What this process is not":

Dispute resolution or other discussions: Dispute resolution should proceed through the normal channels. Disputes with an administrator should be discussed first with that administrator, and then via the normal channels of third opinion, mediation, request for comment, and arbitration. Mild or one-time only incivility should instead be reported to Wikiquette Alerts. If the administrator is listed at Administrators open to recall and you believe the conditions listed there have been met, they should be reported there.

Under "Before nomination":

Consider that nominations that do not address the core issue of whether the community as a whole does or does not trust the account to have the sysop right will likely fail, and possibly backfire spectacularly. Determining that is the purpose of this process. If this is not the issue in your case then you are in the wrong place. In all but the most extreme cases, there should be a demonstrable pattern of repeated unacceptable behaviors, not just a single incident. Processes like this one usually result in intense scrutiny of all involved parties. The bright light you are about to shine on a particular administrator will reflect on you as well.

16.1 Support

1. Support as proposer. First, let me head off the issue of instruction creep by pointing out that this is only a slight expansion of sections that are already in the draft proposal, about when or when not to use this process. I think we should do anything we can to help give confidence to the community that the process will not be used frivolously or harmfully, and the language I suggest adding here (written by Beeblebrox, not by me) should be helpful in getting the eventual proposal accepted. --Tryptofish (talk) 00:44, 11 December 2009 (UTC)
2. You know, I don't call everything creep. :) I support these changes. Gigs (talk) 03:16, 11 December 2009 (UTC)

   :-) --Tryptofish (talk) 16:43, 11 December 2009 (UTC)

3. The additional clarification more than justifies the added length. –BLACK FALCON ^(TALK) 05:20, 13 December 2009 (UTC)
4. Support - With the amendment below, there is no wiggle room to game this Cda process, which is why we are parsing the wording carefully here in order to craft this document into a polished, finalized proposal to move forward with. Good job. Jusdafax 20:23, 13 December 2009 (UTC)
5. Support clarifies that this is what happens after all 'normal' dispute resolution processes have been exhausted. -- PhantomSteve/talk|contribs\ 00:07, 15 December 2009 (UTC)
6. Support This clarification is a good idea. A Stop at Willoughby (talk) 03:40, 15 December 2009 (UTC)
7. Support -- Avi (talk) 06:51, 15 December 2009 (UTC)
8. Sensible.  Sandstein  23:53, 15 December 2009 (UTC)
9. –MuZemike 23:12, 22 December 2009 (UTC)
10. Support - A good clarification. Camaron · Christopher · talk 10:55, 23 December 2009 (UTC)
11. Bility (talk) 20:53, 31 December 2009 (UTC)

16.1 Neutral

1. Neutral No text should be locked in stone. Whomever were the most hard-working, shepherding authors in this process should be trusted to follow the spirit of the community’s desires to improve what is there. Greg L (talk) 06:10, 26 December 2009 (UTC)

16.1.5 Prior discussion

Tighten wording regarding prior discussion with administrator

I regard the following as a friendly amendment to the above:

"Disputes with an administrator should must be discussed first with that administrator, and then via the normal channels of such as third opinion, mediation, request for comment, and arbitration." --Tryptofish (talk) 18:07, 13 December 2009 (UTC)

16.1.5 Support

1. I support this as kind of a no-brainer. Changing "should" to "must" is clearly what has always been intended in this proposal; please see #Before a CDA nomination, below. The "such as" is simply to remove the implication that every case must go through each of those processes in order. --Tryptofish (talk) 18:07, 13 December 2009 (UTC)
2. Support - This wording should satisfy a consensus-sized majority. It is the final detail needed in this wording, I believe, as it makes no bones about the stages needed to ensure a Cda is widely and clearly understood to be final resort. Thanks. Jusdafax 20:14, 13 December 2009 (UTC)

   Thank you! --Tryptofish (talk) 20:46, 13 December 2009 (UTC)

3. Support Clearly meets the spirit of the intention of the proposal -- PhantomSteve/talk|contribs\ 00:13, 15 December 2009 (UTC)
4. Support "must" >> "should" -- Avi (talk) 06:51, 15 December 2009 (UTC)
5.  Sandstein  23:53, 15 December 2009 (UTC)
6. "Shall" is also good to use. –MuZemike 23:13, 22 December 2009 (UTC)
7. Support - Makes sense so a nomination does not come out of no where. Camaron · Christopher · talk 10:57, 23 December 2009 (UTC)

16.1.5 Neutral

1. Neutral Not particularly necessary. A Stop at Willoughby (talk) 03:40, 15 December 2009 (UTC)
2. Neutral No text should be locked in stone. Whomever were the most hard-working, shepherding authors in this process should be trusted to follow the spirit of the community’s desires to improve what is there. Greg L (talk) 06:08, 26 December 2009 (UTC)

16.1.6 Multiple resubmissions

Tighten wording regarding multiple resubmissions

I would like to see wording at the end of the notice along the lines of:

Repeated resubmissions of failed RfDA's may result in measures taken to protect the project from repeated frivolous submissions that may include, but are not limited to, suspension of editing privileges.

Wording, of course, is open to suggestion. -- Avi (talk) 06:55, 15 December 2009 (UTC)

16.1.6 Support

1. Agree - Sadly, I find myself in agreement that this is needed. In a good year there should not be more than 2-3 Cda's, as I view this, and a really bad year perhaps double that. If enacted, the Community de-adminship process, as I say elsewhere, must be a last resort that will only come (in most cases) after ArbCom has taken a look at the admin(s), and seldom actually used. And for Cda to be enacted, thoughtful minds must be convinced that the process makes things better and not worse. This addition makes it absolutely clear that there will be zero tolerance for attempts to abuse a Cda. Jusdafax 07:32, 15 December 2009 (UTC)
2. Agree with wording tweaks: Frivolous resubmissions of failed CDAs may result in measures taken to protect the project that may include, but are not limited to, blocks of editing privileges. --Tryptofish (talk) 19:42, 15 December 2009 (UTC)

   Actually, I also think Sandstein's wording below is better. --Tryptofish (talk) 21:35, 24 December 2009 (UTC)

3. Support, but I prefer Sandstein's wording in the neutral section below. A Stop at Willoughby (talk) 05:17, 23 December 2009 (UTC)
4. Support - However I also prefer Sandstein's short but sweet wording. Camaron · Christopher · talk 10:59, 23 December 2009 (UTC)
5. Support Sandstein's version. — Bility (talk) 20:55, 31 December 2009 (UTC)

16.1.6 Neutral

1. Where is that, exactly? Sounds like instruction creep and can be omitted entirely. Anyway, a briefer version, if even necessary: "Repeated resubmission of failed nominations may be treated as disruption."  Sandstein  23:56, 15 December 2009 (UTC)

Publicity

This discussion has been publicized in the following locations:

1. Wikipedia talk:WikiProject Administrator#Recall - Something to do whilst we are waiting for a better idea
2. Wikipedia talk:WikiProject Administrator/Admin Recall
3. Wikipedia:Administrators' noticeboard — Oli ^OR Pyfan! 03:36, 23 November 2009 (UTC)
4. Wikipedia:Bureaucrats' noticeboard (by Jusdafax) Ben MacDui 18:27, 23 November 2009 UTC)
5. Note left at Wikipedia:Wikipedia Signpost/Newsroom/Suggestions - appears in week of 23 November.
6. WP:CENT
7. WT:RfA (by Jusdafax). --Tryptofish (talk) 22:09, 27 November 2009 (UTC)
8. Village Pump Policy, Proposals, and Miscellaneous (by me). --Tryptofish (talk) 22:09, 27 November 2009 (UTC)
9. Wikipedia talk:Arbitration Committee. --Tryptofish (talk) 22:15, 27 November 2009 (UTC)
10. Wikipedia talk:Requests for adminship Put up a reminder. Jusdafax 21:52, 14 December 2009 (UTC)
11. Wikipedia:Administrators' noticeboard Reminder posted. Jusdafax 22:30, 14 December 2009 (UTC)
12. Wikipedia:Bureaucrats' noticeboard Reminder posted, with additional note that the proposed draft increases Bureaucrat duties and powers. Jusdafax 23:02, 14 December 2009 (UTC)
13. Given the 'Motion to Close', I have individually notified all editors who have participated in this page, as well as those on the Project Page at Wikipedia:WikiProject Administrator, as well as update regarding same at Wikipedia:Bureaucrats' noticeboard. Jusdafax 07:47, 23 December 2009 (UTC)

SUGGESTIONS NOT YET IMPLEMENTED

all admin-related pages

IRCs, Wikipedia Review

Question: – although this is advertised as a discussion about a draft RfC, rather than an RfC itself, it strikes me that adding the {rfctag|policy} template here is appropriate. Comments? Ben MacDui 11:02, 22 November 2009 UTC)

1. • Question about the question - Forgive my ignorance; what is that template and what is it for? Jusdafax 18:56, 23 November 2009 (UTC)

Apologies - it is for advertising RfCs and its use is referred to at Wikipedia:Requests for comment. Ben MacDui 19:46, 23 November 2009 (UTC)

Related question: Where on this talk page would you put the RfC tag? --Tryptofish (talk) 20:48, 23 November 2009 (UTC)

Top of the page. Ben MacDui 15:51, 29 November 2009 (UTC)

Usually, RfCs direct to a specific question on a talk page (and typically where there is a dispute that needs more eyes). Would doing it in an unusual way end up being confusing? --Tryptofish (talk) 17:10, 29 November 2009 (UTC)

Comment: Please, no to IRCs and Wikipedia Review. The last thing we need is off-Wiki or behind-the-scene discussions. --Tryptofish (talk) 20:48, 23 November 2009 (UTC)

Note: Remove WP:CENT entry when complete here.

Arbcom sanctions

I made a WP:BOLD edit to WP:Guide to Community de-adminship. If you disagree, please revert and discuss.

The change: "Where nomination is made by editors in good standing, those editors: ... may not be subject to Arbitration enforcement editing restrictions, Arbitration Committee restrictions, or Community restrictions, including, but not limited to, topic bans, project bans, and paroles without the permission of the arbitration committee."

Rationales: 1) If ARBCOM imposes a sanction that, by this policy, includes not being able to nominate, they should be able to lessen that sanction, and 2) prior to the adoption of this procedure, ARBCOM may not have envisioned that all editors under its sanction would also be prohibited from nominating. This change gives ARBCOM flexibility in this matter.

davidwr/(talk)/(contribs)/(e-mail) 00:33, 23 November 2009 (UTC)

I don't have any difficulty with the revised wording, although if it is necessary to get Arb permission to find ten signatures I suspect the process stands little chance of success. Your boldness is admirable, but it is going to get complex if there are many more such changes. Ben MacDui 20:41, 23 November 2009 (UTC)

Thanks. The idea is there may be some editors who were put on some type of permanent sanction ages ago where the sanction has no bearing on their ability to make RFA-related decisions. The most common examples where an editor would be in good enough standing to participate in DRFA would be a permanent order for editors Joe and John to steer clear of each other, or a permanent order for editor Joe to steer clear of article X or topic Y, as well as short-term sanctions that are not related to an editor's judgment regarding administrators or their actions. It goes without saying that editors who nominate someone they've had a "run in" with in the past say so up front. davidwr/(talk)/(contribs)/(e-mail) 21:02, 23 November 2009 (UTC)

I agree with Ben's point that editing the proposal while comments are in process complicates things here. I'm not sure what I think on the merits. As a compromise between leaving it, and boldly reverting, I struck through it, and will put an explanatory comment above in this talk. --Tryptofish (talk) 21:01, 23 November 2009 (UTC)

I have undone the change and will open a discussion. davidwr/(talk)/(contribs)/(e-mail) 21:47, 23 November 2009 (UTC)

Meta Complaints

This RFC is jumping the gun

Wikipedia:WikiProject Administrator/Admin Recall had extensive discussion on a number of options. Suddenly, we seem to be discussing just one, and one which didn't have all that much more support than the others.

Yes, CDA was the only one gaining a majority - it got 26 support and 13 oppose. But I don't see that a net support of 13 editors justifies throwing out all discussion of other options (WP:VOTE?) and trying to shoehorn every concern raised into a massively WP:TLDR attempt to tweak CDA in a way that will make everyone happy (which will inevitably be unsuccessful). There was discussion on the Admin Recall talk page of collaboratively drafting revised versions of each of the main types of proposal (each group of people who like that type of proposal being involved in drafting theirs). The option types can be enumerated in different ways (eg Wikipedia_talk:WikiProject_Administrator/Admin_Recall#The_way_forward.3F, though I'd try and limit it to 3 or 4) this enumeration is what should be discussed now, and this CDA RFC should be developing the CDA option, which should clearly be one of the 3 or 4 put in an Wikipedia:WikiProject Administrator/Admin Recall 2.

I predict trying to move forward with CDA as the only option will end in trouble, with the result not getting sufficient credibility. (There is also the procedural issue of oh my god who is going to read all that on this massive page.) Rd232 ^talk 15:55, 26 November 2009 (UTC)

It's useful that you raised these concerns. In my opinion, there was discussion of the results of the recall proposals poll, and there was a sense that we needed to move forward, not just sideways, and that all of the other proposals had met sufficient opposition that it would prove difficult for any of them to satisfy the community without major overhauls, whereas this proposal was within reach of gaining clear consensus. The talk on this page began by identifying as many as possible of the criticisms of this proposal that had come forward during the poll, and trying to fix them. Wiki-work being what it is, further modifications, not raised in the last poll, have been suggested by some editors as we have gone along. As an alternative to what you suggested, I'd favor making a greater effort to incorporate what was good in the other proposals into this one, which I think is something that has so far been under-explored. I think the best thing we can do is make a single proposal that is as strong as it can be. For example, I raised above the possibility of incorporating some parts of Beeblebrox's proposal into this one, and I will follow through on a more concrete proposal about that shortly. I'd encourage other editors to suggest good things from other proposals that could strengthen this one too. But I think we need to keep moving forward. --Tryptofish (talk) 16:49, 26 November 2009 (UTC)

While there is something in Rd232's comment, I thank Tryptofish for putting it perspective, and am in complete agreement with Tf. I think the process currently embarked on is for the best, and agree that the Uncle G/Option 4 proposal was clearly the standout in approaching consensus. The very strong vote against doing nothing (Option 0) shows that something needs to be done on this issue, and barring an outcry against the position taken by Tryptofish, I think we should continue here, where obvious progress is being made, in my view. The Jan. 4 deadline gives us time enough to hammer out a consenus; it is my hope to take a solid proposal to the final stage well before spring. Jusdafax 18:57, 27 November 2009 (UTC)

Thanks. Also, it just occurred to me that there is nothing set in stone about the Jan. 4 date, so we can always take some more time to hammer out any issues that arise (just so long as the process doesn't stall). --Tryptofish (talk) 19:18, 27 November 2009 (UTC)

I sympathize with rd232's concerns here, but there does seem to be a rough consensus for some sort of community desysopping, so we might as well use the CDA proposal as a base to work from. I agree that we can't make everyone happy, but I do think that we can get something working. Gigs (talk) 20:17, 28 November 2009 (UTC)

Regarding the massive page, I think some of these sub-proposals that have had unanimous opposition or support could be integrated into the main proposal and archived pretty soon here. Gigs (talk) 20:18, 28 November 2009 (UTC)

Agree. Looks like consensus being reached at some points, allowing us to focus on areas where discussion continues to be needed. I'd suggest the first week in December as a possible time frame. Jusdafax 21:32, 28 November 2009 (UTC)

Agreed and comment added above under "Purpose of this discussion" above. Ben MacDui 13:33, 29 November 2009 (UTC)

A pause to look at the numbers

Erm, there seems to be a very short peg on which this particular proposal's hat is hung. Looking at the numbers, we're told that this proposal garnered a solid 65% support in the earlier round of voting. (Note that this is the only proposal that managed the support of a majority.) A closer look at that number, though, suggests that the enthusiasm for this proposal is somewhat overstated.

• Supporting this option in the original poll were 26 editors.
• Explicitly opposing this option in the original poll were 13 editors.
• Implicitly opposing were another 7 editors, for a rather sickly support percentage of just 56.5%.
• Total participant count on which this new proposal is based: 46.

By 'implicit' support, I mean the seven editors who voted in support of Option 0 – the status quo – but who didn't then run down the entire list of polls to add individual oppose votes to each of the remaining 14 options. (Yes, I checked for duplicate names in the two lists; no, I didn't count them twice in the tally above.)

Considering that most of the editors who bother to follow Village Pump invitations to talk about desysopping are predisposed to favour it (most of the rest of us have been around the merry-go-round too many times to bother showing up any more), a 56.5% supporting fraction is a thin edge indeed. While I doubt that this post will persuade any of this proposal's supporters to step back and think about where they're headed, hope springs eternal. There's been no clear identification of the problems that this proposal is supposed to solve, beyond the painfully vague variations on because we need a faster process. In a bit of a self-plug, I urge a look at

• Wikipedia:De-adminship proposal checklist#Utility. Give us some examples of the problems you'd like to fix.
• The Policy Reform treadmill. A never-quite-completed essay on why these proposals tend to get rejected.

Until you've got clear examples to talk about, I'll be on my way. TenOfAllTrades(talk) 21:53, 3 December 2009 (UTC)

I went back to look at the previous poll, and you !voted to support the status quo, and you did not explicitly !vote on this proposal, so it's entirely reasonable to expect that implicitly you would have reservations about it. I think most of us do understand that editors who feel as you do may oppose whatever proposal comes out of here. On the other hand, there were quite a few editors who opposed the status quo, opposed this proposal, and supported other proposals; it may be hoped that the improvements we are attempting to make here may make this proposal more attractive to them. And in a bit of a plug for an essay that someone other than me wrote, I'll urge a look at Wikipedia:WikiProject Administrator/Five Problems with a Single Solution. :-) --Tryptofish (talk) 22:17, 3 December 2009 (UTC)

Re clear examples, there was an explicit statement earlier in the process that we would avoid "naming names" as this could only result in labyrinthine side-tracks and name-calling. If you are unaware of any recent, high-profile cases that may have caused increased interest in this subject, drop me a note. Ben MacDui 09:53, 4 December 2009 (UTC)

It's important to note that what we are doing here is significantly rewriting CDA, such that the support levels for the original proposal is not very relevant. If you would like to shape the process, now is the time to provide your input. Gigs (talk) 13:01, 4 December 2009 (UTC)

• We need this new process!
• Why?
• We can't tell you!

Oh. To Gigs - if this is significantly different from the original proposal, then using the original poll numbers to try to justify this proposal was probably a poor decision on someone's part. And no — as I said, unless there's a clear, evidence-based explanation of why a new process will improve the project, I'm not going to help to shape a useless process. Without a clear understanding of the problem this proposal aims to solve, I can't help to build a solution. TenOfAllTrades(talk) 15:02, 4 December 2009 (UTC)

Ummm, not opposing something is not implicit support. ^Chillum 15:12, 4 December 2009 (UTC)

The original poll numbers were just used as a way to decide to use this as a start point. The rationale and problem description are at Wikipedia:WikiProject Administrator/Five Problems with a Single Solution. Gigs (talk) 15:34, 4 December 2009 (UTC) You should also consider people like me... I did not explicitly note my support for CDA, but I did support some kind of process. I don't really care if CDA is the starting point. Gigs (talk) 15:43, 4 December 2009 (UTC)

Having read the linked 'Simple Solution', I'm disappointed. It doesn't really offer answers to the questions I've posed here, inasmuch as there are only broad claims of the existance of a problem, but no concrete examples. Further, the proposed solution is, at turns, self-contradictory, redundant with ArbCom, and prone to abuse. I offered a much more extensive and detailed critique on that talk page. What it boils down to is this — trying to create a desysopping process which roughly parallels RfA's model and timelines is a bad job because the situations are fundamentally non-parallel.

• An RfA is voluntary, and starts at a time of an editor's choosing. An RfDA is imposed on an editor by others, and will probably come at a highly stressful time right after the admin may have made a significant error.
• An RfA starts with a presumption that the editor is competent and ought to be promoted absent evidence to the contrary. RfDA demands at least a prima facie case for misconduct, misuse of tools, malice, or incompetence.
• An RfA is predominantly about an individual editor's contributions and efforts. An RfDA will almost always be the result of extensive interpersonal conflicts, and sit within the context of broader disputes. Does it make sense to weigh the candidate's actions in isolation in this case?
• An RfA is a frequent, everyday event on Wikipedia. Standards are well estabished, candidates are generally examined in similar ways. An RfDA is (or ought to be) an exceptional occurrence. Most of the participants will not have extensive experience with the process.

Given the very different nature of granting adminship versus withdrawing it, it strikes me as a very poorly-examined assumption that the two processes ought to be very similar. The more thought that I give this, the more strongly I feel that this proposal (in any variant) is counterproductive. TenOfAllTrades(talk) 21:26, 5 December 2009 (UTC)

Since you are arguing for the status quo, the only numbers we need to look at is the 77% that supported some kind of explicit de-adminship process, and opposed the status quo. Unless by some miracle consensus has changed in the last couple weeks, then you are arguing a question that has already been settled for the time being. Gigs (talk) 23:23, 6 December 2009 (UTC)

The consensus, as near as I can tell, is "A large group believe that we need to do something differently! And no one agrees what that change should be!" The 'consensus' that you're claiming certainly doesn't appear to endorse any particular RfDA variant, including the CDA model you're pushing here. Once again, I caution you not to rely heavily on the numbers or percentages at Wikipedia:WikiProject Administrator/Admin Recall, nor to presume to tell me what numbers we need to look at or ignore. In that survey, some 57 editors saw fit to weigh in (for or against) the status quo. By the time we got down to Option 4 – the basis for this proposal – there were only forty editors voting. Somewhere, we lost the interest of roughly a third of the participants by the time the fourth option came up. That suggests to me that the interest in and support for this process is neither as broad nor as deep as you'd like — and it doesn't tell us anything about the substantial majority of editors who couldn't even be bothered to click through and vote in the original poll.

You would be far further ahead if you were to address the concerns I've raised. Even if you fail to persuade me, I expect that there are a lot of people in the 'pro-change' camp who will be asking similar questions. Even if there is substantial, genuine support for a change, there isn't any conclusive consensus demonstration that this change is wanted or desirable. TenOfAllTrades(talk) 03:14, 7 December 2009 (UTC)

(o/d) It's my understanding that after this RFC concludes, another RFC will be launched in order to confirm the "final" version as policy, thus rendering the question of if this proposal had consensus in the previous RFC moot. Am I mistaken? Rami R 08:56, 7 December 2009 (UTC)

Reply to TenOfAllTrades: I agree that the support for this particular process is something that cannot be taken for granted - indeed improving on it is the purpose of this discussion and you are very welcome to contribute to that. With more than three quarters supporting a process of some kind however, the principle is not the main topic here. If you want "concrete examples" can I suggest looking at the current Questions for Arbcom candidates, several of which refer to the subject matter? I agree that the process is open to abuse, and personally I am conservative on question 5 above. My ideal would be that the very existence of the procedure would solve 90% of the problem or more and that its use would be exceptional.

Reply to Rami R. That is my view - although see also the dicussion at Wikipedia talk:Community de-adminship/RfC Strategy. Ben MacDui 09:03, 7 December 2009 (UTC)

Ah, that's an interesting discussion. I didn't realize that Gigs was hoping to justify implementing this proposal on the basis of no clear community mandate, relying on the numbers from the previous RfC. Obviously, that's not going to fly, and the 'crats wouldn't stand for it. The point where everyone gets tired of discussion and drops off this talk page should not be mistaken for 'consensus'. I'll plug my essay again: User:TenOfAllTrades/Policy reform treadmill#The Reformer's experience.

Incidentally, a further point was raised up above regarding WP:CANVASS. It probably ought to be in my bullet list in this section, but I'll slip it in here instead. At RfA, canvassing is strongly discouraged. We're trying to get a reasonable cross-sectional read of the Wikipedia community, and any sort of broad canvassing would tend to skew that sample. In an RfDA process, what we desperately need is information. While we want to have candidates evaluated in as impartial a way as possible, we want to have input and testimony from all of the editors who have relevant experience with the admin in question. It is reasonable to contact editors who have had conflicts with the admin in question, however that puts us in a bind. Since the outcome of the RfDA is to be decided by vote (or !vote, if you prefer), any attempt to ensure that the process is properly informed also guarantees that the participation will be (badly) biased. Short timelines (less than two weeks for the whole process) virtually ensure maximum drama and public or private canvassing. TenOfAllTrades(talk) 14:19, 7 December 2009 (UTC)

I don't know that I would worry about canvassing problems. They are easily dealt with at RfA, and there is no reason to assume that it wouldn't work the same way here. I fully expect that CDA pages would be added to User:X!/RfX Report and those who are interested in the process would see it there or by monitoring WT:CDA or on a watchlist. We should also note that we already allow a mild form of canvassing to get RfA co-nominators, or else there would never be any. To touch on some of the other earlier comments, naming names here would just create drama and defensive arguments that are unnecessary. I am sure we can all think of cases where ArbCom decided to admonish an admin but not desysop them, and at least some of the community disagreed with that decision. That is but one case where a process like this is necessary. Community bans have followed less serious ArbCom restrictions, and this would parallel those situations. There needs to be a method in all cases where the community, not a committee, is the final arbiter. This process would fill that void. Jim Miller ^{See me | Touch me} 16:17, 7 December 2009 (UTC)

To Ten, we already have a clear community mandate for a process. The process will be developed using consensus, like any other process. Voting is not required, and is not a good idea. Regarding canvassing concerns, yes, that is one of my primary concerns as well regarding the "10 to certify" requirement. I encourage you to participate constructively to change the proposal for the better rather than engaging in these distraction tactics. Gigs (talk) 18:12, 7 December 2009 (UTC)

Gigs, I'm sorry that you see raising legitimate concerns with the proposal as 'distraction tactics'. Seriously, though, even among the supporters of this proposal I doubt that you're going to get much traction for your 'we already have consensus' position. You're gonna hafta put it in front of the community to get a clear approval before it goes live — and in anything like its present form, I anticipate that this proposal will get shot down.

Jim Miller, I don't think I was quite clear in my point about canvassing. If we are to evaluate whether or not an administrator has engaged in misconduct, it's both necessary and reasonable for the participants in the RfDA to have as much detailed evidence as possible. That, in turns, means going out of our way to deliberately notify parties who have interacted with that administrator, to bring them to the RfDA to offer their testimony. (Compare with the opening statements and evidence phases of an RfArb.) We need to bring together the editors with grievances in order to evaluate the admin's conduct. On the flip side, administrators being examined should have every right to invite supporting views from other individuals familiar with the disputes and conduct at issue. Unlike RfA, we aboslutely should not rely on random drop-ins and people noticing passing watchlist messages to supply us with necessary information. (This goes back to my earlier remarks about the significant differences between the RfA and the RfDA processes, which I need not further belabor.) Canvassing is likely to be a required part of the certification process.

Unfortunately, once we've got all of the angry people in one place, we can't just tell them to go away again and pretend that they don't know about the rest of the RfDA. Once they're there, they're going to vote. In an RfArb, the people who evaluate evidence and choose remedies – the ArbCom – are separate and distinct from the parties to the case. In the proposed RfDA process here, there is no way to enforce such a separation. Indeed, the loudest participants are going to be the closest friends and direst enemies of the admin under examination; the people voting will have a personal, vested interest in the case's outcome. The voting population will be exactly the opposite of the cool-headed, impartial body that we would ideally employ. The problem will be exacerbated by the short timelines employed; there will not be sufficient time to discuss, interpret, or debate in depth, nor to consider alternate outcomes beyond straight-up desysopping. Unfortunately, I see no clear way around these fundamental structural problems within the framework of this proposal. TenOfAllTrades(talk) 20:14, 7 December 2009 (UTC)

That's very well put. It makes the status quo sound more appealing to me than it ever did before! I still think a proposal based on RFC (with RFA a distant possibility when absolutely necessary, with sufficient safeguards) might be an improvement based on the status quo, but it would depend on the details. Rd232 ^talk 21:20, 7 December 2009 (UTC)

I'd be willing to look at an RFC-like option to open the recall to replace the certification requirements. The Canvassing discussion is a good one, can we break it out from the tangled conversation here? Gigs (talk) 21:31, 7 December 2009 (UTC)

I hadn't really thought of it that way before, because I think of it under four terms: 1 - WP:NBD; 2 - The community gives adminship, and the community can take it away; 3 - The only thing preventing the community from doing just that is a lack of process; and 4 - This proposal fills that void. I will have to give more thought to the ArbCom comparison, but I really wouldn't want to see any more evidence here than at an RfA. Something complicated enough to require such an extensive process should be at ArbCom, not CDA. Removing adminship shouldn't need to be more difficult than granting it. We just need a process that keeps it from being filled with nuicance nominations that will only serve to disrupt. Jim Miller ^{See me | Touch me} 21:01, 7 December 2009 (UTC)

Ten, I suggest you review my position again. My intent never was to avoid putting the final RfC in front of the community, I merely want to avoid a massive overall "vote", which will never pass, as you are well aware. We need to get feedback and comment to build consensus, not votes that will divide it. Gigs (talk) 21:33, 7 December 2009 (UTC)

I'm confused, I think. I don't actually know what the difference is between a 'final RfC' in which editors support or oppose the proposed process, and a 'vote', in which editors vote to support or oppose the proposed process. I also don't understand why you would expect one to pass and the other to fail, nor why a policy proposal which fails the latter should be enacted. You're welcome (and encouraged!) to request comment from the community to develop a proposal, but at some point you also have to ask the community the clear question, "Is this the rule we're going to go with?" If you can't get an unambiguous affirmative to that, then you need to go back to the drawing board. (For the reasons I've discussed, I don't think that this proposal will get that approval. It's just too fast and too narrow, and it lacks sufficient checks and balances.) TenOfAllTrades(talk) 22:59, 7 December 2009 (UTC)

Because there are more options than support or oppose. For something like this, we need to build consensus, not destroy it by forcing people to take sides. Even during the "final" approval process, people need to be able to make proposed amendments and attempt to build consensus for them, kind of like you are starting to do here. Just because we started with CDA doesn't mean we need to wind up with it. We might end up closer to one of the other proposals entirely once it's said and done. Gigs (talk) 13:53, 8 December 2009 (UTC)

Well, no. It is certainly possible (and generally desirable) to revise Wikipedia policies and guidelines after they're enacted, as we learn from our experiences with them and generate new ideas. In order to enact a policy in the first place, however – particularly one like this which has some very far-reaching effects, and constitutes a major revision in our dispute resolution mechanisms – you do actually need to get a clear 'yes' or 'no' from the community. A substantial majority of editors must be able to say, "Yes, let's give this a try; I can accept that this process seems fair, even if it's not exactly the way I would have done it" — without that, the proposal can't go live. You're welcome to raise requests for comment as often as needed (within reason) during the development process, but at some point you have to give people an honest choice on something that isn't a moving target. If you're still making substantial revisions to the process during the so-called 'final' approval process, then you're not actually getting final approval. TenOfAllTrades(talk) 15:17, 8 December 2009 (UTC)

Where is the final approval "vote" for establishing AfD? UAA? MfD? AN/I? Here's a hint, they don't exist! No major process has ever, and can ever be created in that fashion. Gigs (talk) 19:52, 8 December 2009 (UTC)

I think that Ten has made a very good point about certain conditions where canvassing should actually be viewed favorably. The question is, how do we delineate those situations from those where canvassing should be viewed unfavorably. Please let me suggest this: there should be wording that any involved editors (including the admin under review) may invite other editors to comment, but must do so on wiki, and provide links or diffs of these invitations on the actual CDA page. Then the community can judge the validity or lack thereof of what results. This approach is basically following existing policy at WP:CANVASS, rather than trying to create something kludgy. (And by the way, this observation supports my earlier suggestion that it is best to extend the initial nomination period from 3 to 7 days.) --Tryptofish (talk) 22:30, 7 December 2009 (UTC)

I'm afraid I'm coming to this discussion rather late, since it slipped under the radar, but I would be opposed to any kind of community desysopping proposal. As TenofAll said above, this is a solution looking for a problem, we have a perfectly good desysopping method already, via arbcom, all a community desysop will do is create more instruction creep, open the door to frivolous nominations and harassment, undermine arbcom's desysop authority, and make it generally slower and more difficult to achieve desysop when required. Don't we have enough wikidrama already? I just can't see the point of this. Gatoclass (talk) 12:11, 11 December 2009 (UTC)

Don't worry you're not too late to participate and it's good to hear your contribution. The purpose of this phase is to come up with a fairly detailed proposal for a workable CDA, which can then be put out again to a community RFC. Essentially the CDA will only gain community approval to start functioning if we are able to address those arguments somehow - something that this process has as yet shied away from. (except for the essays referred). Is that enough - should there be a justification in the CDA proposal to answer the question why CDA? why is ArbCom not sufficient? AndrewRT(Talk) 22:22, 11 December 2009 (UTC)

That's a very good point! I wonder if we should merge something from the essays or project discussion pages into the page that will be produced. If so, what? And would there be issues with "too long, didn't read"? --Tryptofish (talk) 22:26, 11 December 2009 (UTC)

A few editors have raised general questions about this process here. The main questions so far are listed below. The extensive discussion has been archived. Continued comments of this nature are welcome, although please bear in mind that this discussion is aimed at improving the existing WP:CDA, not challenging its purpose. Discussion about whether or not enact WP:CDA will form a part of the next stage.

• 1. Comment: Wikipedia:WikiProject Administrator/Admin Recall had extensive discussion on a number of options. Suddenly, we seem to be discussing just one, and one which didn't have all that much more support than the others.

Short reply: CDA was the only one gaining a majority - it got 26 support and 13 oppose.

• 2. Comment: There seems to be a very short peg on which this particular proposal's hat is hung. Looking at the numbers, we're told that this proposal garnered a solid 65% support in the earlier round of voting. (Note that this is the only proposal that managed the support of a majority.) A closer look at that number, though, suggests that the enthusiasm for this proposal is somewhat overstated.

Short reply: Possibly, although it is clear there was a 77% support for creating a generic system of Admin Recall. Discussion about whether or not enact WP:CDA will form a part of the next stage.

• 3. Further discussion, mainly under the heading "Where does one get to say "Hell No!" to this process?

---

Well, the summary above is certainly misleading. I notice that the archiver has decided that any specific questions about the goals of the process aren't worth mentioning, and couldn't be bothered to sign his editorial work. I guess those were the questions that couldn't be dismissed with a neat little one-line soundbite. Buy hey, feel free to keep rearranging your deck chairs. I've wasted enough good-faith effort, and now I've been shuffled off to the "Screw you — 77% think you're wrong, so shut up!" 'Complaints section' for my trouble. Hammersoft's comment below (which for some reason was preserved) is rendered nonsensical.

The reason why these proposals always fail, and probably always will, is this insistence on wearing down, ignoring, or scorning anyone who questions the premise. (That...and the process won't work and isn't necessary.) Let me know if this ever makes it to a final vote, or if it just dies the usual lingering death. TenOfAllTrades(talk) 02:55, 17 December 2009 (UTC)

I'm sorry you don't feel heard, and I'm guilty as charged for archiving the detailed material - as I have done for about half of the on-topic discussions. I respect your reservations and opposition to the process, but we are trying to undertake a complex and detailed refinement process in an "IAR" environment and leaving every last comment and point of view will simply discourage participation in an already very long page. If you feel that there were comments that were archived that are an important part of the discussion here (as opposed to not supporting the premise of the discussion) I have no objection to them being re-instated. I did however think that RamiR summed it up in a sentence pretty well. Ben MacDui 21:05, 17 December 2009 (UTC)

• I think users deserve an opportunity to hone a process into something that is ready for a proposal stage. That said, pushing it into Wikipedia space (as opposed to say userspace) puts it into a venue for everyone to work on. I think this proposal, handled in the way it has been, is a premature birth. There are massive gaps. It's not ready for prime time yet. I would encourage the backers of this proposal to take this to userspace, invite the users you want to work on it, and bring it back to Wikipedia space when it is ready for prime time. I would caution such a work group to have a sharply clear and precise response to what problem this solution intends to solve, and how this solution will actually result in one or more improvements and very specifically what those improvements are.
• The reality is a huge number of proposals get fielded on this project. Very, very few get accepted. It's easy to create new ideas. It's orders of magnitude harder to figure out if the idea is needed, if its any good, what problem it solves, whether there's better solutions at hand, or even if it is a good idea whether in reality it could become good practice when put into play. The homework hasn't been done here. --Hammersoft (talk) 15:25, 17 December 2009 (UTC)

It would be helpful to me at least if you could identify what these "massive gaps" are. As far as I am aware everything that has been raised to date as requiring discussion has been included here. If there are serious omissions that so many reviewers have not yet identified I'm not sure what hiding it away in user space would achieve. Ben MacDui 21:10, 17 December 2009 (UTC)

• Please read the last paragraph what you responded to. It would be a very good start to answer those concerns. --Hammersoft (talk) 13:26, 18 December 2009 (UTC)

Where does one get to say "HELL NO!" to this process?

I see lots of voting opportunities on various aspects of this process, but nothing on whether this process is a good idea or not. I'm forced to agree with TenOfAllTrades. Unless there's a clear, evidence-based explanation of why a new process will improve the project, this proposal is a solution looking for a problem. --Hammersoft (talk) 23:01, 15 December 2009 (UTC)

It is currently projected that the Cda proposal will be completed in early January, and while discussion continues at Wikipedia talk:Community de-adminship/RfC Strategy about what happens then, I personally see some kind of !vote or adoption process taking place before spring, and perhaps as soon as mid or late January. Jusdafax 23:23, 15 December 2009 (UTC)

I don't believe in polling as a process tool either. Stalin had it wrong: (S)he who writes the questions controls the poll, he who merely counts the !votes comes a distant second. :-P

The wiki-rules give you a lot of options here:

• write out a page with a 'proposed' tag on top, then add in the talking points that were listed here. If people are foolish enough to not kill the tag, the page will end up dead quick enough. Bonus points if you manage to write things out in the form of a reductio ad absurdum, without getting caught. O:-). This is slightly dirty though. Better methods listed below:
• write out a page *without* a proposed tag on top, along one or more of the following lines.
  1. It includes things that already have consensus, (because people are already doing them)
  2. Uses concepts that are only a short leap of logic away from what people are already doing.
  3. Mentions things that are fairly sane to begin with, so that people would be foolish not to agree with them.
  4. Mentions things that were (already) likely to reach consensus, which you can figure out based on input put forward during earlier polls, and/or information you have gleaned from reading people's opinions so far.

  ; You will find that you can actually reach consensus much quicker in this way.

• Refactor the page any way you like.
• Start a discussion elsewhere, or alongside, and promote it well, or not at all.
• Actually create a page associated with this talk page. (with or without proposed on top ;-) )

In general: You are not in any way whatsoever bound to this process or timeline, act as you see fit. However, if you want to override the process, you would be wise to seek methods that are more efficient than the current process, so that you have the shorter decision cycle, and thus the initiative. (see especially OODA loop for more info on why this works).

This is both fair and wise because it means that you compete, and the best process wins.

TL;DR: If you hate this process, Ignore the framework, and participate on your own terms, or compete with it! :-)

--Kim Bruning (talk) 14:23, 16 December 2009 (UTC)

You miss the point, we already narrowed the field from like 15 separate proposals down to one. That took about a month to accomplish. I'm surprised that so many are coming along now with a "nobody has ever heard of this" attitude when we had it listed on WP:CENT and cross-posted at various noticeboards. It's a shame this baby is not ready to fly yet, because there is a perfect "test case" at ANI right now. Beeblebrox (talk) 19:21, 17 December 2009 (UTC)

"That took about a month to accomplish." - ROTFLMAO. It took about a month to have the Admin Recall RFC. It took a couple of days and a handful of editors to decide that only one option of those discussed in the RFC should be pursued further. The alternative, previously proposed, was identifying some fundamentally different proposal types from the range of individually-drafted proposals and working collaboratively on each type in parallel, then effectively having a run-off RFC. In essence the supporters of CDA have hijacked the Admin Recall process on the tenuous basis that it was the only one to get majority support. (Tenuous because of the RFC structure and nature, with variations on similar proposals and much votingcommenting on proposals before later ones were created; and also WP:NOTVOTE.) Rd232 ^talk 19:26, 18 December 2009 (UTC)

In fairness, that's hardly hijacking. More like discussion and, for the time being, consensus. Some of us have actually been working to incorporate the better features of other proposals into the one here. --Tryptofish (talk) 19:36, 18 December 2009 (UTC)

I'm more attentive than you might think. Is the one proposal actually a good solution?

Incidentally, I spotted some people supporting variants that are exploitable (eg. 5.1-5.3). Would anyone be opposed to me closing those options? --Kim Bruning (talk) 00:50, 18 December 2009 (UTC)

I'm not sure what you mean by closing, or by exploitable. We should only be archiving discussion of points where the discussion is over. --Tryptofish (talk) 01:12, 18 December 2009 (UTC)

I would like to end the discussion on those 3 points, because they expose wikipedia to a potential attack vector; see #WARNING_NOTE. They expose a typical flaw in formalized systems, and there is nothing else in the proposal to compensate for that issue -.TL;DR 5.1-5.3 introduce fatal flaws, and cannot be used. There is no way in which a poll on those points will ever benefit the wikipedia; so as a corollary of IAR: "if it harms the encyclopedia, fix it" ; I may remove them.

I certainly wouldn't mind actual discussion on those points, because that how folks get brilliant ideas; but any support for the points themselves moot, 'cause we're not going to do that (or if we do, it won't be for too long, if you catch my drift :-P ). --Kim Bruning (talk) 11:24, 18 December 2009 (UTC) I actually anticipate some people reflexively opposing my action. They're going to have to explain those reflexes, as per WP:WIARM ;-).

I see now: you are referring to that warning note you wrote. Regardless of whether or not implementation of those proposed ideas would expose Wikipedia to such a thing, discussion of those proposed ideas only exposes Wikipedia to: discussion. I think that most editors here would prefer to let discussion continue for the remainder of the discussion period, so, no, I would object to you doing that. If certain proposed options end up never being implemented, it does no harm to discuss them. Editors who are concerned that these options should not be implemented are very welcome to discuss why they feel that way. Indeed, that's the whole point. --Tryptofish (talk) 18:02, 18 December 2009 (UTC)

I certainly would not want to stop a discussion. Can you link me to where that discussion is being held? I'll replace the polls with a link to that discussion. Will that do? --Kim Bruning (talk) 19:05, 18 December 2009 (UTC)

Thanks. Personally, I'd rather just see more editors making expanded comments on this page, instead of a numbered "me too". But I think a lot of editors are making thoughtful comments. They don't stop being discussion just because they are formatted a particular way. --Tryptofish (talk) 19:17, 18 December 2009 (UTC)

A general observation: in answer to the question at the top ("where does one go to say hell no?"), the answer is, for the moment, remember that WP:There is no deadline, and for the near future, that there will be an opportunity to oppose the product of this discussion. Whatever comes out of the discussion here, there will be no way for anyone to force it down the community's throat, and I'm pretty sure no one wants to. Of course, an alternative would be to try to improve what's being worked on here. --Tryptofish (talk) 19:41, 18 December 2009 (UTC)

In answer to the question at the top of this section, one of the proposals of the earlier poll was pretty much "do nothing". If one wanted to object to the entire process one should have voted for that proposal. Lambanog (talk) 11:53, 23 December 2009 (UTC)

• So now, since I missed that poll, I have no voice? I can't object? I have no right to say anything? Excuse me? --Hammersoft (talk) 18:24, 27 December 2009 (UTC)

Quick comments

1/

Edit:

"This process covers solely the sysop right. And it only applies, of course, to accounts that actually have that right in the first place, or could acquire it without seeking community or Arbcom approval."

Scenario: user resigns in normal course of things without a cloud, then does something seriously wrong, then a year later seeks adminship back at WP:BN as he's not "under a cloud" and it's "old stuff".

The community needs to be able to convert his self-request deadminship to a formally decided one if he has acted wrongly and yet could get adminship back easily, to prevent gaming.

2/

Addition:

"Private evidence: Arbcom may be asked for a formal statement and characterization of any non-public material salient to the request, to allow the community to understand how they should be interpreted. If (exceptionally) the matter cannot be characterized publicly in a fair manner then community de-adminship may not be a practical process."

Scenario: a user does something on a page that is widely held to be an abuse of access. He has private knowledge that he would raise in his defense -- but he can't post it on-wiki because (for example) it relates to oversighted defamatory material, he would have to re-post deleted BLP content, or it concerns harassment or off-site attacks, etc.

In such circumstances this amendment would mean he should contact Arbcom in the first instance and say "here is the evidence, can we review it by email and then Arbcom post a formal statement at the de-adminship to explain what's gone on and how they see it, to allow fair discussion and so the admin is not torn between defending themselves and breaching privacy."

Immediate 2 comments. FT2 ^{(Talk | email)} 22:21, 30 November 2009 (UTC)

There is no need to create drama by formally revoking sysop from someone who doesn't even have it currently. If they somehow got it back then we could use this process. Gigs (talk) 22:41, 30 November 2009 (UTC)

Not convinced you could. If User:Example did something very wrong some months ago, and then asked for adminship back a long time later (no bar to it, not formally under a cloud) could you justify removal of adminship at that later time, on the basis of events dating back? You'd get a lot of "old stuff, mere drama" etc if you tried.

A user who has voluntarily dropped adminship but can claim it back at any time, needs some way for the community to say "Actually we don't think you should just be able to claim it back. Not after this incident." Given the user isn't a current sysop it's also unlikely such a request would get the numbers needed to initate it, unless the incident was fairly major. FT2 ^{(Talk | email)} 22:46, 30 November 2009 (UTC)

Do crats automatically grant the bit back without even considering intervening behavior? Is this an actual problem? Gigs (talk) 22:55, 30 November 2009 (UTC)

A user who voluntarily gave up the bit can ask for it back at any time. Trust doesn't fade in that sense. A user could retire in 2003, and wander back in 2010, and if they could prove they were the same person, just ask for the bit back. (Maybe some eyebrows at their return, but no eyebrows at their right to request it). The only exception is someone who was actually desysopped or gave up the bit "under a cloud". Asking the community to judge conduct of an old intervening matter is likely to be seen as contentious, and the crat's (rightly) won't see that as their role. FT2 ^{(Talk | email)} 23:04, 30 November 2009 (UTC)

Come on, give our bureaucrats a little more credit; I think they're smart enough to not blindly promote. Either way, this seems to be a very hypothetical situation. How many resigned "not under a cloud" admins do we actually have? Rami R 21:15, 2 December 2009 (UTC)

If it is going to require secret evidence, then the whole matter should go to arb com. The community is niot a suitable forum in such cases. DGG ( talk ) 05:17, 3 December 2009 (UTC)

I agree with DGG about the secret evidence. About the person coming back and asking to be re-sysopped, I think we can let the Crats decide, and if it turns out that the person turns over a new leaf (possible), then good, and if they commit new wrongs, then this proposed procedure as it is could kick in, based on current evidence (and possible discussion of the past, if the community sees fit). The solution to "old stuff" arguments is counter-argument, which should prevail if still valid, and should fail if it is not. --Tryptofish (talk) 19:48, 3 December 2009 (UTC)

Motion to close

I think this page ought to be closed as a scary bureaucracy that will never be approved by the community. We've recently reinforced the admin conduct RFC process by giving it more visibility. If an admin is a problem, start an RFC to generate a consensus for desysopping. Then ask the admin to resign. If that fails, go to ArbCom. They will look at the RFC and decide if an involuntary desysopping is needed. The proposed bureaucracy will not work smoothly. It will just end up in lengthy, convoluted or gameable process ultimately leading to ArbCom. We should not divert attention from proper, existing processes. Instead, we should use what we have and refine it to work better, rather than creating new bureaucracy whole cloth.

Support

1. As proposer. Jehochman ^{Make my day} 14:08, 22 December 2009 (UTC)
2. Rd232 ^talk 14:12, 22 December 2009 (UTC)
3. -- Avi (talk) 15:42, 22 December 2009 (UTC)
4. If the community wanted this, they would not have rejected it the last half dozen times something like this was proposed. We have a procedure that takes evidence from all parties and applies that evidence to the applicable policies and community expectations. Alternatives including complicated bureaucracy and popular votes have been repeatedly rejected when proposed. Chillum ^{(Need help? Ask me)} 15:47, 22 December 2009 (UTC)
5. Yep, it's dead. The last seven days saw fewer than fifty edits to this talk page, the majority of those were criticism and attempts to stifle criticism. No proposals made after 1 December have garnered more than eight voters total. The community has lost interest and wandered off. TenOfAllTrades(talk) 19:22, 22 December 2009 (UTC)
6. Amen. Preach on brother. Existing processes work fine when used. Creating new processes people don't want to use will not solve anything. --Jayron32 20:32, 22 December 2009 (UTC)
7. Support. Any form of mandatory de-adminship will be gamed and used against those administrators who work in the hardest to control the worst areas on WP. We already have RfC/admin conduct, and if there truly is a problem, RfArb to de-admin. SirFozzie (talk) 21:51, 22 December 2009 (UTC)

   But, as written, this is a motion to close the debate. This isn't about whether or not de-adminship is a good idea. Granted, if you close the debate then the de-adminship issue goes away; but that is a worrying president to set. Do we close all discussion on issues when we don't agree with their current objectives? After some discussion, debate, and compromise, this may well evolve into something useful. Closing the debate removes that possibility. ~~ Dr Dec (Talk) ~~ 23:29, 22 December 2009 (UTC)

8. -- PhantomSteve/talk|contribs\ 22:34, 22 December 2009 (UTC)

   Indenting, going to abstain. While I do support a de-adminship process of some form, I'm not sure this one is right. I agree with SirFozzie, because while I do think we shouldn't have to go to ArbCom to get someone desysopped, it shouldn't be in this format. I'm willing to let this stay until mid-January though, because if parts were rewritten it could be largely satisfactory - however, at this point, I'm going to say we should close it. ceranthor 23:30, 22 December 2009 (UTC)

   Dr Dec says what I am thinking, it seems, but I still don't think this process is completely satisfactory (at least not yet). ceranthor 01:30, 23 December 2009 (UTC)

   So fix it; don't close it! ~~ Dr Dec (Talk) ~~ 01:35, 23 December 2009 (UTC)

9. Any kind of a popular vote type process for de-adminship is a bad idea. Admins should be allowed to do their job, which includes dealing with nasty and difficult disputes, without being in a constant re-election mode. The current process (RfC, and if that does not work, ArbCom) basically works fine. Nsk92 (talk) 00:23, 23 December 2009 (UTC)
10. I see no reason to keep this open. I myself have commented here, but with such low community participation, nothing can come of it. --Coffee // have a cup // ark // 00:33, 23 December 2009 (UTC)

    There have been quite a few !votes on this closure motion in the last hour or so. Just as many as with an RfA. More people are now aware of this page and so "community participation" is bound to increase. Even if it doesn't, why close it? Is it that much of a drain on server space, or on other resources? ~~ Dr Dec (Talk) ~~ 00:40, 23 December 2009 (UTC)

11. (edit conflict) Not enough community participation, I agree. The current system (RfC, then arbitration) pretty much works as it is anyway... (I know there are people participating in this motion to close, but, I think a lot of it may be the same people who discussed elsewhere in this proposal)--Unionhawk ^{Talk E-mail} 01:37, 23 December 2009 (UTC)
12. Participation too low, and nothing is very useful. This is indeed just a solution in search of a problem. We may have had a small problem a few years ago with some entrenched admins, but we don't have it now. We have a desysop-loving ArbCom, and if anything one could argue admins actually need more protection. Close.Deacon of Pndapetzim (Talk) 03:24, 23 December 2009 (UTC)
13. I've not generally seen such processes as terribly beneficial. In emergency situations (compromised admin account being used to vandalize the main page, etc.), a steward will act immediately, so there would be no need for a process like this. In more contentious situations, I think the process of arbitration is the best way to determine whether someone has used admin tools abusively, and if so what the best resolution to the problem is. I've participated here in the interest of making the process as good as it can be if it should occur, but realistically, I don't see the need. Seraphimblade ^{Talk to me} 08:20, 23 December 2009 (UTC)
14. Let's kill it off. Stifle (talk) 09:39, 23 December 2009 (UTC)
15. As good as the proposal sounds, the community has clearly demonstrated that they are unable to reach a consensus on any proposed method. If we clearly cannot decide on how to do it, it's no use to continue discussing the matter. Regards SoWhy 09:50, 23 December 2009 (UTC)
16. As a proof of concept it shows that the community is divided on whether to proceed or how to ensure integrity in the process. In all that I have read it hasnt demonstrate a need for the process, it has demostarted that community resists any bureaucratic system that complicated or easily gamed Gnangarra 10:14, 23 December 2009 (UTC)
17. Clearly the proposal as worded does not have consensus and discussion is not moving towards consensus either. Guy (Help!) 10:26, 23 December 2009 (UTC)
18. There might be an argument that the community wants a (new) system to desysop admins. This draft RfC isn't even close to coming up with a workable system. I'm personally of the opinion that the current system works adequately. GedUK  10:53, 23 December 2009 (UTC)
19. Ruslik_Zero 17:17, 23 December 2009 (UTC)
20. Weakly. This proposal (the de-adminship, not the closure) is byzantine, poorly expressed and cloaked in needless bureaucracy. I'm absolutely dumbfounded by the sheer complexity of the discussion and the preparation involved. A number of smart, interested people helped write this. When did it turn into this incredible mess? There are 79 subsections to this talk page not counting complaints added by outsiders. Most of those sections are polls, permutations to the original procedure or other clarifications/provisos. Shut it down. Protonk (talk) 20:54, 23 December 2009 (UTC)
21. FASTILY ^(TALK) 23:18, 24 December 2009 (UTC)
22. Dont see a net benefit to community desysop. FeydHuxtable (talk) 22:46, 3 January 2010 (UTC)

Oppose

1. Oppose - There is a lot of evidence that a substantial number of editors want an alternative, or final appeal, to the issue of problematic admins. Dozens of people have voted and worked on this draft Cda for months now, in good faith that a process for 'reverse Rfa' is just common sense. This motion to close, coming at the start of the core of the holiday season, jumps the gun and in my view is unfair to those who may be out of town or occupied. Strongly suggest we complete the process on this draft in early January, and then consider a consensus vote at that time. Jusdafax 18:15, 22 December 2009 (UTC)
2. It's kind of silly to close this because the absolutely non-binding RfC/U is nothing like CDA. And yes, we've spent months working on this, so just because we now have a place to talk about an admin's actions doesn't mean CDA is useless. If you want to discuss it next year when it is put up for discussion, feel free. Otherwise, don't equate two things that are entirely unequal, or make judgements that something is "dead in the water" before it gets into the water. Angryapathy (talk) 19:40, 22 December 2009 (UTC)
3. Oppose - if for no other reason than to oppose the proposer. Work in progress, should continue. Leaky Caldron 21:26, 22 December 2009 (UTC)
4. Oppose per Jusdafax; a significant number of editors would like to see some change. Shubinator (talk) 22:33, 22 December 2009 (UTC)
5. Oppose − We should not smother free speech, nor debate. Bad ideas usually fizzle out; so if this is such a bad idea then it will just fizzle out and go away. I don't see what's "scary" about this at all; what is scary is the motion to force a closure upon a debate. If it "will never be approved by the community" then there's nothing to worry about: it will be totally inconsequential and so its closure or non-closure will make no difference. There's no need to impose a closure upon the discussion. ~~ Dr Dec (Talk) ~~ 22:57, 22 December 2009 (UTC)

   This WAS Fizzling out, until this motion to close (See TenofAllTrades's Post in the Support section above). Does that mean it's a bad idea? SirFozzie (talk) 23:42, 22 December 2009 (UTC)

   No it doesn't. In logic: "If A then B" is not the same as "If B then A". If all men wear hats then it doesn't mean that all those that wear hats are men (all men, and some women, may wear hats). (Bad Idea ⇒ Fizzle Out) does not mean that (Fizzle out ⇒ Bad Idea) ~~ Dr Dec (Talk) ~~ 23:51, 22 December 2009 (UTC)

   Is this discussion Fozzling out? LessHeard vanU (talk) 22:47, 23 December 2009 (UTC)

6. Per Dr Dec NW (Talk) 23:34, 22 December 2009 (UTC)
7. 50 edits in 7 days does not strike me as evidence that discussion is fizzling out... it sounds like a fairly lively debate in fact. No convincing reason to stifle that. Personal views on this de-adminship proposal are not relevant to how soon we close the draft RfC; the liveliness of debate and level of activity, however, is. -kotra (talk) 23:58, 22 December 2009 (UTC)
8. I think that an RfA is, more or less, a special case of an RfC; I believe there's a strong need for a clear form of RfC for cases where an administrator has lost the trust that got them the buttons to begin with. I think that Jehochman's proposal above is mistaken. This will not so much distract from an existing process, as it will clarify the way to execute an existing process. -Pete (talk) 00:04, 23 December 2009 (UTC)
9. Oppose. If the rationale is that the number of edits has declined lately, that has nothing to do with the level of support or opposition; rather it's just a reflection of some points reaching the stage of not needing to be debated much more, and probably some pre-holiday travel. If the rationale is that the proposal that will eventually emerge from this discussion will eventually be rejected, then there's a very good solution to that concern: let the proposal emerge, and then reject it. But this motion seems like a highly un-collegial attempt to prevent the proposal from ever emerging, out of fear that the community will actually approve it. What are you, really, afraid of? If the community rejects it, nothing changes. If the community embraces it, then this motion is contrary to the community's wishes. Either way, let the discussion continue, and argue your case, but don't try to prevent others from arguing theirs. --Tryptofish (talk) 00:08, 23 December 2009 (UTC)
10. Oppose, per Dr Dec. –blurpeace ^(talk) 00:26, 23 December 2009 (UTC)
11. Oppose: There is already a closing date/time scheduled ("8pm GMT on Monday 4th January 2010"), which makes allowances for holiday absences. No need to rush matters. Let people have time to think about and discuss the issue. — Sizzle Flambé (☎/✍) 00:29, 23 December 2009 (UTC)
12. Oppose early close. --SarekOfVulcan (talk) 00:48, 23 December 2009 (UTC)
13. Oppose in spirit I have serious doubts about the viability of this particular style of processmaking, as I have expressed in volume on many of these pages. I think there's no harm in letting this run its natural course, but I have serious doubts about the ability for it to succeed as currently framed. As for the argument that it's "diverting resources", that's a sort of "fallacy of personal values", the same as saying "Why does anyone waste time editing Wikipedia when they could be feeding poor people?" Gigs (talk) 02:02, 23 December 2009 (UTC)
14. Oppose I see no reason to close. The low activity as of late could easily be explained as holiday travel and activities. Also, I agree that this proposal would be much more binding that an RFC/U. Further, I believe there should be multiple ways to resolve issues and RFC/U, this proposal, and finally an Arbcom could be steps to resolving an issue with an admin. Too early to close.--v/r - TP 03:40, 23 December 2009 (UTC)
15. Oppose. Bsimmons666 (talk) 03:42, 23 December 2009 (UTC)
16. Oppose per Jusdafax and Dr Dec. A Stop at Willoughby (talk) 05:10, 23 December 2009 (UTC)
17. Oppose. People should have the opportunity to express themselves on this issue. A rough deadline has already been set. There is no need to prematurely shorten the period of discussion. That the motion to close has even been tabled and finding support among admins is troubling. Do current admins have a propensity to cut off discussions? I'd have expected more neutrality. Lambanog (talk) 05:33, 23 December 2009 (UTC)

    To be fair, five of us (so far) opposing an early closure are admins. -kotra (talk) 06:07, 23 December 2009 (UTC)

18. Oppose closure on the rationale offered above. This is a needed reform that should be implemented as a new process not killed in favour of RfC. Eluchil404 (talk) 05:47, 23 December 2009 (UTC)
19. Oppose because there should always be an appropriate exit strategy, and currently the exit strategy is unclear and governed by a slow-moving and over-stretched committee who a) do not always operate to the satisfaction of the community, and b) for whom there is some concern about growing influence and power. By the very nature of Wikipedia the community should be dealing with as much as possible. And if the community decides when a user is to be trusted with extra tools, the community should also decide when that user is no longer trusted with the tools. SilkTork *^YES! 06:13, 23 December 2009 (UTC)
20. Oppose Citing low user participation in a holiday block is a bit unfair. If this proposal can get off the ground it would make for an interesting alternative to RFC/U -> Arbcom for these matters. Unomi (talk) 06:44, 23 December 2009 (UTC)
21. Oppose. Admins are important; they have extra tools to help this project, and they are also expected to engage in conduct that is fitting for their position, both with respect to their tools, and otherwise. This is not another method of banning users; it is a mechanism for suspending/removing the extra privilleges of the minority of admins who bring this project into disrepute and/or do not conduct themselves in accordance with the expected standards of behavior and decorum for their position. The community shouldn't be forced to keep ArbCom/RfC as the only solutions to this ongoing issue; the community should be free to discuss and brainstorm another process of its own - we need to put as much thought into it as we can. Also, this is a holiday period so substantially lower participation is quite predictable. Finally, this is about de-adminship - admins should not have been the first to propose closure in this manner, if at any time. Ncmvocalist (talk) 06:58, 23 December 2009 (UTC)

    It may be worth noting that the basic proposal was drafted by an admin - the now regrettably MIA Uncle G. Jusdafax 07:22, 23 December 2009 (UTC)

22. Oppose. I think admins have a COI in this discussion and that should be taken into account. Sole Soul (talk) 09:45, 23 December 2009 (UTC)
23. Oppose - When the community have lost interest in it, they have lost interest in it, and this page will go inactive on its own without the requirement of motions. Reform is needed and for various reasons RfC is not a substitute for this. Camaron · Christopher · talk 10:08, 23 December 2009 (UTC)
24. Oppose. The RFC has not gone stale yet, and still receives commentary. A significant portion of the community has expressed some dissatisfaction with the status quo, and I don't think shutting down this effort at this point will do any good. Sjakkalle (Check!) 10:09, 23 December 2009 (UTC)
25. Oppose closing I think some of the reasons (or lack of) given for closing can be seen as reasons we need to keep this on track. If there was ever an inevitable procedure it is this one. Also, we cannot allow admin to close something that could compromise their future too (ie in comparison to concerns about a frothing rabble gaming an admin's fall - global warming would be nothing of course to the very thought of such an unthinkable outcome!) If this is done properly, any gaming will even out, and all kinds of precautionary measures can be put in place - the idea that gaming could happen is a terrible reason for quashing what will eventually be such a fundamental process of Wikipedia. Faith in admin, in my opinion, has to be an actual 'consensus' matter, backed up by fail-safe percentages/measures etc. Perhaps we need to ask ourselves - do we really believe in consensus? Something will inevitably develop from here for a number of reasons, one of them being that the overall quality of admin is simply too poor, as the RFA process is hardly perfect and game-free itself. Admin are handed almost emeritus status for being (in many cases) people who have simply kept their noses clean for long-enough to get a nomination (often for the wrong reasons - ie to do with a subject, friendship, a shared view or a basic need - rather than any intrinsic neutrality/work-ethic/diplomatic balance), and/or have become experts at playing a system which on balance suits the Machiavellian above the neutral. A community-based de-admin procedure will actually eliminate quite a lot of the real cynicism people have towards admin, and the system in general. But if you are already an admin under the status quo, why would you need to care about something like that?? The more people are made to be responsible for their actions, the more responsibly they behave. When I summarise the admin system to people who turn their nose up at Wikipedia (which is almost all of the serious world, regardless of how it ranks on Google and the amount of people who consequently read it) they just dryly laugh as they've basically had all their prejudices confirmed. Wikipedia is still too primitive to be taken seriously, even if it is foolish to ignore. These things take various rounds of debating/voting to work - they take a little time, so lets take the time.. Matt Lewis (talk) 11:26, 23 December 2009 (UTC)
26. Oppose out of process and weight of opinions to support close. If it's still going, it's still going... and it's not really in the spirit of community to shove closed a discussion that hasn't reached its suggested end date. ♪ daTheisen(talk) 13:25, 23 December 2009 (UTC)
27. Oppose upon the premise that a strengthened RfC option is the alternative; ultimately in that case the method of enforcing a desysop rests with ArbCom/Jimbo - this proposal reflects a major viewpoint that deadminning should also reside within the communities remit; what the community may bestow they may also remove. LessHeard vanU (talk) 13:35, 23 December 2009 (UTC)

    "in that case the method of enforcing a desysop rests with ArbCom/Jimbo" - not necessarily. The RfC previous to this one identified several ways RfC could lead to a reconfirmation RfA. Rd232 ^talk 14:09, 23 December 2009 (UTC)

    "Last year I recommended an RfC based de-sysop process that would be judged by a bureaucrat on the theory that what bureaucrats can give, they can also take away. The proposal was rejected by the community because ArbCom has time and willingness to review all cases of involuntary de-sysopping, and that the bureaucrats were loath to take up such power without a very clear consensus. The current proposals fail because they don't answer the question of who decides the results? Any straight out voting will be subject to gaming and abuse. Who counts the votes? Who disallows bad votes? Any such process will descend into controversy and end up at ArbComat the end. Thus, the current set of proposals are nothing more than a rehashing of old proposals that have already been rejected, and they represent needless bureaucracy. Anybody is free to make a new proposal at any time. However, this meta discussion about drafting new proposals is inefficient, and represents circular discussion. My motion to close is a warning that all this has been tried before and rejected. Please don't waste your time further. Jehochman ^{Make my day} 14:46, 23 December 2009 (UTC)

    I thought this was a honing process more than an right-first-time proposal? These things need to gather steam and, if necessary, develop from each other, don't they? Disjointed proposals are often easily broken too. I agree a lot needs ironing out though, but Wikipedia needs more of a handle on the 'consensus' it promotes so heavily. Look at all the AFDs, for example, that just sit there waiting for a biased admin to judge the way that suits him/her, claiming "no consensus" when, with a will, consensus can easily be spotted. Via the internet all kinds of arrangements should be possible. Admin could come into the CDA for a separate round perhaps, the first one being editor-only. Longstanding editors could be invited to contribute too. like a kind of voluntary jury service. The jump from editor to admin is certainly too stark - something inbetween could make a lot of sense, and if people wanted the admin tools, they could have to attend these type of things. Certainly if admin were made less invulnerable, they might worry about where they stand with editors a little more, and might be less inclined to game themselves. I'm personally tired of seeing ones who clearly don't give a shit about anything but themselves. I think more effective RFAs will happen as a direct result of having a community de-admin process. Matt Lewis (talk) 15:32, 23 December 2009 (UTC)

28. Oppose as out of process. There needs to be a discussion. Tavix |  Talk  17:05, 23 December 2009 (UTC)
29. Oppose proposing to do nothing about the rogue admin problem. Since before I started editing Wikipedia, over five years ago, this so-called encyclopedia has had an amazing set of rules that aren't worth the bandwidth they consume. Way too many users, including too many admins, consider the rules something to use, not follow. Many admins don't even know what the rules are. Things haven't gotten better over the years, and WP needs a seachange, not no change. While there are good admins, rogue admins must be desysopped. WP has a huge flow of good editors leaving because tendentious winning gamers frustrate them. I am one such editor. In the absence of change, neither I nor throngs of other editors see WP as worth it. One consequence of this is that we tell others that WP isn't reliable. While many people have checked out Wikipedia, most leave, unimpressed. Word is getting out.
    The choice isn't about making changes that must be made. The choice is about success or failure of WP. Our children are growing up knowing that Wikipedia is bad. It's just a matter of time. Years ago, it was made difficult to desysop because Wikipedia had a severe shortage of admins. Now that difficulty has become a serious problem. Admins should be held to a higher standard of conduct, but they're just (anonymous) people. -- Rico 18:44, 23 December 2009 (UTC)
30. Oppose There is no reason to cut this off at this time, and any assumption that this will "never be adopted by the community" is pure speculation. Closing this now would simply serve as a way to prevent wider discussion and eliminate the possibility that the opinion of the community may actually be heard regarding adoption or rejection. A community-based method that allows removing admin status as easily as granting it is a necessary process for WP, and must be addressed eventually. Jim Miller ^{See me | Touch me} 20:59, 23 December 2009 (UTC)
31. Oppose I'm not convinced by the arguments for closure. Discussion seems to be ongoing. ChildofMidnight (talk) 21:43, 23 December 2009 (UTC)
32. Oppose - This is still actively being considered. -- Atama頭 23:09, 23 December 2009 (UTC)
33. Oppose - I see no reason to close this when it's still under active consideration. There's no harm to the project if this comes to fruition and is formally presented to the community. Beyond My Ken (talk) 03:45, 24 December 2009 (UTC)
34. Oppose - Early days yet. WP is crying out for a way of mitigating the corrupt 'jobs for life' adminocracy. We mustn't let assorted admin interests derail this. Ohconfucius ^¡digame! 07:21, 24 December 2009 (UTC)
35. Oppose. I see no remotely convincing reason to close this discussion now, except as a means to get a head start on saying "no" to this draft proposal before it was scheduled to become a formal RfC. Maybe it's not a good idea (I've just become aware of it and haven't really looked at it), but why on earth would we not wait a couple of weeks and let everyone weigh in on a full-blown RfC? If it won't gain consensus as some claim above then what's the worry about having the discussion? Maybe it will be a waste of time, but even if no consensus is achieved maybe we'll get some useful information and/or better ideas about how to go forward (at this point I'd rather maintain momentum to address the issue of lack of admin accountability, and closing this now would seem to short circuit that). Some of those supporting closure above are really stating their general opposition to some form of community de-adminship, but that's not the purpose of the "motion to close" or indeed of this "draft RfC." I should also think it would be obvious that having an admin move to close a discussion about maybe talking about a specific form of admin recall, and then having a number of admins leap in and say "let's kill this" and the like is not a good idea. Finally you would need a strong consensus to shut off discussion (it's kind of a hard thing to enforce) and that's obviously not going to happen, so I would actually move to close the move to close this discussion about having another discussion (did I just accidentally pass the bar exam at the end there?). --Bigtimepeace | talk | contribs 08:47, 24 December 2009 (UTC)
36. Oppose - While there's a fairly good chance I'll oppose the final proposal, and I agree that this RFC should be closed, I don't see that this is so bad it needs to be killed before it even gets to the final proposal stage. The community is so resistant to change, simply plopping out a proposal almost never succeeds anymore; this RFC is just trying something different. Mr.Z-man 16:32, 24 December 2009 (UTC)
37. Oppose shutting down this discussion, no comment on the draft RFC. The discussion may or may not go somewhere that will be adopted, but the discussion is good. Let this discussion finish and then see if there is a consensus to adopt the outcome of the discussion. Just because other proposals have not been adopted in the past is not a reason to believe that a new proposal will not be adopted. ~~ GB fan ~~ ^talk 22:19, 24 December 2009 (UTC)
38. Oppose: This is the wrong venue for a "motion to close". Try MfD. --Thinboy00 @992, i.e. 22:48, 24 December 2009 (UTC)
39. oppose no clear reason to end what is still an active discussion. Hobit (talk) 01:55, 25 December 2009 (UTC)
40. Oppose Discussion has not stalled. ηoian ‡orever ηew ‡rontiers 03:32, 25 December 2009 (UTC)
41. Oppose No clear reason to close this discussion. Debate is still productive. I agree there is a lack of consensus, but that is precisely why this discussion must not be closed right now; it should only be closed if the discussion has stalemated, which it has not. --Shirik (talk) 05:42, 25 December 2009 (UTC)
42. Oppose I see nothing wrong with the process which is being applied here. Clearly something like this should not be implemented unless or until it has the clear support of the community. In fact this motion to close debate is very useful in striking up that debate and bringing out the objections. But what is wrong with a group of Wikipedians working collaboratively to put together a workable proposal that can then be discussed widely in the community? Please, cut us some slack - give us a chance to come up with something workable which you can then shoot down if you so please. AndrewRT(Talk) 20:45, 28 December 2009 (UTC)
43. Oppose - ignoring a cancer doesn't make it go away. Sarah777 (talk) 21:58, 28 December 2009 (UTC)
44. Oppose - it can't hurt to continue. GoodDay (talk) 22:25, 28 December 2009 (UTC)
45. Oppose The scheme has merit and the work should continue. Colonel Warden (talk) 09:21, 2 January 2010 (UTC)

Discuss

We already have a reverse RfA process. It's called RFC. People just need to start using it. You only need two concerned editors to talk to the admin, and if good faith concerns are not answered, an RFC can be started. That's a very low threshold. I see no obstacles to removing bad admins. Jehochman ^{Make my day} 19:26, 22 December 2009 (UTC)

And who judges the RfC after the discussion has ended? Angryapathy (talk) 19:35, 22 December 2009 (UTC)

The RfC you provide is nothing like this proposal. In fact, the RfC/U states that it cannot Impose/enforce involuntary sanctions, blocks, bans, or binding disciplinary measures. So now we have a dedicated forum for people to talk about an admin. But it is just as effective as the admin recall, or maybe even less so. Angryapathy (talk) 19:43, 22 December 2009 (UTC)

I disagree with the reasoning for this Motion to Close, and am notifying members of Wikipedia:WikiProject_Administrator as well as relevant noticeboards - with neutral wording under the provisions of WP:CANVASS - so that involved parties have a chance to respond to this motion, which as I note in my oppose above comes at the start of the biggest holiday cycle of the year. Jusdafax 19:48, 22 December 2009 (UTC)

That sounds like a non-neutral audience. How about announcing at WP:AN and WP:PUMP in the policy section so that we get a more representative members of the editorial community. Jehochman ^{Make my day} 19:51, 22 December 2009 (UTC)

I've hacked out that section of WP:RFC and replaced it with a more accurate statement of how things actually work.[1] I've also added a note to Wikipedia:Administrators.[2] Hopefully those two edits will serve to clarify matters. Jehochman ^{Make my day} 20:40, 22 December 2009 (UTC)

Since Judasfax seems to be notifying individuals veeeeery sloooowly (I count twelve personal invitations in one hour), I've taken the liberty of offering a general invite to the broader, more neutral audience at AN: Wikipedia:Administrators' noticeboard#Motion to close de-adminship process proposal. TenOfAllTrades(talk) 21:17, 22 December 2009 (UTC)

Naturally, I do reserve the right to take breaks, talk to my family (as I note, it's the holidays and a lot is going on for many of us) and so on. And I'm happy to have all involved or interested parties notified. Thing is, quite a few of us are on vacation and won't be able to respond at all until after New Years. My take: this 'Motion to Close' should not be finalized until January, to be fair. Jusdafax 21:35, 22 December 2009 (UTC)

This page is not intended to be a discussion page for those who a priori oppose the idea of Admin Recall and the motion is essentially incompetent. When it is closed, whether sooner or later, the next step is to decide how to present a proposal to the community when such views will be taken into consideration. If those who don't like the idea are correct, and that support is weak, then they have nothing to worry about. Why, one wonders, is there then a concern that this discussion might continue for a few more days? It's not as if we are short of disk space. I am of course assuming good faith. Ben MacDui 21:22, 22 December 2009 (UTC)

for the record, I did not and do not oppose the idea of Admin Recall. See my involvement in the previous RfC, including its talk page. Rd232 ^talk 21:26, 22 December 2009 (UTC)

Thank-you for reminding us. I also note that we have been assiduous in avoiding naming names when the question of "can you gave examples" comes up. Given that some believe the "existing processes" are a shambles I wonder if providing a few would actually help? Ben MacDui 21:29, 22 December 2009 (UTC)

No, it wouldn't. What would help is going back to the previous RfC, and not closing down discussing of fundamentally different approaches. The claim that CDA could be adapted to please everyone was always hogwash, the attempt to do so disastrous, and this farce is the result. Move back one square, and roll again. Rd232 ^talk 22:47, 22 December 2009 (UTC)

You're not assuming good faith. You're wrapping yourself up in the cloak of WP:AGF while very obviously implying that there is some sort of cabal trying to suppress your noble crusade against oppression and corruption. Quit it. For the sake of argument, what do you think is still missing from this proposal, and what effect will your anticipated changes have on the likely outcome? If you can't give a substantive answer to that, then there's no reason not to have this vote. Why waste the time of good people over the holidays on a proposal destined to die?

It's worth noting that the only time you've been prepared to give serious consideration to requests for details and examples is right now — after someone has posted a 'put up or shut up' motion to close. I raised Wikipedia:De-adminship proposal checklist weeks ago, and got no constructive response. Heck, you even decided that objections should be archived instead of answered (and buried them under a 'shut up we have consensus' mockery of a Q&A in a special 'complaints' section). Well, now you have to prove that the community endorses your continued attempts here. TenOfAllTrades(talk) 21:50, 22 December 2009 (UTC)

Ben, if some editors want a vote on this, let's go with it. Alert the media, etc. etc. Let's find out, despite the length of time it's going to take due to the holidays, just who wants to support this proposal's ongoing process. If New Year's comes and goes, and we don't have a reasonable mandate to continue, we wouldn't get far anyway, so let's consider this as a blessing in disguise, shine as big a light as possible on this, and let the chips fall where they may. Happy Holidays, everyone! Jusdafax 21:57, 22 December 2009 (UTC)

Well said! ~~ Dr Dec (Talk) ~~ 23:22, 22 December 2009 (UTC)

This occurs to me: what effect would this motion, really, have? Telling editors: "oh, no, you have to stop working on this, and no matter what edits you make to the draft proposal, you may never ask other members of the community what they think of it!"? This motion appears to me to come from a place of fear. Let's all stipulate to the fact that there are editors who are going to !vote "oppose" to whatever proposal comes out of here. But why have that !vote now, when the draft isn't finished? The only reason I can see is to prevent any proposal from reaching the community. Anyone who believes that this proposal is bad, please understand that you will have an opportunity to oppose it. You don't need to shoot it down before it is even finished. --Tryptofish (talk) 00:25, 23 December 2009 (UTC)

What it says is that you don't have consensus for the proposed change. Durova³⁸⁶ 00:47, 23 December 2009 (UTC)

Could we please stop insulting editors by telling them that they oppose this proposal out of some sort of poorly-articulated 'fear'? That's playground taunting, not rational discussion. I think it's a bad proposal, generated by a broken development process. I oppose it on that basis, not because I'm afraid that the Big Bad CDA Monster will come after my admin bit. Perhaps you could offer an answer to the question I posed for MacDui (who hasn't responded) — what do you think is still missing from this proposal, and what effect will your anticipated changes have on the likely outcome? If you can't give a substantive answer to that, then there's no reason not to have this vote. TenOfAllTrades(talk) 00:52, 23 December 2009 (UTC)

Firstly: this is a discussion about the motion to close this whole draft RfC. So those that "oppose this proposal" are those that oppose the closure of this draft RfC. Ten, you actually support this proposal, i.e. you support the closure motion. Secondly, and this isn't a typo: this is a discussion about the motion to close this whole draft RfC − not about whether the idea of a de-sysoping protocol is a good idea. You might think that a de-sysoping protocol is a bad idea, but that doesn't mean that you should endeavour to close all discussion on the matter. Can you see the distinction: saying that you don't like the ideas put forward in this draft RfC is exercising your right to free speech, supporting the closure motion is trying to deprive others of their right to free speech. ~~ Dr Dec (Talk) ~~ 01:03, 23 December 2009 (UTC)

It seems that you're confused about what I'm saying. I oppose this proposal (for CDA), but I support the extant motion (to close this purposeless policy proposal).

I don't know where 'free speech' enters into this. Presuming that this entire discussion actually has the ultimate aim of generating a proposal (through community consultation) which will be accepted or rejected by the community, there must logically come a point where the discussion ends and the proposal is evaluated. What this motion says is this — we have reached that point, and the discussion has apparently run its course; can the community see anything salvageable going forward here? I would have thought that this proposal's proponents would want to know the answer to that question. (Incidentally, no one has yet offered any answer to my question about what significant portions of this proposal are still in question, or what changes might be made before their 'final' version was presented to the community. Why is it that no one can answer that?)

Any suggestion that this motion represents an attempt to permanently suppress, for all time, any further discussions or new proposals for de-adminship protocols is patently ridiculous. Despite a dozen or so previous, failed attempts to generate such a process, this discussion was allowed to go on for months until lurching to the current motion. I'm sure that someone will make another proposal (possibly based on these discussions) next year, and I expect that it will die too. TenOfAllTrades(talk) 01:29, 23 December 2009 (UTC)

I understand you perfectly well. You "oppose the proposal" (for CdA) and "support the extant motion (to close this purposeless policy proposal)" Quite simple really: you don't like the idea and you don't want people discussing the idea. This motion says that "...this page ought to be closed..." That is all encompassing. There are many sections and subsections to this page. They discuss many aspects of this whole de-adminship idea. Yet the closure proposal aims to close the whole page: everything! No-one will be able to express their opinions on any of the issues raised here, because the page will be closed. If they try to start the discussion elsewhere then it'll get closed there because we would have already set the president of closure. I'm sure that, after some thought, you will agree that this is not at all "patently ridiculous"; it is a very real possibility. This, IMHO, denies people their right to free speech. ~~ Dr Dec (Talk) ~~ 01:48, 23 December 2009 (UTC)

The Doc raises some points I had not considered. Sobering stuff. Jusdafax 01:58, 23 December 2009 (UTC)

There's no right to free speech here. This is a private server run by a private organization. Gigs (talk) 02:14, 23 December 2009 (UTC)

I am not going to full protect Wikipedia:Arbitration/Requests/Case right now, even though I feel the Giano mess is a big distraction that is sucking up a ridiculous amount of time that could be much better used elsewhere. If you dislike this idea, why not simply let this proceed until the full RfC begins, and oppose then? Perhaps the rest of the community feels differently from your (the generic supporter of this motion) view of the "The current process (RfC, and if that does not work, ArbCom) basically [working] fine." NW (Talk) 02:54, 23 December 2009 (UTC)

Fair enough, but "the rest of the community" is an amorphous, non-specific whole.

Let's get specific and do some real work. :-)

What are your personal concerns? Can those concerns be translated into realistic requirements? Would you be able to propose solutions for those requirements? --Kim Bruning (talk) 14:59, 23 December 2009 (UTC)

It's interesting to see 50/50 support/oppose on this. --Kim Bruning (talk) 02:52, 23 December 2009 (UTC)

It would be more interesting if those wishing to continue the discussion had not been systematically canvassed. Jehochman ^{Make my day} 14:48, 23 December 2009 (UTC)

I do not believe in the concept of canvassing. --Kim Bruning (talk) 14:54, 23 December 2009 (UTC)

It is interesting but I'd like to remind us all that this page's intention is to refine the CDA proposal to improve its prospects of success. Despite the verbiage produced to date it is still not clear how this motion is relevant to that end. I respect the views of those who don't want the proposal to succeed, but this motion is, so it would seem, an attempt to prevent the question as to whether the community wants it or not even being asked. When we get there, if the arguments are persuasive, I might even !vote "oppose" myself. Right now however such discussion is simply an irrelevance and a distraction. Ben MacDui 09:20, 23 December 2009 (UTC)

Proposing the closure of this on any basis is nonsense. It is a DRAFT and could just as easily be taking place on someone’s talk page. Try closing it there if anyone dare. Leaky Caldron 11:40, 23 December 2009 (UTC)

• As for administrator COI; this is bollocks. Anybody who wants to see an admin lose a bit would also have a COI; they want the process so they can use it. Well, I guess that excludes all of us from the discussion! No, every member of the community is entitled to have a say in policy, most certainly including those who would be affected by the policy. Jehochman ^{Make my day} 14:48, 23 December 2009 (UTC)

I agree that anybody who wants to see an admin lose a bit would also have a COI but I disagree that that excludes all (or some) of us from the discussion. Opinions of the admins should be taken into accounts, but their COI should also be taken into accounts especially in closing the discussion. Sole Soul (talk) 15:25, 23 December 2009 (UTC)

That COI should be taken into consideration just as much as non-admin COI. Bottom line is that having an opinion is absolutely fine. Remember, this is not an article, this is a discussion about policy, and how can anyone opine if they do not have an opinion?! Perhaps, admins having experience in admin work have a perspective that non-admins do not have? Also, reductio ad absurdum, being that this is a policy about wiki editors, why doesn't every wiki editor have a COI according to your logic? Lastly, with only 1600+ admins and hundreds of thousands of editors, I am not that concerned. -- Avi (talk) 16:06, 23 December 2009 (UTC)

Admins will always exist, so I don't see how non-admins have COI. Opinions are fine but we need to be transparent and say this is the opinion of an admin and this an opinion of non-admin. Finally, admins are disproportionally represented in policy discussions, so I'm concerned. Sole Soul (talk) 17:00, 23 December 2009 (UTC)

Wait, what? Of course they are disproportionally represented; pretty much by definition the editors who care about such maintenance tasks as managing policy (including its crafting) are the very editors most likely to want the bit and get it. Editors who don't care about such things are unlikely to even try to be admins. This is like being concerned because doctors of medicine are disproportionally represented in hospitals! — Coren ^(talk) 01:59, 24 December 2009 (UTC)

Please read Avi's last sentence. Sole Soul (talk) 10:51, 24 December 2009 (UTC)

I've no clue as to what this Draft is about. It'll take me days to read up on 'everything', to figure it out. GoodDay (talk) 15:09, 24 December 2009 (UTC)

I have strongly suggested that the actual draft guide be updated in the normal wiki fashion as consensuses emerge, but I keep getting shot down on that idea. This idea of formulating everything as a bunch of polls and then making a big update to the draft guide in the end does not sit well with me, and makes it nearly impossible for anyone to see what the current state of consensus is. Gigs (talk) 16:44, 24 December 2009 (UTC)

I agree, Gigs. I'm now convinced we should expedite this process. The last week, due to the 'Motion to Close', has brought new eyes to this page, so let's get the entire current proposal as it now stands up on the table for easy review, with areas still under debate in colored font. I'm not sure who has been doing the grunt work in that department (my thanks to them, by the way) but any competent coder could handle it. Let's take a look at what we've got and see if we can't wrap this up by the proposed early Jan. timeframe, and then as I now see it, just put the finished product before the community. Jusdafax 17:15, 24 December 2009 (UTC)

I've done you a favor by bringing in a lot of fresh eyes. I suggest you set up an archive for this page, move off the old discussions, take note of the feedback received and see if you can craft a proposal. My advice is to take stock of where we are now and try to make an incremental step forward using existing processes. That has a chance of succeeding. I'm very sympathetic to your goals here. My concern is that the process has become excessively convoluted, and that new eyes can't be bothered reading such complexity. Jehochman ^{Make my day} 21:27, 24 December 2009 (UTC)

Please see my reply to Tryptofish at the very bottom of this page, thanks. Jusdafax 21:50, 24 December 2009 (UTC)

Next steps

The "default position" as described above is that this discussion process will continue until 8pm GMT on Monday 4th January 2010. At that point:

• if sufficient consensus has been reached a version of the RfC will go live as a formal proposal for community consideration, or
• the time period for discussion will be extended to allow a greater degree of consensus to emerge, or
• the process will be dropped.

Comments and alternative suggestions are welcome.

I think the purpose of this stage is to draft the best possible proposal to put to the community in an RFC. We need to pro-actively approach people involved in the debate and get them to raise objections so we can work through these. I suggest the next step should be more definitive:

Between now and 8pm GMT on Monday 4th January 2010, discussion will continue to refine the proposal to address the concerns raised.

• if sufficient consensus has been reached on the details the RFC will go live as a formal proposal for community consideration, or
• if further discussion would be useful, it will be extended

AndrewRT(Talk) 11:58, 22 November 2009 (UTC)

I've no objection to that. Ben MacDui 19:47, 23 November 2009 (UTC)

I also agree: it's more constructive that way. --Tryptofish (talk) 20:50, 23 November 2009 (UTC)

No objections so 'twill be done in next edit. Ben MacDui 20:59, 27 November 2009 (UTC)

Wording of the Actual RfC

This page is already very long and I suggest creating Wikipedia:Community de-adminship/RfC Strategy or similar to begin the discussion. Arguably this is premature, but it has to begin sometime and requires some clear thinking. Ben MacDui 14:46, 28 November 2009 (UTC)

Page created. Ben MacDui 16:10, 29 November 2009 (UTC)

Proposal to Refactor this Page to Focus on Drafting RfC

A lot of comments on this draft RfC page are off topic. I propose refactoring the page so as to remove superfluous discussion not directly concerned with improving the proposed RfC so that interested parties can focus on improving the draft rather than talking about irrelevant motions to close, motions to close motions to close, and talking about streamlining instead of actually streamlining. Naturally this section making the offer to clean this page up would be removed as well. In my opinion everything from the Motion to Close section down is extraneous and can be removed. Does anyone have a problem with that? Lambanog (talk) 17:12, 24 December 2009 (UTC)

Yes. The proponents of this proposal have regularly attempted to remove all criticism from this talk page. It's a mockery of community consultation. They keep asking what Wikipedia's admins are afraid of in this proposal, but are unable to handle a little bit of light shone on their own work. Embarrassing double standard. TenOfAllTrades(talk) 17:37, 24 December 2009 (UTC)

Not at all. This is a draft page. Open-ended criticism and side discussion can be easily accommodated in a subpage for that purpose. Constructive criticism is reflected in which proposals are accepted and rejected. By the way, I didn't find your comment clear. Are you making a comment in favor or disfavor of refactoring this page or simply making a comment? Lambanog (talk) 18:06, 24 December 2009 (UTC)

We shouldn't care about what the admins are afraid of, the adminship is not something they earn because it is not a reward. We should care about what is best for the project. Sole Soul (talk) 21:05, 24 December 2009 (UTC)

move to other place instead of remove. The problem: this is a talk page, so move to where? Sole Soul (talk) 21:06, 24 December 2009 (UTC)

If you don't accept open-ended criticism during the formation of the draft, then it is unlikely that the draft will be anything the community will accept. I hardly think that those disagreeing with the proposal are off-topic or superfluous, they have as much say in this proposal as anyone else. I suppose if this was a draft by one person in their userspace such an argument could be made, but this supposedly a draft that is being produced by the community in the Wikipedia namespace. The fact that many people are objecting to the proposal is very relevant and should not be swept under the rug. Chillum ^{(Need help? Ask me)} 21:02, 24 December 2009 (UTC)

I'd love to focus more on improving the document. But, as much as I am dismayed by the motion to close, and as much as I agree that an awful lot of recent discussion has been off-topic, I say that we should slow down on archiving stuff. In fact, we may have already archived too much. Please let everyone with something to say, say it. The more criticism we can get now, the more we can improve what comes out, and, if we do that right, the less criticism we will get later. --Tryptofish (talk) 21:25, 24 December 2009 (UTC)

I have to agree, Tryptofish. Let's keep what we have here and finish up in the next couple weeks. I do support Gigs' note above that the entire proposal, as it curently stands, should be available and easy to read. Perhaps a subpage, with multiple postings of the link, is the way. Also, if possible, sections we are not resolved on to be placed in a colored font. Thanks to you or whoever carries the water in that department. Jusdafax 21:47, 24 December 2009 (UTC)

Maybe you could set up an archiving bot to move any sections untouched for the last 7|14 days to an archive subpage. That's a good, neutral way to keep a talk page organized. Maybe take stock of all the comments above, and create a new proposal down at the bottom in a new section. Distill, summarize, and start a fresh thread that people can follow without having to reference everything above. I personally like my proposal the best. <smile/> You've got a lot of fresh eyes here. Take advantage of them. Jehochman ^{Make my day} 22:06, 24 December 2009 (UTC)

Lambanog: So do you propose to hold a poll on closing a discussion that mentions holding a poll to close the poll to close the poll to create a proposal? ;-)

I'm sure you're kidding!

In the mean time, I'll look into moving and refactoring sections to a new page after christmas, if you insist. But then it'll be a race to see which process gets implemented first, as opposed to cooperation on somehow salvaging this one. Is it on? ;-)

Note that I didn't claim to want to talk about merely streamlining, someone else made that a pretty section heading. We've been looking into what can be implemented NOW. Not next month, or next year.

Currently Jehochman has already implemented some improvements to RFC procedure, based on discussion held here. I'm asking people to put forth further ideas on improvements we can implement short term, see relevant section. --Kim Bruning (talk) 03:11, 25 December 2009 (UTC) Tip: before accepting a challenge, I recommend reviewing the fate of former bureaucratic redoubts such as Wikipedia:Wikirules proposal, WP:AMA, WP:Esperanza. I always *do* try to salvage things first! It's just very difficult to turn around a bureaucracy before it's too late; due to the resistance to change inherent to bureaucratic systems.

I said that I would comment here a couple of weeks ago, but... well, the fact is that I still haven't slogged through the often stilted, and decidedly Byzantine, commentary throughout this talk page. This is a towering example of process, seemingly for it's own sake, run amok. I don't intend to insult anyone who has participated here, especially since I can easily see that there are good intentions among all participants. The fact remains that the prestu-parliamentary procedure being used here is slightly rediculous, and is certainly not very approachable. The point being, I support anything that makes this talk page more "user friendly".
— V = I * R (talk to Ω) 18:36, 26 December 2009 (UTC)

Ouch. (I guess an easier approach would be to make me the absolute dictator and... oh, never mind.) Suggestion: please go to the (very brief) "quick links" section at the top of this page, read what it has there, and then go to whatever is of interest to you. I hope that helps. --Tryptofish (talk) 18:43, 26 December 2009 (UTC)

Dictators are kind of messy. Somewhere down the line we have this post called "Coordinator"; Coordinators are often quite effective! I would appoint you coordinator "by the power invested in me" (to wit: the power of my big mouth ;-)); buuuut we'd have to discard most of the current page to make that work. --Kim Bruning (talk) 03:22, 27 December 2009 (UTC)

Ouch to that too! --Tryptofish (talk) 14:40, 27 December 2009 (UTC)

heh, I didn't really mean to stomp on you, or anyone in particular. I will say that most online communities benefit greatly from the presence of "benevolent dictators" (or facilitators, or coordinators, whatever), as long as the person in such a position is responsible. Wikipedia, however, seems to have developed a cultural aversion to such developments, so I wouldn't recommend trying to take that position here.

Regardless, I think that the biggest issue with the page is that there's simply too much going on all at once. We should strive to stick to one issue at a time, as much as possible.
— V = I * R (talk to Ω) 20:20, 27 December 2009 (UTC)

But I didn't say "benevolent" (sound of evil laughter). Anyway, do we have a community recall process for dictators? --Tryptofish (talk) 15:11, 28 December 2009 (UTC)