Wikipedia:WikiProject Administrator/Admin Recall

WikiProject Administrator (subpages)
General information Main project page talk Community de-adminship WP:CDA draft RfC talk Draft Guide to De-Adminship talk Related Pages Wikipedia:Administrators talk Wikipedia:Administrators' noticeboard talk

This Request for Comment discussed a number of proposals for removing Administrator rights - otherwise known as Admin Recall.

A poll was held on fourteen proposals, and closed on 16th November 2009. Only one proposal gained majority support - community de-adminship - and this proposal is now being finessed into a draft RFC Wikipedia talk:Community de-adminship/Draft RfC, which, if adopted, will create a new process.

Purpose

The community appoints administrators through a process known as RfA. A number of recent discussions and a lengthening list of Former administrators who have laid down their mops for one reason or another suggests that some process for recalling admins who do not meet expected standards is overdue.

Advocates for such a process argue that since the community grants the access to admin tools, the community should also have some process for revoking that access. At present there is no such process and ArbCom are reluctant to take on this issue, some members seeing it as falling outside of their brief. It may also help (some) administrators to gain a clearer understanding of what is expected of them.

Please note that this idea is not the same as Administrators open to recall, which is a voluntary process.

Summary

Recall proposals generally consist of the elements:

• Initiation when some objective criteria is reached (such as requiring X number of uninvolved editors, X number of admins, X number of arbs, or Arbcom as a whole)
• A period of time in which the community provides feedback by the form of !votes (akin to RFA)
• Closure by a trusted authority (such as a bureaucrat, arbitrator, or arbcom as a whole)

The key to a successful process is likely to be finding a way to

a) enable the community to discuss and where necessary enact an admin recall where there is a broad consensus that this is appropriate, whilst

b) avoiding frivolous or malicious requests.

It should borne in mind that some editors take the view that administrators "look after one another" and use their knowledge of the system and previously good track records to avoid sanctions that might fall on less experienced editors. Some also believe that whilst this does occasionally happen, it is a relatively infrequent occurrence when weighed against the volume of work undertaken by administrators.

There is also another side to the coin. Many administrators take on duties that by their very nature are likely to disappoint or anger some editors. If closing controversial discussions or attempting to enforce agreed sanctions turns into a recall process on a regular basis, few administrators will wish to take these tasks on, and indeed fewer editors may wish to become administrators.

The results of the poll were:

No	Name	Support	Oppose	Neutral	Majority	Percentage
0	The status quo	13	44		(-31)	23%
1	Wikipedia:Requests for de-adminship	8	21	1	(-13)	28%
2	User:Tony1/AdminReview	10	20		(-10)	33%
3	Wikipedia talk:WikiProject Administrator/Admin RFC draft	15	18	1	(-3)	45%
4	Wikipedia:Community de-adminship	26	13	1	13	67%
5	Wikipedia:Declaration of no confidence	5	16	2	(-11)	24%
6	Make CAT:AOTR mandatory	1	27		(-26)	4%
7	User:Sandstein/Reconfirmation RFA	6	22		(-16)	21%
8	Straightforward reconfirmation	9	18	2	(-9)	33%
9	Admin reconfirmation	5	7	2	(-2)	42%
10	User:Tim Smith/Administrator-initiated recall	4	14		(-10)	22%
11	AdminRFC+RFA	5	6	2	(-1)	45%
12	Reconfirmation initiated by the Arbitration Committee	5	10	3	(-5)	33%
13	Signatures prompt RFA + extra safeguards	6	6	2	0	50%
14	Regular recall schedule	1	2	4	(-1)	33%

Options

Option 0: The status quo

That is, no formal admin recall process

Requires no action at all to enact

Does not address the presenting issue

Option 1: Wikipedia:Requests for de-adminship

Drafted by Roux (talk · contribs)

Easy to understand

Threshold for commencement - a single user

The RFDA must then be certified by any two administrators

A single Bureaucrat makes a determination

Note: Contains a list of previously "Proposed processes"

Option 2: User:Tony1/AdminReview

Created by Tony1 (talk · contribs)

Most complex proposal

Threshold for commencement - a single user "who was involved in the incident"

A "Managing Coordinator" (who must be a non-admin) determines whether a complaint is accepted for investigation.

Detailed management of procedures

Details of expected Admin behaviours

Determination: The Managing Coordinator and an additional coordinator. If they do not reach agreement on the decision and recommendations, the case moves to a review by all available Coordinators, who make a determination by simple majority.

The Coordinators are elected by popular vote for staggered terms of 12 months.

Option 3: Wikipedia talk:WikiProject Administrator/Admin RFC draft

Per Beeblebrox (talk · contribs)

Clear statement of purpose

Easy to understand

Threshold for commencement - a single user

"Any previously uninvolved user" makes a determination

Option 4: Wikipedia:Community de-adminship

Devised by Uncle G (talk · contribs)

Very clear about what the recall is NOT for.

Mirror image of RfA, so easy to understand

Threshold for commencement - either by Arbitration Committee or by "10 editors in good standing"

Adds to Arbcom workload

A single Bureaucrat makes a determination

Option 5: Wikipedia:Declaration of no confidence

Devised by Skomorokh (talk · contribs)

No new process or policy required

Has precedent

Deals with concerns with administrators that might otherwise go to Arbitration through RfC – thus devolves some ArbCom power to the community

Non-binding – ArbCom make the final call

Option 6: Make CAT:AOTR mandatory

