User talk:Hersfold/Admin recall

Discussion

WereSpielChequers observations

• Adminship required to vote. This could be counterproductive - making admin even more of a big deal and attracting extra opposes at RFA. How about 3 months tenure and 500 edits. WereSpielChequers 09:56, 16 January 2009 (UTC)

  The original concept thrown out put the necessary disapproval rate at 80%, which I felt was extremely high. I first suggested that it be dropped to 75% (flipped with RFA). As I thought about it a bit more, in order to decrease uninformed votes, I suggested limiting voting to admins and dropping the disapproval rate. The idea behind this is that admins understand adminship, obviously, and what has to be dealt with as an active administrator. If this stipulation makes it into the process, I would argue for a lower disapproval rate than 75%. When we're talking about only admins voting, if the majority of them think you should be out, then you should probably resign. I think a 51% (simple majority) disapproval rate among admins would be ideal. If voting is to be open to pretty much everyone, then I support the 75-80%, because we know how it will go with grudge votes and 'Support per' votes of those who don't know what's going on and have no desire to inform themselves. We see it in RFA everyday. لennavecia 13:20, 16 January 2009 (UTC)

  I can see the reasoning behind wanting to limit voting to the community and I doubt if anyone will dispute excluding single edit accounts. But if we set the threshold somewhere new it becomes a big deal and if we use an existing process such as RFA it becomes an even bigger one. WP:RFA is bad enough already, adding another admin only thing could make it worse. That's why I'd rather have the sort of threshold we had for voting in ArbComm elections. WereSpielChequers 14:06, 16 January 2009 (UTC)

  And I can see it from your view as well. If we use an AC election criteria for voters, however, the disapproval rate should be set at 75-80% as was first suggested, rather than a simple majority method I suggest with admin-only voting. لennavecia 17:58, 16 January 2009 (UTC)

  When we were coming up with this whole plan last night, a restrictive eligibility requirement such as you're suggesting, SpellCheckers, was brought up. To make sure that a) whoever votes has a firm understanding of policy and b) has at least some idea of what adminship involves, I'd probably prefer at least six month's tenure. Those who can't vote can still discuss under this procedure; and their arguments may convince a large number of people. Those who can't vote aren't excluded from having their voice heard; we're just relying on those who have been appointed to judge consensus well to do the actual voting. Hersfold ^(t/a/c) 19:00, 16 January 2009 (UTC)

  This may sound odd, but my concern is for a fixed length eligibility requirement though I'm not sure where to put that between 2 and 6 months. Partly that's because I don't feel that I have the experience with newbies to know where to set the threshold, but also because from my own experience at RFA I think a clear threshold is less cliquey - I first had a good look at RFA in my early months as a newbie, saw that there was some unwritten rule about newbies not participating and didn't come back to RFA for many moons. I think I'd been editing for about a year when I first !voted at RFA but I'm not suggesting the threshold be anywhere near that high. WereSpielChequers 10:48, 17 January 2009 (UTC)

  A year would probably be too high, but anything less than three months I'm not sure would be enough for the average editor to have sufficient "clue." I think a good level would be about 6-ish months? An edit count probably wouldn't hurt either, to make sure it's not someone who pops in to edit one article every two weeks and is still essentially a newb; maybe around 500-1 000 for that.

  I'd still somewhat support admin-only voting, though, mainly because that would allow us to have a lower "removal" percentage around 50-60%. Administrators are appointed to judge consensus in certain cases; while personal opinions will of course be a factor in how the admins vote, we can ask them to consider the wishes of the community as shown by the discussion as well. I'm still afraid of the risk of a pile-on even with the eligibility requirement; I've seen it happen at RfA and I'm sure it would happen here when tempers are running high. Hersfold ^(t/a/c) 02:03, 18 January 2009 (UTC)

• Requests requiring at least 5 diffs. What about instances where there are four or less truly terrible decisions? WereSpielChequers 10:02, 16 January 2009 (UTC)

  I agree. This should be something like "Requests must include evidence (diffs or links to logs) to support all claims of abuse." لennavecia 13:20, 16 January 2009 (UTC)

  That was a completely arbitrary number. It can be changed. Hersfold ^(t/a/c) 19:00, 16 January 2009 (UTC)

• Public vote lasting 5 days. Suggest 7 to allow for weekend editors. WereSpielChequers 10:23, 16 January 2009 (UTC)

  I agree with this as well. لennavecia 13:20, 16 January 2009 (UTC)

  That works - it mirrors RFA better then anyway. Hersfold ^(t/a/c) 19:00, 16 January 2009 (UTC)

