Wikipedia talk:WikiProject Administrator/Admin Recall

Should be allowed support more than one option

There is no reason why these mechanisms ought to be mutually exclusive. At the very least there ought to be scope to declare preferences (e.g. Roux's model first choice, Tony1's if that does not pass, Uncle G's if neither pass). Unless someone objects, I'll alter this accordingly.  Skomorokh, barbarian  19:27, 22 October 2009 (UTC)

I've no problem with that I was just trying to keep it simple until the general layout became more clear. Ben MacDui 19:49, 22 October 2009 (UTC)

Great! In that case I'll add my own proposal without fear of detracting from those of others.  Skomorokh, barbarian  20:17, 22 October 2009 (UTC)

WP:CENT

Currently there is just an open call to join this project listed there, it should probably be modified to point to this RFC as the more participants we have the better results we are likely to get. Beeblebrox (talk) 19:38, 22 October 2009 (UTC)

Good idea... Ben MacDui 19:49, 22 October 2009 (UTC)

 Done Beeblebrox (talk) 17:47, 24 October 2009 (UTC)

If this is on CENT, does that mean it is live? If so, perhaps the intro needs to be reworded, and mentions of "draft" clarified.  Skomorokh, barbarian  18:16, 24 October 2009 (UTC)

I guess I justassumed it was since people had started voicing opinions and nobody objected, I'll change the intro now. Beeblebrox (talk) 02:31, 25 October 2009 (UTC)

CAT:AOTR added

... for completeness. Not sure I'd support it being made mandatory but maybe? If we MUST have a mandatory recall process, that's the one I like. Also, maybe move the Status Quo to option 0 so it's always first, or move it to be last? dunno. It's in the middle now. ++Lar: t/c 22:55, 22 October 2009 (UTC)

Thanks for adding this - moved sq to the end. Ben MacDui 09:22, 24 October 2009 (UTC)

Discussion moved from project page re "oppose status quo"

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

   Perhaps you could provide some examples of these bad apples? Christopher Parham (talk) 13:22, 23 October 2009 (UTC)

   Oh please let's not go there. We're here to discuss which of these processes to run with, not to actually begin the process of going after specific admins. Beeblebrox (talk) 18:19, 23 October 2009 (UTC)

   I don't think it's useful to make general aspersions if people aren't prepared to back them up with specific examples. Those behind the regular proposals for new deadminship processes seem to take as a given that the current process is broken, but I've yet to see a case where there's consensus that the current process produced a wrong outcome. Christopher Parham (talk) 18:54, 23 October 2009 (UTC)

   I agree strongly with Beeblebrox. Christopher, naming names here would run up against WP:NPA, and would derail the discussion into talk about individuals. If you have questions about the extent of editor concern that the current process is failing, please just see Wikipedia:WikiProject Administrator. --Tryptofish (talk) 19:08, 23 October 2009 (UTC)

   I've certainly seen it and am a member of the project. My point is this: we have an RfA process which everyone agrees has made dozens of errors, promoting abusive sockpuppets as well as individuals who proved otherwise incompetent. On the flip side, we have a deadminship process (ArbCom) which has made zero identifiable errors in years of operation, at least none pointed out at this page or that wikiproject. Why are we focusing on fixing the non-broken side of the equation? Christopher Parham (talk) 19:19, 23 October 2009 (UTC)

   It gets to be a Catch 22 to answer your "zero" claim without violating NPA, but if you go to the talk page of that project and read the section on "Long rambling post on the problems and initial brainstorming of potential solutions", you'll see what I would regard as a good description in general of what the problem is. --Tryptofish (talk) 19:27, 23 October 2009 (UTC)

   I feel like the point is being missed here. Although I think it would not be all that hard to find an ArbCom desysopping that was not fully supported by the community (since we all love to argue so much and ArbCom is a favorite whipping boy) my understanding was that the type of cases these new processes are for are not the "bright line" offenses such as socking or blatantly abusing the admin toolset, but rather for admins that have lost touch with current standards and policies or are otherwise not acting in a way consistent with what the community expects of an administrator at this time. This is all discussed rather thoroughly on the project's main talk page, and is the only reason I created my proposed process at all. So it's not about ArbCom making mistakes, it's about identifying admins that have not committed acts that would lead to a rapid removal of admin status, but who the community nonetheless feels should not have it anymore. Beeblebrox (talk) 17:36, 24 October 2009 (UTC)

   Do you believe that there are currently any "admins who have lost touch with current standards"? Christopher Parham (talk) 16:30, 25 October 2009 (UTC)

   I'll answer, simply, "yes" (but they are a small minority). I'm sorry to say this, but your continued asking of the same question is starting to appear to be unhelpful. --Tryptofish (talk) 18:00, 25 October 2009 (UTC)

   Were any of the admins in this small minority taken to arbcom, detailing the ways in which they had lost touch? If so, what was the result? Christopher Parham (talk) 22:07, 25 October 2009 (UTC)

   Yes, and it was discussed extensively at Wikipedia talk:WikiProject Administrator. --Tryptofish (talk) 22:27, 25 October 2009 (UTC)

   Perhaps I have missed the discussion of specific cases on that page; although I've been following, the volume has admittedly been high. Could you point me to where on the page specific cases were discussed? Christopher Parham (talk) 22:33, 25 October 2009 (UTC)

   I'll point you to WP:NPA. --Tryptofish (talk) 22:36, 25 October 2009 (UTC)

   Echoing that, yes there unfortunately are a small minority of admins who work more or less "in the dark," not keeping abreast of changes to policies that they are interpreting/enforcing, not participating in discussion with anyone, not even informing users when they've been blocked in some cases. As I've said repeatedly, this is not about starting an admin witch hunt, but rather to minimize damage done to the project by the small percentage of admins who are playing from their own book. (I don't wish to name names here but have a look at my talk page for a clue, this came up just the other day, right in the middle of all this, and the problem came to me, I didn't go looking for it) Beeblebrox (talk) 20:39, 25 October 2009 (UTC)

   I'm sorry if you feel it's an unhelpful question but it seems rather crucial to me; what's the point of any new recall process if nobody intends to use it? The insistent refusal to "name names" seems a decidedly unhelpful attitude; a bitter defense of one's right to make sweeping accusations without backing them up specifically is awfully McCarthyist. Christopher Parham (talk) 21:44, 25 October 2009 (UTC)

   Bitter? Sweeping accusations? McCarthyist? Please understand that other editors just don't agree with you. And yes, the new process is most certainly going to be used. --Tryptofish (talk) 21:57, 25 October 2009 (UTC)

   Given that I've asked the question, as you pointed out, multiple times, and each time a sweeping accusation has been made (that there are problem admins out there who should be removed) but editors have specifically indicated they do not intend to provide backup for that statement ("I don't wish to name names here"), I'd say it is reasonable to characterize it as bitter refusal. Notice that I haven't made any statement of my views so to say that editors disagree with me, I'm not sure what you mean. I am simply trying to determine the practical implications of the policies being proposed. Christopher Parham (talk) 22:04, 25 October 2009 (UTC)

   Sorry for being unclear about that. Where we disagree with you is about naming names, per WP:NPA. --Tryptofish (talk) 22:31, 25 October 2009 (UTC)

   I find it disappointing that WP:NPA is being used as an excuse for keeping insinuations as broad as possible. The message seems to me that supporters of reform are not actually interested in addressing particular problematic instances, but in making sweeping attacks against admins altogether. But it seems like there is little interest in taking the conversation beyond general smears. Christopher Parham (talk) 22:46, 25 October 2009 (UTC)

   You would obviously prefer specific smears, and it could be argued that your talk here is a smear against those of us who prefer not to name names. --Tryptofish (talk) 00:05, 26 October 2009 (UTC)

   Saying that X should not be an admin because of action Y is a rebuttable point, not a smear or a personal attack. How would any recall process make sense otherwise; is nominating a user for deadminship a personal attack? On the other hand, saying that some admins are out of touch with community standards, but steadfastly refusing to identify specific users or incidents, is a smear. It can't be challenged, of course, because no specific claim is made: that's the beauty of baseless insinuation. Christopher Parham (talk) 00:42, 26 October 2009 (UTC)

(undent) No, it's just not the point of this RFC. We're here to discuss which of these processes to put our efforts into, not who would specifically be the subject of the reports. If you don't think we need a process at all, then option 0, the status quo, is for you, put your support there. It's ironic that you would accuse others of being McCarthyist when you are the one demanding that names be named, exactly as Joe McCarthy did. Beeblebrox (talk) 03:12, 26 October 2009 (UTC)

"Who would this effect" seems to me the most important question to ask in comparing the processes, or deciding whether any of them is necessary. And it's not as if I'm the one who brought it up; Skomorokh mentioned, and a number of people seconded, the idea that there are "too many bad apples who will never be rooted out under the status quo". If I, for instance, suggested that many of those seeking reform were acting out of malice, it would be incumbent upon me to back up the accusation or withdraw it. Empty allegations are unhelpful. Christopher Parham (talk) 03:38, 26 October 2009 (UTC)

The entire RFC is predicated on the idea that a new community driven process is needed. As I said, if you don't support that notion you have the the option to support the status quo. Beeblebrox (talk) 03:54, 26 October 2009 (UTC)

Another rambling post

The general problem as I see it is is wrapped up in the well-known "No Big Deal" idea. This seems to me to promote a lack of awareness of "rank" issues. If you are the Founder of the Encyclopedia and an administrator arrives on your talk page accusing you of incivility or some such, you can ignore these remarks with insouciance. If the comments persist, you can take action to prevent them continuing. On the other hand, if you are a newbie this is hardly the case. "Administration" may be no big deal, and a great deal of it is simply irksome work, by the administrator's tools are a big deal. Intentionally, they can make the life of a vandal or blatant POV pusher uncomfortable and, almost inevitably, they will be misused in a few circumstances. Admins are not just janitors. We have the powers of arrest and detention that most non-Wikipedians would associate with a police force.

Furthermore, RfA is a big deal. It is an initiation rite that works pretty well in that it requires the applicant to expose themselves to the community in a way that, at best, is likely to take up a good chunk of their time and at worst will dredge up a lot of angst and hurt feelings.

Consequently, I believe that some formal recall procedure is a requirement and that it needs to be both above (reasonable) reproach, accountable and requisite to the effort required to become an admin in the first place. We must avoid the twin poles of a system which is too weak to work effectively and too easy to use. Specifically, I am very uncomfortable with a system in which admins themselves decide whether other admins have abused their tools sufficiently to be desysopped or one which is a kangaroo court and may end up with admins being tried for calling blatant vandals "childish" or similar indiscretions.

I'm also unconvinced that this is a process that should be entrusted to Bureaucrats. Unlike an RfA, where a Bureaucrat is unlikely to have much involvement with a candidate, we might be asking them to impose (or not impose) a pretty severe sanction on an editor with whom they are familiar. Perhaps this is over-cautious, and it would be interesting to hear from a Bureaucrat or two. The idea of a reverse RfA is simple enough, but for me, this should be about more than just !numbers expressing opinions.

If Arbcom want the responsibility, that's fine with me, but my guess is that they are already over-loaded.

Thus, I find myself supporting Tony's idea. For me it is the most comprehensive and has the advantage of combining a democratic approach that would also involve a (hopefully) skilled cadre of co-ordinators. It isn't perfect, but it would be my starting point. Ben MacDui 10:49, 24 October 2009 (UTC)

• I'm not sure your reasoning is entirely sound, although I do take your point. I'm speaking specifically of your objection to my proposal, that it leaves the decision in the hands of an admin. Theoretically, that is not the case. The decision is made by the community at large, the closing is done by an admin who has had no involvement in the case up to that point. As I've said, I've gotten very little feedback on this before now, so maybe it could be tweaked so that any uninvolved user in good standing could do the close, although of course a crat would still be required to come in and do any actual desysopping should that be necessary. In any case, I appreciate your remarks and welcome any other feedback on my proposal, which is still very much a work in progress. Beeblebrox (talk) 17:28, 24 October 2009 (UTC)

• I've made several changes to my proposal this evening, including changing it so that any previously uninvolved user may close the discussion. I've also added a discussion section so that users can provide direct feedback on the current state of the proposal. Beeblebrox (talk) 05:48, 25 October 2009 (UTC)

Temporary de-admins / fluidity

I'd like something where admins can be "blocked from admin tools" for short times. Getting the tools back would normally be automatic. This allows good admins to recover from mistakes, allows aggreived parties to see that something has been done (and thus disengage from attacks). It would be decided by community discussion at some venue, advertised on ANI and relevant notice boards. Discussions would eb open for 72 hours for most stuff, a week for more serious stuff. Sometimes the community would ask the admin to go to arbs to get tools ack, or perhaps to go through RfA again. Important parts of this are i) Auto-regain the tools after block served ii) quick and fluid. Which of current proposals best matches this mdoel? NotAnIP83:149:66:11 (talk) 13:32, 25 October 2009 (UTC)

Temporary desysopping seems like something ArbCom might handle best. Fences&Windows 00:39, 26 October 2009 (UTC)

Hmm. The point of this is to avoid Arbcom. Major stuff goes to Arbcom. Minor stuff gets explained. It's the inbetween stuff that's a problem. An editor that doesn't deserve to lose the bits for ever, but needs a prod to get the hint, is not covered by anything today. 00:58, 26 October 2009 (UTC) —Preceding unsigned comment added by NotAnIP83:149:66:11 (talk • contribs)

Maybe this can just be worked into the consensus proposal as a way to close a RfdA - that the community has temporarily lost confidence, but that the admin can have their tools back in x months, with the proviso that any misuse or gross misbehaviour would land them back at RfdA quicker than a shake of a lamb's tail. Fences&Windows 01:44, 29 October 2009 (UTC)

I'm kinda busy

And I don't have time to read all this, but I'd support just about any sort of recall based on consensus. Do any of these have any chance of passing? Which ones? - Peregrine Fisher (talk) (contribs) 01:49, 26 October 2009 (UTC)

That's the whole point of the RFC, to determine which process has the best chance of gaining support. Most of them are based on community driven consensus, there are summaries of each process at the top of the page. Beeblebrox (talk) 03:57, 26 October 2009 (UTC)

Right way to do this?

After going through the various proposals yesterday and seeing a couple more popping up today, I can't help but to wonder if this is really the right way to go about this? We currently have a dozen or so similar but different proposals, none of which seem to be getting a whole lot of support. Even if we use this process to weed out some of the less-supported proposals and narrow in on the few that seem to have the most support, I wonder if throwing a medley of options at us like this is really going to accomplish what we hope it does.

One thing I've noticed among the various support/oppose comments is that people tend to like certain attributes of certain proposals, while they dislike others. Perhaps, rather than using this as a method to identify a single workable proposal, we should instead be focusing on what the individual comments are saying. What are people looking for in a viable recall process, and what are they wanting to avoid? I suspect it would have been simpler if this whole thing were broken down differently but as it's already well under way it'd be silly to start over at this point, but rather than coming in to this with the idea of supporting one or more proposals over another, it might be used as a way of identifying the traits a good proposal ought to have, and use that information to come up with some kind of hybrid process that incorporates the "good" out of these various proposals and avoiding what people dislike .. Shereth 16:36, 27 October 2009 (UTC)

I never expected this to lead to lead to one concrete result, but I think we can let it run as is, and use the results to move to the next stage, wherein we would take whatever proposal came closest to satisfying people, and add good ideas from the other proposals, remove what doesn't work, and try to come up with a finished product to re-present to the community.Beeblebrox (talk) 18:43, 27 October 2009 (UTC)

Right. Carry on, then! Shereth 21:39, 27 October 2009 (UTC)

Inevitably, the proposals at the bottom of the page are getting less attention, that'll need taking into account when deciding how to move forward. The proposers and any interested parties can try to reflect the comments given here to come up with a workable proposal. Fences&Windows 01:14, 28 October 2009 (UTC)

It's part poll, part ongoing discussion. Notice, for example, it looks like proposals are starting to coalesce towards certain aspects-- for example, using RFA as part of the process. --Alecmconroy (talk) 17:11, 31 October 2009 (UTC)

Change to "Admins for Discussion", or something

I've been holding off on voting here at all for a while, cause something about this rubbed me the wrong way. I realize now what it is (aided by NotAnIP's posting a couple sections up). I think the whole focus of this RFC should be different. We should be brainstorming processes for discussing admin behavior, sure, but the understanding that these processes will only have two possible outcomes -- deop or don't deop -- is making people unnecessarily skittish about where to cast their votes. I think there is much wider consensus for a binding process that can impose restrictions on admins, including the possibility of deop, than there is for a process solely intended to deop. We need to change the name of this page. Does anyone agree or am I just talkin crazy again? I'd be fine with the undercarriage of this comment becoming a straw poll, by the way, just to determine who shares this feeling. Equazcion (talk) 02:02, 28 Oct 2009 (UTC)