That is, adopt the processes and procedures of this category (perhaps mandating use of the default recall process if an admin hasn't chosen a different one, and perhaps circumscribing exactly what a non default recall process can have in it) as mandatory rather than voluntary

Pros

We have some experience with how this process works (see Wikipedia:Administrators_open_to_recall/Past_requests)

Cons

The experience we have hasn't been uniformly positive :)

Option 7: User:Sandstein/Reconfirmation RFA

Any administrator is made subject to the requests for adminship process (RFA) for the purpose of reconfirming their administrator status if one hundred users who are eligible to participate in RFAs request it.

Pros

• Builds on the existing RFA process (accepted for determining community trust) as much as possible – no new bureaucracy.
• Follows the KISS principle.

Cons

• Builds on the RFA process perceived by some as broken.
• Possible Sword of Damocles feeling produced by a running count of signatures. This may be perceived as a positive effect by some.

Option 8: Straightforward reconfirmation

• An administrator is subject to a reconfirmation RfA, using the same standards as a normal RfA, if a user in good-standing requests it.
• Like a typical RfA, the end result is determined by an uninvolved bureaucrat.

–Juliancolton | ^Talk 13:57, 25 October 2009 (UTC)

Option 9: Admin reconfirmation

Drafted by Jake Wartenberg (talk · contribs)

• Admin conduct RfC is conducted as normal.
• Bureaucrats discuss as to whether reconfirmation is needed and vote.
• If there is a majority (50%), admin has two weeks to either put up a new RfA or resign.
• Move bottom of discretionary range for reconfirmation RfA from 70% to 65%.

Pros

• Simple
• Does not add more processes/bureaucracy

Cons

• Not what we elected the 'crats for
• Admin must go through both RfC and new RfA

Option 10: User:Tim Smith/Administrator-initiated recall

Any administrator may nominate another administrator to be reconfirmed by the community at RfA.

Pros

• Simple; uses an existing venue and nomination system (RfA); no complicated rules.
• No appeal to a nebulous concept of "good standing" or arbitrary edit count requirements.
• Frivolous requests are filtered out because the recall initiator must be an administrator; on the other hand, if an admin has truly lost the community's trust, then at least one of Wikipedia's 848 administrators would step forward to recall them.
• Any administrator who abuses the process by making vindictive requests would eventually be nominated for recall themself for misuse of their position, so the system should be to some extent self-correcting.

Cons

• Ordinary users become second class citizens when they are already most vulnerable to abusive admins.
• Admins not the only ones with grievances and common sense.
• Potentially shuts out non-admins with a grievance - esp if admins collude (common fear/perception).

Option 11: AdminRFC+RFA

KISS (Keep It Simple, Stupid). Also, don't set the bar too low to discussion and don't exclude other remedies or outcomes from discussion by over-focussing on de-sysopping.

• Admin RFC (WP:RFC/U), as at present.
• If the outcome of the RFC is the community's consensus view that a reconfirmation RFA is required, as opposed to some other action, then an uninvolved admin should file one (if no uninvolved admin volunteers, an RFA should be requested at WP:ANI; if no-one can be found to do it, the request is presumed not to be sufficiently supported by the community).
• Reconfirmation RFA

Option 12: Reconfirmation initiated by the Arbitration Committee

Proposed by Cenarium (talk · contribs)

The Arbitration Committee may initiate a reconfirmation of adminship when they find - based on evidence by users requesting the reconfirmation, a RFC/U, or through the course of an arbitration case - that the user's administrator status may likely no longer be sufficiently supported by the community and all prior steps of dispute resolution failed. ArbCom should write a summary of the situation and give their reasons to open the reconfirmation, then open the reconfirmation; any involvement ceases thereafter.

The reconfirmation should determine whether there is consensus in the community to retain adminship; if there is no consensus to retain adminship, the rights are removed. The format is retain/remove/neutral; after a week of voting, there is a discussion among uninvolved bureaucrats to determine the state of consensus, then it is closed based on it.

• Relies on the analysis and judgment of the Arbitration Committee to avoid abuse of process and ensure that there is good cause to start a reconfirmation, they are trusted to analyze and judge in such cases
• the final decision rests in the hands of the community, with bureaucrats determining community consensus, one of their natural role

Option 13: Signatures prompt RFA + extra safeguards

Proposed by Alecmconroy (talk · contribs)

Initiation, signatures expire and must include admins

• Initiation requires 30 signatures.
• Signatures expire after 7 days.
• Signatures must include at least 5 admins.

RFA, but easier

• RFA conducted as usual
• At closure, Crat has great discretion to declare success
• Borderline at 50% support
• Success at 65% support

Ultimate Safety Valve

• Failed RFAs can still appeal to Arbcom to restore adminship.

There may be more popular values than the ones listed here.
If you could support this with alternate numbers, please shout them out.

• Jump to opinions on this option.

Option 14: Regular recall schedule

Proposed by John Carter (talk · contribs)

The core of this proposal is to, basically, create a standard timeperiod for recall/reconfirmation to take place. I think it might be easiest on all involved if there were a given regular period, say, for example the first of the month, when individuals who have received a request for recall could all file at the same time, and all be listed on one page with links to the relevant discussions. Having such a regularly scheduled recall period would be one way for the recall petitions to get some degree of notice from interested editors, and might make it easier for any parties who wish to recall a given admin to have their request taken seriously. The one obvious disadvantage is that it would make it easier for trolls to try to recall any number of admins, but I tend to think the trolls might also stand out a bit more clearly under such circumstances.

It might also be possible to have some sort of semi-official neutral "examiners", probably admins, to look over the complaint(s) and see if they are valid. Recall/reconfirmation could begin when the requirement for a set number of signatories is met and over half of the examiners have indicated that they believe that the nature of the complaint is a fair one. With the number of admins out there, I don't think it would be that hard to find perhaps five admins who are capable of being neutral on the subject and reviewing the nature of the claim against the candidate for recall.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Opinions

Please express your preferences for the options described above in the appropriate section below. If you choose to support more than one option please make it explicit which one is your FIRST choice, SECOND choice and so on. You may also express opposition to ANY NUMBER of the options. By all means add a sentence explaining your view. Longer statements should be made on the talk page.

If a clear consensus emerges this will be followed by a detailed policy proposal (not immediate enactment of any particular system).

Option 0 (Status quo)

Support (Option 0)

1. Record numbers of desysopped admins in recent months shows that the arbitration committee is able to and willing to tackle poor admins. Anything else is a recipe for petty vendettas and abusive requests. Spartaz ^Humbug! 13:59, 25 October 2009 (UTC)
2. I agree with Spartaz—all proposals look like solutions in search of problems. In addition, half of them are simply impractical. Ruslik_Zero 14:58, 25 October 2009 (UTC)
3. This RFC is an irrelevant distraction. As well as the evidence of recent Arbcom cases showing that we as a community are already quite capable of desysopping admins; The biggest problem we have with adminship is that the number of active admins is falling by 1% a month. The second biggest problem is that we don't have an ongoing training/mentorship program to make sure admins are using their tools appropriately. Human beings will make mistakes, taking away the mop is an extreme measure and we need systems for handling mistakes where a desysopping would be grossly disproportionate. Currently we only have wp:trout, we need to invest far more in training new admins and refreshing the training of existing admins, desysopping should be a rarely used penultimate resort. Focusing on desysopping would be like supervising car drivers solely by removal of licences with no training and no lesser penalties. ϢereSpielChequers 16:17, 25 October 2009 (UTC)

   There are good thoughts here, and I don't want to beat up on the minority just because it's easier than beating up on the majority, but my problem with arguments like "It would be better if we do a training/mentorship program" is that I've never seen any interest in this. It's easy to understand why; it would be a lot of work, and make people responsible for training other people; there's no interest in vetting, much less training. People are more interested in offering commentary on performance ... and of course, we'd prefer that it just stay at the "commentary" level and not progress to the "desysopping" level ... hopefully that's how it will work. With respect, Ruslik, I don't think we can say there's "no problem", because the stringent standards at RfA have often been attributed to the lack of a procedure that might lead to a decision by the community (as opposed to Arbcom) to desysop; stringent standards are a problem, although we would have to run the experiment if we want to see whether these proposals will help.

   You often hear that WT:RFA has never accomplished anything, but helping with debates like this one is exactly what we've accomplished at WT:RFA over the years; we know what's not likely to get anywhere, so we can start the discussion with that knowledge. - Dank (push to talk) 20:22, 25 October 2009 (UTC)

   Dank, I know that several discussions at RFA have been turned into discussions about the alleged need for a desysopping system, so I'm well aware that some people consider that the lack of a desysopping system is the cause of RFA being broken. I agree that the declining number of active admins and the 18 month drought in new admins is compelling evidence that RFA is broken. But I disagree with the prescription that a desysopping system would help solve the problems at RFA. Concerns about desysopping predate RFA breaking in the spring of last year, and there is a distinct dearth of evidence that the sort of behaviour that leads to desysopping is screened for at RFA. If anything the two processes are increasingly divergent; when Law was desysopped one of the only two editors with the good judgement to oppose both his RFA and Pastor Theo's was having his RFA tanked, mainly for concerns about his judgment. ϢereSpielChequers 10:08, 26 October 2009 (UTC)

   To WereSpielChequers, what kind of lesser penalties would you propose? And have you ever made such proposals before? Equazcion (talk) 05:14, 26 October 2009 (UTC)

   Lesser penalties could range from admonishment, retraining and apologies, an admin agreeing not to use particular tools or not use the tools in a particular area all the way to a temporary desysopping. As for my advocacy of that, I've probably raised it at wt:rfa, and I was the initiator of WP:NEWTREAT which is running some live tests to identify the problems of mistreatment of newbies by speedy deleters in the article creation process. ϢereSpielChequers 09:37, 26 October 2009 (UTC)

   We're talking about a binding process here, though, which the community obviously sees some basic need for. How about a binding process that results in these lesser penalties? Would you care to add a new option on this page for something like that? I'd be interested to see your suggestions. There's no rule that says this page must only be for de-opping (aside from the title, but I don't think you'll get significant complaints). Equazcion (talk) 16:43, 26 Oct 2009 (UTC)

   What is obvious to you may not be obvious to me. I have commented on a number of the options set out and one of my suggestions has been accepted. I've also drafted some thoughts of my own. I doubt that a proposal 10 this late in the day would get much attention, but if this comes back again in another six months or so I may dust off my thoughts and make a proposal. ϢereSpielChequers 19:18, 26 October 2009 (UTC)

   I disagree, I think many people would like to hear about the possibility of a middle ground, rather than having to choose for or against a de-op procedure. I for one think that's a novel idea and would be paying attention. But it's up to you. Equazcion (talk) 19:29, 26 Oct 2009 (UTC)

4. Who exactly are all these people needed "recall" who are not being desysoped? I am still not convinced a problem exists. Every so often I see the pitchforks go up and a few people demand the bit of some guy who made a mistake, but I have never seen a case where the community came to a consensus to desysop someone and arbcom had not already done it. We need our desysoping process to be base on evidence applied to policy, not the shifting moods of the mob. I don't think voting on a change is a good idea either, any change should be based on an actual need not a straw poll. Chillum 14:31, 26 October 2009 (UTC)
5. We have a more reactive arbcom, with a larger and more responsive support staff (OS/CU). We have a process, called rfAr, and ArbCom has not been afraid to remove the admin bits recently. As sysops, we are forced to make edits that upset one or another group at times. Further, any sysop who, as an editor, enters one of our more "difficult" areas, should any form of forced recall be institutued, will now have to worry about "revenge nominations". With the current process, at least we have the security of knowing that the people whom we vote are the most level-headed and fairest in the project will be the ones responsible for investigating any claims. -- Avi (talk) 16:03, 26 October 2009 (UTC)
6. This option's description is deceptive to the point of falsehood. There is quite a large body of extant policy, practice, and precedent for filing a request for Arbitration. While RfArb is a process that has broader application than just desysopping, to assert that it is not a formal admin recall process or that it does not address the present (poorly-described) issue is, respectively, false and extremely debatable. Users offering a novel proposal for de-adminship should review my Wikipedia:De-adminship proposal checklist, particularly the section on 'utility'. TenOfAllTrades(talk) 16:22, 26 October 2009 (UTC)
7. This RFC is stupid. WP:RFAR is that-a-way. -- Y not? 18:35, 26 October 2009 (UTC)

   Thanks for dropping by and taking the time to insult everyone who put time and effort into this. WP:DICK is thataway. Beeblebrox (talk) 22:52, 26 October 2009 (UTC)

   IMHO, it appears that getting the required votes to start a requested arb is not as easy as you would suspect (given in part the number of people voting).--Epeefleche (talk) 06:22, 27 October 2009 (UTC)

   I love you too, Beebzie. Frankly, the people who put time and effort into this badass dramz-fest may be in need of a little insulting. Some of us take their Wikipedic activities a trifle too seriously. -- Y not? 15:05, 27 October 2009 (UTC)

   And what's more, as a person who put time and effort into this, shouldn't you be listed at CAT:AOR like I am? lol -- Y not? 15:08, 27 October 2009 (UTC)

   I only got involved in this because so many users seem to want a process of this type, and I wanted to insure that whatever came out of it was fair. And AOR is a toothless farce, that's why we're here. Beeblebrox (talk) 19:56, 28 October 2009 (UTC)

8. I haven't seen any compelling argument that changes are required in this area, which isn't to say an additional process might not be useful. Christopher Parham (talk) 14:37, 27 October 2009 (UTC)
9. This seems like unnecessary WP:CREEP to me, the ArbCom is doing a fine job tackling poor admins, and is more than willing to desysop if necessary. Best, Mifter (talk) 23:56, 27 October 2009 (UTC)
10. I appreciate the time put into this, but RFAR does not appear to be broken in this regard and a mandatory admin recall procedure would, in my opinion, lead to an increase in the level of frivolous or vexatious requests. Stifle (talk) 09:36, 29 October 2009 (UTC)
11. ArbCom seems willing (and more willing of recent) to desysop those who misuse administrative tools. An ArbCom case, due to its length, forces a type of "cooling off period", in which tempers (hopefully) cool as the events go farther in the past, each party presents evidence (not simply assertions) of misconduct, and a body used to dealing with often tangled disputes makes the final decision. It's not perfect, but nothing is, and I really don't see anything here that convinces me it'd be better. Seraphimblade ^{Talk to me} 05:26, 1 November 2009 (UTC)
12. Current process seems to have the right balance. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
13. per the arguments of Spartaz and WereSpielChequers Polargeo (talk) 10:20, 12 November 2009 (UTC)

Oppose (Option 0)

1. Ben MacDui 19:53, 22 October 2009 (UTC) Per comments by Beeblebrox below - yes, the red link !votes are just tests. Now removed.
2. The fact that there are so many proposals and they date back years is evidence enough that the status quo is not accepted by large portions of the community. Beeblebrox (talk) 20:18, 22 October 2009 (UTC)
3. Too many bad apples who will never be rooted out under the status quo. It is a travesty that the community is trusted to judge whether or not an editor ought to be made an administrator but not to judge when they are no longer fit to be one.  Skomorokh, barbarian  01:06, 23 October 2009 (UTC)
4. Whatever we do, the status quo should not be it. --Tryptofish (talk) 19:10, 23 October 2009 (UTC). As I have been reading the comments in support of the status quo, I note the frequent statement that the present system is already dealing with all the problems. I urge editors who feel that way to read this, and consider that there are some (not many) admins who do not make "bright-line" violations, but who nonetheless have lost the community's trust. I feel that it is obvious that such admins exist and are not adequately dealt with. --Tryptofish (talk) 23:56, 2 November 2009 (UTC)
5. Completely agree with Skomorokh. --Malleus Fatuorum 17:09, 24 October 2009 (UTC)
6. The process needs to change from what is happening now. ~~ GB fan ~~ ^talk 20:14, 24 October 2009 (UTC)
7. If an admin requires consensus to become an admin they should have to maintain consensus to continue on with the post, some system needs to be enacted to ensure this. Icewedge (talk) 21:23, 24 October 2009 (UTC)
8. Skomorokh puts it well. We strongly need a system where administrators are kept accountable with the community. JamieS93 21:44, 24 October 2009 (UTC)
9. Some sort of formal process is required beyond ad hoc deadminship by ArbCom.  Sandstein  21:54, 24 October 2009 (UTC)
10. This system, or lack of, does not work. Ironholds (talk) 04:39, 25 October 2009 (UTC)
11. Agree with Skomorokh. iMatthew ^talk at 13:37, 25 October 2009 (UTC)
12. Per Skomorokh. –Juliancolton | ^Talk 13:51, 25 October 2009 (UTC)
13. Per Skomorokh. --Cameron Scott (talk) 14:30, 25 October 2009 (UTC)
14. Agree that we need a better system of accountability.--Jmundo (talk) 14:52, 25 October 2009 (UTC)
15. I'm usually wrong about what new processes Wikipedians might be interested in, so don't listen to me, but it does seem to me a lot of people are putting a lot of effort into this, and that suggests the time is right for an experiment. I don't have any strong feeling which of the proposals would work out better in practice, I'll need to see the results of the experiment first. Many have said that RfA is likely to produce more admins if we try one of these proposals. That makes sense to me, but if it doesn't happen, then we need to keep trying new things until it does happen, or else find a way to get more non-admins involved productively with admin work. Some have said that there's no point to this because Arbcom, Jimbo or the WMF will overrule us, but the relationship between en.wikipedia and the WMF is like a good marriage ... I do trust Arbcom, Jimbo and the WMF to have the best interests of the project at heart, but at the end of the day, we have to be clear about what we want as a community, and since the WMF does understand the importance of consensus to en.wikipedia, I expect them to respect our decisions. - Dank (push to talk) 15:38, 25 October 2009 (UTC)
16. The community needs to have confidence in it's admins. Davewild (talk) 15:49, 25 October 2009 (UTC)
17. — Jake Wartenberg 16:04, 25 October 2009 (UTC)
18. per Skomorokh - though WereSpielChequers raises a very valid point, which should be pursued further. The fact that the status quo fails in other ways isn't sufficient reason to avoid fixing this; and indeed, fixing this rather raises the incentive to fix that. Rd232 ^talk 16:51, 25 October 2009 (UTC)
19. Arbcom should be the last resort, not the only resort. MLauba (talk) 22:11, 25 October 2009 (UTC)

    Hard to argue with. - Dank (push to talk) 22:23, 25 October 2009 (UTC)

20. Per Skomorokh. Nev1 (talk) 22:24, 25 October 2009 (UTC)
21. There needs to be a recognised way of removing adminship without requiring the intervention of ArbCom. Fences&Windows 23:54, 25 October 2009 (UTC)
22. Strongly in opposition here. Admin tenure of office creates a separate, privileged class of supereditor, exacerbated by the excessively wide latitude given to admins in many situations. Ray^Talk 06:26, 26 October 2009 (UTC)
23. Per Skoromoth and also Ray and Nev, who raise valid opposition points. AtheWeatherman 10:52, 26 October 2009 (UTC)
24. Just putting my "no" to the status quo here and will look at the proposals later. WereSpielChequers raises valid concerns about admin retention and workload, but addressing those issues and also addressing the lack of a community desysyop option are not remotely mutually exclusive. A large chunk of the community (including many admins) feels that it's a bit insane that the community that selects admins cannot de-select them, and this fact regularly creates additional anger during difficult disputes, particularly (and understandably) among non-admins who see what they believe to be admin abuse about which they can do little or nothing. The status quo is not acceptable. --Bigtimepeace | talk | contribs 17:26, 26 October 2009 (UTC)
25. The status quo is a disaster. The role of Admin is, de facto, judge, jury and executioner. They must be accountable to the non-Admin editing community on an on-going basis. Sarah777 (talk) 21:15, 26 October 2009 (UTC)
26. Seems to me that problems often arise when admins ask themselves "What do I think should happen here?" rather than "What would the community want to happen here?" Implementing a recall procedure will give admins more incentive to consider how the community is likely to react to any given course of action. Also, per Tony Benn's 5 questions. MoreThings (talk) 00:43, 27 October 2009 (UTC)
27. Per Skomorokh.--Epeefleche (talk) 06:19, 27 October 2009 (UTC)
28. I've never seen a more toothless promise than the promise to be open to recall in RFA. Does more harm than good to keep this. Hipocrite (talk) 12:36, 27 October 2009 (UTC)
29. Spartaz does make a good point, however there's still the issue that an arbitration case still takes months to handle, and a user who is not desysopped by that process may still have lost the trust of the community. I've always believed, like Skomorokh, that if the community has the ability to say who they trust, they should have the ability to say who they don't, provided the admins themselves are protected from abuse of the system. Hersfold ^(t/a/c) 14:24, 27 October 2009 (UTC)
30. It has never made sense to me why the community can say who they trust, but can't say who they no longer trust. I also find it difficult to argue with the view put forward that ArbCom should be last resort, not the only resort. The amount of times admin recall debates and proposals have cropped up in itself shows that something is not right with the status quo. Camaron · Christopher · talk 19:32, 27 October 2009 (UTC)
31. Most of the above commentors in this section make good points. I feel that a "faster, better, cheaper" method to remove adminship has long been needed. The lack of a way to remove the tools from those who have lost the trust of the community has long been a driver in the increasingly unreasonable standards at RfA. My only fear is that consensus may be reached that the status quo is unacceptable but still not exist for any of the proposed replacements. Eluchil404 (talk) 02:41, 28 October 2009 (UTC)
32. At the very least, te arbitrary and selective Admin Open To Recall should be laid to rest. It is a bizarre blend of optional and compulsory and unenforceable. One of the historical reasons that there have been proposals for a de-amin process is a difficulty or delay in it being handled by the arbitration committee. I do feel we (well, now they) have come some way in remedying that, but I get the impression that those unhappy about others' admin conduct have not been as proactive in requesting the arbitration committee to examine others. Casliber (talk · contribs) 09:52, 28 October 2009 (UTC)

    Thanks for weighing in, the viewpoint of Arbs and former Arbs is especially helpful. Do you think ArbCom might be open to listening to arguments in a particular case, making an initial determination that they are hearing legitimate concerns about an admin and don't see that the process is being "gamed", and handing it over to the voters and crats to decide (with the understanding that they'll take the case back in the hopefully rare cases where something goes terribly wrong)? Something like this has recently been proposed as Option 12. - Dank (push to talk) 19:35, 28 October 2009 (UTC)

    While I was on the arbitration committee, I was surprised that the complaints of admin conduct were often not followed up with a request for the arb committee for review. I spent months stating this everywhere I could that it was the role of the committee to do so. Personally, I feel all the system needs to work alot better is two changes of behaviour - (1) people to give a little bit more leeway in allowing someone to have a crack at the tools at RfA, and (2) be more proactive in requesting for a review of tool use to the arb committee. If these two happened, I think we wouldn't be having this discussion. Casliber (talk · contribs) 19:50, 28 October 2009 (UTC)

33. The current system is a mishmash of efforts - some admins are not open to recall, some who are may not honor their recall promises, and other who are open to recall have such high grounds that they likely cannot be met. Many users (myself included) are unsure when it is appropriate to bring an administrator to ArbCom, and opening an ArbCom case is so laden with drama that many don't want to bother. Karanacs (talk) 20:25, 28 October 2009 (UTC)
34. The community decides whether a user is to become an admin, and the community should decide whether a user is to stay an admin. The current system, in which adminship can be removed only by Jimbo or by a ruling of the Arbitration Committee (itself appointed by Jimbo following "advisory elections"), is too top-down. I am troubled by ArbCom's practice of allowing desysopped administrators to appeal directly to the Committee for reinstatement of their privileges, bypassing RfA. I strongly favor a more community-based process. Tim Smith (talk) 21:49, 28 October 2009 (UTC)
35. The status quo is an RFA that has to reject good talent rather than risk appointing a bad admin. The status quo is that any inter-admin dispute has to be taken to arbcom for months of drama. These are two different arrows point to a change in the status quo. --Alecmconroy (talk) 12:24, 31 October 2009 (UTC)
36. No. Per Skomorokh. -FASTILY_sock ^(TALK) 00:04, 3 November 2009 (UTC)
37. Adminship is supposed to be no big deal. Being so hard to undo means that it has become a big deal. Gigs (talk) 22:24, 3 November 2009 (UTC)
38. Those in support of the status quo believe that the only way an admin should be de-sysoped is by Arbcom; I disagree. If an admin makes a huge error, then Arbcom will handle the problem. However, when an admin performs small abuses, and loses trust of the community, then we have no recourse than a voluntary recall (if they are even open to it). They have to earn the trust of the community to become admins, and should be required to keep that trust. No to the status quo. Angryapathy (talk) 15:11, 4 November 2009 (UTC)
39. Definitely need a way to remove the sysop bit when the tools are used abusively. The current process is too hard. --Coffee // have a cup // ark // 02:40, 6 November 2009 (UTC)
40. What Casliber, Karanacs, Gigs, Camaron, and many others say above. I'm not comfortable with my own, now old, proposal (see below) in several respects, and have said it would be better to pick out the better parts of it and create an ArbCom Subcommittee to perform the role. I still think non-arbs should be represented on such a committee to gain the confidence of the community as a whole. Tony (talk) 05:31, 7 November 2009 (UTC)

    Agree w/the subctee idea. We need a way to narrow the proposals at some point.--Epeefleche (talk) 05:37, 7 November 2009 (UTC)

41. It’s time for Wikipedia to get away from being a exclusive social club where the privileged elite circle the wagons to protect their brethren. It is far too hard right now to kick out Admins who are ill-tempered and hostile. Administrators like to quote hokum about how they are just “regular editors which access to special tools”. This is bunk; they have police powers because of their ability to block editors. Admins govern the conduct of others. It is high time to institute a sensible process that doesn’t impose preposterously high hurdles to boot out unsuitable Admins. Those who govern must only do so with the consent of the governed. As it currently stands, the Wikipedian community does not have that right because there is no effective remedy. Greg L (talk) 19:31, 7 November 2009 (UTC)

    "The consent of the governed": that's an excellent point. Well said! --Tryptofish (talk) 21:41, 7 November 2009 (UTC)

    Sounds like "Who watches the watchmen?" (and I tend to agree) Angryapathy (talk) 07:46, 8 November 2009 (UTC)