No blocks for those initiating requests

I forgot to add this earlier. There were two points (numbered 3 and 4). 3 stated no indef blocks in past year. 4 stated no blocks in past year that expired of their own accord. I condensed these two into one that now reads "No block in past year. Those that were overturned are disregarded." لennavecia 18:02, 16 January 2009 (UTC)

That works. Hersfold ^(t/a/c) 19:01, 16 January 2009 (UTC)

Now that I think about this more, this will probably have to be footnoted to include the bit about an indef block. Any user who was indef blocked or placed under a temporary community ban that was lifted after a so much time would not count as overturned, thus the user would not be eligible to initiate the request. لennavecia 20:33, 16 January 2009 (UTC)

Perhaps something like "No blocks, bans, or editing restrictions within the past year that were not overturned as erroneous or undeserved; or that ran for a period of at least two weeks before being lifted." Would that work? Hersfold ^(t/a/c) 21:13, 16 January 2009 (UTC)

Well, I think if we specify "erroneous or undeserved", we don't need to set an arbitrary time frame. لennavecia 20:20, 17 January 2009 (UTC)

Actually, someone just pointed out to me in IRC that a 24-hour (or less) 3RR block probably shouldn't prevent someone from participating in this, particularly for a one-time thing. What if we just leave it at blocks that lasted for two weeks or more? Hersfold ^(t/a/c) 06:10, 17 January 2009 (UTC)

OK how about: "Re blocks, bans, or editing restrictions that were not overturned as erroneous or undeserved; No 24 hour ones in the last 6 months or longer ones in the last year." WereSpielChequers 10:55, 17 January 2009 (UTC)

What about cutting this entirely? If an admin has made some really iffy blocks, then don't the blocked editors deserve a chance to comment? NuclearWarfare _(Talk) 01:36, 18 January 2009 (UTC)

WereSpielChequers, I'm not quite understanding how you've worded that. NuclearWarfare, your suggestion may actually be the best; my only other suggestion would be to make it not depend on the length, but the number of blocks: "No more than three blocks in the past year, and no blocks in the week prior to the initiation of the request." That takes care of the repeat edit warriors, and allows those who were blocked for severe disruption that are trying to redeem themselves the chance to continue to do so. Hersfold ^(t/a/c) 02:11, 18 January 2009 (UTC)

At what point does one's block log push them out of "good standing within the community"? I would say an editor who's only had a block or two for minor infractions would be considered "in good standing" while someone who's had several blocks in the previous few months would not be considered so, correct? In most cases, 24 hour blocks aren't for anything major. In cases where actions are repeated, or where the transgression is greater, longer durations are imposed. If "editor in good standing" is too open for interpretation, perhaps 24 hour blocks should be disregarded and only those who have had longer blocks imposed in the previous 3 or 6 months, would be ineligible. I'm opposed to totally disregarding block histories. لennavecia 06:11, 18 January 2009 (UTC)

I disagree with this caveat entirely. If you want to sell this to the community at large, it should be made as open as possible so that any user can file a complaint. I trust the community and the team of bureaucrat/administrator reviews enough to deal with issues from edit warriors as issues come up. NuclearWarfare _(Talk) 18:17, 18 January 2009 (UTC)

Cleanup

I've gone ahead and started the cleanup process since we have more eyes on this and will have a lot soon; I've already turned the bulleted "why we have this" section into a three-paragraph section of prose complete with graphs and a reference. More will come, and if I screw something up check back in a couple minutes. Hersfold ^(t/a/c) 08:36, 17 January 2009 (UTC)

In the last section, for those who can vote, it lists eligibility requirements, but it's not an all or one list. As it is now, the user must be one of the first three bullets and the fourth. I hope I'm wording this in a way that makes sense. I have to go to work, so I don't have time to tweak or better explain, but that did pop out in my reading of it just now. I also noted in the new lead that there is quite a bit of redundancy. To avoid any unnecessary tl;dr, I think that can eventually be trimmed down a bit. Perhaps utilizing footnotes for things that should be obvious to everyone, but need to be explained for the wikilawyers and those who can reasonably be considered less than clueful. لennavecia 20:24, 17 January 2009 (UTC)

I'll try to work on that in the eligibility - don't worry, I do get what you mean. As for the lead, I was writing that at 2-3 AM, so it almost certainly can be improved on. I'll look it over again later on. Hersfold ^(t/a/c) 21:50, 17 January 2009 (UTC)