1. Agree. This is why I think an RFC-based process should be favoured, where desysopping is just one of the recommendations that might emerge. Rd232 ^talk 09:44, 29 October 2009 (UTC)

User in good standing

I'm surprised that so many users are making an issue out of the various proposals use of the phrase "user in good standing." I thought this was generally understood to mean any user whose rights are autoconfirmed or better, who is not under any blocks or other restrictions. Anyone have any thoughts on this? Beeblebrox (talk) 19:08, 28 October 2009 (UTC)

Censure first, desysop later

I think what is wrong with the alternate proposals here is that they necessarily have the possibility of desysopping at the conclusion of a single community mediated process. This leads to the perhaps-justified fear of witch-hunts (remember the "votes-for-banning" board anybody?). I would rather support these processes if they could only censure an administrator on the first go-round through the process. It would be something of a "wake-up call" to the administrator in question (we don't typically block without warning after all). Only an administrator who had been previously censured by one of the above proceedings could be desysopped through the same proceedings and only after a certain interval had elapsed with the problematic behavior remaining (a couple of months perhaps). The goal of this would be to let heads cool and allow for behavioral correction. Arbcom could still unilaterally remove the tools if the circumstances were severe enough to warrant it (and I think Arbcom has generally done a good job in this respect). IronGargoyle (talk) 18:54, 30 October 2009 (UTC)

I can't speak for everyone else, but I have tried to make it clear that my proposal is the last stop, not the first, and that admins should not be reported without clear evidence of previous attempts to resolve the situation, and clear evidence that the disputed behavior is ongoing despite those attempts to resolve it. Beeblebrox (talk) 19:48, 30 October 2009 (UTC)

Preventing witch-hunts is absolutely essential. Any process like this has to be sufficiently difficult so that it doesn't get abused.

But you needn't worry about the lack of a explicit 'censure' option. Censure options abound-- we have several working venues for censuring, ranging from their talk page, to noticeboards, to ANI, to Arbcom. And although it hasn't been explicitly stated in the proposals, I think they'll have cenure in practice. For example, I'm sure that whatever process we wind up adopting, there will be many people who simultaneously censure a user's specific actions and express their continued confidence in the user's adminship. --Alecmconroy (talk) 17:08, 31 October 2009 (UTC)

I think Irongargoyle's point is to provide for a clear cooling off period after censure, whereas most if not all of the current proposals don't really allow for that. I'd argue the RFC-based processes (like my proposal, Option 11) have (or should have) the flexibility to permit that without creating a formal structure for it (i.e. leaving it up to the community to choose how to proceed in each instance). Rd232 ^talk 17:44, 31 October 2009 (UTC)

I think this needs to be explicitly stated in the process. People who are mad-as-hell about some "wrong" committed by an admin are not likely to go back and think about their past "intentions for censure mechanisms" in the heat of the moment. "Why go halfway if we can throw the book at him/her?" they will ask. They're going to want heads mops and buckets to roll. You say that censure and warning are what the creators of these proposals intended, but then why didn't they include censure and warning? Not one of the proposals explicitly includes these principles. A mandatory first step of community censure, followed by a cooling off period, needs to be explicitly written in to the proposal. Flexibility in sanctions is why we have Arbcom (and Stewards for the crazies who delete the Main page or block Jimbo). It should not be as easy for the community to remove adminship as it is to grant it. Take the analogy to politics: If elected officials could be easily "voted out" midway through their terms, they would be even less likely to do what was unpopular, but morally right. IronGargoyle (talk) 20:30, 31 October 2009 (UTC)

Mmm, well fair enough in general, but in my mind it was part of the community accepted practice that there would be censure if necessary, and a chance to improve/reflect, and RFA as a last resort. Sure, some would be out for blood, but others wouldn't, and I figure that will work out; and it's in the spirit of WP:CREEP that we tried to avoid prescribing if we think it can be avoided. Rd232 ^talk 20:43, 31 October 2009 (UTC)

I hope that as long as it's sufficiently difficult to meet the threshold for initiation, we could prevent frivolousness or vindictiveness. There will always be a few that are motivated that way, but if we require way more than the few, I believe (& hope) it would work out. The way I envision the process, it would be almost impossible to get the support for an RFA without there being a "pattern of behavior" and prior history of dispute resolution. --Alecmconroy (talk) 20:58, 31 October 2009 (UTC)

Absolutely. The RFC has gone a bit askew with if you ask me with all the new proposals popping up. It's gotten a bit muddy. It may be a good idea to try and clarify that (I'm assuming we're on the same page on this point) the desired outcome here is not a finished product, but rather to find what works and what does not about each one, and to try afterwards to combine the strengths and remove the weaknesses until this pile of proposals becomes one cohesive idea, which can then be polished up and re-presented for a final up-or-down vote or RFC. However, on the matter of censure or results other than de-sysopping, I deliberately left that out for the simple reason that in my particular vision of how this would work, nobody should be reported unless lesser measures have already failed to resolve the problem. Beeblebrox (talk) 14:51, 1 November 2009 (UTC)

Wikipedia:WikiProject Administrator/The Proposal with a Thousand Faces

As I was trying to weigh each of the individual options, I made a little framework to help me compare and contrast the proposals. A few don't easily fit into the framework, but most do. I wrote it for myself, but it may be useful to others as we start mulling over the universe of possibilities. --Alecmconroy (talk) 17:26, 31 October 2009 (UTC)

Narrow to top proposals?

Given peoples' bandwidths, and to avoid them putting their good efforts into dead ends, might it make sense to at some point as an interim measure narrow the proposals by deleting a few of them?

We could come up with some criteria (e.g., at least 10 support votes, and no proposal with twice as many oppose votes as support votes). That would allow us to put enegery into fine-tuning the best proposals, rather than discussing why we don't like proposals that won't be adopted in any event.

For those who are wondering, those criteria would today still have us considering proposals 3 and 4 (and a few other proposals are close to the criteria), but for example take off the table proposal 6 which has so far received 1 support vote and 22 oppose votes.--Epeefleche (talk) 06:38, 1 November 2009 (UTC)

Absolutely oppose. We're trying to identify good qualities of proposals, not choosing between complete ideas. That requires some hard work analysing the comments and how the structure of proposals relates, not mechanical striking of those that didn't make it. Also, even if we didn't have WP:NOTVOTE, later proposals are disadvantaged. Rd232 ^talk 07:46, 1 November 2009 (UTC)

Some thoughts on common threads of concerns and ideas:

General

• Avoid Frivolous or vexatious requests. A recurring reason to oppose all proposals except the status quo.
• It ain't broke, don't fix it - the current system relying mostly on Arbcom is good enough (and in fact anything easier may be dangerous).
• Need more accountability; community elects and should be able to sanction (up to and including desysopping) more directly than through Arbcom
• Some "bad apples" aren't being tackled by the current system (but nobody wants to name names, for understandable reasons)
• Processes shouldn't overfocus on desysopping yes/no, but be broadened to include consideration of non-trivial complaints generally, and other appropriate outcomes (option 1, 2

Process-based

Deciders

• Bureaucrats shouldn't be involved beyond the usual RFA decision - that's not their job, and not why they're chosen (option 4,9)
• arbcom shouldn't be involved (option 5)
• decider shouldn't be just anybody

RFA initiators

• "any user in good standing" (option 8)
• "any user in good standing" +2 uninvolved admins(option 1)
• "any user in good standing" +2 uninvolved users (option 3)
• RFC/U requirement (2 users who attempted to resolve dispute)+majority of bureaucrats: option 9
• RFC/U requirement (2 users who attempted to resolve dispute)+an uninvolved admin: option 11
• 10 editors in good standing in 3 days (option 4)
• 100 users in good standing, open-ended (option 7)
• any admin (option 10)
• 30 users in good standing within 7 days (including 5 admins) - option 13
• N/A - no RFA: option 2 - (own process); option 5 (arbcom);

Other

• Threshold for initiation too low; insufficient protection for "accused" (option 1,3,8)
• Needing admins involved in initiating/certifying may be a problem, as they may be unwilling to act against each other (option 1)
• too bureaucratic and limiting on who can comment (option 1); too bureaucratic and complicated (option 2)
• not open-ended enough (option 1,2,3,4,10)
• not specific enough about issues to be discussed, i.e. specific indication of which admin tools have been misused (option 3)
• if it is patterned at all along the lines of current RfC, then it is not a good format and will lead to inconclusive outcomes with alot of acrimony on the way
• building on existing processes (RFC, RFA, arbcom) is easier and less WP:CREEPy
• adds nothing to the status quo (option 5,12)
• little point in making a voluntary process mandatory (option 6)
• open-ended signature list is unworkable (option 7)
• arbcom may be permitted to launch a reconfirmation RFA (option 12; part of option 2)

Summary

• RFC-based processes: Option 3 (but highly focussed on desysopping); Option 5 (declaration of no confidence after RFC, if passing -> arbcom motion, -> arbcom judgement); Option 9 (RFC + RFA if bureaucrats agree); Option 11 (RFC+RFA if uninvolved admin agrees)
• Recall referendum based processes: Option 7 (open-ended, 100 signatures); Option 13 (limited, 30 signatures)

Summary

Substantively opposed proposals

Option 1 (7/15/0); Option 2 (7/15/0), Option 5 (5/10/1), Option 6 (1/22/0), Option 7 (5/15/0), Option 8 (7/12/1), Option 10 (3/9/0)

About equal for/against

Option 3 (12/14/0); Option 4 (13/9/0); Option 9 (5/2/1), Option 11 (4/2/1), Option 12 (3/4/0), Option 13 (3/0/0)

Substantively supported proposals

Feel free to amend the above. Rd232 ^talk 09:35, 1 November 2009 (UTC)

I think we should try and take the existing proposals and ideas as ingredients for baking 2-4 new proposal cakes, one of which will hopefully be tasty enough to pass. This would be an RFC-based idea, a recall referendum-based idea, and maybe a couple of others. Rd232 ^talk 10:36, 1 November 2009 (UTC)

Having a short-list based on the best ideas would seem to me to be the appropriate outcome, although there is clearly the possibility that additional variants or new ideas will keep appearing. We are nothing if not creative anarchists. However it needs more time before any sifting can begin. Ben MacDui 17:15, 1 November 2009 (UTC)

Well what I'm trying to do is figure out some sort of a specification. Some general thoughts have been written by TenOfAllTrades at Wikipedia:De-adminship proposal checklist. I'm trying to work towards something more concrete. Rd232 ^talk 17:47, 1 November 2009 (UTC)

Draft specification for a recall process:

1. Have good guidance on usage of process, and what's expected of admins (some propopsals have developed this, and this may be adapted, probably, for any proposal)
2. Not overfocussed on recall. Should specifically incorporate general discussion, in a non-judgemental way, before putting desysopping, as final measure, on the table.
3. Not overfocussed on voting; signature lists without discussion may encourage flash mob or "pile on" behaviour
4. Leverage existing processes I. RFC/U (or something like it) is leveraged by a number of proposals.
5. Leverage existing processes II. Using RFA as a reconfirmation (or not) mechanism seems popular enough to justify focussing on this. (Permitting arbcom to launch such RFAs seems also acceptable, but not enough in itself, so it may be considered an optional sidebar.)
6. Have a bar to initiation of RFA which is (a) low enough to make it viable when necessary (b) high enough to exclude frivolous and vexatious requests. Bars proposed range widely.
7. Not burden bureaucrats with a task they're not elected for; not create excessive complexity or duplicate existing processes.

Rd232 ^talk 18:08, 1 November 2009 (UTC)

Where are we with this process? Some suggestions

Looks to me like #4 (my own choice, by the way) has picked up a bit more support than the others. Where are we going from here? Pick say, the top 3, and debate anew for another 30 days? I'd like to suggest that, with the holidays coming up, it might be an ideal moment - the period of Dec. 15 to Jan. 7 - to announce more widely for a wiki-wide !vote on the watchlist and/or introduction pages. Final decision/implementation to be made by the 'crats. Happy to hear any other suggestions, but lets pick something and move forward. One thing seems clear, from the many opposes on Option 0 (to do nothing)... people want to put some kind of a a process in place. Again, let's choose some from what we see, and figure out how to wrap this up by early January. Such is how it looks to me. Thoughts? Jusdafax 06:37, 10 November 2009 (UTC)

I'd strongly oppose picking from the existing proposals, each thrown up by an individual. We need to collaborate on producing a limited number of good proposals to choose between. This is a wiki, isn't it? Rd232 ^talk 09:22, 10 November 2009 (UTC)

I think it is time we narrowed this list down and started focusing our discussion. I agree with Judas. Angryapathy (talk) 07:19, 10 November 2009 (UTC)

See the discussion at "Narrow to Top Proposals" immediately above.--Epeefleche (talk) 07:41, 10 November 2009 (UTC)

The are still a few folk turning up to input so I'd give it a few more days. I suggest putting a "This poll will close on Sunday 15th November GMT" or similar at the top of the page before closure. That would give a month before the suggested re-launch of 15th Dec. Ben MacDui 08:45, 10 November 2009 (UTC)

That sounds fair. I'd make the end-date next Monday though, to give weekend editors in every time zone one more shot. Rd232 ^talk 09:22, 10 November 2009 (UTC)

I think we should eventually narrow eveything down to the top proposal, then open up discussion on what changes need to be made to that proposal, then finalize and finally see if consensus warrants its addition to WP. This is a complex task, so if we just start over and see which points people most agree with, then many of the little details important to a new proposal will be stifled by bureaucracy, or missed altogether. Angryapathy (talk) 14:47, 10 November 2009 (UTC)

A couple of comments. I agree with the end-date plan as a way of moving forward. I also agree with the basic point that there is clear evidence of dissatisfaction with the status quo. But I think that it may be a somewhat artificial issue as to picking the single top proposal as opposed to combining the top few/several. I think a careful reading of editors' comments shows that many !votes do not amount to a simple support or oppose; for example, there are multiple cases of I like part of this proposal and dislike other parts where one editor supports for that reason while another opposes for exactly the same reason (kind of like glass half-empty or half-full). Add to that the fact that some (not all!) editors who supported the status quo went on to oppose everything else, as well as the valid observations made earlier in this talk that the !voting sample size varies considerably from one proposal to another, and I think we have to be very careful about simply counting !votes. We should probably have some discussion about which features of the proposals tended to be popular and which unpopular, and use that as a starting point for drafting a revised version, maybe including cut-and-pastes from a couple of the better-liked proposals here, that could be put forward to the community. I'd much rather see us put forth one well-crafted proposal, than ask in another poll for editors to choose again between multiple options. --Tryptofish (talk) 18:08, 10 November 2009 (UTC)

Basically, I think it comes down to: "Of the people who support the basic idea of Admin Recall, which proposal framework and values is least objectionable". The values can always be tweaked with time, we don't have to get it perfect the first time, the process can evolve. We just need to find a proposal that gets the job done with as few people as possible opposing. Just getting consensus that any threshold of community agreement can cause a de-admin, that would make future discussions and reform much easier. Even if the first version of recall wasn't effective enough, it would still be a big step in the right direction. --Alecmconroy (talk) 22:30, 10 November 2009 (UTC)

Gradual adoption via RFA !voting

The fallback here, if the policy-discussions get too bogged down to function and we're left with an unpopular status quo, is to reform RFA gradually by more active engagement at RFA itself.

Meaning-- suppose people unsatisfied with the status quo find some policy we could mostly agree on-- The Wikiproject Admin Proposal. What if it's popular, but a little too much change too fast for some.

In that case, there is a way to gradually start to adopt it that's less scary-- at RFA on a case by case basis. Meaning, borderline candidates could agree to sign the "Wikiproject:Admin Contract", a binding agreement. With a de-RFA process in place (for that user), the community would be able to be more lenient with its trust, since there's an undo button.

Meanwhile, this would show the system works (or maybe that it needs tweaks), and it wouldn't be a "huge overnight" change that people fear. Instead, everyone involved should be happier than with the status quo. RFA candidates who sign the contract should be happy, because they might not have passed otherwise. The people who support the "Wikiproject:Admin Proposal" would be happy too, since it's on step closer towards a better RFA. People who oppose the proposal might be happy too, since it couldn't be used against admins who didn't sign the contract.

And, people who believe "Wikiproject:Admin Proposal" should apply to all admins are happy too, since if the change is an improvement, it might lead to wider adoption.

Maybe applying some new de-RFA to the entire population of sitting admins is just too much change for Wikipedia to bite off at once. Maybe that's why these proposals keep getting bogged down despite an overwhelming disapproval of the status quo. Maybe the solution is to start a "pilot program" that just affects those RFA candidates who choose to sign the contract as a condition of their RFA support.

Straight passage would be better, but if we get a few more months down the road and the situation hasn't changed, RFA contract could be what's needed to get things rolling in the right direction. --Alecmconroy (talk) 17:24, 10 November 2009 (UTC) --17:24, 10 November 2009 (UTC)

You'll need to get approval from someone to make it binding. Pledges made at RFA have been ruled non-binding already. Hipocrite (talk) 17:29, 10 November 2009 (UTC)

Has anyone ever said, ahead of time, that their RFA pledges were binding and would result in their de-admining under certain objectively-definable criteria?

I know the admin-open-to-recall compliance is voluntary-- but surely some way could be found to make it binding, if only a pledge from any crat adding the bit to also assume the duty of removing it when the objective criteria is reached. Objective initiation criteria will be very important of course, or else it will be just as arguable and voluntary as the current admin-open-to-recall process is. --Alecmconroy (talk) 17:36, 10 November 2009 (UTC)

'crats can't desysop. You need a steward to sign off. Hipocrite (talk) 17:55, 10 November 2009 (UTC)

Would people really refuse to submit to an RFA if they had entered into contract that was very express about it's being a binding promise? I have a hard time believe a Wikipedia admin would breach a contract like that. And then, if they did breach, a quick trip to arbcom should settle things.

So, I guess that's what it comes down to. The contract signers and the rest of the project would, collectively, be asking arbcom to help enforce a protocol. So if arbcom wanted to refuse that request and nix the whole thing, there's a chance they could.

But, I guess I really do trust the arbs, and I don't think they'd nix it if it was good for the project. And since any specific deRFA always going to be appeal-able to arbcom anyway, in the end, it mostly collapses into terminology.

So, let's consider the "breach of contract" scenario

• When objective criteria is met, the admin-under-contract should request resignation as they promised to do. I think they will, because I think admins are honorable people-- even the so-called "bad admins" may too many mistakes but I don't see them as intentionally and knowingly breaking their own word. But let's suppose I'm being naive, and the theoretical "bad admins" are actually immoral-- they don't resign.
• Maybe that alone would be an emergency desysop. But let's suppose it isn't.
• According to the contract, whenever objective criteria are met, any steward can remove the bit on their own initiative or when requested to, as enforcement of the contract. We make sure at RFA that there is at least one steward on board. But let's suppose the stewards all refuse to desysop.
• Most likely, if all the stewards unanimously agree there's no problem, then something has gone wrong in the system and the stewards have invoked Ignore All Rules. This is a good thing, since it's one more safeguard. But let's suppose there really was a problem.
• The evaluation mandated by contract continues on as scheduled. Given the unanimous steward support, the evaluation probably resulted in the admin status being 'restored'. But let's suppose it didn't.
• Everyone will throw a fit and beg arbcom to sort the mess out. Since everything is appeal-able to them anyway, and whether we call it an admin-appealing-the-case or a community-requesting-desysop, either way it winds up at arbcom which decides (either by declining or deciding) the outcome of the dispute.
• And ultimately, I trust arbcom to set things best. They're smart cookies, and if we could give them all a full-time salary, we probably wouldn't even need to have this process.

Am I thinking this out right? It seems to me that in all but the worst case scenario, the contract gets enforced and the process works. Meanwhile, in the absolute worst case scenario, we default to our current status quo. But I'm very much thinking aloud here, so perhaps there's a big piece of the puzzle I haven't even considered. --Alecmconroy (talk) 21:54, 10 November 2009 (UTC)

A steward was intimately involved with the most embarrassing failure of recall - Elonka. She was not desysoped. Hipocrite (talk) 22:46, 11 November 2009 (UTC)

I'm not familiar with the case, but whatever inefficiencies or errors that may have been made in the past are all the more reason why we need reform-- as a policy if possible as a contract if necessary. --Alecmconroy (talk) 08:08, 12 November 2009 (UTC)

Babysteps

So, the people we need to understand better are the people who oppose the status quo, but haven't yet accepted the most popular option(s).

So, for example, how many people are there who don't support option 4 but would support option 4 if we required CDA be preceded by user-conduct RFC or other substantive discussion?

And so on. Piecewise amend with snowballing support until the thing can actually pass. --Alecmconroy (talk) 08:21, 12 November 2009 (UTC)

Question for Arbcom Candidates?

Arbcom Elections are almost upon us-- what would people think about asking the candidates a question or two related to their views on the issues raised by this wikiproject.

Would it help? or would it just complicate the process? --Alecmconroy (talk) 04:16, 14 November 2009 (UTC)

I notice it has been referred to obliquely already. I think a question is a good idea, but this early in the process it may be tricky to come up with a meaningful one. By all means make a suggestion or two here if you would like some feedback. Ben MacDui 11:36, 14 November 2009 (UTC)

Thoughts re: Option 4

Since the !vote here closes soon, I took another careful look at the long version of Option 4 which appears to be the 'winner' in this debate. Suddenly I realized the words 'mirror image' in the short form of the proposal may be unclear to some. To make absolutely sure we are all on the same page: If an admin recall is to be much like an Rfa in reverse, that means that the process requires well over 50% to remove the admin rights, with about 70% being the minimum needed. (This is in fact what I am voting for.)

My concern: have some - who may not have fully read the long version - cast their !vote here thinking the opposite is true, that we would in effect be voting all over again on the fitness of the admin to hold the mop? If so, and you object to what Option 4 really requires, then you need to change your vote for Option 4 asap. The proposal, quite rightly in my view, sets the bar high at over 70% to pull the plug on an admin, with a minimum of 50 votes needed in favor of taking the buttons away. This discourages petty attacks with trumped-up reasons. All in all, I find Uncle G's Option 4 to be well-written and thoughtful, as well as a thankfully common-sense approach, and I commend him for his work.

A final thought: As I say in my statement supporting it, I would like to hear from some of the 'crats, on whom the final decision must rest... both in the adoption of this (or any) of the Options, as well as making the tough final decisions that would be called for when a consensus is not clear under Option 4. Jusdafax 20:22, 15 November 2009 (UTC)

I feel moved to comment that I very much oppose trying to choose one option from the current list as a "winner". See section above, #Narrow to top proposals?. A second round with a limited number of collaboratively-developed proposals is needed. Rd232 ^talk 20:27, 15 November 2009 (UTC)

Agree, as I noted above in the section just below the one you point to. For what it's worth, I'd be in favor of choosing a top three for a second round, to last around three weeks. Any more Options than that, I feel, and the debate gets to be too wordy. Jusdafax 20:35, 15 November 2009 (UTC)

Per my comments earlier in this talk (please see: Where are we with this process? Some suggestions), I think it's very important that we not just count !votes and declare a winner. And rather than just having another run-off round, I think we need to look thoughtfully at several of the better-received proposals, not just number 4, and look at what people said about them, pro and con, and try to come up with something that reflects that to put forward. In fact, I did not read number 4 as saying that, about 70% needed to desysop, and I doubt that I'm the only one! We can't expect everyone to come back and revise their !votes at this late stage, so I cannot emphasize too strongly how important it is to not just count !votes, but to look at the comments behind them. --Tryptofish (talk) 20:53, 15 November 2009 (UTC)

Conditionally agree. Note in my statement just above that I put 'winner' as I wrote it just now, in single quotes to denote ambiguity in the term. Your comment re: Option 4 validates my concerns. Since the process we are engaged in is both somewhat important (setting policy for the forseeable future) and tricky, in that the devil is in the details, we all need to support total clarity at this stage, but I worry about possibly bogging down in verbiage, thus my thought that 3 Options might be a good limit for a proposed second round. I'm not against sub-proposals to tweak or merge features of Options, but I think there should be some kind of process or limit... hopefully a simple one. Jusdafax 21:17, 15 November 2009 (UTC)

OK, I have gone back and re-read the long page of proposal 4. It does not say explicitly that 70% is needed to desysop, unless I'm really missing something. I cannot find anywhere that it says a percentage one way or the other. It does say "mirror image", which can just as reasonably be construed to mean the same percentage of supporting !votes is required to remain confirmed as an admin, as to pass an RfA (the idea behind a reconfirmation RfA). I guess we both agree that what we are discussing here validates both our concerns! I wonder: how many editors in this poll read the proposal to mean what we wanted it to mean? Proves my point: let's not simply count !votes, but look carefully at the comments, and have some thoughtful discussion of what features of the proposals are or are not seen favorably. --Tryptofish (talk) 23:26, 15 November 2009 (UTC)

In the section above I identified several types of proposal. I'd say (as I did there) collaboratively develop one proposal per type, and then vote on those. Rd232 ^talk 21:19, 15 November 2009 (UTC)

Ah. That's where I don't agree with you. I personally think it's better to deal with the proposals at hand, rather than develop new ones. Again, I'm not against tweaking or merging within reason. Regarding Option 4: I just read it through a third time and my feeling is that Uncle G has carefully crafted the full (long version) Option 4 to be easy to understand and glitch free. I see one modification was made, from 100 to 50 minimum needed in favor to de-admin. If I understand your comments above correctly, you do not think 'crats should be involved in the process of de-adminship? Jusdafax 21:46, 15 November 2009 (UTC)

Not develop "new" ones, but to merge related proposals and produce a better version of each kind. And no, I have nothing against bureaucrats closing RFA-style proceedings. My oppose to option 4 (and others) is based on insufficient prior discussion before desysopping is on the table. Having desysopping on the table too early is inimical to discussion, to admitting error, to seeking to improve. (Even to make proposals for desysopping too easily has a negative effect, even if high standards for approval prevent desysoppings being seriously discussed when they're inappropriate, never mind actually done.) Rd232 ^talk 21:57, 15 November 2009 (UTC)

Ok. Could you, for clarity, list the kinds here? To be frank, it still seems like a lot of new effort. As to your concerns about prior discussion... As you most likely know, Option 4 would take ten "editors in good standing" or ArbCom to initiate the process, and I assume there would be a page to discuss that first. I respectfully wonder how would you change that to satisfy your concerns? Also, I had not fully realized until I counted up just now that Option 4 was the only Option with a substantial net positive !vote at 23 Support vs. 13 Oppose. Since there is no running tally of the !votes, this fact suddenly looms over the discussion, as many like me may have been to lazy to scroll and count all the !votes, though the wording in the short version may have misled some. Hmm. Jusdafax 22:23, 15 November 2009 (UTC)

Remember that the later suggestions have got less attention due to editor fatigue by the time they get to the bottom of the page, so raw numbers supporting each proposal won't give the full picture. Fences&Windows 23:54, 15 November 2009 (UTC)

Yes, and there are plenty of "weak support" and "weak oppose" comments, often for the same reasons. --Tryptofish (talk) 23:58, 15 November 2009 (UTC)

Say, I notice that the table below is both incomplete and incorrect. Option 4's vote totals are pasted into Option 3. Also, if I remember correctly, the later Options were added later. They didn't all appear at once. UPDATE: Nevermind, I fixed it myself, and added the others that were missing. Jusdafax 01:03, 16 November 2009 (UTC)

Thanks for the fix. I'll add back the sort parameter asap as otherwise the negatives numbers don't appear in the proper order. I'm not sure it is meaningful to put anything in the table about the timings of the options appearing - although arguably it is a factor in any conclusions that may be drawn. Ben MacDui 18:30, 16 November 2009 (UTC)

Results table

Final results at 7:00 GMT 16-Nov-2009

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%

I'd appreciate it if the above were checked for accuracy. Ben MacDui 19:41, 16 November 2009 (UTC)

Main Conclusions

The above results may result in complex discussions but at the risk of being unduly glib the most obvious outcomes are that:

1. The status quo, whilst garnering some support, is very unpopular. 77% of respondents do not support its continuation.
2. Only one proposal achieved a greater degree of support than opposition- "Wikipedia:Community de-adminship"- which received a majority of 13, and the support of 65% of those who considered it. Hats off to its creator Uncle G (talk · contribs).
3. "Make CAT:AOTR mandatory" was remarkably unpopular, with 96% opposed. (Thanks also to the nominator, who enabled this useful result to be known.)
4. Various other proposals received some real support and/or little opposition - and it is important to note that the higher numbered proposals appeared later in the process and were therefore viewed by fewer respondents. Ben MacDui 19:41, 16 November 2009 (UTC)

I think it's safe to say that reconfirmations are rather unpopular, also, judging by the number of proposals to that effect, with very little support. Angryapathy (talk) 19:58, 16 November 2009 (UTC)

Actually, looking at the percentages, it's not at all clear that reconfirmations are less popular than other options. --Tryptofish (talk) 19:05, 17 November 2009 (UTC)

I think that your (Ben's) analysis is accurate and fair. And I underline the conclusion that there is dissatisfaction with the status quo. A few suggestions: (1) It's not clear that any other proposals come close enough for it to make sense to have a run-off poll between them and proposal 4. (2) The proposals that involve processes very different than proposal 4 (AOTR being a conspicuous example) did not fare well, so we should probably look most seriously at those that are similar to it. (3) Of those that are similar, are there features that were well-received and might be incorporated into proposal 4? (4) What objections were raised to proposal 4, and what revisions might be made to it to improve it? --Tryptofish (talk) 19:59, 16 November 2009 (UTC)

I would tend to disagree with that conclusion. #4 was clearly the most popular (and happens to be the framework I prefer), but I don't think it is fair to conclude it was the most popular b/c of the framework. #1 is very similar, other than the details of how it starts/who can comment and it got overwhelmingly negative feedback. #13 arguably did the 2nd best and is rather different. The RfC based proposals generally did pretty well. Many comments on all proposals focus on the specific details. In short, there are too many variables to draw an accurate conclusion about what exactly made #4 the most popular. --ThaddeusB (talk) 21:10, 16 November 2009 (UTC)

Actually, I agree with the main thrust of what you say here. I agree with you that it's a mistake to simply count !votes, without looking at the reasons expressed in editors' comments. --Tryptofish (talk) 21:51, 16 November 2009 (UTC)

Thanks. I'm going to reply in a section below in the perhaps vain hope that we can keep "conclusions" and "discussion about what happens next" separate. Ben MacDui 20:10, 16 November 2009 (UTC)

The way forward?

(Note: The analysis above in #Narrow to top proposals? is more thorough. I am purposely trying to focus things a bit.)

Looking over the !votes of the various different proposals, it seems to me that with any given proposal most opinions focus on the specific details rather than the general type of the proposal. There is nothing wrong with that, of course, but the actual comments create a problem I think. Specifically, for any given proposal there are both editors who think it is too easy to initiate and/or de-sysop and editors that think it is too hard. That makes reading consensus as to where we should go next rather difficult.

As such, I think the next step should be a pick which general type of system is the "favorite" and attempt to work out the details once we know the frame work. As I see it, the proposals generally fit into the following "systems" (please amend this if I've missed anything):

• A reverse RfA-type process initiated by some editor(s) where a clear consensus is required to de-sysop.
• A reconfirmation process initiated by some editor(s) where the admin must re-run for RfA and obtain either a majority or a clear consensus to remain an admin.
• A partially committee base process where either ArbCom or some new committee screens out "frivolous" complaints before sending it to a community vote.
• A completely committee driven process where a new elected committee reviews cases and decides the admin's fate.
• An amendment to the existing RfC process whereby the RfC can end in requiring an admin to re-stand for RfA in order to retain their adminship (or some similar RfC based conclusion).

Of course I would be way off base here, but I think it is best to settle on a general structure before proceeding. The next step could then be deciding how its initiated, then who can participate, and so on. What do others think? --ThaddeusB (talk) 23:50, 15 November 2009 (UTC)

I agree. You'll need to come up with something to revitalize the discussion and move it forward though, since things are petering out here. Gigs (talk) 03:50, 17 November 2009 (UTC)

Simple solution

In reply to the above and to Tryptofish's remarks in the "Main conclusions" section above, I think it is clear that by far the simplest solution is to examine the results for Option 4 (which we must stop calling it - let's use the existing shortcut of WP:CDA) and attempt to identify:

Its strengths

The weaknesses as perceived by the respondents

What amendments or options to amend are worth considering

with a view to creating a new poll seeking its implementation.

I stress "simplest" above as this may not be the best way forward, but in such a complex and unstructured environment, clarity often commands a premium. This could of course involve introducing elements from one or more of the other proposals, but (in my view) none gathered sufficient support for a "run-off" to be worthwhile. Ben MacDui 20:23, 16 November 2009 (UTC)

I agree that just running with WP:CDA is the simplest solution and that a run-off is not necessarily a good idea. I think this RfC went about this in rather the wrong way by comparing complete proposals from the onset. A better idea of what the community wants would probably have been generated by having the discussion over the general format of a de-admin process. That said, I'm not sure if it is worth going back and testing that now. CDA certainly has enough support to justify using it as a starting point and working from there.

So basically, I am OK with either another preliminary RfC to try and better nail down what the community wants or using CDA as the starting point and working to amend that to the point where it is strong enough to gain consensus form the community. --ThaddeusB (talk) 21:19, 16 November 2009 (UTC)

• I did a quick scan of the votes for Option 4 (AKA WP:CDA), and here are the complaints I collected:

1. The "10 editors to open" bar is too high.
2. The definition of "editor in good standing" needs revision.
3. The 100 votes total to desysop is ineffective. (Note: the proposal has been amended to a minimum 50 supporters of desysop, removing the 100 total)
4. Need more concrete percentages for de-sysoping.
5. Should not have the bureaucrats involved at all.
6. "Too easy to game the system"

Feel free to add more, if I missed any. Angryapathy (talk) 20:49, 16 November 2009 (UTC)

I'm OK with using CDA as a starting point, as long as the general questions in the section above are still negotiable. Gigs (talk) 03:54, 17 November 2009 (UTC)

• I think Angryapathy did a good job of listing the issues raised in the discussion of CDA, but I'd add two things:

7. Along with the "10 editors to open", there were questions about the number of days (3) and how the information would be publicized to the community.

8. There were some questions about being able to adequately discuss possible outcomes short of full desysoping.

Should we start a page for discussing how to address these questions? --Tryptofish (talk) 19:23, 17 November 2009 (UTC)

Such a page is a priority and I think the alternatives are:

A new page in this space such as Wikipedia:WikiProject Administrator/CDA, or

A new page in CDA space such as Wikipedia:Community de-adminship/RFC

I favour the latter but I'd like to get some input from Uncle G first. I will request a comment. Ben MacDui 19:35, 17 November 2009 (UTC)

I agree with the move to focus the discussion, and would suggest opening seperate sections on the talk page for discussion of each point raised above to gauge consensus, with of course room for discussion of various other points that might be brought up. We should also mention that this doesn't mean we are going to implement WP:CDA, it is just the groundwork for a community proposal. Angryapathy (talk) 14:57, 18 November 2009 (UTC)

Yes, and I think the separate talk page sections are especially desirable. --Tryptofish (talk) 19:01, 18 November 2009 (UTC)

Detailed Proposal

It would seem that Uncle G has taken an untimely wiki-break. I think we press ahead with creating a Wikipedia:Community de-adminship/RFC type page. Before this happens, I'd like to be as clear as possible about its purpose. In my view:

The first stage is a discussion with a view to sharpening up the existing CDA in order to create an RFC.

The second stage is the RFC itself, and we should avoid rushing from one into the other until the first phase has been given sufficient airtime.

If this is the case then perhaps what is needed is a project page e. g. Wikipedia:Community de-adminship/RFC, which has a rough draft of an RFC, but with "THIS DRAFT IS UNDER DISCUSSION - PLEASE CONTRIBUTE TO THE TALK PAGE BEFORE MAKING ANY AMENDMENTS" prominently at the top.

and the associated talk page which would have:

The main conclusions of the poll above.

A statement about how we actually get to the RFC.

Section headers per the above each including:

the proposal

options for that proposal

space for discussion of the options and

expressions of support/opposition.

A section identifying what publicity the process has received.

The second item may need a little thought. Imagining it will be possible to achieve consensus on each of the options is optimistic. I think it should something along the lines of: This process will continue until 8pm GMT on Monday 4th January 2010. At that point:

if sufficient consensus has been reached a version of the RFC will go live as a formal proposal for community consideration, or

the time period for discussion will be extended to allow a greater degree of consensus to emerge, or

the process will be dropped.

If the above makes sense, I think we should call the project page "Wikipedia:Community de-adminship/Draft RFC" in order to minimise confusion. Ben MacDui 20:19, 19 November 2009 (UTC)

I agree that we should move forward now, and I agree with most of your plan. My main suggestion would be, instead of trying to anticipate now how we will move to the second (RfC) stage, omit the parts about how the move will happen and the deadlines, and subsume the expressions of support/opposition into the discussions of options, and instead ask along with the other options being discussed, how editors would like next to move towards ratification. --Tryptofish (talk) 20:36, 19 November 2009 (UTC)

I don't believe there is a right/wrong answer to any of this, and:

re the discussion/support I'm fine with that.

re other options for moving forward, I think the challenge here is the inherent flexibility of wiki-discussions. If no default position is specified then creating an agreed outcome can be tricky because there is not even a pre-arranged format within which a decision can be made. I suggest the alternative of stating a closing date, but creating a section for discussion of other options. I am not at all concerned about following a different path if a consensus emerges but I'd like to avoid a result with ten different suggestions each with two supports and four opposes if at all possible. I am working on a draft talk page structure which should be available soon. Ben MacDui 08:48, 20 November 2009 (UTC)

I've dropped a note at the WP:CDA talk page announcing the impending discussion. The draft talk page is here and comments and assistance are welcome.

I'd genuinely like to believe that a two-stage process of going straight from here to RFC was possible, and tho' I fear some will get weary at being asked to comment three times, it seems to me that ironing out, or at least discussing in more depth, the perceived problems first is a necessity. Ben MacDui 19:55, 20 November 2009 (UTC)

Good, thanks for doing that. I'm just getting caught up after some holiday-related travel, but I'm going to take a careful look at your sandbox draft soon. --Tryptofish (talk) 17:28, 21 November 2009 (UTC)

OK - I think it is just about ready to go - I'll wait for comments before going "live". Ben MacDui 18:01, 21 November 2009 (UTC)

Here we go - other than here and at WT:LOOMPA I am not intending to undertake any of the suggested publicity today and would appreciate assistance with this. I note Tryptofish's addition of 5.2 for %ages required and my prediction is that this subject will be at the heart of the debate. Wishing this process good luck! Ben MacDui 10:41, 22 November 2009 (UTC)

PS per Sandbox talk comment the blue link will be at Wikipedia talk:Community de-adminship/Draft RfC. Ben MacDui 10:41, 22 November 2009 (UTC)

Thanks for your work on this, and I second that prediction! --Tryptofish (talk) 15:39, 22 November 2009 (UTC)

Agree that you deserve thanks, Ben. Also I just alerted the Bureaucrats on their page. I strongly feel they need to be involved in this process if they are to be at the heart of proposal. Jusdafax 18:45, 22 November 2009 (UTC)

Extend this RfC?

I only just found this, and I'm not going to be able to look or comment on anything in detail for another 12 hours at least. This doesn't seem to have been as widely advertised as ArbCom elections for example. Perhaps it could be extended accordingly? Ncmvocalist (talk) 01:25, 16 November 2009 (UTC)

I appreciate your point, and for any next step more attention will need to be paid to this subject, but I see you did manage to make some comments and it's my belief that creating an extension would result in confusion. Ben MacDui 19:50, 16 November 2009 (UTC)

Ncmvocalist, it was on WP:CENT (and thus AN + ANI), the lists of RfCs, WT:RFA; I'm not sure where else you would expect it to be advertised.  Skomorokh, barbarian  20:05, 16 November 2009 (UTC)

Well, ArbCom elections and RfCs on ArbCom have been put on the watchlist announcements section before (I'm not sure what it is technically referred to as); was it advertised there? I don't recall seeing it there (and if it said x number of days to go towards the end, that would help too). I'm sure it would've generated more interest if it was. But yeah, I did end up making some comments anyway so it's OK from where I'm standing. Ncmvocalist (talk) 04:24, 19 November 2009 (UTC)

Good point, though. We should definitely have such an announcement on watchlists for the next round. --Tryptofish (talk) 18:06, 19 November 2009 (UTC)

I would encourage any who comes here after the RFC has 'closed' to just add their own views here on talk or if they see fit, throw them into the poll. This RFC doesn't need to be 'extended', per se, since it has no direct effects beyond sharing your point of view with the rest of Wikipedia, and obviously, it's never too late to do that.

The "rfc closure" isn't at all a discouragement of participation after the fact-- it's a more a reminder to the Wikiproject that we're probably not going to get too many more opinions beyond a certain date just from running that poll. But yes, yes, a thousand times yes, we want all the help opinions we can get, regardless of when or where. --Alecmconroy (talk) 08:51, 17 November 2009 (UTC)

Cheers for clarifying Alecmconroy. :) Ncmvocalist (talk) 04:24, 19 November 2009 (UTC)

Celebrity endorsements

If anyone knows them well, could we ask arbs to look at any proposals before before proceeding to any kind of "ratification poll".

The Arbs are our village elders and I don't think any proposal can work unless it makes sense to most of them. "The Arbitration Committee" may or may not need to approve the plan, but the individual arbs absolutely need to approve of it for it to fly.

I'm not particularly wiki-socially aware, but I'm pretty sure a few Arbs have called for some form of community desysop? If, I think we're getting close to the point where their opinions might be very helpful as we craft, polish, and propose. --Alecmconroy (talk) 09:04, 17 November 2009 (UTC)

It's certainly reasonable to make sure they are aware. Would a notice that this project exists be appropriate for Wikipedia talk:Arbitration Committee/Noticeboard? --Tryptofish (talk) 19:09, 17 November 2009 (UTC)

I am not at all knowledgeable about this subject but I think Wikipedia talk:Arbitration Committee would be a more appropriate location to inform ArbCom. However, a note to Wikipedia:Bureaucrats' noticeboard seems to me at least as important given the proposed role for 'crats. Ben MacDui 19:29, 17 November 2009 (UTC)

Yes, that's absolutely right on both points. --Tryptofish (talk) 19:40, 17 November 2009 (UTC)

And as I have commented previously, I think having a few 'crats weigh in is a good idea. Jusdafax 04:27, 18 November 2009 (UTC)

Question from an outsider

I don't want to sound flippant, but I can't make heads or tails of where a centralized discussion is occurring on the admin recall proposal being linked from CENT. Everywhere I seem to go is either linking me to some other admin recall discussion/proposal or is otherwise byzantine. Where can someone who hasn't participated in any of the past RfCs (or had any experience with the various proposals) go to see a short summary of what you are proposing and offer comments on that proposal? Protonk (talk) 07:16, 26 November 2009 (UTC)

The phase of discussion conducted here is now closed - refining the details of WP:CDA continues at WT:CDADR. Ben MacDui 09:17, 26 November 2009 (UTC)

Just to expand on what Ben said, I want to ask Protonk if there is something we have overlooked in how editors find their way to the correct place. Is there a wrong or misleading link somewhere? As Ben said, the page associate with this talk contains discussion of, and links to, all of the past proposals. The proposal being looked at now is at WP:CDA (and its associated links), and the active discussion is at WT:CDADR. At the beginning of WT:CDADR is a background section that hopefully explains this. --Tryptofish (talk) 17:01, 26 November 2009 (UTC)

Er...ben's response kinda points to the problem. I have no idea what phases of discussion are demarcated and when they start or end. The CENT notice has two links. The second, Wikipedia:Community de-adminship is helpful in the sense that I can get to something that makes some sense within one click, Wikipedia:Guide to Community de-adminship (which honestly should be what CENT links to). The first link points to what I imagine is the "next phase" Wikipedia talk:Community de-adminship/Draft RfC. But reading that makes my head hurt. Not because it is long (though that is a problem) but because it is full of sections like this and this. And if I read that whole not-RFC correctly, the idea is to refine the RfC so that on Jan 4 2010 (?) an actual RfC can be presented to the community. The whole thing is opaque from the perspective of an outsider. Protonk (talk) 18:44, 26 November 2009 (UTC)

I know what you mean about the "Guide" link separate from the main CDA page. That was, somewhat unfortunately, the way Uncle G wrote it. I tried putting links at the beginning of CDADR, so maybe (?) that helps. As for TLDR and head-pain, well, I feel your pain! But I have no idea what to do about it. On the bright (?) side, as messy as the discussion is now, the hope is that a simple proposal will come out of it in January, in which case the community need only read the proposal, not the sausage-making that went into creating it. --Tryptofish (talk) 19:24, 26 November 2009 (UTC)

I just feel (from experience bringing complicated proposals to cent, most of which didn't pass) that the "discussion" pointer needs to go to some general discussion section where someone can offer a suggestion or weigh a proposal. I would have done it myself, but it seems you guys have a system and I didn't want to fiddle with that. Protonk (talk) 19:31, 26 November 2009 (UTC)

Thanks, I appreciate that. (About having a system, well, don't over-estimate us! :-) ). --Tryptofish (talk) 19:53, 26 November 2009 (UTC)

• Just thinking outloud here, but my guess is that the "small steps" we've managed to achieve with a lot of this de-adminy thing at the admin project won't get that "giant leap" into mainstream practice until we actually push someone through it all. Right now, there's not anyone that I personally see as worthy (?) of such a thing. While there are certainly some admins. that I've lost a lot of respect for, I can't think of one that has the community is crying for their heads (at least with any justification). I'd imagine that the big day will come when an editor actually types in the "/some admins user name" thing, and files a request. No, I'm not going to volunteer here .. but I suspect that it will happen soon enough. — Ched :  ?  20:08, 3 December 2009 (UTC)

Regular recall schedule

I've only just stumbled across this debate, but that probably makes me in that respect representative of the majority of the wikipedia community, who are mostly unaware of it. I see that "Straightforward reconfirmation" was proposed and found unpopular, but I'm not sure what it is intended to mean. I notice that "Regular recall schedule" was proposed only very late on in the voting process above, and that only two people were actually opposed to it. This sort of suggestion is open to the worry as to how it might work out in practice, since some versions of it which have been proposed are not viable. I prepared a suggestion at User:SamuelTheGhost/Re-electing admins which I think could work. If it has any major flaw, I'd be grateful to be told what it is. SamuelTheGhost (talk) 23:32, 14 December 2009 (UTC)

Turkeys don't vote for Xmas. --Malleus Fatuorum 23:36, 14 December 2009 (UTC)

Turkeys don't get the opportunity to vote at all, but apart from that I can't see the meaning of this apparent metaphor. Who are the turkeys supposed to be? Perhaps Mr. Malleus Fatuus could explain. SamuelTheGhost (talk) 23:52, 14 December 2009 (UTC)

I'm not sure about the metaphor either, but I figured he meant that (what Malleus sees as) a corrupt system isn't going to support a course of action that could undermine it's authority. (There may also be some confusion as in the States turkeys are primarily associated with the Thanksgiving holiday. Many Americans opt for a ham or other cut of meat on Christmas as we have "turkey fatigue" by that point.) My objection to re-confirmation RFAs on a set schedule is that it will force all admins, even those whose actions are generally not in question, go through what is at best a difficult process. This could have a "chilling effect" that would cause admins to not be as bold as normal, especially in the months before their "term" is up, and would create more drama with questionable benefit to the project as a whole. You may note that some admins are on ANI and so forth constantly, either arguing with others or being dragged through the mud themselves, while some are rarely if ever seen there, they just keep their heads down and do the work that needs doing. You don't have to get re-confirmed to use rollback or AWB or whatever if you aren't misusing it, adminship shouldn't be any different. Beeblebrox (talk) 00:20, 15 December 2009 (UTC)

The very big difference though is of course that if you misuse rollback a couple of times then it gets taken away. No fuss, no bother. How much fuss would be involved in desysopping an admin who'd made two bad blocks of established users? --Malleus Fatuorum 00:27, 15 December 2009 (UTC)

Under our current system, an awful lot of fuss, a billion and a half words over fifteen seperate threads at at ANI, a user conduct RFC, a few more threads at ANI, and several weeks of deliberation by ArbCom, and then maybe something will happen. I don't like that either, which is the point of trying to find a new way here, I just don't think this is the one to go with. Beeblebrox (talk) 00:32, 15 December 2009 (UTC)

Well, at least we agree on what the problem is. --Malleus Fatuorum 01:27, 15 December 2009 (UTC)

In answer to Beeblebrox: I should have thought that those admins who "just keep their heads down and do the work that needs doing" could present themselves for re-election in fairly brief terms, and one would expect them to sail through without bother, which is what one would want. As for those who "are on ANI and so forth constantly, either arguing with others or being dragged through the mud themselves", those are the ones who it might be better to lose, or who might think, when their term expires, that it's a good time to step back and have a rest. I should have thought that the "chilling effect" would apply only to those who have a bad conscience, and for those it would be beneficial.

As for Malleus, if I could work out precisely what he is suggesting or opposing, I could respond. SamuelTheGhost (talk) 12:49, 15 December 2009 (UTC)

"... a corrupt system isn't going to support a course of action that could undermine it's authority". --Malleus Fatuorum 19:42, 15 December 2009 (UTC)

Wikipedia has both strengths and weaknesses. I hope that we're all trying to make it better. That means we try and make constructive proposals. Those who mock those attempts cannot be part of the solution; they are part of the problem. SamuelTheGhost (talk) 22:14, 16 December 2009 (UTC)

Pointer

I've noticed some editors having questions about what, exactly, is the wording of what is being discussed. Please go to: Wikipedia talk:Community de-adminship/Draft RfC, which is where the primary discussion is, currently. There, the first section, called "Quick links", will link you directly to the draft language. I hope that helps. --Tryptofish (talk) 19:11, 15 December 2009 (UTC)

Community de-Adminship - finalization poll for the CDA proposal

After tolling up the votes in the revision proposals, it emerged that 5.4 had the most support, but elements of that support remained unclear, and various comments throughout the polls needed consideration.

A finalisation poll (intended, if possible, to be one last poll before finalising the CDA proposal) has been run to;

• gather opinion on the 'consensus margin' (what percentages, if any, have the most support) and

• ascertain whether there is support for a 'two-phase' poll at the eventual RfC (not far off now), where CDA will finally be put to the community.

Matt Lewis (talk) 23:33, 17 January 2010 (UTC)

Request for your comments at Wikipedia:Community de-adminship/RfC

Wikipedia:Community de-adminship/RfC went live yesterday, and your comments are invited. The long-awaited run-up to the RfC (indeed, this is not the first attempt) was not without incident, but love it or hate it, it's up.

I also suggest a discussion regarding this RfC here, on this page, which now becomes a default spot for such. One topic I would like to see discussed is where we go from here, if anywhere, if the RfC fails. A major thumping or a strong bureaucrat thumbs down, or both, mean it's back to the drawing board, or in a worst case, disbanding this WikiProject.

And for reference: Wikipedia:'Community de-adminship' - The original Uncle G proposal, so that casual members of this WikiProject can judge for themselves where we were and are now. Thanks to all who have taken an interest, Jusdafax 09:20, 23 February 2010 (UTC)

(Better link, here is the original from the archives) NewsAndEventsGuy (talk) 22:52, 10 July 2017 (UTC)