42. The community occasionally gets it wrong; good apples go bad. At the moment, Admins (except for those subject to recall) have a job for life; few are ever removed despite plenty of anecdotal evidence of Men Behaving Badly. This is not about professors being given tenure to ensure academic freedom. We need a process which is fair and transparent, but with an adequate threshold so as to deter frivolous or vexations challenges. A bit of bureaucracy is a small price to pay to ensure that proper checks and balances exist for both litigant and defendant. Ohconfucius ^¡digame! 06:11, 10 November 2009 (UTC)
43. Per Skomorokh.--Staberinde (talk) 17:20, 11 November 2009 (UTC)
44. If the community can be trusted to grant administrator tools, it should be trusted to remove administrator tools as well. Also per the many excellent points above. --ThaddeusB (talk) 14:11, 12 November 2009 (UTC)

Comments (Option 0)

1. Option 0 doesn't really mean "keep the status quo". Arbcom in the distant past was very reluctant to desysop admins for any reason. That was why Category:AOR was created (and soon proved itself useless). The earliest arb cases resulting in desysopping (maybe Carnildo/Karmafist, my memory is hazy) involved offenses that were way over the top compared to what routinely gets desysopped now. There was also a principle, that was valid back in the day but is completely obsolete now (so deal with it, holdouts), that admins were just users with extra buttons and "adminship is no big deal". The community has delegated more and more authority to admins to handle complex dispute resolution that used to require monstrous arb cases. That is a good thing and it usually works, but it means that every admin is now a miniature arbitrator, so adminship is a big deal.

   Arbcom now is much more willing than before to desysop admins for bad judgement even when admin buttons aren't involved, another good thing once we accept that adminship is about judgement and not buttons. Aitias resigned just before being desysopped through an arb motion [1] without the endless bureaucracy of running a full case, after an RFC saying (among other things) "Arbcom, please desysop Aitias".[2] I could imagine it getting even more streamlined and I hope it does. The changing nature of adminship has also led to higher standards at RFA, another good thing, since adminship is no longer about "buttons" and requires higher confidence of good judgement. So Option 0 actually means "natural evolution of RFA and arbcom practices is changing the status quo enough to not need a further explicit recall procedure". 69.228.171.150 (talk) 10:45, 6 November 2009 (UTC)

   Good point - but some of the options here are fairly natural evolutions of existing procedures, and RFC (like this one) is certainly part of how evolution works here. Rd232 ^talk 12:30, 6 November 2009 (UTC)

   I'm not sure what it was meant to mean, but this vote shows that people want an actual system in place, and that current recall/Arbcom procedures are inadequate, especially in non-egregious offenses. Angryapathy (talk) 14:24, 6 November 2009 (UTC)

   Well, a) this isn't a vote; b) that option 0 has some supporters shows that not everyone wants a new system in place. The point of my comment is that the description of option 0 as "keep the status quo" is not really accurate and creates a false dichotomy between "create yet another new system with yet more rules and bureaucracy" and "keep doing exactly the same broken stuff that we're doing now and keep suffering from it exactly the same way".

   Whether through option 0 or some other means, the main change I see being pursued through all the approaches in this RFC is that the criterion for desysopping should be "admin X has lost the community's trust" rather than "admin X has used the admin buttons improperly". (The recent Jennavicia/Law incident was an example of button-less loss of trust). My view of option 0 is that arbcom practice is indeed evolving (maybe not fast enough) towards that approach, so it's reasonable to support just letting that keep happening. 69.228.171.150 (talk) 22:07, 6 November 2009 (UTC)

   I guess since this section doesn't have a definition for what "status quo" actually means, it is open to interpretation. If you feel that there is a slowly developing trend for arbcom to take up more action in admin sanctions, that isn't an opinion held by all. The comments above seem to be referring to what is in place right now, which is very little. Angryapathy (talk) 07:50, 8 November 2009 (UTC)

Option 1 (Devised by Roux)

Support (Option 1)

1. Far too bureaucratic, but better than the status quo. Prefer the more straightforward proposals.  Skomorokh, barbarian  01:18, 23 October 2009 (UTC)
2. Support, as the first proposal I examined. I could perfectly live with that, I believe, however, that a notion of "conduct unbecoming of an administrator" needs to be added to the criteria. MLauba (talk) 14:04, 25 October 2009 (UTC)

   How about "a pattern" or "a history" of conduct unbecoming of an admin? I'm sure we've all done something that could be construed as unbecoming even if we meant well. The problem is when there's a good likelihood that it's going to keep happening. delldot ∇. 01:19, 26 October 2009 (UTC)

   Good point, I like that approach. That being said, it's also a matter of degree. An admin starting to go on a massive verbal abuse because he snaps needs at the very least a wikibreak. MLauba (talk) 11:53, 26 October 2009 (UTC)

3. Seems like the best proposal on the table should it be demonstrated that ArbCom is inadequately active in removing adminship from problematic editors. Christopher Parham (talk) 21:51, 25 October 2009 (UTC)
4. Easier to understand, IMO. The last thing we need is another policy which is too complex.--Giants27(Contribs|WP:CFL) 23:00, 26 October 2009 (UTC)
5. This seems similar to the process I use for my recall process through CAT:AOR. I'd also prefer this process be used for a pattern of abuse, rather than single incidents as seems to be implied. This does have a fair bit of red tape associated with it, but I believe it's necessary to avoid turning this process into a total witchhunt or vendetta enabler. A single editor is only able to propose any given admin's desysopping once, ever, and can only do one in a year. Admins do make mistakes in good faith and need to be protected from dramamongers. Hersfold ^(t/a/c) 14:34, 27 October 2009 (UTC)
6. This is not my first choice, but I would support this method with several caveats: a) it must include as a potential reason "a pattern" or "a history" of conduct unbecoming of an admin (as mentioned above) and b) involved users should not be able to request that someone else initiate these. If the behavior was egregious, someone else will notice it and file the case, or it can be first brought to ANI. Without both of these changes, I don't think this proposal is workable. Karanacs (talk) 20:29, 28 October 2009 (UTC)
7. Support as better than status quo, but agree that "conduct unbecoming of an administrator" or even a honest, sincere, and sufficiently widespread understanding that the user "just isn't working out as an admin" would both be good reasons to revisit adminship. --Alecmconroy (talk) 21:09, 31 October 2009 (UTC)
8. Not my first choice, but support as having elements that are useful to incorporate into the version that will eventually come out of this discussion. Strength: I like the way it defines "who may initiate". Good to spell that out in that way, and maybe a marginally better system than limiting it to admins as the only ones who can initiate. Weakness: The list of reasons to desysop is unsatisfactory. It is only "bright line" offenses, which probably are dealt with by the status quo, but needs instead to be directed to admins who have lost community trust, per Karanacs and Alecmconroy just above. --Tryptofish (talk) 00:19, 3 November 2009 (UTC)

Oppose (Option 1)

1. Not convinced Bureaucrat decision makes sense - see talk page. Ben MacDui 10:59, 24 October 2009 (UTC)
2. Too complicated.  Sandstein  21:55, 24 October 2009 (UTC)
3. I also feel it's overly complicated, and places restrictions not just on who can initiate, but on who is allowed to comment. These restrictions are significantly harsher than the restrictions on who may comment at RFA, so doesn't really make sense as it's the reverse of that process. Beeblebrox (talk) 02:28, 25 October 2009 (UTC)
4. How many sysops these days are uninvolved? I've heard voices whispering "there are not enough admins", and it is safe to presume that most of active ones will be involved with one or both sides of the case. NVO (talk) 06:31, 25 October 2009 (UTC)
5. As we've seen from recent desysoppings there will be occasions when the community loses confidences in an admin for reasons other than misuse of admin tools or role. But this proposal says "Only for actions that involve use of an administrative function (something an auto-confirmed user couldn't do), or abuse of the role of an administrator". Also not convinced either that only one user can start the first stage, or that admins should be needed for the second stage. ϢereSpielChequers 16:25, 25 October 2009 (UTC)
6. Oppose I like the idea, but this can still be gamed quite easily by groups such as those involved in the Eastern European mailing list fiasco. If an admin is not in the good graces of a specific group of editors who happen to be obsesive and secretive about gaming Wikipedia, then this could just create one big, constant headache. Hiberniantears (talk) 20:28, 25 October 2009 (UTC)
7. I think the threshold for starting with one user is too low, but then the need for two admins to certify has the potential problem of admins being unwilling to act against each other. I might support with tweaking. Fences&Windows 23:58, 25 October 2009 (UTC)
8. RfDA drama will make RfA drama look like a cake walk. I foresee that FdFAs will turn into witchhunts, push further factionalization, and be used for vendettas and vengeance. Kingturtle (talk) 02:33, 26 October 2009 (UTC)ome variant of this approach might work,
9. Oppose per Kingturtle. It could be that some variant of this approach might work, as noted by Fences and Windows just above KT's post, but the devil's in the details. Jusdafax 04:21, 26 October 2009 (UTC)
10. Oppose as others have said, far to bureaucratic and limiting on who can comment. Something closer to RFA is better. ~~ GB fan ~~ ^talk 13:59, 26 October 2009 (UTC)
11. Oppose - too bureaucratic and too restrictive. I understand the intent behind some of the limitations is to prevent abuse of the system but I would prefer to see disruptive users treated as such rather than trying to combat them up front by unecessarily restricting the system. Shereth 14:24, 26 October 2009 (UTC)
12. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:04, 26 October 2009 (UTC)
13. Oppose - support forced recall (any less is worthless); but against the requirements that anyone mentioned by Arbcom is afforded no protection. Sarah777 (talk) 21:27, 26 October 2009 (UTC)
14. Oppose - As I read it, I suspect it can be gamed quite readily. I'd worry for admins working in difficult areas of the wiki here (the last group we need to lose). Casliber (talk · contribs) 09:56, 28 October 2009 (UTC)
15. Too easy to generate frivolous or vexatious requests. As Casliber suggests, admins working in difficult areas (copyright, image policy, arbitration enforcement, etc.) are more likely to generate enmity. Stifle (talk) 09:39, 29 October 2009 (UTC)
16. Oppose - too open to gaming. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
17. Oppose. Per above. To easy to abuse. -FASTILY_sock ^(TALK) 00:05, 3 November 2009 (UTC)
18. Oppose—Needs the stamp of authority from the opening of a complaint. Otherwise it will encourage bloated drama and a failure to reach resolution. Tony (talk) 05:46, 7 November 2009 (UTC)
19. Oppose per Fences and others. The checks and balances are out of kelter. Ohconfucius ^¡digame! 06:28, 10 November 2009 (UTC)
20. Per Ben MacDui. Ncmvocalist (talk) 11:04, 16 November 2009 (UTC)
21. Oppose The initiation threshold is simply too low. High likelyhood of disruptive reports. Jim Miller ^{See me | Touch me} 14:41, 16 November 2009 (UTC)

Neutral (Option 1)

1. I like that it mirrors the RfA process in many respects. I especially like the mirroring of the <70%/70-80%/80%+ vote range system. However, I am bothered by many of the specific details esp. that editors with less than 500 edits or past run-ins with the admin are not allowed to !vote. Indealing the !voting should be open to everyone, with the closing 'crat (or other chosen closer) being free to discount !votes that are "less valid." --ThaddeusB (talk) 14:20, 12 November 2009 (UTC)

Option 2 (Devised by Tony1)

Support (Option 2)

1. Support - see talk page. Ben MacDui 10:59, 24 October 2009 (UTC)
2. I think most of the options are good ideas to varying degrees, but I like Tony's the best because it seems to be the most complete, fair, and bulletproof of the options. Cla68 (talk) 00:43, 23 October 2009 (UTC)
3. Doesn't leave the decision in the hands of other administrators or bureaucrats. --Malleus Fatuorum 17:13, 24 October 2009 (UTC)
4. Well at least this one actually allows bringing the case for review without hypocritical "bring in dozen of admin allies first" prerequisites. NVO (talk) 06:33, 25 October 2009 (UTC)
5. Support (provisionally) - this does not appear to make value judgments between established registered editors; almost be definition those most likely to be concerned by Admin abuse are victims of same. Sarah777 (talk) 21:31, 26 October 2009 (UTC)
6. Support (tentatively) - in some ways a step in the right direction. Levels the playing field in a good way and much less likely to be gamed than Roux's option. Casliber (talk · contribs) 09:59, 28 October 2009 (UTC)
   1. Yes. I'm not entirely comfortable with this now-elderly proposal because (1) it is proper that it be a SubCommittee of ArbCom, which deals with behavioural issues; (2) it probably needs to be streamlined in process and explanation. An ArbCom Subcommittee to perform the role should, I believe, include non-admin members—a mixture of arbs, admins and non-admins—to gain the confidence of the community as a whole. It does need a process to filter out unworthy complaints early on, IMO (as Tryptofish is getting at below). ANI is clearly unsatisfactory, and ArbCom needs to delegate or people won't use that channel for this purpose. Tony (talk) 05:38, 7 November 2009 (UTC)
7. Would be much better than status quo. --Alecmconroy (talk) 13:01, 31 October 2009 (UTC)
8. Moral support, given the detailed work by the proposer, and the fact that it should be examined for use in developing the final version. But there are significant problems. The "coordinators" system appears too complicated. Letting any user initiate leaves it too open to harassment of good admins, and framing it in terms of "an incident" misses the point of chronic bad behavior. --Tryptofish (talk) 00:25, 3 November 2009 (UTC)
9. Tony’s is the most complex because he is a long-time editor who recognizes the social complexity necessary to keep an all-volunteer system working smoothly. I think he has done a good job trying to balance the needs of the community against the need to not make Admins feel despirited. Greg L (talk) 19:39, 7 November 2009 (UTC)
10. Support I believe it is an egalitarian proposal with reasonable safeguards for plaintiffs and defendants. Coordinators will also come under scrutiny. (Disclosure - I have a hand in drafting AdminReview) Ohconfucius ^¡digame! 06:32, 10 November 2009 (UTC)

Oppose (Option 2)