Yes and no

I like the fact this is being discussed, and there are some good ideas. User:EVula has offered an alternate proposal at WT:RFA; his link is User:EVula/opining/RfA overhaul. Roughly speaking, his idea is: no new structure, no preconditions, simply set RFDA up like RFA and let it evolve in the same way that RFA evolved. See JDelanoy's response there; his response is similar to what I'm hearing from the most active admins, namely: over my retired body. If (and that's a big if) we hear that the current admins most active in blocking and deletions either will do them a lot more slowly, or won't do them at all, under the new system (on the theory that they can't know what's safe anymore if we haven't worked that out yet), then both proposals, it seems to me, are non-starters. It doesn't matter if they're good ideas; we can't afford a sudden drop in admin activity due to admins looking over their shoulders.

But we could do something that picks up most of the advantages of both proposals: we could apply RFDA/admin recall only to those admins whose RFAs begin after the proposal passes. This sounds like one of the PEREN proposals (a "probationary period" for admins), but it's not, because it's not a probationary period; it would be the status quo going forward, for all new admins. It would be just as effective at what seems to be the main reason for Hersfold's and EVula's proposal, namely, the fact that RFA is too hard to pass now. And it is quite likely to be effective over time in freeing up ArbCom to desysop troublesome admins; the folks at ArbCom are sensitive to what the community wants, and if we have a string of votes at RFDA showing that the community as a whole feels that certain types of admin behavior warrant desysopping, that's likely to be persuasive at ArbCom when cases come up involving "grandfathered" admins. Finally, since the main point of EVula's and Hersfold's proposals is to make it easier to pass RFA, I submit that the admins who pass using what will almost certainly be a lower threshold are exactly the ones that are more likely to need oversight from RFDA. Also see the arguments in the various threads (which are sprouting like weeds) at WT:RFA. - Dan Dank55 (send/receive) 20:25, 17 January 2009 (UTC)

Just so you know, I have read this, and do intend to respond; both times I've had a chance to log in and comment since you posted I haven't had time to work out a reply. You have given me some food for thought, though, so it'll be a while before I have the time to do so. Hersfold ^(t/a/c) 02:13, 18 January 2009 (UTC)

Thanks, take your time. I mentioned this page and the WT:RFA threads at WP:AN#Poll coming on Admin Recall (aka RFDA). - Dan Dank55 (send/receive) 03:00, 18 January 2009 (UTC)

Oh. Uh. I'm not sure we were *quite* ready for that yet, but thanks all the same; we're nearly there anyway, I think. :-) WARNING: TL;DR ALERT! If you don't want to read the whole thing (but I recommend you do) I have highlighted the important bits in bold. The reasoning behind this is very important, so try to read in between the bold bits if you have time.

I did see EVula's proposal - he'd pointed it out to me last night on IRC after I finished up the lead for this page. His proposal is very simple, and I believe intentionally so to avoid having to demonstrate how things work. The two proposals (this one and EVula's) are actually rather similar; he described his as the "hippie version" compared to this one; the main difference between the two is that this proposal works to add a little more protection for the administrator being recalled. An RfA-like recall process enables the mob rule you tend to have with controversial RfA's, which I believe is the main concern administrators such as Jdelanoy have had with previous recall ideas. David Gerard actually specifically mentioned this on the talk page of EVula's proposal: "The problem is that the present RFA gives too much voice to axegrinders." This proposal would be set up more as a "jury of one's peers" as User:MZMcBride put it the other day. Both sides of the argument would have their chance to fight it out in the open discussion period. There are minimal restrictions in place to ensure that those participating in the discussion do in fact have enough knowledge of policy to know what they're talking about (and these could probably be removed; it's a work-in-progress, after all). However, once it comes to the final decision, only those editors the community has already placed their trust in to undertake difficult and challenging tasks will be able to do so. These administrators (or experienced editors, if we take that route) know what working in a Wiki is like, and have "been in the trenches," so to speak (link for those unfamiliar with the term, not for a literal comparison). I, and the other editors working on this proposal, are afraid that a purely-RfA style recall proposal will lead to pile-ons against administrators who are either unpopular or are in fact doing a good job, but do it in a questionable manner. That's not what this proposal is intended to do, as it will make administrators afraid to take action when they should and/or need to. The precautions we are working into this proposal are set up to not only allow the community their voice, but also to protect the accused.

As for your suggestion about how to implement this, I think that is an excellent idea. I was wondering if there was anyway we could do a "trial run" of this process, and I think you've hit the nail on the head. With such a "grandfather" period, we would be able to sit back for a period of a few months and track progress both in administrator performance and standards at RfA. After some time, we could go back and review the proposal and figure out if we want to "flip the switch" and put everyone under this system, work out some bugs and try again, or just scrap it entirely if it does turn out to be a miserable failure. At least we can say we tried it, anyway. As Dan pointed out, even a trial run can have lasting effects on ArbCom, showing them what the community considers to be problematic behavior that should be looked into.

As Dan said, the main purpose of this is not to be able to fire admins who aren't doing a good job, although that is a potentially useful end. The main purpose is to help increase the number of administrators, by enabling us to lower the standards at RfA to the point the process can be worked on as has been called for countless times before. Who knows, it could be that a lowering of standards is all that is needed to "fix" RfA, and if that is the case, then this is probably the only way to do it. It seems strange talking in absolutes on Wikipedia where we try to focus on consensus so much, but the fact of the matter is, consensus has time and time again failed to address the problem that statistical studies and recent events are showing us is continuing to degrade. It's time to do something about it now. Hersfold ^(t/a/c) 05:19, 18 January 2009 (UTC)

It sounds like some of my ideas were helpful; I'm glad to hear that. My position is that I'm going to sit this one out, but as always, I'd like to see the process work; I'd like to see both sides give serious consideration to the ideas and talk with each other instead of talking past each other. I look forward to whatever poll results from this; please let me know when things move into a wider forum. - Dan Dank55 (send/receive) 15:49, 18 January 2009 (UTC)

I did a forbidden thing and altered your text. You can revert and warn me if you want, just don't block. EVula is all man, though... so I changed references of she/her to he/his.

Other than that, nice overview. I am very much opposed to making it RFA style with no higher standards for all the reasons Hersfold has noted. As far as grandfathering, I personally don't like the idea. Another point of this is to bring on a corp of better behaved admins. Any admins threatening to decrease the amount of work they do because they fear who's watching are being silly. As long as they're not abusing their tools or position, they shouldn't be worried. Under this plan, two other admins and a 'crat have to certify the request. It would be difficult to get screwed over undeservingly. I think we all know that we've got some admins who have been admins for a long time and have a history of questionable actions and what some consider abuse of position. Grandfather actions, not admins, so that (assuming this becomes active) when this goes live, all admins have a reason to clean up their act a little; mind their Ps and Qs. So that's to say, only actions made after this goes live would be game.

Admins should have never been allowed to operate unaccountable. But that's pretty much how it's been. We gain adminship, get the rights and we're thrown into it without much guidance. It's like starting a new job, being taken to your work area on day one, boss says "Here's where you'll be working and here's your equipment. GO!" And that's it. Surely admins will make mistakes, but most jobs can potentially be lost. And while this isn't a "job", it sort of is. Knowing you can be fired is one motivation people have for doing their job well. Currently, there's little threat of being fired from adminship, so to speak. That should change. لennavecia 06:33, 18 January 2009 (UTC)

Interesting

Never like these proposals, they tend to either be open to abuse or so full of provisos and get outs to be of little real effect and please no one. Haven't read this in details but came across this interesting part regarding arbcom actions "By the time the case finishes some months later, whatever the problem was in the first place has usually become a moot point, and the remedy is usually of the form "Admin X is admonished."" - I'm assuming this is supposed to indicate it's a positive that we can get a knee jerk witch hunt to teach these people a leason rather than (a) a calmer process which shows that it wasn't ever much of a problem or (b) That time and personal reflection on events are enough to fix the underlying issue.

"As a result, administrators are regarded by many editors as "above the law," " well my understanding is that wikipedia doesn't operate a legal system and isn't about crime and punishment, the fix to the problem is to make people more aware of that, not to turn it into a system of crime and punishment to make people feel better. --81.104.39.44 (talk) 08:42, 18 January 2009 (UTC)

• To clarify my own point a bit, I'm suggesting that maybe we are addressing the wrong problem. Looking at the root of what causes people to be unhappy with admin action, what can be done to lessen that unhappiness, are there better ways to deal with problems, admins have a limited number of tools available to deal with issues and most of the tools are pretty blunt. --81.104.39.44 (talk) 08:52, 18 January 2009 (UTC)

My point with the sentence you quoted was actually the opposite; for truly problematic admin behavior, by the time the ArbCom finishes the case, it has become totally pointless to do anything about it, so the admin gets a slap on the wrist and that's that. We need an intermediate step so that ArbCom can deal with the big cases they were made to deal with, and the community can still make it clear when they feel something is out of line.

I know Wikipedia doesn't have laws; that's the expression. My point was that many editors feel that administrators are able to get away with much worse conduct (incivility, etc.) than other editors because we're admins. Usually when I put something in quotes "" it's either not something I myself said or it's an analogy.

Currently, we have limited ways to deal with admin actions that make us unhappy. As I covered previously, we can either complain to no real end at ANI, get a steward to desysop in emergencies, or waste several months at ArbCom. There is no way to hold admins accountable, as they have to really mess up in order for ArbCom to accept a case in the first place, and really really mess up for it to still be a big enough point months later that ArbCom desysops them.

Do you have an account, by the way? You seem to have a much higher-than-usual understanding of Wikipedia for an anonymous editor. Hersfold ^(t/a/c) 17:20, 18 January 2009 (UTC)

Simple majority?

Why was this chosen over a 60% or 2/3rds majority? Apologies if this is answered in the FAQ above. Protonk (talk) 13:13, 18 January 2009 (UTC)

Simple majority is a possibility if voting is limited to admins only because, in my view, if the majority of your peers don't trust you with the tools, you probably shouldn't have them. This was taken from my recall criteria. لennavecia 16:12, 18 January 2009 (UTC)

Looked at it one way, administrators are more likely to be rational about a recall procedure than a group of other editors who are all highly upset at a particular action. The bar shouldn't need to be as high in that case, because you won't have to compensate for the "torch-&-pitchforkers" as we sometimes have to do at RfA. On the other hand, I've had several people point out to me that admins would be less likely to vote against "one of their own" (along the lines of meatball:DefendEachOther), so the bar from that point of view would need to be lower for this to be functional. Also, as Jenna pointed out, if half of the voting admins think you shouldn't have the tools, that's probably a really really big sign that it's time to step back for a while. Hersfold ^(t/a/c) 17:25, 18 January 2009 (UTC)

Checklist

Here's a plug for my De-adminship proposal checklist. Have the concerns there been addressed for this proposal? TenOfAllTrades(talk) 01:25, 20 January 2009 (UTC)

Let's see... (each bullet corresponds to the same bullet on the checklist)

Clarity

• The procedure is clearly laid out, with specific time limits for every portion of the process (initiation, discussion, vote). At this time there is no specified appeal process, but I had meant to note that admins desysopped through this process can reapply through RfA.
• At present, administrators vote in the final decision; there is debate currently ongoing as to whether this should be extended to experienced editors as well. The basis on which the decision should be made is not spelled out as of this time.
• This proposal is mainly intended to lower the standards expected at RfA to allow more eligible candidates to earn the tools. That should be the only direct effect on other processes, although this would be considered to be a step down from ArbCom.

Utility

• This proposal is not particularly likely to reduce drama, however as currently set up it should insulate the final decision from the side effects of drama. Paperwork would be reduced, as less cases would have to go through ArbCom; they could be handled directly by the community first.
• That is uncertain. The largest concern I have heard about admin-only voting is that administrators would be unlikely to vote to desysop one of their own. If this is the case, then there is a possibility that cases would be appealed to ArbCom. I respectfully disagree, however, and point out that ArbCom has desysopped 20 administrators to date, and all Arbitrators to this point have been administrators throughout their terms. If voting is extended to experienced editors, however, I fear we may have more administrators removed than are in fact deserving of that fate.
• Recall appeals should only be started in response to a history of abuse of the tools and/or a history of gross misconduct, after repeated attempts to address the issue through other means. To date, these are the only reasons administrators have been desysopped.
• I do not have an example at this time. However, I believe that several ArbCom cases would have been much more quickly handled through a process such as this.
• This proposal attempts to limit the ways in which it can be abused by instating basic eligibility requirements to participate in discussion and voting. Editors will be expected to meet a certain experience level, by which point they should have an understanding of applicable policies. Those voting would be administrators (or highly experienced users) who should not only have a high understanding of policy, but also basic knowledge about what is expected of administrators.

Redundancy

• This proposal is not markedly similar to any existing process.
• This proposal is not a duplicate for ArbCom; it should be attempted before ArbCom, except in exceptionally severe cases or those involving private information.
• It is not likely that a simple change to an existing policy could provide the same functionality and not be as open to abuse.
• This proposal is not markedly similar to any previous proposal.

Trust

• Any case which would be based largely on private information as evidence would be referred to ArbCom by the reviewers. If private information is a part of the evidence, but is not a major portion, discussions with sitting Arbitrators would determine how the case should be handled. If ArbCom recommended such as case go forward under this process, an effort would be made to provide as much information as possible without violating the privacy policy. Similar cases have been conducted largely on the word of the Checkusers, which seems to have been sufficent.
• A bureaucrat and two administrators review each request prior to its being officially filed for validity. Currently, voting is done by administrators. These users have been selected by the community due to their trustworthiness. All administrators would be subject to this process, and ArbCom would be right next door.

Technical

• Ugh, no. The only thing that might need to be implemented would be a bot to strike or remove comments made by ineligible editors, and that should not be very difficult since we have many bots with similar functions or operating methods currently running.

Implementation

• Widespread community support. A proposal has been brought forth to have this initially apply to administrators whose RfAs began after the implementation of this proposal, however this has not yet been decided.
• If enacted, this proposal should be reviewed after a maximum of six months, provided at least one case has been requested. That review should include a recommendation to continue, substantially modify, or scrap the process altogether.

Several of these responses are likely to change over time; however, if you have any questions or concerns, please comment. Hersfold ^(t/a/c) 05:04, 20 January 2009 (UTC)

Okay; thanks for going through that so thoroughly. I was really just hoping that people would have a quick glance over the list, but the point-by-point is great. :D

Coming back to the issue of utility now. As I read it, the aim of this proposal is to provide an alternate, faster, lower-paperwork process (compared to Arbitration) for dealing with admins who have abused their tools repeatedly and/or particularly egregiously, is that correct?

The problem, as I see it, is that ArbCom has not been reluctant in the past to do emergency desysoppings on the basis of truly egregious abuses of the buttons. The ArbCom has also been willing to suspend or remove the sysop bit from admins during regular Arbitration cases. Where those cases have been straightforward, clear cases of simple abuse the ArbCom has generally handled the cases promptly — though such cases are admittedly rare.

The cases that tend to generate the most paperwork and the most ill will are generally the ones where Admin Alice is involved in some way with a dispute with Bob, Carol, and Dave, and the circumstances include some mixture of interpersonal conflict, article content, page protection or user blocks, long-term grudges, other admins on the periphery, cheerleader cliques on both sides, and general dickery all around. In such cases, it usually doesn't make sense to say "Let's desysop Alice, then Arbitrate the rest!". (If misconduct by Alice does seem clear, a temporary injunction at the start of Arbitration is always available pending final resolution of the case.)

In other words, I fear that there would be little reduction in paperwork — just the transfer of a very few 'easy' cases from the ArbCom to a different bureaucracy. Given that the ArbCom has not expressed any concerns about being overworked by straightforward desysoppings, I'm not sure that we'd be solving a genuine problem.

Now, one unstated aim that some supporters of this proposal may have is that it does open up a new avenue to remove sysop privileges (one that doesn't run through ArbCom). That, this proposal may accomplish — but we should then be very careful in the future about 'scope creep' of this process. To my jaundiced eye, the only genuine change that this proposal may bring about is a broadening of the circumstances under which an admin may be desysopped. Your mileage may vary, of course. TenOfAllTrades(talk) 16:33, 21 January 2009 (UTC)

Criteria for starting the process, and other comments

I suggest that the bar be raised for the criteria to start the process. Currently to start an RfC requires two people complaining. Your proposal is to make beginning a recall easier, in a sense, than that: it only requires one person complaining (though perhaps two admins to certify that a complaint has been made). How about requiring two or requiring three complainers, as well as the higher level of certification than an RfC requires.

I fear that this process will add stress to the lives of admins. Just going through the process will be unpleasant even if one is not desysopped. That's a reason to make it harder to start, as I suggest above, and also a good reason to consider not introducing this system. I doubt it will increase the number of admins; instead, it may result in more resignations from those who don't wish to take the stress of regular recall procedures.

Here's an alternative proposal which might have a better chance at increasing the number of admins: Continue to allow people to RfA just as they do now, and not be under this recall procedure; but also allow people an option of stating in their RfA that they will be under such a recall procedure, and in that case have it be binding on them. I'm not sure that this wouldn't be worse than just keeping the system we have now, though: with time it might come to be expected that everyone who RfAs will agree to be under a recall procedure, and it may be invoked too often, causing too much stress on the admins. ☺Coppertwig (talk) 00:41, 24 January 2009 (UTC)