User:Writ Keeper/Community desysop process

Yes, it's that time again. Many people have tried this and failed; I doubt I'm any wiser than they are, but I should at least try.

Anyway, my general plan is to co-opt structures already in place, rather than making things up Just Because I Can. Basically, the process (and it is a process, sadly; policy wonkery abounds, but there is no other way for it to be so) is a fusion of an RFC/U and an RfA, since those are the two procedures that are most relevant in my eyes. Basically, it starts in almost exactly the same way as an RfC/U does: A user or group of users states their case for a desysop, citing with diffs whatever misbehavior they feel is relevant. Ideally, at least some of these will be diffs of specific admin actions, though I guess they don't have to be, if one wants to conduct a more general "conduct unbecoming" type thing. Some of the formal trappings of an RfC/U can be done away with (there's no need for a "Desired outcome" section, for example), but this case should probably broadly resemble a standard RfC/U, including the attempts by users to resolve this previously. When completed and gone live (and the subject of the request notified via talk page), this request will be subject to the usual rule of RfC/Us: if it's not certified by another user in 48 hours, it goes inactive and is subject to deletion.

However, if it is certified, that's where the process diverges. Instead of proceeding to a general comments stage, a link to the request should then be forwarded to the 'crats via BN, who will then manage the procedural things. Note that the subject must be notified specifically that the request has been certified; the second notification they will have received to this point. I would suggest that, if there is a consensus of 'crats that the request is completely frivolous and baseless, then they are allowed to scuttle the request at this stage; however, this consensus must be reached publicly, through public discussion (probably on BN), and it is specifically only reserved for entirely frivolous complaints. If there's a hint of legitimacy to the request, it should proceed. Anyway, there should be a 48 hour wait between the report of certification to BN and the opening of the next phase of the process. This is for two reasons. First, the aforementioned 'crat discussion (which, if it were ever invoked, should be pretty quick.) Second, to allow the subject of the request to give their agreement (which is why they must be notified again). This is to prevent a request for desysopping that happens to occur at a bad time in real life for the subject, leaving them unable to defend themselves throughout the procedure. Basically, if the subject replies on BN that they do not have time to participate in the process right away, they are allowed to ask for additional time up to an additional 48 hours (so, up to four days out from when the request was certified, total.) If this still isn't enough time, or if the subject doesn't reply at all within the original 48 hours, than the process may be delayed indefinitely, but the subject's admin bits will be removed until the desysop request can go forward--presumably, if the subject does not have enough time (because of real-life issues, one surmises) to defend themselves, they are probably also too busy to use their bit.

Now, from here on out, the structure will be not dissimilar to an RfA. A new page is started, and the original initiatior's statements will be placed where a nominator's statement would go. This will probably be simply a direct copy of what was in the RfC/U-like first phase. Notifications can be placed in the usual areas for RfCs, seeking input from other users. The subject can place a defense statement underneath the initiator's. There will be a section for questions much like an RfA's; these questions can be aimed at either the initiator or the subject (and must clearly identify whom they're being asked of). These questions, as always, are not mandatory to answer, for either person. Finally, the votes. Instead of "support" or "oppose", since those would be ambiguous terms in this context, the sections (and !votes) should be "Retain" (the bits) and "Remove" (the bits), as well as the standard Neutral section. In-line replies to specific !votes should be allowed, but since this is probably the one place that will earn a reputation even worse than RfA's, such comments should be moderated (probably by, again, the 'crats). Again, 'crats should be extremely careful about what they choose to moderate here, and a person's actual !vote itself cannot be subject to moderation (though it can be indented for the usual reasons).

Finally, the decision. This part I'm still undecided. The minimum requirement for removal of the bits should certainly be between 50%+1 and 70% of people voting "Remove" (as 70% the lowest bound of the discretionary range for RfAs); it shouldn't be harder to remove an admin at this point than it was to approve them. I would hazard a discretionary range starting at 60% and ending at either 75% or the percentile margin that the user passed their most recent RfA; whichever is lower. However, I'm not sold at all on those numbers, and anxiously await feedback from them. Anyway, this phase will run for a week, and at the end, will be decided by the 'crats in a similar way to an RfA.

Now, some questions I can already foresee:

Why this? Why not mandatory reconfirmation RfAs every X months/years?

Well, the two aren't mutually exclusive. Reconfirmation RfAs do admittedly have some advantages; most notably, since there's no original instigator, there's less possibility for the fear of reprisal. And that's fair (in general, I think fears of reprisal are somewhat overblown, though perhaps I wouldn't be the one to know about it if they were legitimate). But I'm proposing this avenue as opposed to reconfirmation RfAs for a few reasons. One, if there is a person who really should not have admin bits, we don't have to wait until their turn to remove them; although this is a fairly lengthy process (which is probably one of its flaws), it's not that long. Also, mandatory reconfirmation RfAs are just a lot of work, and most of it will end up being pointless. It's a drag for "innocent" admins, it's a drag for 'crats, it's a drag for everyone. But also, and this is a thing that I don't see brought up a lot but could easily see actually happen: I would worry that, since they would happen all the time, a reconfirmation RfA could simply become a foregone conclusion; the equivalent of a week-long line at the DMV to renew your driver's license, if you will. It could provide the illusion of a recall process for admins, but after the first year or two, I could easily see it becoming just another rubber-stamp process for process's sake, rather than any kind of real useful thing.

Yeah, what about that reprisal thing?

As I said, I think those fears are overblown, but that doesn't mean I'm right, or that they're not worthy of consideration regardless. The fact that there is basically a "prime mover" in this case does offer the opportunity, if nothing else. I was considering a means for a way to do this anonymously; basically, one could email the 'crat list or Arbcom or some other type of group, with a copy of their statement/diffs/etc., and have one of them post it as the start of the first phase. From then on, the process will take care of itself; the statement can be reuse for the top of the RfDA, and questions to the initiator will obviously simply go unanswered. Of course, this requires that that group the actual initiator emails be trusted by them; I'd hope they can trust someone, but yeah. And really, it shouldn't much matter if the request is done at the behest of another; it should be the content of the objections that matter, not their source. But yeah, that is an admitted flaw in this system, and perhaps a big one.

You seem to be delegating a lot to the 'crats. And hey, you're one yourself, jackass! isn't this just a power grab for the 'crats?

Funnily enough, no; I'd expect it to be more likely that the 'crats in general might oppose this, due to the extra workload piled on them. (But hey, we're losing renames; gotta have something to fill the time and earn our paychecks!) But basically, I use 'crats in this for most things because a) they're supposed to be trustable by the community, perhaps the most trustable group that the community elects, and b) they're already deeply involved with issues of granting and revoking adminship, since they're the ones who have the technical capability to do it. But if y'all have better suggestions for a trustworthy group, I'm all ears. And, to assuage any concerns about my personal lust for power: I will be more than happy to resign as a 'crat if this proposal (somehow) passes and anyone thinks I should and asks me to. And, in accordance with what I said on my RfB, I would absolutely not seek to regain the 'crat bit without another RfB, where the community at large would have a chance to assess my powerhunger. The project will be much better served by having an actual desysop process than by having me be a 'crat (or even an admin, for that matter).

Anyway...

This is still a draft, of course. I'm not thinking of proposing it to the community as a whole yet; I'm looking for general feedback first. Please use the talk page, if you would be so kind. I've been kicking this idea around for quite a while now, but I don't knwo that it's different enough (or even at all?) to the previous attempts that I know have been around forever, so it'll be especially interesting to hear from those who have been around Wikipedia for longer than I have, and have watched some of these previous measures fail. Cheers!