1. Too complicated.  Sandstein  21:56, 24 October 2009 (UTC)
2. Overly bureaucratic, and lacks any authority to actually remove sysop rights, so if agreement is not reached and/or not abided by we wind up back at ArbCom. Beeblebrox (talk) 02:37, 25 October 2009 (UTC)
3. No thanks. I'd rather take my chances with the arbitration committee and I dont like the idea of elected coordinators. Spartaz ^Humbug! 14:01, 25 October 2009 (UTC)
4. Is it really a recall process? I have always thought that AR is just a forum for users to express grievances about administrators. Ruslik_Zero 15:06, 25 October 2009 (UTC)
5. Per above and dislike institutionalising a divison between admins and non-admins. Davewild (talk) 15:51, 25 October 2009 (UTC)
6. This has some potential, but as currently written is only interested in serious complaints. Could it be broadened to include consideration of non-trivial complaints, and its options to include verdicts and appropriate options below desysopping? Also the limitations as to how many comments can be made by the parties to the case risk a breach of natural justice. Long threads may be tiresome and would hopefully will be rare, but the proposed limit would tempt both sides to leave some ammunition to the statement that can't be replied to. ϢereSpielChequers 16:46, 25 October 2009 (UTC)
7. Per Sandstein. MLauba (talk) 22:12, 25 October 2009 (UTC)
8. Seems overly complicated, adds a new layer of bureaucrats into the system, doesn't seem to involve community input, and only applies to single incidents rather than cumulative concerns. This seems more like an arbitration process than desysopping. Fences&Windows 00:04, 26 October 2009 (UTC)
9. Really, this would just be creating a new ArbCom. Having elections for yet another governing body is not useful. It just will add more to the bureaucracy. Kingturtle (talk) 02:40, 26 October 2009 (UTC)
10. More complicated and more bureaucratic even than option 1. Shereth 14:27, 26 October 2009 (UTC)
11. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:04, 26 October 2009 (UTC)
12. Bureaucratic to an extreme and toothless, a bad combination. Also, the comment above about institutionalising a divison between admins and non-admins hits the mark. RxS (talk) 22:26, 26 October 2009 (UTC)
13. Too complicated, and I greatly dislike the fact that we would need to elect people for this purpose; it removes part of the decision from the community and essentially makes a mini-ArbCom. Hersfold ^(t/a/c) 14:36, 27 October 2009 (UTC)
14. WP:BURO Stifle (talk) 09:39, 29 October 2009 (UTC)
15. Excess bureaucracy, and to specify how many coordinators must be admins/non-admins seems to me to encourage an unhealthy adversarial mindset. Christopher Parham (talk) 17:32, 29 October 2009 (UTC)
16. For this level of complexity and bureaucracy, we already have Arbcom. Rd232 ^talk 17:25, 1 November 2009 (UTC)
17. Worse than status quo. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
18. Oppose. per Jayjg -FASTILY_sock ^(TALK) 00:05, 3 November 2009 (UTC)
19. Could be a slight improvement over the status quo, but I would prefer a process that is completely community driven than one that substitutes one elected group ("Coordinators) for another (Arbcom). --ThaddeusB (talk) 14:26, 12 November 2009 (UTC)
20. Per above. Ncmvocalist (talk) 10:59, 16 November 2009 (UTC)

Option 3 (Devised by Beeblebrox)

Support (Option 3)

1. I do of course support my proposal, but I have had very little direct feedback on it thus far, and there are some good ideas in the other proposals as well. I think a merger of some of these ideas might be a wise course of action, and I may just add what works from the other proposals as this progresses so stay tuned. My goal is not to start killing off admins, but rather to respond to the various calls for some sort of process like this, and to make sure that it does not degenerate into an admin witch hunt where frivolous complaints deprive us of qualified admins. Beeblebrox (talk) 19:50, 22 October 2009 (UTC)
2. A better option than No confidence, as this keeps adminship between the community and the bureaucrats and restricting recourse to ArbCom to a last resort, as it should be. I'm concerned about how malicious reports and drama will be contained, but this is a huge improvement on the status quo regardless.  Skomorokh, barbarian  01:22, 23 October 2009 (UTC)
3. Not a bad approach in general, but I would prefer something that does not need a dedicated forum and new rules (see my proposal no. 7, below).  Sandstein  22:02, 24 October 2009 (UTC)
4. Sounds like a reasonable proposal. –Juliancolton | ^Talk 13:52, 25 October 2009 (UTC)
5. I think this one sounds like the best course. ···日本穣^? · 投稿 · Talk to Nihonjoe 15:25, 25 October 2009 (UTC)
6. 4th choice. Similar to the RfC procedure, not sure about the details of closure but that can be thrashed out. Fences&Windows 00:10, 26 October 2009 (UTC)
7. Support but would like amendments to closing - should be done by crats, and of course the bit will be removed by a steward as the crats can't do that. MLauba (talk) 09:51, 26 October 2009 (UTC)
8. Support the general format and direction of this one, with some need for refinement. Couple of things (such as "user in good standing") need to be better defined, some clarification as to the closing process, but I could get behind an effort to reine and implement something like this. Shereth 14:33, 26 October 2009 (UTC)
9. I support this scheme initially and will take a closer look at all the proposals to possibly support or oppose others. I do like the open-ended closure deadline, I don't think anything like the Bush v. Gore situation would ever arise, maybe only a few more days than seven for rough cases. Sswonk (talk) 14:42, 26 October 2009 (UTC)
10. Support (#1) - this is the best of the options presented. "user in good standing" needs to be clearly and unambiguously defined. Sarah777 (talk) 21:37, 26 October 2009 (UTC)

    I took a swing at that already, in the "footnotes" section. Beeblebrox (talk) 22:54, 26 October 2009 (UTC)

11. Support. Sounds reasonable, though we may want to take a second look at putting in a timeframe.--Epeefleche (talk) 07:34, 27 October 2009 (UTC)

    I tweaked that section a bit to better reflect what I had intended, which was early closes when it rapidly becomes clear that the admin will be retained, sort of like a "reverse WP:NOTNOW." Beeblebrox (talk) 18:45, 27 October 2009 (UTC)

12. Support. --Alecmconroy (talk) 13:05, 31 October 2009 (UTC)
13. Strong support. In fact, the only one where I am bolding my comment, my first choice. Not perfect, and should incorporate some of the better features of some of the other proposals here, but this is the most responsive to the concerns that got this process of discussion started, and it should be the starting point for drafting the version that will emerge from here. --Tryptofish (talk) 01:07, 3 November 2009 (UTC)
14. Not perfect, but worthy of support. The "reverse NOTNOW" part is OK if properly explained and not done too quickly, but a result of a full discussion should always be assessed by a 'crat (or other highly trusted person). The "possible reasons" and "what not to report" sections are esp. good and should be incorporated into whatever "consensus solution" emerges from this RfC. --ThaddeusB (talk) 14:38, 12 November 2009 (UTC)
15. Support this process in all but the "any editor can close" portion. non-admin closes of process need to be non-controversial, and a de-sysop is going to be controversial almost every time. Desysop should mirror RfA and the crat should close. I would also like to see a higher number for certifying the process than the 2 uninvolved editors, but this is the best of the bunch to me. Jim Miller ^{See me | Touch me} 14:57, 16 November 2009 (UTC)

Oppose (Option 3)

1. Opposed to other admins making a decision. Ben MacDui 10:59, 24 October 2009 (UTC)

   • I've rethought that aspect, I don't see any harm in letting it be closed by any user in good standing, same as other RFC processes, will make that change now. Beeblebrox (talk) 02:38, 25 October 2009 (UTC)

2. no. Spartaz ^Humbug! 14:03, 25 October 2009 (UTC)
3. There shall be no set period of time for discussion to run So the process can run indefinitely? Thanks, no. Ruslik_Zero 15:10, 25 October 2009 (UTC)
4. Dislike having any uninvolved user or even uninvolved administrator make the call. NW (Talk) 15:23, 25 October 2009 (UTC)
5. Per NW. This would seem to be a good option otherwise. — Jake Wartenberg 16:09, 25 October 2009 (UTC)
6. Per NW re non-crat closures and per Ruslik re this running potentially for longer than 7 days. Thirdly because this is restricted to "the administrator in question has used either their administrator tools or status in a way not consistent with the reason they were granted the tools" as we have seen in recent incidents the community can lose confidence in an admin for non admin actions. Also this proposal is only for matters serious enough to merit desysopping, and we already have arbcom for that, the gap is for matters below that level. ϢereSpielChequers 16:58, 25 October 2009 (UTC)

   I feel like I missed your point at the end there. If there is no call for them to be desysopped, we already have tons of places to report. However, I think you do make a good point about the scope of the process, and I've adjusted the language in that section. (I didn't really get any direct feedback before this thing went live, so I'm eager for reports on any loopholes or flaws found in the proposal) Beeblebrox (talk) 19:11, 25 October 2009 (UTC)

   Thanks for making that change, I've struck that part of my objection, My last point in my previous post was that I liked the start of your process "an Admin RFC can result in sanctions or the removal of user rights if that is the consensus reached in the discussion" but not the end, as that gave a binary choice between desysopping and not desysopping. ϢereSpielChequers 00:58, 26 October 2009 (UTC)

7. Doesn't require specific indication of which admin tools have been misused, which I feel is a crucial requirement; issues like long-term incivility should be addressed with normal existing remedies, not removal of unrelated tools. Christopher Parham (talk) 22:19, 25 October 2009 (UTC)
8. I foresee troubles with the loose criteria for how this is to be closed and by whom. These things are bound to be hugely contentious. Imagine if RFAs could be closed either way after a few hours if consensus seemed clear. One editor closing this (admin or otherwise) closing this is bound to be problematic, even if they're not directly involved it's going to be difficult to show whether they have some old bias. And I'm also concerned by the problem brought up on the discussion page about how this could be rammed through while one continent was sleeping. delldot ∇. 01:26, 26 October 2009 (UTC)
9. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:04, 26 October 2009 (UTC)
10. How is this really any different than the current admin RFC/U? Basically only in that it turns the present RFC/U into a reverse WP:RFA. I don't see the advantage of that: it makes more sense to me to have an open-ended RFC/U on the rights and wrongs of an admin's behaviour, considering various appropriate remedies, and if the outcome of that discussion is that the community wants a reconfirmation RFA, that should be a separate step. (And ideally the decision on whether that step is required should be taken be an appropriately-trusted figure; I think an uninvolved admin should be required to launch the RFA itself, if community opinion demands one.) Otherwise, we're encouraging a rush to judgement. Rd232 ^talk 13:02, 27 October 2009 (UTC)
11. Makes no effort to protect the accused. Consensus should be judged by an admin, bureaucrat, or arbitrator (with my preference to the latter two), not any person who happens to stroll by. Hersfold ^(t/a/c) 14:41, 27 October 2009 (UTC)
12. Sorry, if it is patterned at all along the lines of current RfC, then I think it is not a good format and will lead to inconclusive outcomes with alot of acrimony on the way. Casliber (talk · contribs) 19:54, 28 October 2009 (UTC)
13. Oppose. I like most of this proposal and would consider changing my vote here if closing was not left open to any "uninvolved user". The method for deciding close cases is also not well-defined. This could be very easily gamed. Karanacs (talk) 20:33, 28 October 2009 (UTC)
14. Witchhunts, anyone? Stifle (talk) 09:40, 29 October 2009 (UTC)

    Could I ask you to be more specific? Not because I want to argue with you but because that is exactly what I don't want this process to become. I've tried to strike a balance between having an open community driven process but also preserving the admin's dignity and hopefully filtering out unreasonable requests, but it's somewhat difficult to balance the two. Beeblebrox (talk) 20:12, 30 October 2009 (UTC)

    Because a request can be filed by a single user and there is no limits, checks, balances, or downside for making pointless requests, an administrator who takes unpopular but correct decisions regularly is very likely to be targeted with a lot of these and eventually lose the bit due to bad luck. Stifle (talk) 11:13, 10 November 2009 (UTC)

15. Per Stifle, above. To clarify why I'd say so, this is a problem with any process that takes it out of ArbCom's hands. Admins have to make tough calls sometimes, and will almost by necessity irritate someone by doing so. That's not the same as abuse, but could just as easily lead to recall requests. Abusers already know they can be desysopped, and that either discourages them or it doesn't, adding a different way it can happen isn't really any more or less likely to. However, this would put a lot of heat on admins who are willing to step into contentious areas, and they take enough of that as it is. Seraphimblade ^{Talk to me} 17:23, 1 November 2009 (UTC)
16. Too open to gaming. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
17. No. -FASTILY_sock ^(TALK) 00:05, 3 November 2009 (UTC)
18. Oppose Despite liking the clear statement of purpose, I have strong reservations about requiring a supermajority to support removal. Any admin not receiving that supermajority at RfA would not be elected in the first place, so it's a slap in the face if the vote is anything more that one third in support; more than half, it's a kick in the groin; if it's at 60%, we really have a problem. Ohconfucius ^¡digame! 06:40, 10 November 2009 (UTC)

Neutral (Option 3)

1. Still looking over it. Ncmvocalist (talk) 11:00, 16 November 2009 (UTC)

Option 4 (Devised by Uncle G)

Support (Option 4)

1. Support this is possibly the best approach. We really need an RfA-like system where the community decides whether or not somebody be desysopped, as long as the system is not abused, and each request is backed by several good-standing users. I believe that all admins should be open to the community's opinion of them, whether or not it be through a "Recall criteria" system ("criteria" are OK, although I tend to dislike them). Of course there will be problems with anything, but I don't see any major roadblocks with this proposal. JamieS93 18:40, 24 October 2009 (UTC)
2. Similar to my proposal no. 7, below, which has the additional advantage of not needing a dedicated forum, and less complexity.  Sandstein  22:05, 24 October 2009 (UTC)
3. The best proposal in my mind and the ability for the ten editors to re-sign within the 3 day period means it really should not be too hard a requirement to open a recall attempt where merited. Davewild (talk) 15:56, 25 October 2009 (UTC)
4. 1st choice. Well thought out, threshold for opening seems about right, and closing process by bureaucrats seems necessary. Fences&Windows 00:13, 26 October 2009 (UTC)
5. This seems workable. I agree with WSC's concern in the oppose section that the 100 participants total is kind of irrational, maybe it should be no action if less than a certain number of people support desysopping. But really I doubt this is going to be a problem, with how contentious these are bound to be. I bet they're always going to get a lot of participation. delldot ∇. 01:52, 26 October 2009 (UTC)
6. Support with reservations. Best option presented, as I see it, but... Would like to know what 'crats think of this one; if there is no support at that level my reservations become grave indeed. It does increase their duties, needless to say. Jusdafax 04:37, 26 October 2009 (UTC)
7. Support. The 100 number seems a bit high for a 7-day interval, but the rest of the process looks good. Very similar to Sandstein's proposal. I have a slight quibble regarding the definition of "editor in good standing" - there are some Arbcom restrictions covering very broad areas indeed (such as, say, all articles related to certain ethnic conflicts). We should make clear that it is only people who have actually been named in enforcement actions - rather than merely editors in those areas who have been made aware that the articles they're editing are under restriction - who are barred from raising a de-RfA. Ray^Talk 06:36, 26 October 2009 (UTC)
8. May need some tweaks as pointed out above, but it seems workable and probably the best option available at the moment. AtheWeatherman 10:52, 26 October 2009 (UTC)
9. Second choice - least harm. -- Y not? 18:36, 26 October 2009 (UTC)
10. This makes sense to me, first choice so far. The "10 users to certify" bar may be a bit high, but it's a good defense against abuse. Maybe reduce it to 7, but no lower than 5. I don't see that this significantly increases ArbCom or clerk workload; from what I see, it's just counting heads and making sure they're not subject to any restrictions (which is simply Ctrl+F+Username on the ArbCom case index) to make sure discussion can begin. Hersfold ^(t/a/c) 14:50, 27 October 2009 (UTC)
11. All these procedures are somewhat bureaucratic and somewhat open to abuse. We need to implement one anyway, and, option 4, I choose you.—S Marshall ^Talk/_Cont 23:52, 27 October 2009 (UTC)
12. Receptive - strikes me as an arbcom deadminship followed by an RfA in reverse. Still think it can be gamed and concerned about admins working in difficult areas. —Preceding unsigned comment added by Casliber (talk • contribs)
13. 'Support!. I would suggest making it "50 support for desysop" instead of "100 participants", so as to encourage poll participation. (If there had been 99 votes, and you opposed desysop, you would tip it over into 100 just by voicing you opposition. To speak out in opposition could be to seal the fate. This sort of thinking might lead to oppose tending to boycott any polls that look like they might not get a quorum. --Alecmconroy (talk) 12:42, 31 October 2009 (UTC)
14. Support as having useful parts to consider, though not my first choice. It is reasonable to allow Arbcom to be able to initiate the process as the outcome of a case, in addition to letting the community initiate. I agree with some of the comments above about how some of the numbers-of-editors issues become difficult to work with. P.S.: I notice that this is starting to emerge as having the highest percentage of support !votes. In addition to the other points made in this talk, I want to point out that it will be necessary to flesh out what percentage of support/desysop would lead to what outcome for the closing crat. --Tryptofish (talk) 00:31, 3 November 2009 (UTC)
15. Support - This one seems to be the best, everything is well thought out, even if it has to be a bit bureaucratic. The 10 person bar should definitely be there, it shows that the admin's incorrect use of the tools was seen by a wide audience, and prevents abuse; I don't see any way how that could be considered too high. --Coffee // have a cup // ark // 02:37, 6 November 2009 (UTC)
16. Strong support This has the advantage of preventing abuse on both ends by having the 'crats involved, but the ultimate decison up to the community. The bureaucrats can make judgement calls to see if the system has been gamed, and I like the reverse RfA. If an admin has to be chosen that way, it seems natural that they should be de-sysoped that way. Also, the ten signatories in good standing again prevents vendettas by a few slighted individuals. Angryapathy (talk) 03:17, 6 November 2009 (UTC)
17. Not perfect, but a good concept.--Kubigula (talk) 04:49, 6 November 2009 (UTC)
18. Extraordinarily simple. Requiring ten editors may be too many, but the process can later be tweaked if the community perceives the need. It’s high time we have something besides the ridiculously high hurdles that are currently imposed on the regular Wikipedian community. Greg L (talk) 19:44, 7 November 2009 (UTC)
19. Support Well thought out, although ten editors of good standing may be a bit stiff hurdle for an aggrieved newbie. Ohconfucius ^¡digame! 06:53, 10 November 2009 (UTC)
20. Support, although this page has very much gotten to be a tl;dr thing. Something simple as I understand it, but the exact numbers and percentages need to be fleshed out if it does go through. In general, I'm in favor of keeping the "de"-admin very much like the "plus"admin process. — Ched :  ?  14:16, 10 November 2009 (UTC)
21. Support Seems to be most reasonable and practical proposal.--Staberinde (talk) 17:34, 11 November 2009 (UTC)
22. Looks good Doesn't reinvent the wheel. ChildofMidnight (talk) 00:04, 12 November 2009 (UTC)
23. Support - It uses the current AfD process, and has a reasonable threshold for it to be initiated, so that a small handful of people with a grudge couldn't cause trouble for an administrator. -- Atama頭 07:10, 14 November 2009 (UTC)
24. Weak support - The process itself is along the right lines (mirror of RfA), but I don't like the details. It should either rely on a lower number of editors to get it started or allow more time for people to become aware of the request. It seems unlikely that "10 editors in good standing" would simultaneously come to express distrust of the same admin within 3 days time, unless the admin was part of some horrible mistake - in which case the existing process already does its job well enough. A viable de-admin process should be flexible enough to allow for cases where the admin has lost confidence due to a long series of "small mistakes" and I don't see this process, as currently structured, allowing for that. --ThaddeusB (talk) 22:34, 15 November 2009 (UTC)
25. Support I think this is the best overall option. ~~ GB fan ~~ ^talk 23:34, 15 November 2009 (UTC)
26. Weak support. Concur with ThaddeusB. Principle is good but the bar is set too high. 5 or maybe even 3 established users in good standing should be enough to get the ball rolling. A move for a recall is tantamount to a public denunciation and is likely to be approached with trepidation even if called for. This number can be revised later if experience shows it is too low. Adding precautions would make sense too like an admin being able to challenge all nominators who share similar address ranges even if there is no evidence of sockpuppetry and requesting that another qualified nominator make up the prescribed number.

Another idea if it is implementable is an anonymous vote of no confidence button associated with every admin, available only to established users, that when pressed enough times by various members to reach a certain threshold automatically triggers an admin recall process. Safeguards could include that admins who clear the recall process by a large margin are immune to such a process for a certain amount of time unless the arbitration committee endorses another move to recall before that time expires. Arbitration committee could also set a higher bar according to a formula for admins who draw particular ire but who clearly have the support of the community regardless. Whatever process is chosen, a trial period would be in order to see if the threshold levels are appropriate and to avoid a sudden flood of requests for admin recall. — Lambanog (talk) 10:21, 16 November 2009 (UTC)

Oppose (Option 4)

1. Not convinced Bureaucrat decision makes sense - see talk page. Ben MacDui 10:59, 24 October 2009 (UTC)
2. The hurdles of recruiting nine dedicated angels in three days (as well as denial of service to those harassed by sysops) seem to be designed to never work. NVO (talk) 06:27, 25 October 2009 (UTC)
3. This proposal only covers desysopping and can only result in an admin being cleared or desysopped. We need to handle lesser offences and we need "shades of grey" results in between innocence and desysopping. I disagree with "no request shall be closed as a de-sysopping if fewer than 100 editors in total express opinions in the poll" as this would mean 80/20 would be a desysop but 95/3 wouldn't and 99/1 wouldn't if the 1 opposer struck their oppose. Also ten may be a little high for initiation. ϢereSpielChequers 17:22, 25 October 2009 (UTC)
4. I don't like the "single bureaucrat makes the call" bit; I'd rather that either crats not be involved at all, or conduct crat chats, that is, any crats who want to can weigh in and discuss with each other. Since this is new ground, many of the first cases will be hard. Of course, crats weren't elected with this in mind and some of them have indicated in the past that they don't think it's an appropriate job for them; of course, they don't have to participate if they don't want to. - Dank (push to talk) 22:31, 25 October 2009 (UTC)
5. Proposal is well defined and well written but trends back toward the bureaucratic and restrictive. Requiring 10 users to certify a nomination seems a bit onerous to me. Shereth 14:37, 26 October 2009 (UTC)
6. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:04, 26 October 2009 (UTC)
7. Oppose - until "editor in good standing" is clearly defined this could turn out to be merely an Admin support mechanism for bad Admins. (I also wonder if Admins should be voting here as they could be thought to have a vested interest?). Sarah777 (talk) 21:41, 26 October 2009 (UTC)

   No less vested than anyone else who volunteers here. Any editor supporting any of these ideas could just as easily be called out for having a vested interest in taking down all the admins. Ultimately, this is why we all know that none of these proposals will make it off this page. Hiberniantears (talk) 21:50, 26 October 2009 (UTC)

   Agree these proposals won't make it off the page; disagree that everyone has an equal vested interest. Admins will protect themselves like any cabal. As some wise person once said all professions are conspiracies against the public; I'd extend this to cover all vested interest groups. And I note you are an Admin who "won't shirk difficult blocks". And I thought blocking was just a few clicks. Sarah777 (talk) 23:44, 26 October 2009 (UTC)

   Actually, you have validated my view that allowing Admins to vote here is totally inappropriate. If they haven't the sense of propriety to recuse yourselves they should be recused by the hierarchy. Sarah777 (talk) 23:51, 26 October 2009 (UTC)

   I'm an admin, and I wrote one of the proposals. I doubt that has made me many friends in the admin corps. We are a varied group of people who are by no means in lockstep with one another, not a secret cabal bent on wikipedia world domination.Beeblebrox (talk) 18:51, 27 October 2009 (UTC)

8. Too easy to generate frivolous or vexatious requests. Stifle (talk) 09:42, 29 October 2009 (UTC)
9. Doesn't seem to protect sufficiently against frivolous requests, but otherwise fine assuming what is meant is that a ~70% majority would be needed to desysop. Christopher Parham (talk) 17:38, 29 October 2009 (UTC)
10. Per Stifle. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
11. I am concerned about the definition of the "user in good standing", which seems to be too narrow and too broad simultaneously. Ruslik_Zero 14:41, 2 November 2009 (UTC)
12. Oppose. Too easy to game the system. -FASTILY_sock ^(TALK) 00:06, 3 November 2009 (UTC)
13. Oppose per WereSpielChequers and the need to have discussion about substantive issues and about other possible outcomes. Jumping straight to the drama of "I want to desysop this guy, who else is up for it?" is really not good. Just consider the effect on morale even of failed attempts. Rd232 ^talk 09:45, 10 November 2009 (UTC)

Neutral (Option 4)

1. Still looking over it. Ncmvocalist (talk) 11:02, 16 November 2009 (UTC)

Option 5 (Declaration of no confidence)

Support (Option 5)

1. A minimalist proposal; as things stand, editors have their administrator access removed by ArbCom either after a long case (usually with little if any community dispute resolution) or in extraordinary circumstances by emergency motion. The Aitias case offers a way to repair this democratic deficit by tying the arbitrators and community consensus on admin rights closely together. We lose nothing in implementing this option (which is complementary with the others), and gain a much less dysfunctional situation than the status quo.  Skomorokh, barbarian  13:15, 25 October 2009 (UTC)
2. Nothing's going to pass directly from this RFC; there'll be further discussion/refinement before implementation. On that basis, I support exploring this further; it overlaps somewhat with Option 9, which I also supported. These are good directions to go in. Rd232 ^talk 10:59, 26 October 2009 (UTC)
3. Don't believe any action is needed to make this possible, I have no objections. Christopher Parham (talk) 17:41, 29 October 2009 (UTC)
4. Don't think this adds much more than we already have, but it would be a tiny step in the right direction. --Alecmconroy (talk) 12:50, 31 October 2009 (UTC)
5. Weak support - Less ideal than a completely community driven process, but does have some appeal as a minimalist approach. I see this as a "recommendation to de-sysop" from the community with a final say from ArbCom. As long as the community's will is normally followed I wouldn't really have much of a problem with it. --ThaddeusB (talk) 22:38, 15 November 2009 (UTC)

Oppose (Option 5)

1. Because it still lands at ArbCom's doorstep and they still make the call, defeating the purpose of having a new community driven process. Beeblebrox (talk) 17:40, 24 October 2009 (UTC)
2. Per Beeblebrox.  Sandstein  22:07, 24 October 2009 (UTC)
3. The community decides who is sysopped, we should decide who should be de-sysopped. ~~ GB fan ~~ ^talk 02:30, 25 October 2009 (UTC)
4. How it this new? It's just an appeal to ArbCom. Fences&Windows 00:15, 26 October 2009 (UTC)
5. Remains squarely at Arbcom's feet. MLauba (talk) 09:56, 26 October 2009 (UTC)
6. I like the idea, but the proposal has no teeth. Shereth 14:38, 26 October 2009 (UTC)
7. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:04, 26 October 2009 (UTC)
8. This is no different than the status quo. An RFCU is usually the step just before ArbCom anyway; there's nothing new here. Hersfold ^(t/a/c) 14:52, 27 October 2009 (UTC)
9. Two issues. First, the first line is "It has long been recognised that it is too difficult to remove sysop access from problematic administrators", which is a proof by assertion. Second, the matter ends up with ArbCom at the end, so it may as well start there. Stifle (talk) 09:43, 29 October 2009 (UTC)
10. Per Beeblebrox/Fences/Hersfold -- this adds nothing to the status quo.--Epeefleche (talk) 06:21, 1 November 2009 (UTC)
11. Not as good as status quo. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
12. Oppose. per Jayjg again. -FASTILY_sock ^(TALK) 00:07, 3 November 2009 (UTC)
13. Oppose because of too little community involvement, and too little difference from the status quo. --Tryptofish (talk) 00:34, 3 November 2009 (UTC)
14. Per Beeblebrox. Tony (talk) 05:40, 7 November 2009 (UTC)
15. Oppose Few if any of the options are free of the gaming risk, but placing obstacles in our own way, like running it past arbcom is just asking for the status quo without voting for it. Ohconfucius ^¡digame! 06:58, 10 November 2009 (UTC)
16. No change. Ncmvocalist (talk) 10:41, 16 November 2009 (UTC)

Neutral (Option 5)

1. This has some flaws, and reads to me as a draft. If the threshold for initiation is raised from one editor in good standing to three, seven days was stipulated as the normal duration, crats as the closers and we have more detail as to what levels of support ere required for the various outcomes then I might move to support. I like the formula of a petition to arbcom as route by which this could lead to desysopping, though I can see that if this took off then once the system bedded down that might be modified. ϢereSpielChequers 10:29, 26 October 2009 (UTC)
2. I see this as a version of option 0 (see my comments there). I do see delegating the final evaluation to arbcom as having benefit. RFA is gameable ([3] was a prescient comment) and an inverse-RFA (in any form) would likely be even more subject to gaming, since any admin who has been active for a while has probably accumulated more enemies than a new RFA candidate, and what we call "!voting" in practice turns out to be almost equivalent to voting. Arbcom is supposedly a cluocracy or the closest thing we have to one, so is hopefully harder to game. I don't propose to turn admin appointments over to arbcom, but RFA is well-known to be broken (even if it's improving slightly) and trying to replicate that same broken system at the de-adminning end just sounds ill-advised. 69.228.171.150 (talk) 00:41, 7 November 2009 (UTC)

Option 6 (re CAT:AOTR)

Support (Option 6)

1. Allowing admins to select their own criteria has obviously make the process open to gaming, but if applied uniformly and with a set standard, maybe the recall system could work. Nev1 (talk) 22:28, 25 October 2009 (UTC)

Oppose (Option 6)

1. There is little point in making a voluntary process mandatory, admins could simply set a ridiculously high bar for their own recall, "if one thousand Wikipedians unanimously agree I will quit, if there is one objection I will not." Beeblebrox (talk) 17:42, 24 October 2009 (UTC)
2. AOR has repeatedly shown itself to be a toothless RfA campaign promise. --Malleus Fatuorum 17:06, 24 October 2009 (UTC)
3. Per Malleus. AOR has never really worked, and enforcing it is illogical. JamieS93 21:39, 24 October 2009 (UTC)
4. But if it hasn't worked, it's because it was not mandatory and no uniform standard was used. I propose such a standard as option 7 below.  Sandstein  22:10, 24 October 2009 (UTC)
5. Each admin setting their own standards for when/how they can be recalled is not a solution, there needs to be one set of standards for all admins. ~~ GB fan ~~ ^talk 02:22, 25 October 2009 (UTC)
6. Really no way AOR can work. –Juliancolton | ^Talk 13:53, 25 October 2009 (UTC)
7. This is a discredited system and not worth relying on, even if it was reformed so that "I will resign if on the balance of complaints on this page I think it is time to go" ceased to be a valid set of AOR criteria. We've recently had admins desysopped by arbcom for matters that their recall rules excluded from consideration. ϢereSpielChequers 17:29, 25 October 2009 (UTC)
8. Oppose A good idea, executed poorly. Essentially only works if an Admin has never made any kind of content related edit to an article that exposes a propensity for critical thinking. Hiberniantears (talk) 20:51, 25 October 2009 (UTC)
9. This has been gamed rather frequently in the past. Christopher Parham (talk) 22:37, 25 October 2009 (UTC)
10. Elonka. Hipocrite (talk) 23:01, 25 October 2009 (UTC)
11. Arbitrary. Admins can set any criteria they like, making this toothless. Fences&Windows 00:20, 26 October 2009 (UTC)
12. Agree with Fences and windows. It doesn't make sense to uniformly enforce something but not by uniform criteria. delldot ∇. 01:15, 26 October 2009 (UTC)
13. Oppose - you need uniform criteria. And if you use the perhaps most widely used (MBisanz), you end up pretty much with Option 1 (which I support in that form, BTW). MLauba (talk) 09:59, 26 October 2009 (UTC)
14. Oppose - per sandstein and fences and windows. This just would not work in my opinion. AtheWeatherman 10:52, 26 October 2009 (UTC)
15. Does not seem to address the problem at hand. Shereth 14:39, 26 October 2009 (UTC)
16. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:05, 26 October 2009 (UTC)
17. Oppose per all of the above.--Epeefleche (talk) 06:39, 27 October 2009 (UTC)
18. No, wouldn't work. Hersfold ^(t/a/c) 14:53, 27 October 2009 (UTC)
19. The category was created on the basis of it being voluntary, and if it was mandatory there wouldn't be any point the category existing since the list of administrators would cover its function! A uniform criteria would be needed for something mandatory, otherwise the current problem of it being too open to abuse will continue. Camaron · Christopher · talk 19:38, 27 October 2009 (UTC)
20. Oppose. I believe the community must have a uniform standard by which administrative recall might be judged, although I think administrators should be able to hold themselves to weaker criteria than the community might otherwise insist on. The current system of AOR allows to much variation in the standard, and allows admins to change their criteria. I might be willing to support a more defined proposal that specifies what the criteria should be. Karanacs (talk) 20:38, 28 October 2009 (UTC)
21. Rather pointless, as it's easily defeated by making ludicrous criteria. Stifle (talk) 09:44, 29 October 2009 (UTC)
22. Nope-- AOR doesn't work. --Alecmconroy (talk) 12:57, 31 October 2009 (UTC)
23. Oppose. Non-uniform, open to gaming. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
24. Oppose. Not very uniform. Could be easily gamed. -FASTILY_sock ^(TALK) 00:08, 3 November 2009 (UTC)
25. Strong oppose, because it simply expands a system that is too ad-hoc, and can be too easily gamed by the admin subject to recall. --Tryptofish (talk) 00:37, 3 November 2009 (UTC)
26. Oppose - to work any de-sysop process must be uniform.--ThaddeusB (talk) 22:51, 15 November 2009 (UTC)
27. Oppose A non-standard system is really no system at all. There needs to be a single set of standards, not hundreds of arbitrary self-designed systems. Jim Miller ^{See me | Touch me} 15:06, 16 November 2009 (UTC)

Option 7 (User:Sandstein/Reconfirmation RFA)

Support (Option 7)

1. As proposer. The parameters (WP:100 editors, 18 months minimum interval between reconfirmation RFAs, 65%-80% discretionary range for success of reconfirmation RFAs) are open to discussion, of course.  Sandstein  21:50, 24 October 2009 (UTC)
2. Support dependent the change I suggested on proposals talk page. [4] RxS (talk) 16:17, 25 October 2009 (UTC)
3. 3rd choice. I like the idea of the cumulative list, that is an excellent way to record community dissatisfaction with an admin over time. 100 editors may be a bit high, but the principle is good. This is compatible with Uncle G's suggestion. Fences&Windows 00:23, 26 October 2009 (UTC)
4. My favorite choice. I would specify a time interval in which to gather those 100 or so signatures -- I actually think something more discretionary, such as, say "equivalent to some fraction of supporters at last RfA" might be better. As for time, more than a week, but less than 90 days before signatures go stale for certain - you don't want this to be excessively open-ended. Ray^Talk 06:18, 26 October 2009 (UTC)
5. Support -- a rolling list might be helpful, but only votes within the last 90 days count towards the 100. --Alecmconroy (talk) 13:11, 31 October 2009 (UTC)
6. Moral support, even though I don't have that much enthusiasm for the 100 signatures, in that it can become a process-without-end that could be needlessly unpleasant for a good admin. But the spirit of community input is a step in the right direction. --Tryptofish (talk) 00:41, 3 November 2009 (UTC)

Oppose (Option 7)

1. Weak oppose mainly it's the 100 users thing. I understand that the intent is stop frivolous complaints, but many admins (including myself) got the bit with far less than 100 supporters. And keeping a running list of users who want a particular admin desysopped open indefinitely seems, well, mean. Beeblebrox (talk) 06:56, 25 October 2009 (UTC)
2. Weak Oppose Concur that 100 is too unreasonably high. --Cybercobra (talk) 12:09, 25 October 2009 (UTC)
3. Weak Oppose, I like the idea, but as is mentioned above, 100 editors thinking someone should stand a reconfirmation is high. Also the indefinite list is another negative. ~~ GB fan ~~ ^talk 14:38, 25 October 2009 (UTC)
4. Oppose Due to the open ended nature of the 100 users. Obviously open to abuse by long term sock/meatpuppets. We have ample evidence that a substantial number of editors here are willing to maintain disputes and deception for years at a time. I'm still uncomfortable with a narrower time frame, but it would be preferable. Likewise, our policies and standards of behavior change significantly on this project, often in a time range of months. Something that was unacceptable last year could be acceptable now (as well as the reverse). Hiberniantears (talk) 20:42, 25 October 2009 (UTC)
5. Standards for the reconfirmation RFA seem high given that any such reconfirmation is likely to be initiated in the fire of a particular erroneous or controversial action by the admin in question. Christopher Parham (talk) 21:49, 25 October 2009 (UTC)
6. Oppose There's no notion of "decay", because it's easy for an editor to sign in the heat of the moment yet completely forget about it a couple of days later when he no longer cares or even agrees, on second thought, with the admin. I'm also uncomfortable with the running list, as Beeblebrox. MLauba (talk) 10:03, 26 October 2009 (UTC)
7. Oppose. This is like a really badly thought out recall referendum, with fairly obviously catastrophic consequences for those few admins willing to make tough-but-necessary calls that piss lots of people off on both sides of an argument. A recall referendum approach is reasonable to consider, but it needs signatures collecting over a reasonable, limited timeframe, based on some reasonably well-constructed argument, not an open-ended list of "people I once pissed off, who may have forgotten and/or left long ago". Making the number of signatures absurdly high (100) is a flawed attempt to fix the basic problem with the idea, namely its open-endedness. Rd232 ^talk 10:50, 26 October 2009 (UTC)
8. Strong Oppose In my view an unworkable drama generating trollfeeding exercise. It would disappoint those who want various editors desysopped but can't get 100 people to agree until the incident is long forgotten, and leave every admin with a steadily growing list, including from retired users who had signed without giving a reason for the desysop. ϢereSpielChequers 12:41, 26 October 2009 (UTC)
9. Unreasonable requirements. Shereth 14:42, 26 October 2009 (UTC)
10. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:05, 26 October 2009 (UTC)
11. Oppose - this is pointless and hardly improves on the current situation. Sarah777 (talk) 21:21, 26 October 2009 (UTC)
12. Oppose 100 is way too high.--Epeefleche (talk) 06:32, 27 October 2009 (UTC)
13. If you have 100 users in good standing say you should resign the tools, then quite frankly you either need to resign them yourself or you're already under ArbCom's gavel. I understand and appreciate the attempt to protect the accused, but setting the bar that high is entirely impractical. Hersfold ^(t/a/c) 14:56, 27 October 2009 (UTC)
14. Oppose I think this will be impossible to judge. 100 users is much too high a threshhold, and after 100 people have signed there should be no reason for an RfA - you've obviously already lost the community's confidence. Also, it would be difficult to audit this list. It is highly likely that some editors would sign, later change their minds, and forget to go strike their name. Furthermore, admins who are very active in routine tasks (including blocking and deletions) run the risk of having editors they have sanctioned or disappointed signing the petition out of spite. And then there is the issue of sockpuppets... Karanacs (talk) 20:41, 28 October 2009 (UTC)
15. There should be a timeframe for the collection of signatures; I'm sure I've offended 100 users over the course of my time as a sysop here, 90 or more of whom will have shrugged it off but might have been so annoyed at the time as to demand my removal as an admin. Stifle (talk) 09:45, 29 October 2009 (UTC)
16. Worse than status quo. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
17. Never. -FASTILY_sock ^(TALK) 00:08, 3 November 2009 (UTC)
18. Oppose—It's all said in this section. Tony (talk) 05:49, 7 November 2009 (UTC)
19. Oppose Per Beeblebrox and others here. A hundred? A googolplex was too much so a hundred sounded more reasonable? Greg L (talk) 05:22, 8 November 2009 (UTC)
20. Oppose plenty of checks, insufficient balance. Ohconfucius ^¡digame! 07:03, 10 November 2009 (UTC)
21. Oppose 100 editors is way to high and the no time limit isn't ideal either. --ThaddeusB (talk) 22:58, 15 November 2009 (UTC)
22. Oppose per above. Ncmvocalist (talk) 10:53, 16 November 2009 (UTC)

Option 8 (reconfirmations)

Support (Option 8)

1. There are some parts to this that I like, and other parts that I don't. I like the straight-forwardness of a simple reverse RfA. However, this process seems either too flimsy or too useless, depending on how you look at it. If it is just one (experienced?) editor in good standing making the call whether to put an administrator through this process, I would dislike it. If the administrator has the choice of acceeding to the request, I would dislike it. I would much prefer that at least five very experienced editors have to ask the administrator to get through this process. Perhaps it could be changed to that? NW (Talk) 15:32, 25 October 2009 (UTC)
2. Support I support this with a condition. No consensus results in an admin keeping their adminship. What we consider consensus for granting adminship should also be considered for deadminship. Generally I think 70-80% oppose to adminship is required to remove adminship. This is because if many of the current administrators had to go up before RfA without a FA or GA, they could fail on those grounds and not on any poor admin grounds.--TParis00ap (talk) 16:52, 25 October 2009 (UTC)

   Makes sense to me. - Dank (push to talk) 18:29, 25 October 2009 (UTC)

   RFA standards have been greatly inflated since most admins were appointed, and whilst once a good vandalfighter could pass, nowadays RFA not unreasonably requires candidate to have contributed to the encyclopaedia. But thankfully the need an FA or GA meme has subsided of late. However I'm not sure I agree that an admin could or should continue if a majority of the community wanted them desysopped. ϢereSpielChequers 12:52, 26 October 2009 (UTC)

   "if a majority of the community wanted them desysopped", yes, but how representative of the community are RFA voters in a reconfirmation RFA? Selection bias is going to be a much bigger problem than with a standard RFA... Rd232 ^talk 17:27, 27 October 2009 (UTC)

   I wouldn't have a problem with there being a minimum threshold, say at least 30 !votes for a desysop. But if 30 !vote for a desysop and only 15 disagree, the admin in question should IMHO be desysopped. ϢereSpielChequers 22:55, 28 October 2009 (UTC)

   The problem I see is that you can look at it two ways, which I explained below. You can either look at it as a consensus to reconfirm, where a non consensus would mean no reconfirmation; or you could look at it as a consensus to desysop, where a non consensus would mean no desysop. Both ways of looking at it would have community consensus but would be judged differently. A majority support could mean reconfirmation or a majority oppose could mean desysop, but it is the in the middle that I am worried about. What happens when there is 50 support and 50 oppose (and 50 neutral for the sake of being fair)? Is that a reconfirm via no consensus or a desysop via no consensus? I look at an RfA on an administrator as a RfDA using the RfA process where no consensus would mean the admin would keep their adminship. It should take a consensus of oppose to desysop where it originally took a consensus of approve to grant sysop.--TParis00ap (talk) 21:32, 30 October 2009 (UTC)

   I don't think participant selection bias would be much of a problem (if high profile RFAs are any indication hundreds of participants could be expected) but the bias caused by holding the RFA in the immediate aftermath of the admin's most severe error would certainly cloud things. This issue I think warrants requiring a substantial consensus to desysop. Christopher Parham (talk) 15:24, 4 November 2009 (UTC)

3. Support with wariness because of the low-thresholding. However, current RfA does not suffer too much from low thresholding, the egos of new editors who get snow rejections aside. However, I disagree with TParis00ap - existing admins should not enjoy privileged status above new admin-candidates in the same process. Their existing status and past behavior will clearly be taken into account by voting editors, which I expect to get an additional base of support. Ray^Talk 06:41, 26 October 2009 (UTC)

   I do not feel I am giving them privileged status in my request. It currently takes consensus to adminship, it should also take consensus to deadminship. You are looking at it as a reconfirmation, I am looking at it as desysop. One approach is consensus to reconfirm and the other is consensus to desysop. I suggest the latter and you suggest the former. Both are valid points of view, I definitely see where your coming from, but I think consensus to desysop is the better. If no consensus is achieved, no action should be taken.--TParis00ap (talk) 19:22, 30 October 2009 (UTC)

4. Support - 2nd preference; unless there is a forced recall element this whole exercise is pointless. But again, we need very explicit definitions of "editors in good standing". Sarah777 (talk) 21:47, 26 October 2009 (UTC)
5. Support. I like this except that I think one user initiating it is too low. Any administrator can make enemy just by using the tools properly, and we'd all end up in reconfirmation proceedings all the time. Karanacs (talk) 20:44, 28 October 2009 (UTC)
6. Conditional Support per Karanacs. This is my preferred option, but I don't think it's workable with a single initiator. I don't know what the right number would be, perhaps 5. Have it so that a single editor can initiate the process, and the rfa goes ahead if there are the requisite number of additional signatories within a week. MoreThings (talk) 22:08, 28 October 2009 (UTC)
7. Support, but agree it would be better having 5, 10, or even 20 editors required to initiate. --Alecmconroy (talk) 13:14, 31 October 2009 (UTC)
8. Support We don't need convoluted processes for this. Frivolous or vexatious requests can be speedy closed, just as RfAs are early closed when they don't stand a chance in hell. Gigs (talk) 22:21, 3 November 2009 (UTC)
9. Tentative support - Proposal is along the correct lines (simple to understand, not particularly different than RfA), but without any details it is hard to support outright. --ThaddeusB (talk) 23:02, 15 November 2009 (UTC)

Oppose (Option 8)

1. Weak oppose; "if a user in good standing requests it" - (a) could be open to frivolous requests (b) who defines "a user in good standing"? Bsimmons666 (talk) 15:36, 25 October 2009 (UTC)

   Frivolous/malformed requests would be dealt with by the community, just like any other RfA. –Juliancolton | ^Talk 19:03, 25 October 2009 (UTC)

   For what it's worth I attempted to explain the concept of a user in good standing as I use that phrase in my proposal as well. Generally, it's any autoconfirmed user with a clean recent block log. I don't think any of these proposals would allow a user to make a report or case or whatever as one of their very first edits, as common sense would tell us they would be a troll or a sock of some sort. Beeblebrox (talk) 19:06, 25 October 2009 (UTC)

2. Oppose Similar to my reason for opposing the idea above this one: Obviously open to abuse by long term sock/meatpuppets, and we have ample evidence that a substantial number of editors here are willing to maintain disputes and deception for years at a time. RfA is already gamed to no end, and this would just take a poorly functioning process and make it even more corrupted. Hiberniantears (talk) 20:46, 25 October 2009 (UTC)
3. Too many admins to be practicable. would need aprox 19 reconfirmations a week to keep pace. Spartaz ^Humbug! 22:57, 25 October 2009 (UTC)

   Err? I didn't say we need to reconfirm all admins, just those whose use of the sysop bit is in questioned... –Juliancolton | ^Talk 23:21, 25 October 2009 (UTC)

4. No threshold to opening. Fences&Windows 00:25, 26 October 2009 (UTC)
5. Oppose Because I think that people are entitled to know why someone thinks they should be desysopped. Also it should need at least three editors to initiate this procedure, but it would be unsatisfactory if once this started an admin could keep the tools against the wishes of 60% of the community. ϢereSpielChequers 12:59, 26 October 2009 (UTC)
6. Weak oppose - I like the idea but the requirements are a little too weak. Need to a higher bar to initiate. Shereth 14:45, 26 October 2009 (UTC)
7. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 16:05, 26 October 2009 (UTC)
8. Weak oppose - I also like the idea but feel the requirements are a little too weak.--Epeefleche (talk) 06:37, 27 October 2009 (UTC)
9. Prefer option 4 above; this proposal makes no attempt to protect the accused and has the potential to waste the community's time. Hersfold ^(t/a/c) 14:58, 27 October 2009 (UTC)
10. Absolutely not, unless you feel like having 50+ frivolous or vexatious recalls on the go at any one time. Stifle (talk) 09:46, 29 October 2009 (UTC)
11. Too little protection against frivolous requests. Christopher Parham (talk) 17:45, 29 October 2009 (UTC)
12. Per the above; too easily abused.  Sandstein  14:49, 30 October 2009 (UTC)
13. Too easy to abuse. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
14. Oppose Too easy to abuse. -FASTILY_sock ^(TALK) 00:09, 3 November 2009 (UTC)
15. Mild oppose, simply because I think other proposals here have a lot more details thought out. --Tryptofish (talk) 00:43, 3 November 2009 (UTC)
16. Totally impractical. Tony (talk) 06:00, 7 November 2009 (UTC)
17. Oppose completely lacks balance. Almost guaranteed to attract vexations complaints and cause drama. Ohconfucius ^¡digame! 07:09, 10 November 2009 (UTC)
18. Oppose Single user threshold is simply too low. Dispruptive requests are far too likely. Jim Miller ^{See me | Touch me} 14:45, 16 November 2009 (UTC)

Neutral (Option 8)

1. Hmm, seems a good idea in theory, and is very simple, but will need a lot of work before this solution becomes viable a shown in the oppose section. AtheWeatherman 10:52, 26 October 2009 (UTC)
2. Still looking over this. Ncmvocalist (talk) 10:52, 16 November 2009 (UTC)

Option 9 (Devised by Jake Wartenberg)

Support (Option 9)

1. Avoids the issues blocking a lot of the other proposals, I think. — Jake Wartenberg 16:32, 25 October 2009 (UTC)
2. This is the direction I was thinking in independently - it builds best on existing processes, with least bureaucracy. If it doesn't work for some reason, the issue can be revisited later. I would suggest, though, to minimise Bureaucrat workload, that requests to Bureaucrats to review an Admin Conduct RFC have to be made by an uninvolved admin. (Also, an alternative to Bureaucrats deciding if an RFA is necessary would be ARBCOM deciding that, again with referral by an uninvolved admin.) Rd232 ^talk 16:58, 25 October 2009 (UTC)
3. 2nd choice. The RfC is an existing process, the bureaucrats only need to agree that a RfdA is necessary rather than actively supporting deadminship, and will work like RfA, so a familiar process. However, other ways to open an RfdA might be needed in addition to the RfC-Bureaucrats-RfdA route. Fences&Windows 00:29, 26 October 2009 (UTC)
4. This is tied for my second choice. As Rd232 mentions, it builds well on existing processes that are familiar to a lot of users. Karanacs (talk) 20:46, 28 October 2009 (UTC)
5. Equal preference to my proposal, option 7.  Sandstein  14:49, 30 October 2009 (UTC)

Oppose (Option 9)

1. Seems very difficult for bureaucrats. "Should this person be an admin" is not even the question that admin RFC asks; taking the average admin RFC, for a bureaucrat to read that and answer "should this person be reconfirmed?" is a pretty impossibly subjective question. Christopher Parham (talk) 22:24, 25 October 2009 (UTC)

   My first reaction was that you hit the nail on the head, Christopher, but now I'm not so sure ... maybe this bug is actually a feature. Arguments about whether someone should be de-mopped are going to involve a lot of "philosophy of adminship" that the crats really don't need to hear, arguments that aren't relevant to the typical RFCU. I'd be happier if the conversation were bout whether tools were misused, temper-tantrums were thrown, etc. Under this plan, the crats wouldn't have to decide from all this whether the person should be desysoped, only whether there's a significant chance that a desysoping vote would succeed. Btw, I think WP:CONSENSUS probably constrains the crats to only desysop at the reconfirmation vote if there's consensus to remove the tools. - Dank (push to talk) 23:29, 25 October 2009 (UTC)

   The point is that if you take a discussion unrelated to desysopping (an admin RFC), determining whether a desysopping vote would have a significant change of success is quite hard. Most comments in the discussion will not bear on the issue. Christopher Parham (talk) 23:45, 25 October 2009 (UTC)

   "Most comments in the discussion will not bear on the issue." That's where my amendment comes in - bureaucrats wouldn't be asked (by an uninvolved admin) to think about this if there wasn't anything to think about. Rd232 ^talk 10:44, 26 October 2009 (UTC)

2. Not sure this is the best option - this isn't within the crat's remit, and drags things out through two current processes. If it can be shown the crat corps would be amenable to this, I might go to support, but I still feel there are better options. Hersfold ^(t/a/c) 15:03, 27 October 2009 (UTC)
3. Oppose. Per Christopher Parham, Hersfofd. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
4. Oppose per above. This really isn't what we elected crats for and it gives them significantly more power. Power which, if abused, could result in quite the amount of infighting. -FASTILY_sock ^(TALK) 00:11, 3 November 2009 (UTC)
5. Oppose as an inappropriate role for crats. --Tryptofish (talk) 00:45, 3 November 2009 (UTC)
6. Oppose per above. This adds too much to the 'crats role. Very bad idea. Jusdafax 04:03, 16 November 2009 (UTC)
7. Oppose per above. Ncmvocalist (talk) 10:42, 16 November 2009 (UTC)

Neutral (Option 9)

1. This has much to commend it, but some flaws, including the extra step of an RFA after the RFC. I might move to support if this was amended into RFC including an option to desysop subject to a few safeguards ϢereSpielChequers 13:58, 26 October 2009 (UTC)
2. The proposal has merit, but I am uneasy about the bureaucrat voting step. I also agree with WereSpielChequers that the RfC + RfA requirement might be a bit much. --ThaddeusB (talk) 23:07, 15 November 2009 (UTC)

Option 10 (User:Tim Smith/Administrator-initiated recall)

Support (Option 10)

1. Support as creator. Tim Smith (talk) 23:16, 27 October 2009 (UTC)
2. 6th choice. Would work. I'd prefer that non-admins could open the RfdA, but it'd be better than nothing. Fences&Windows 05:07, 28 October 2009 (UTC)
3. Support as first choice. I think this is very workable. Non-admins could request these at ANI. Karanacs (talk) 20:47, 28 October 2009 (UTC)
4. Mild support. Not a high choice for me, but the issue of having an admin start the process is worth looking at more seriously. I prefer some of the other proposals on who initiates, but this does help deal with the issue of not letting a bad editor use the process for pay-back. --Tryptofish (talk) 00:49, 3 November 2009 (UTC)

Oppose (Option 10)

1. You don't have to be an admin to nominate someone at RFA, it's not fair to suggest that only an admin would have the judgement to initiate the proceeding. Also, and I hate to keep beating this drum but nobody seems to hear it so here we go again, I don't think "user in good standing" is a nebulous concept or an unknown quantity. It's any autoconfirmed or higher user with a clean recent block log. This whole proposal seems to be a knee jerk reaction to quickly throw out something that deals with perceived problems in the other proposals, the entire bottom of the page is all "unlike other proposals." None of these are going to be perfect, they are all bound to need a little fine tuning before being implemented. Beeblebrox (talk) 02:33, 27 October 2009 (UTC)

   I didn't mean to suggest that only an admin would have the judgement to initiate the proceeding. That requirement is just a way to filter out frivolous requests and avoid unnecessary drama. Not everyone defines "good standing" in the same way, as you'll see if you look through the other proposals. For example, in Option 4, users in "good standing" are "active editors on the English Wikipedia, with accounts more than three months old and with no fewer than 500 edits" who are not "subject to Arbitration enforcement editing restrictions, Arbitration Committee restrictions, or Community restrictions". In Options 5 and 8, "good standing" is not defined at all. Even your own definition is ambiguous: how recent is "recent"? I think it's simpler to use familiar, well-defined user classes. In my proposal, an administrator initiates a recall, and the whole community of registered users weighs in on it. This is not a knee-jerk reaction at all. I had this idea before the RfC started, and first got involved in recall discussions years ago; administrator accountability is a long-standing concern of mine. I'm serious about this proposal and I think it really does have some advantages over the alternatives. Tim Smith (talk) 23:13, 27 October 2009 (UTC)

2. Per Beeblebrox.--Epeefleche (talk) 06:24, 27 October 2009 (UTC)
3. Per above really. Shereth 14:06, 27 October 2009 (UTC)
4. Oppose Per opinion that any forced recall process is too open to gaming. -- Avi (talk) 14:49, 27 October 2009 (UTC)
5. Efforts to protect the accused are insufficent. Hersfold ^(t/a/c) 15:05, 27 October 2009 (UTC)
6. "finding at least one administrator to recall them should not be hard" sounds like implicit encouragement for going to the other parent. rʨanaɢ ^talk/_contribs 16:50, 27 October 2009 (UTC)

   You're right, and I didn't mean to encourage that. I've reworded it; I hope you'll take another look. Tim Smith (talk) 21:40, 27 October 2009 (UTC)

7. I like the week between notifying the desysop candidate and initiating the process. However I don't agree with the admin only rule about initiating the process. There does need to be a filter to prevent frivolous proposals, but not in my view an admin based one. I also don't like the idea of a process that can only choose between desysop and not desysopping. ϢereSpielChequers 00:05, 29 October 2009 (UTC)
8. Still too easy to have vexatious requests. On the other hand, if the result of a failed recall was that the nominator was desysopped instead, I might be tempted. Stifle (talk) 09:49, 29 October 2009 (UTC)

   That's flat-out ridiculous. "Two men enter, one man leaves"?? Rd232 ^talk 10:11, 29 October 2009 (UTC)

   Funny you should say that. I got the idea for this proposal from a suggestion by User:Alecmconroy titled "Single-Admin-initiated RFAs (aka Thunderdome)", in which inter-admin disputes would be resolved by having both admins independently stand for RfA. In my proposal, the subject of a recall could choose to start a separate recall of the nominating admin, but it's not required, since the nominator might not have done anything wrong. Tim Smith (talk) 17:20, 29 October 2009 (UTC)

9. Oppose. Doesn't permit sufficient discussion in advance of an RFA as to what the appropriate response to alleged errors or misdemeanors (if any) should be. A reconfirmation RFA, once started, is high drama, and it requires a more thoughtful process before launching one. For one thing, ANI is not the venue for that. Rd232 ^talk 16:54, 29 October 2009 (UTC)
10. Too open to gaming. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
11. Oppose. per the above. Open to gaming. -FASTILY_sock ^(TALK) 00:11, 3 November 2009 (UTC)
12. No. Tony (talk) 06:03, 7 November 2009 (UTC)
13. Oppose inegalitarian. Ohconfucius ^¡digame! 07:11, 10 November 2009 (UTC)
14. Weak oppose That any user can participate is a big plus to this particular proposal, but I think having the request at RfA when the !voting works differently would probably lead to confusion. I'm not wild about the idea of "admin initiated" but I could live with it. --ThaddeusB (talk) 23:12, 15 November 2009 (UTC)

Neutral (Option 10)

Option 11 (AdminRFC+RFA)

Support (Option 11)

1. Obviously. (My proposal.) Rd232 ^talk 13:10, 27 October 2009 (UTC)
2. 5th choice. You mean that at the end of an RfC the closing admin can open a RfdA? If so, it's simple. I'm not sure though that the decision to open a RfdA should only ever follow an RfC or be at the discretion of the closing admin. Fences&Windows 05:01, 28 October 2009 (UTC)

   It's not merely at the discretion of the closer, it's at the discretion of any uninvolved admin who reckons that the RFC opinion demands one, and that the RFC sufficiently represents community opinion to act on. Rd232 ^talk 10:11, 28 October 2009 (UTC)

   Oh, right, even better. Fences&Windows 21:53, 28 October 2009 (UTC)

3. Tied for second choice. This leverages existing processes in a good way. Karanacs (talk) 20:49, 28 October 2009 (UTC)
4. Equal preference to 7 and 9, though I'd prefer it if a bureaucrat were to file the RFA.  Sandstein  14:55, 30 October 2009 (UTC)

   That would make it similar to 9. I avoided that for some of the reasons given by people opposing option 9, but depending on how we proceed from this RFC in amending/merging/choosing options, that could be debated. Rd232 ^talk 15:43, 30 October 2009 (UTC)

5. Support - Requiring an RfC isn't my first preference, but I can certainly see merit in that step. If we go that route, this is the way to do it b/c it keeps it simple and doesn't ask the 'crats to do something they weren't elected to do. --ThaddeusB (talk) 23:17, 15 November 2009 (UTC)

Oppose (Option 11)

1. Needs more fleshing out; no indication of what it means for "the community's view" to be that a reconfirmation RFA is required. Christopher Parham (talk) 20:18, 27 October 2009 (UTC)

   It's not spelled out because it doesn't need to be: cf WP:CREEP. We use consensus, as applied eg at WP:ANI. Rd232 ^talk 21:59, 27 October 2009 (UTC)

   "Consensus" would probably be a better term than "community's view" then. However, the structure of RFC, as mentioned above, would make it quite difficult to arrive at such a determination; it would be hard to turn a handful of outside views with varying levels of support, few directly addressing the issue, and divine a clear consensus on the issue of whether an admin requires reconfirmation. It would be better to use a new venue where the question (is reconfirmation required) rather than a venue like RFC which is focused on different issues. Christopher Parham (talk) 12:37, 28 October 2009 (UTC)

   That seems more like a fixable flaw in the RFC system than anything else. Proposed rmedies are supposed to be clearly discussed, and one of those could easily be reconfirmation RfA. Rd232 ^talk 13:05, 28 October 2009 (UTC)

   I would say the contrary: discussion of remedies (in the form of involuntary sanctions like a reconfirmation RFA) are best avoided at RFC because they corrupt the effort to bring about agreement via discussion. From the RFC instructions: "it is a tool for developing voluntary agreements and collecting information." This would turn it into a step in the process of imposing involuntary sanctions against an administrator, as a forum for gaining consensus that a reconfirmation RFA is required. RFC is supposed to be an open discussion, not a trial. Christopher Parham (talk) 14:18, 28 October 2009 (UTC)

   RFC/U has long had the possibility of concluding that voluntary agreements are not feasible (eg if the subject declines to participate). Formally non-voluntary measures are outside the RFC process, but that's a technicality (and one respected in the formulation of this option). A double protection prevents ignoring other remedies or outcomes than desysopping: (a) an uninvolved admin has to agree (and that should include consideration of what other measures have been discussed or taken previously) (b) RFA has to result in that. The whole point of RFC is precisely to be open-ended - we just seem to disagree on whether the setup would achieve that. Fair enough, but I'd argue we're better off tweaking a familiar, established process if problems arise than creating new ones in case they do (as if those new ones couldn't have their own issues). Rd232 ^talk 22:45, 28 October 2009 (UTC)

   Also, on the issue of "corrupt[ing] the effort to bring about agreement via discussion." - RFC/U is not mediation, it is a Request For Comment on User Conduct. All outcomes should be discussable, including ones not formally enforceable as a direct outcome of the process. This is no different to WP:ANI - there is no formal mechanism for saying any particular ANI thread has to lead to enforceable outcomes; it's open-ended, and any enforcement is done by those we trust to enforce appropriately, namely admins, on the basis of community opinion and established custom, guidelines, and policy. Rd232 ^talk 22:52, 28 October 2009 (UTC)

   RFC will almost certainly no longer be open-ended, because it is now the place where you go to get someone desysopped and it has two definite outcomes. The only possible endpoints are successful further progress down the road to desysopping or failure to desysop the subject: it turns from an open discussion into a grand jury. Even if someone did initiate an RFC without that outcome in mind, it would be perceived in that manner and at any rate since they had lost control of the process after initiation, it could go to reconfirmation even if that was not the initiator's intent. Christopher Parham (talk) 01:29, 29 October 2009 (UTC)

   You're basically declaring that an open-ended discussion is actually a binary decision process, which is clearly not the case. What amazes me is that you don't seem to address the same criticism with ten times more vehemence at proposals not framed around RFC, which are actually binary processes. Rd232 ^talk 09:48, 29 October 2009 (UTC)

   I don't have a problem with binary processes - what I am complaining about is taking something designed as an open-ended collaborative process (admin RFC) and transforming it into a binary prosecutorial process. Sure there are still multiple possible outcomes, but only two that matter. It's impossible to have a constructive discussion at RFC when any admission of an error could lead to a reconfirmation RFA. Now people are wary of supporting a statement that says "this admin made a significant, but singular and good faith error, in this case", if they don't want that admin desysopped. The problem isn't that the final process is binary, it's that you've ruined RFC in arriving there. Christopher Parham (talk) 13:22, 29 October 2009 (UTC)

   Let's just agree to differ. That's not the intention, and I don't expect that to be the outcome. The idea that occasional (or even one-off) good faith errors might lead to RFA seems implausible (which uninvolved admin is going to launch an RFA for that?), and that such an RFA would actually lead to desysopping, even more so. And to reiterate, I completely reject your notion that this would create a binary process. The framework as described just isn't there to make that happen. It's an open-ended discussion, and declaring it a binary process doesn't make it so. Rd232 ^talk 16:44, 29 October 2009 (UTC)

2. As ever, too easy to make frivolous or vexatious requests. Stifle (talk) 09:49, 29 October 2009 (UTC)

   How so? It requires the standard bar to launching an RFC/U (two users who tried to settle the dispute), and then an uninvolved admin to launch an RFA, if it's warranted. And the RFA itself still has to lead to desysopping, and the whole point about RFC I'm trying to make to Chris Parham above is that it is an open-ended discussion which might lead to all sorts of remedies or voluntary agreements. Rd232 ^talk 09:59, 29 October 2009 (UTC)

   Sorry, I've been on Wikibreak. If three users could kick off a deadminship discussion, we would end up with dozens on the go at once. Not all users, and not even all admins, aren't vindictive. Stifle (talk) 11:18, 10 November 2009 (UTC)

3. Per Stifle. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
4. Oppose per Stifle. Easy to game, could cause a lot of infighting. -FASTILY_sock ^(TALK) 00:13, 3 November 2009 (UTC)
5. Oppose, because the process of determining whether there is consensus for the process to go forward will end up being drama before the process even gets underway. Not really an improvement on the status quo. --Tryptofish (talk) 00:53, 3 November 2009 (UTC)
6. Oppose, per Stifle, Fastily. Tony (talk) 06:05, 7 November 2009 (UTC)

   Would be nice if some of the people saying "per Stifle" responded to my question to him, which he hasn't answered. Rd232 ^talk 11:28, 7 November 2009 (UTC)

Neutral (Option 11)

1. Undecided. I don't feel as though this protects the accused sufficiently. Hersfold ^(t/a/c) 15:06, 27 October 2009 (UTC)

   It requires an uninvolved admin to decide that an RFC has concluded that an RFA is needed, agree that the RFC sufficiently represents community opinion and then launch an RFA, and then an RFA to actually succeed. What higher standard of protection would you suggest? Rd232 ^talk 15:22, 27 October 2009 (UTC)

   To be honest, I'm not really sure. RFCs have a tendency to turn into pitchfork mobs, but having the admin determine the result may help balance some of that out. This does cover things a bit more than others, hence neutral instead of oppose. I'll keep thinking about it. Hersfold ^(t/a/c) 20:56, 29 October 2009 (UTC)

   Thank you. I think it makes more sense to have energies feed into improving the existing, generally applicable RFC process (see WT:RFC#Revamp) than on creating a new, very specific process. Rd232 ^talk 21:01, 29 October 2009 (UTC)

2. I'm in the same boat as Hersfold. Ncmvocalist (talk) 10:45, 16 November 2009 (UTC)

Option 12 (Reconfirmation initiated by the Arbitration Committee)

Support (Option 12)

1. As proposer. Cenarium (talk) 01:35, 28 October 2009 (UTC)
2. I hadn't heard of this or thought of it before, but it's interesting. I can support this, except for the last bit; ArbCom is the final arbiter of matters on en.wikipedia. But I don't think this matters; if ArbCom is fine with handing something off to voters and the crats, they're not likely to want to overturn the decision unless something dramatically bad has happened. I don't think voters would need to fear that the decision isn't in their hands; almost always, it will be. But on the main point: there's a chance that this would give you the best of both worlds; ArbCom could use their behind-the-scenes knowledge to blunt the top complaint of the people supporting the status quo, that recall is too open to gaming, by making a determination that it's not gaming and that the community has legitimate concerns, then they could let the community decide. - Dank (push to talk) 19:18, 28 October 2009 (UTC)
3. Support. I do believe Arbcom should have the authority to call for a reconfirmation RfA, but I don't believe that should be the only method to open one. This is better than nothing, but would work best in conjunction with other proposals. Karanacs (talk) 20:50, 28 October 2009 (UTC)
4. Sort-of-support. No, I don't see this as actually being the proposal that should come out of this discussion, and I'm not convinced it really differs from the status quo, but I want to make the point that what does come out of this discussion should include, as an option, the ability of ArbCom to start the process, in addition to a mechanism for initiation by the community. --Tryptofish (talk) 00:57, 3 November 2009 (UTC)
5. Support. This maintains the status quo to an extent, where administrators can only be involuntarily removed for cause, but formalizes a removal process. This seems to allow those who do their jobs to do the work without fear of retaliation for petty matters, since when you consider the number of admins we have, we'd be doing a lot of re-RFAs if people were up for reconfirmation every few years. But this formalizes a process for removing those who obviously have abused their mop. I've always viewed admins as like civil servants to an extent. They're entrusted with the tools by the community, and the tools should only be removed for cause, but this determines a process of determining cause. SchuminWeb (Talk) 03:42, 3 November 2009 (UTC)

Oppose (Option 12)

1. Oppose. If the entire community holds a no-confidence RFC/U, there's no need to pass it to ArbCom. It's not ArbCom's role to approve or overturn community decisions. It would be appropriate to pass it to ArbCom only if there were a dispute concerning some procedural aspect of the RFC/U. MoreThings (talk) 22:25, 28 October 2009 (UTC)
2. Been there, done that. Stifle (talk) 09:51, 29 October 2009 (UTC)

   I see you're supporting Option 0 because you don't want to see frivolous requests, which I guess would mean Option 12 would be the one you'd support if you could support any. I'm wondering how relevant an example from 2005 is; that was the year the concept of "policy" was invented, a significant part of the push for a self-regulating community, which IMO is the issue here. - Dank (push to talk) 12:42, 29 October 2009 (UTC)

   It's strictly inferior to the option of ArbCom just desysopping someone; if the community is happy for such a person to be a sysop, it can reappoint him. Stifle (talk) 11:20, 10 November 2009 (UTC)

3. We appoint Arbcom members to handle difficult cases, if they've consider a case why should they then pass it to us for reconsideration? I think this could lead to issues of double jeopardy] ϢereSpielChequers 12:43, 29 October 2009 (UTC)
4. Redundant. ArbCom can already desysop people through whatever process they like. The point here is to find a method that does not involve them.  Sandstein  14:52, 30 October 2009 (UTC)
5. Oppose This adds bureaucracy to the current (Option 0) process. ArbCom can desysop without starting any new process, and that should be sufficient. -- Avi (talk) 15:18, 1 November 2009 (UTC)
6. Oppose. Per Avi. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
7. Oppose. Ummm....doesn't arbcom already do this!? -FASTILY_sock ^(TALK) 00:14, 3 November 2009 (UTC)

   Then why oppose? Do you want to stop Arbcom doing this? Rd232 ^talk 14:44, 6 November 2009 (UTC)

8. Already possible, though I don't believe it's a wise idea for ArbCom to take this measure. Normal RFA standards are too high for a reconfirmation initiated in the light of an error sizable enough to warrant such measures. Christopher Parham (talk) 15:22, 6 November 2009 (UTC)
9. Oppose. Needs to avoid the Arbcom bottleneck. Ohconfucius ^¡digame! 07:14, 10 November 2009 (UTC)
10. Per Avi. Ncmvocalist (talk) 10:47, 16 November 2009 (UTC)

Neutral (Option 12)

1. ArbCom should be allowed to open RfdA cases, but they shouldn't be the only ones. Once ArbCom have decided an RfdA is needed, they'll have probably decided to desysop them anyway, or the admin will likely have resigned. Fences&Windows 05:10, 28 October 2009 (UTC)

   At least it would be a step forward. I'm not convinced by other alternatives to initiate reconfirmations, it's clearly in my mind not the job of bureaucrats, and x users/admins in good standing looks arbitrary and 'good standing' can't be consistently defined, 'uninvolved' is also problematic. But I saw and can imagine plenty of cases where an admin status is strongly disputed, sufficiently for ArbCom to allow a reconfirmation to happen, but where ArbCom would decline to desysop and the admin would not wish to resign. Cenarium (talk) 06:00, 28 October 2009 (UTC)

   Something along these lines will probably be included in the mix in the next step of the process of arriving at consensus on a recall procedure. Fences&Windows 01:35, 29 October 2009 (UTC)

2. Leaning towards oppose. I share Fences and windows's concerns, this doesn't really give the community the chance to participate until after ArbCom has had a look at things, and this is just going to drag the accused through the mud even longer. I know it's meant well, but this seems like it's asking ArbCom to sentence users to "desysopping followed by public flogging". Hersfold ^(t/a/c) 20:53, 29 October 2009 (UTC)

   It depends on how you look at this, the form can change though. The main point is that those reconfirmations can be requested by anyone at anytime, but they have to get the authorization of ArbCom to proceed, they have to make their point. So ArbCom acts as a safeguard against unwarranted requests, but it doesn't have to originate from ArbCom. Cenarium (talk) 18:46, 1 November 2009 (UTC)

3. This could work, but that would depend on how willing ArbCom is willing to 1) accept this responsibility; and 2) use it if granted. If they would only allow the community to decide when they already thought de-sysop was a good idea, then it clearly won't work. If, however, they would screen cases just to make sure they had some merit but not actually pass complete judgment it could work. I would prefer something more community driven, but I can see how this would at least be an improvement over the status quo. --ThaddeusB (talk) 23:22, 15 November 2009 (UTC)

Option 13 (Signatures prompt RFA + extra safeguards)

Jump to Option Description

Support (Option 13)

1. As proposer. The numbers may be off, but I think this is the basic framework that's starting to emerge out of all these proposals. --Alecmconroy (talk) 16:41, 31 October 2009 (UTC)
2. I like this, it's got a few improvements over option 7. Signatures expiring is the key. Not quite sure about the admin requirement but this is the one I think. RxS (talk) 19:56, 31 October 2009 (UTC)
3. Equal preference to 7. This general approach seeems the most workable; the numbers can still be tweaked.  Sandstein  07:02, 1 November 2009 (UTC)
4. Moral support. I think other proposals have more workable systems, in that the numbers get a little complicated here. --Tryptofish (talk) 00:59, 3 November 2009 (UTC)
5. Not perfect, but I see this as the best of the proposals so far.--Kubigula (talk) 04:44, 6 November 2009 (UTC)
6. The percentage needed to remove should be at least as high as the percentage needed to grant, but otherwise like the deadline system, admin support requirement. Not sure about the appeal. A new RfA should be enough appeal. Jim Miller ^{See me | Touch me} 15:02, 16 November 2009 (UTC)

Oppose (Option 13)

1. Oppose Any forced desysop outside the purview of ArbCom has too much potential to be gamed. -- Avi (talk) 15:20, 1 November 2009 (UTC)

   Would it help if Arbcom had the final verdict over the reconfirm RFA instead of the 'crats? The nice thing about this is that it runs itself, it's lightweight and easy to administer. RxS (talk) 17:09, 1 November 2009 (UTC)

2. Oppose. May encourage pile on behaviour; doesn't allow for discussion of substance or of other outcomes; near-misses may be demoralising for the subject, and cause high drama for those who feel justice has not been done. Rd232 ^talk 18:11, 1 November 2009 (UTC)
3. Oppose. Per Avi, Rd232. Jayjg ^(talk) 22:17, 1 November 2009 (UTC)
4. Oppose. Easy to game, has the potential to create massive amounts of infighting and drama, too complicated. This project is about building an encyclopedia, not whether we can politically best one another. -FASTILY_sock ^(TALK) 00:15, 3 November 2009 (UTC)
5. Oppose too many safety valves. will encourage disproportionate gaming. Ohconfucius ^¡digame! 07:14, 10 November 2009 (UTC)
6. Weak oppose - I'm not really a fan of the "signature gathering" type system, but if we chose to go that way this is probably about right. I would definitely remove the "5 admins needed," though. Admins are not more important than regular users and should not be given so much weight. Not a fan of the Arbcom appeal either. --ThaddeusB (talk) 23:27, 15 November 2009 (UTC)

Neutral (Option 13)

1. Concept could work; numbers may need to be amended. Stifle (talk) 11:21, 10 November 2009 (UTC)
2. Still looking over it. Ncmvocalist (talk) 10:48, 16 November 2009 (UTC)

Option 14 (Option 14: Regular recall schedule)

See Wikipedia:WikiProject Administrator/Admin Recall#Option 14: Regular recall schedule

Support (Option 14)

1. Moral support, without believing that it is feasible. This is essentially term limits for admins. In principle, it's what we should have had from the start, and might still be something to transition into in the future. But we are stuck with what already exists, and it would take years to clear the backlog of existing admins, so there is, unfortunately, no way that this will ever be accepted by the community. --Tryptofish (talk) 01:02, 3 November 2009 (UTC)

   I seem to be reading the proposal differently than you. It says nothing about term limits or reconfirming all admins on a regular schedule - only that whatever admins are to be reconfirmed in a given period (on account of complaints) have that happen en masse rather than individually. This would ensure there is a centralized place and proper attention could be drawn to recall proposals. I don't actually think drawing attention to proposals will be a problem, but putting recalls off until (say) the end of the next quarter might better allow the initial firestorm of the admin's error to cool down. Christopher Parham (talk) 15:32, 4 November 2009 (UTC)

Oppose (Option 14)

1. I strongly believe that sysop rights should only be removed with good reason, and "they've been an admin too long" is not a good reason. Making someone submit to another RFA for no reason other than timing will cause us to loose qualified admins even faster than we do already. Beeblebrox (talk) 05:03, 4 November 2009 (UTC)
2. We'll do well to come up with a recall process besides figuring out when you need to file requests. Stifle (talk) 11:23, 10 November 2009 (UTC)

Neutral (Option 14)

1. The nice part about this proposal is that no "stigma" would be attached to re-evaluation. Re-evaluation would just become part of the natural order of business of things, neither a black mark nor a sign of guilt. That is good. But, I think the numbers just don't work. 1600+ admins and growing, even with 4-year terms, we'd need to do more than 30 per month. --Alecmconroy (talk) 09:13, 4 November 2009 (UTC)
2. Sounds nice, but gives everyone that develops a grudge for an admin an eventual recourse. Basically everyone an admin blocked (registered only?), who had an article deleted, etc. will make sure to show up at the reconfirmation. If you're going this route it might be better to just make it a term limit; that way admins won't need to worry about counting how many people they piss off vs. how many they coddle for support. Equazcion (talk) 09:21, 4 Nov 2009 (UTC)
3. Doesn't really appear to be a recall proposal per say, but rather a proposal on how the mechanics of whatever system is adopted should work. As such, I think it is a bit premature. --ThaddeusB (talk) 23:30, 15 November 2009 (UTC)
4. Some concerns over users with grudges, and numbers, but I'm inclined to support in some ways too. Still thinking over it. Ncmvocalist (talk) 10:50, 16 November 2009 (UTC)

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