Wikipedia:Requests for comment/Desysop Policy (2021)

A request for comment to discuss changes to the policy on removing administrative permissions 20:43, 20 February 2021 (UTC)

Wikipedia:Requests for comment/2019 community sentiment on binding desysop procedure (WP:DESYSOP2019) closed with a consensus for a different desysop procedure to the current process that requires the referral to the Arbitration Committee. That discussion did not result in action because no one proposal had the necessary support to achieve community consensus. The close also highlighted concerns that the community had including:

• The ArbCom process is unnecessarily difficult
• Administrators who make unpopular calls could face harassment
• The processes on other projects might not work on the English Wikipedia
• The community needs a way to address problematic conduct

As a follow-up to that RfC, I am proposing the following be added to the Wikipedia:Administrators policy:

Any user who is extended confirmed and has made at least 25 edits in the last 6 months may file a request for desysop under the following conditions:

1. The request must link to at least one thread at a community forum such as AN or ANI that closed within the last 6 months where the closing statement indicates that there was consensus that the administrator behaved inappropriately.
2. The request will then be open for endorsements. If 10 extended confirmed users meeting the filing requirements above, including at least three current administrators, endorse the request within 48 hours, the request will be reviewed by a bureaucrat, and if it meets the requirements, certified as being an active request for desysop. If the required endorsements do not occur within 48 hours, the request will be archived as unsuccessful.
3. Once certified, the administrator being discussed must transclude the request for desysop at Wikipedia:Requests for adminship within 14 days or resign as an administrator. If neither occurs within 14 days of certification, a bureaucrat will transclude the discussion.

When opened, the editor initiating should place notices at WP:AN and WP:BN and WT:RFA. Once a request has been transcluded, it should be added to WP:CENT and notices placed again on WP:AN, WP:BN. The request will remain open for comments for 7 days after transclusion.

If there is a consensus with a minimum support threshold of 60% supporting removal, a bureaucrat will close the request for desysop as successful and remove +sysop. Users commenting must meet the requirements for filing a desysop request to support or oppose, but may make general comments if they do not qualify.

Users may additionally initiate this request to remove interface administrator or bureaucrat permissions individually. If a user is desysoped through these processes, bureaucrat and interface administrator permissions will be removed as well.

TonyBallioni (talk) 20:43, 20 February 2021 (UTC)

Support

1. Support I've traditionally opposed these on the grounds that the current process isn't broken, but I think since the last discussion on this a lot has changed on the project and creating a framework for community initiated desyop that takes into accounts the needs and conditions of the English Wikipedia, while being fair to all involved has likely come about. The framework above aims to provide the community with a way to initiate a desysop process without going through the up to 2 months long process of an ArbCom case, while also providing protections against frivolous filings. The activity requirement for voters is a way to deal with socking, as since EC has been around for a while now, a ton of socks have it.
   I also took into account the traditional benefit of an ArbCom case giving individual under scrutiny time to present their response, by allowing them to choose when to transclude. I think this is fair when dealing with real life circumstances. The 60% threshold goes based on en.wiki's standard practice of requiring consensus to sanction someone, and consensus not being a pure majority. It also is a doable number and not unreachable.
   I don't think this is a perfect proposal, but I do think it is a good first step for a framework that will provide both people who believe an admin has behaved inappropriately clearer guidelines on how to proceed without the need to worry about an ArbCom case, and also provide the administrator under scrutiny fairness to prevent railroading. I also agree with the comment of Sdkb below that this will likely be refined over time, and is a starting place. TonyBallioni (talk) 20:43, 20 February 2021 (UTC)

   Noting that if there is consensus here, I do not oppose raising this to 65%. Also, per Tryptofish, this is a consensus based discussion, the numeric thresholds are just minimums. That can be clarified in the close/when it is written into the policy if this passes. TonyBallioni (talk) 23:08, 20 February 2021 (UTC)

2. Support This sounds like it is well thought out, and has sufficient safeguards to avoid frivolous or retaliatory requests becoming active. -- MelanieN (talk) 20:50, 20 February 2021 (UTC)
3. Support I think the endorsements requirement is particularly useful in preventing "grudge" filings. Schazjmd (talk) 20:57, 20 February 2021 (UTC)
4. Support I'm not really a fan of requiring three administrators to initiate a desysop, which I would think would go against WP:TROPHY (that is, giving administrators an elevated status in the community). However, I can certainly see why Tony felt it necessary to include that as a requirement, which I imagine would help avoid frivolous desysop requests. With that said, I still consider this to be a net positive, rather than the patchwork of voluntary recall processes that we have that admins may or may not choose to stick to. OhKayeSierra (talk) 21:27, 20 February 2021 (UTC)
5. Support, with the caveat that it will likely need tweaking in the future. We currently have no good way to remove admins who got grandfathered in and really shouldn't be admins. This may not be perfect, but it's something, and it can be refined over time as we come to understand how easy or difficult the thresholds are. {{u|Sdkb}} ^talk 21:41, 20 February 2021 (UTC)

   Sdkb, Could you expand on what you mean by "grandfathered in"? -- RoySmith (talk) 17:53, 21 February 2021 (UTC)

   @RoySmith: I'm referring to admins who became admins back when there were not strict standards and have retained the bit. See grandfather clause. {{u|Sdkb}} ^talk 18:05, 21 February 2021 (UTC)

   Sdkb, That's what I figured. In other words, people like me? -- RoySmith (talk) 18:12, 21 February 2021 (UTC)

6. Support - I think the community should have a process for removing admins without the bureaucracy and closed-door nature of ArbCom, a process designed for conflict resolution more than figuring out if an admin has retained the community's trust. This proposal has adequate safeguards against frivolous nominations and a relatively high bar to removing the admin bit, which should make the process viable in cases where an admin clearly needs to be removed but allow admins subject to small-scale disputes to be retained. -- Ajraddatz (talk) 21:46, 20 February 2021 (UTC)
7. More strict than my own procedures, so I'm in favor. Seems smooth and strong enough to allow a lot of buy-in while limiting misuse/abuse and most common pitfalls. ~ Amory (u • t • c) 21:58, 20 February 2021 (UTC)
8. Support This is a decent-enough framework to give it a shot. Of course, the numbers are arbitrary and may need tweaking (especially after it is actually used), but I don't think they are too out of left field. Anything that pushes back against the "adminship is for life" narrative to potentially ease pressure at RfA is a good thing. -- Tavix ^(talk) 22:05, 20 February 2021 (UTC)
9. Support. This proposal uses input from the entire community to hold administrators accountable to the policies and guidelines. A desysop policy has the potential to lower the expectations at RfA, which would encourage more editors to run for adminship and help minimize our numerous backlogs. Other Wikimedia projects have successfully implemented community-oriented desysop methods, and it is worth trying out here as well. — Newslinger talk 22:07, 20 February 2021 (UTC)
10. (edit conflict × 2) Support Well thought out. Seem my comments below for my one caveat regarding inactive users but that is not enough to make me oppose. Thryduulf (talk) 22:07, 20 February 2021 (UTC)
11. Support - very well thought out proposal that cuts off many routes for potential abuse. I share most of Beeblebrox's concerns, but in my personal opinion Tony's plan mitigates them just enough for me to support what is a very much needed process. ƒirefly ( t · c ) 22:21, 20 February 2021 (UTC)
12. Support. Eleven years ago, I was the lead proposer of the failed WP:CDARFC, and I just spent a somewhat unpleasant period of time going back to re-read all the objections that were raised to that, to see if any seemed to me to apply here. The proposals are strikingly similar, but not the same. (The old one had a 65% threshold, and I'm not sure if that really makes a difference. This new proposal requires an existing consensus from a thread that closed as finding tool misuse, and that's a clear improvement.) I think that this proposal adequately addresses the concerns that have been raised in the past over earlier proposals, and seems feasible, unless one just does not believe in letting the community remove the permission. I've come over time to feel that ArbCom has gotten better and better at this, and therefore have come to have less enthusiasm for a community-based process, but I still think that this proposal can satisfy a need. Maybe en-wiki is finally ready for this. I think this could work. --Tryptofish (talk) 22:58, 20 February 2021 (UTC)

    Adding that I think the 60% thing should be adjusted upward a bit, and that there should be a more explicit statement that Crats have discretion in determining consensus. This needs to be not-a-vote. --Tryptofish (talk) 23:04, 20 February 2021 (UTC)

    Tryptofish, Agree completely, it must be a discussion so "Desysop - we have too many admins" !votes don't count for much. Ritchie333 ^{(talk) (cont)} 10:54, 21 February 2021 (UTC)

    After reading more comments in this discussion, I want to suggest adding the following language to the part about previous AN/ANI discussions: "...there was consensus that the administrator behaved inappropriately, and for which diffs are provided of the administrator subsequently rejecting or disregarding that consensus." --Tryptofish (talk) 23:14, 21 February 2021 (UTC)

13. Support. We do indeed need a community process for removing adminship to reduce the fear that manifests itself as unwillingness to promote candidates at RfA, and independent of ArbCom's brutal process and often apparently arbitrary decisions and the implications of an ArbCom case that someone has done something unconscionable (ArbCom should mostly be dealing with extreme situations). I share the concerns that the numbers may need tweaking, in particular the percentage support, which seems low since we need admins brave enough to take action in contentious areas. I also have some qualms about using extended confirmed status as part of the qualifications for certifying, but since that exists, yes, it's a valid metric. I strongly suggest that there be a bar on participation in the eventual desysop discussion at the same level as that for certifying, since 60% is so much lower than the usual minimum support level for a successful RfA, and I don't see anything in the proposal preventing unregistered and newly registered editors from voting, unless it's supposed to be implied by location of the discussion at the RfA page. I don't share the concern about the 48 hours, since it's followed by a 14-day period, but there should be a requirement to notify the admin at all three stages and I suggest requiring e-mail notification in addition to on-wiki (last I checked, admins are expected to have e-mail activated). Finally, I think I must add that the concern is not solely with "legacy" admins or even "rusty" legacy admins. I remain opposed to activity requirements for admins, partly because those suggested have never captured non-logged actions like removing a WP:G4 tag after looking at the previously deleted article and determining the new one is different, or defusing a conflict by explaining teh roolz to a new editor, and we want admins who defuse conflict more than we want admins who strut about blocking everybody in sight or deleting everything nominated for speedy. But also because it's a volunteer project, and RL exists, as does off-wiki. Some "legacy admins", including some who return to the project years later, are valuable links to when the project was about boldly creating content and not being a dick stuffed shirt ... an encumbrance. Pace the WMF, there is a difference between wisdom and clarity and "abuse of seniority and connections". And some abusive admins have been corrupted by their power since much more recent RfAs in the post-"no big deal" era. Yngvadottir (talk) 23:01, 20 February 2021 (UTC)

    Yngvadottir, for clarity, there is a requirement barring participation in the discussion to the same metrics as those used to certify: Users commenting must meet the requirements for filing a desysop request to support or oppose, but may make general comments if they do not qualify. TonyBallioni (talk) 23:04, 20 February 2021 (UTC)

    Oh good, thank you! I kept going backwards to re-read the proposal but failed to find that. I will also tack on here that I am very much opposed to Tryptofish's addendum: the bureaucrats have completely lost my confidence that they discern consensus in RfAs that fall into or below the discretionary range, as opposed to supervoting. This needs to be a straight-up vote, as proposed. Yngvadottir (talk) 23:10, 20 February 2021 (UTC)

14. Support; relatively similar to what I've already agreed to (User:ToBeFree/recall) based on good experience with the procedure on the German Wikipedia. Regarding the already-certified "request to desysop" transcluded for discussion at WP:RfA, if possible, I'd favor the administrator under discussion to have the first paragraph on the page, or a prominently displayed section for rebuttal, above the votes. ~ ToBeFree (talk) 23:13, 20 February 2021 (UTC)
15. Support this much needed and well thought-out scheme. At present it is too hard to deal with abusive admins. Xxanthippe (talk) 23:24, 20 February 2021 (UTC).

    I'd like to see some evidence of 'it is too hard to deal with abusive admins', Xxanthippe, and I don't believe this was the spirit in which this proposal was launched. More in the comments section below. Kudpung กุดผึ้ง (talk) 07:46, 21 February 2021 (UTC)

16. Support in principle. I would suggest some minor refinements (see Comments section), but this is a reasonable proposal that avoids bludgeoning over grudges. — BillHPike (talk, contribs) 23:29, 20 February 2021 (UTC)
17. Support. Clear and well thought out with checks and balances. The framework works (although I would clarify in step 1. it is AN/ANI, and no NACs) and the metrics can be refined over time. I think Step 3. would also be useful to ArbCom, who could send ADMINACCT cases there directly. Britishfinance (talk) 23:35, 20 February 2021 (UTC)
18. Support – on the basis of not letting the perfect become the enemy of the good; the details can be tweaked as we learn from experience and IMO this is a good-enough proposal to start with. Levivich ^harass/_hound 00:14, 21 February 2021 (UTC)
19. Support as better than nothing. My suspicion is that this proposed process is sufficiently complex that it'll never be used. But we can always tweak it going forward if folks are interested. Ajpolino (talk) 00:46, 21 February 2021 (UTC)

    Just a note to add that my preference is to stick with the 60% threshold or lower (I'd support down to at least 50%, possibly lower). 65%, as some have suggested, seems to be stretching it. If most editors in a discussion want me to hand in the tools, it's probably best I hand them in. That said, I'm happy for the 'crats to have some leeway, as they do at RfA now. Ajpolino (talk) 05:57, 21 February 2021 (UTC)

20. Support with the caveat that I expect there will be some changes after we see how this works in practice. This isn't free reign to motion to de-admin accounts, it's just a way for the community to deal with some discipline cases without going through ARBCOM proceedings. power~enwiki (π, ν) 00:51, 21 February 2021 (UTC)
21. Support I think this is a good attempt at a desysop policy which has been to date something sorely absent. I feel the proposal has sufficient checks to ensure this proposal is not misused and support its implementation. Hopefully, this might act as an alternative to Arbcom and help the community to feel more empowered to deal with the rare case of admin power misuse.--Tom (LT) (talk) 01:52, 21 February 2021 (UTC)
22. Strong support - This strikes me as an exceptionally reasonable and fair proposal, I really can't see any obvious flaws with it. It gives the community a realistic process to desysop someone for cause, in a way that is not too difficult, but it includes sufficient caveats and restrictions to prevent it from being weaponized disruptively or unfairly. We can play the "what if" game and never get anywhere, or we can implement a good proposal, probably as good as it's gonna get, with the understanding that if any flaws present themselves, the process can always be tweaked as needed. ~Swarm~ ^{sting} 01:57, 21 February 2021 (UTC)
23. Is it perfect? No, but perfect/enemy of the good and all that. But variations of this proposal have been active for years on multiple large wikis and more or less it seems to have worked out okay for them. It is time we bring more accountability to enwiki administrators. --Rschen7754 03:49, 21 February 2021 (UTC)
24. Support as others have said above, we can't let the perfect become the enemy of the good. We are long overdue for some form of community-based desysop procedure. The community is competent to bestow the tools and the community is likewise competent to take them away. LEPRICAVARK (talk) 03:58, 21 February 2021 (UTC)
25. Support I don't know how this will work in practice, but that isn't a good enough reason to oppose. Hawkeye7 (discuss) 03:59, 21 February 2021 (UTC)
26. Support. Tony has big ideas, and this is a good one. ArbCom need not be the alpha and omega for any and all sysop revocations. Not saying that it should otherwise relinquish its desysop role, but having another option that, it, as well, sets out appropriate safeguards — that's a good thing. I trust our admins, I trust our bureaucrats and I trust the community. This is progress. El_C 04:43, 21 February 2021 (UTC)
27. Support. Overdue. It's nigh impossible to remove an abusive admin and this is a step in the right direction. -FASTILY 05:32, 21 February 2021 (UTC)

    I wouldn't say it's particularly nigh impossible Fastily. Arbcom has made an easy task of it for themselves in recent times - almost lining admins against the wall and shooting them in one session... Kudpung กุดผึ้ง (talk) 07:37, 21 February 2021 (UTC)

28. Support This can only do good for the encyclopedia - Administrators should be extremely accountable for all actions. More to the point, the perception that administrators are more accountable to the outside world can only do the project some good. It makes people believe we are fairer and the chances of them getting "jumped on" by an admin will be reduced. Unfortunately, I can see there is significant opposition for the specific proposal rather than the general idea. Please reconsider, and trust yourself that the bigger picture of allowing us to keep admins in check is more important than the nuts and bolts - think of the greater good or the lesser evil, so to speak. Indeed, I would go as far as suggesting any !vote from an admin opposing this should carry less weight as they have a conflict of interest. Ritchie333 ^{(talk) (cont)} 10:23, 21 February 2021 (UTC)
29. Support per nom. Maybe increase the 48hrs bit to 72hrs to take into account long weekends, bank holidays and the like. Lugnuts ^{Fire Walk with Me} 10:25, 21 February 2021 (UTC)
30. Support. This is a good proposal, and though I am willing to negotiate on some details including numbers, these look reasonable to me in the first approximation. Yes, this procedure will definitely be used to harass admins, no doubt about this. But active admins are being subject to constant harassment anyway, with the community unwilling or not being able to do anything in 90% cases (the worst case which happened to me I had to report to police, and I had external sites specifically founded to spread deliberate lies about my personal life - I do not see how deadminship nomination would be any worse). To be honest, I do not foresee this procedure to be used often - to start with, we do not have so many AN(I) threads formally closed, even less closed with an explicit consensus that an admin was at fault, and in the borderline cases it is actually more difficult to get ANI consensus that to get the ArbCom to look at the case - but I think it is important to have this procedure.--Ymblanter (talk) 10:28, 21 February 2021 (UTC)
31. Hello, I support. There is no article about myself in en.wp but there could possibly be an one one day (talk) 11:17, 21 February 2021 (UTC)

    Note: The above editor, whose account was created on 5 February, has 5 edits, two to articles, two to their own talk page, and the edit above.Beyond My Ken (talk) 17:37, 21 February 2021 (UTC)

32. Support. My main motivation for supporting is that we need some process in place. I acknowledge and even agree with some of the objections posted in the comments section. However, it's my belief that having a workable system in place will increase confidence in admin performance in the wider community. Tiderolls 13:53, 21 February 2021 (UTC)
33. SupportThere has to be a better way of removing admins who have lost the trust of the community than full ArbCom cases, and this proposal has enough safeguards to prevent gaming or harassment. P-K3 (talk) 14:31, 21 February 2021 (UTC)
34. Support the proposal as a whole. I am unable to support the three admin endorsement requirement however. I presume that the requirement's intent is to have at least three respected long term contributors which would very likely be included in a successful request. Great step in the right direction! -- Dolotta (talk) 14:38, 21 February 2021 (UTC)
35. Support in principle, with the details to be worked out. Might be good to have a planned debriefing RfC after an incident to see if things worked as intended or needed to be tweaked. —valereee (talk) 15:57, 21 February 2021 (UTC)

    ETA: agree with BK49, the issue with reluctance to close an AN/I in way that will or won't support this needs to be addressed, and yes, a vote to desysop of more than half but less than the threshhold is a concern. —valereee (talk) 22:57, 22 February 2021 (UTC)

36. Support I concur precisely with Tide rolls' comments; happy days, Lindsay^Hello 16:31, 21 February 2021 (UTC)
37. Support I think the deadline for the 10 extended confirmed editor endorsement is a little bit short, per Lugnuts, but overall the proposed policy is quite a reform. Also, after it is implemented, I'm sure we can revise it as needed. P,TO 19104 (talk) (contribs) 17:20, 21 February 2021 (UTC)
38. Support with the expectation that details may be altered, and with thanks to TB for coming up with this -- and a note to the opposers: "The perfect is the enemy of the good." Beyond My Ken (talk) 17:32, 21 February 2021 (UTC)
39. Support per BMK; "the perfect is the enemy of the good", indeed. Like GiantSnowman mentions in the comment section, it seems a bit off to demand that the admin in question transclude their own request for desysop; seems like asking a user to build their own gallows. (I'm not really a fan of this kind of hyperbole, but it's the only metaphor that comes to mind.) TB's comment in response to that makes sense, though, so I feel like we should add some language in to formalize that they can ask a 'crat to do it for them if they wish. But regardless, I don't think that's a dealbreaker. Writ Keeper ⚇♔ 18:10, 21 February 2021 (UTC)
40. Support. Policy proposal is detailed, well-thought-out, and seems like it would be difficult to abuse. I am open to considering amendments to the policy but this is a good start. —pythoncoder (talk | contribs) 19:37, 21 February 2021 (UTC)
41. Support the principle. If this passes, I would expect more detailed discussion on the exact process. Things like 10 users, 48 hours, etc. can be adjusted later. I don't agree with the requirement that three editors need to be admins. — Martin (MSGJ · talk) 20:57, 21 February 2021 (UTC)
42. I have my reservations about specifics (I feel like this would never end up really being used because of the complicated process) but having a community desysop process is needed. Moneytrees🏝️^{Talk/CCI help} 22:06, 21 February 2021 (UTC)
43. Support per Pythoncoder. JJP...MASTER!_{[talk to] JJP... master?} 22:19, 21 February 2021 (UTC)
44. My feelings mirror MSGJ's. SQL^{Query me!} 23:32, 21 February 2021 (UTC)
45. A thorough proposal that I'm inclined to see implemented. It is clear that the current method is unsatisfactory and this proposal seems an appropriate solution. I'm confident that most issues in harassment or singular evidence will be appropriately addressed by the initial review step from 10 extended-confirmed users and 3 administrators. Aza24 (talk) 00:24, 22 February 2021 (UTC)
46. The perfect is the enemy of the good --Guerillero ^{Parlez Moi} 04:08, 22 February 2021 (UTC)
47. Support. I fully agree with others about this: three admins is a lot (my preference is for no admins), 48 hours is too short, and getting a close at AN that specifically mentions tool abuse is going to be extremely unlikely. However, this could very well be the first successful de-sysop policy proposal in Wikipedia history, and that is certainly not nothing right there. We can discuss amendments on the specifics later (or maybe the closer will read the discussion and find consensus for the relevant changes to be implemented.. wishful thinking I know). Right now though, we should just take this one step at a time to make the right fixes later. –MJL ‐Talk‐^☖ 07:51, 22 February 2021 (UTC)

    For the record, I am also not a fan of having the admin have to transclude their own de-sysop request (sounds honestly terribly mean), and I also think it should be a 65% threshold (and probably shouldn't be as discretionary as an RFA is). –MJL ‐Talk‐^☖ 07:55, 22 February 2021 (UTC)

    Let me explain why I think no admins is not a good idea. Imagine user A obsessed with admin B to the point they can not see their name. If they are determined, they can grow 10 or 15 of whatever extended confirmed user to certify the desysop request (after B once get in trouble at ANI). But there is no way they can grown an admin account, because administrator is currently almost the only flag which is given as a result of the community discussion (disregarding interface admin, which does not probe qualities relevant for this situation, and bureaucrat and arbitrator, who in practical terms are always admins). Sure, there are some admins who passed RfA a long time ago, and where there are doubts as whether they are in touch with the community, but it is still better than nothing.--Ymblanter (talk) 08:26, 22 February 2021 (UTC)

48. I land here, generally. I don't like hurdle number 1 - largely the 6 month note - the idea that if an admin makes a "mistake" and especially if they are contrite and accept it as a mistake, that they should be looking over their shoulder for the next 6 months doesn't sit well. However, I think hurdle number 2 is excellent - so much so that I've been keeping something similar on my recall process for a decade. I genuinely see no need for hurdle 1 if hurdle 2 is there, which is why I'm supporting, there's no "looking over your shoulder" if there's a decent safeguard like that. So, if you've got 10 users in good standing thinking you should no longer be an admin, that's a reasonable threshold for a desysop process. I'm not sure I like RfA being the process - but it's simple and well understood by the community.
    That leaves the question of "do we need this process". Well, I'd say yes. Kudpung mentions below that he and I worked on WP:BARC a few years ago, a community desysop process which got majority support, even if it wasn't implemented. This process is simpler - I've already mentioned how close it is to my recall process, a process which I strongly believe is needed. Lifetime adminship is a massive problem in the Wikipedia community - it's a role which requires work and has responsibility associated with it. The responsibility of keeping up with changes, with ensuring that keep treating people with respect. The expectation of setting a good example. However, the barrier to desysopping at the moment is an arbcom case. Firstly that means reaching the threshold of an accepted case - quite a few arbs including myself have a lower threshold for accepting admin conduct cases, but it's still woolly. Secondly, going through an arbcom case. Few people want to do that. This process is much clearer. I do have a few concerns, which I'll address in the comments. Worm^TT(talk) 10:37, 22 February 2021 (UTC)
49. Support: the necessity of an AN(I) closing statement which indicates poor conduct in the last 6 months and requirement for 3 admins to be included in the desysoping discussion request make me think that misuse would be sufficiently rare. I support more routes for the community to desysop because I think cases of admins behaving with consistent incivility and driving editors (both new and old) off the project are occurring, I believe ArbCom is failing to accept necessary cases, and is otherwise less-suited to assess certain types of issues than the community (such as cases where many ArbCom people would have to recuse) and no-one wants the WMF to be involved. For over a decade now people have been complaining, at least at RfA, about a lack of suitable procedures to desysop and we need to at least try this one out. It's not a suicide pact and failure in practice could see this process removed by community consensus, but the time to act is... well, 2010, but given we're in this position the time to act is now. I encourage anyone fretting over the details (%age, number of endorsers etc.) to just support because numbers like these are best adjusted through practice (as the supporting percentage needed at RfA was) and no-one is able to a priori arrive at figures that everyone will look at and go "that's exactly right".
    I would absolutely not support a requirement that a desysop request must go through this process before ArbCom takes it, or vice versa. We should see this as two venues as better suited to different situations, but if one venue is presented with a request that needs handling then it should take it rather than passing the buck. — Bilorv (talk) 13:17, 22 February 2021 (UTC)
50. Support Agree with the proposal. Abhishek0831996 (talk) 13:25, 22 February 2021 (UTC)
51. Support probably Bilorv's comment above has convinced me the most, but also a discussion with Tony. However, I'd like to emphasise the 2nd part of Bilorv's comment in regards to ArbCom, which was my biggest concern. This proposal cannot result in becoming a de facto requirement before an issue is heard at ArbCom. It should not alter the expectations for ArbCom hearing a case, at all. In particular because this proposal only requires 40% community support for an admin to retain the bit, and also because I think some issues benefit more from the structure of a case. Further, I oppose raising the support threshold to 65% (ie, 35% of the community in support of the bit being retained). Also explicitly noting that I don't at all buy the concerns of this being misused - my only concern is people thinking this can suddenly resolve all forms of admin misconduct, which it cannot. ProcrastinatingReader (talk) 14:30, 22 February 2021 (UTC)
52. Support – worth a try; can be tweaked later if needed. Graham87 15:29, 22 February 2021 (UTC)
53. Support I fundamentally believe that it's a broken process where the community has been unable to remove an administrator's bit for cause. I think it causes an unhealthy community atmosphere at times between longtime editors who are not administrators and administrators. We're all in this together, the community is pretty sophisticated on the whole these days, and ArbCom shouldn't be the only option to desysop people. This is why I have my own recall procedure but I would much prefer a standard community process so here I am voting for this. Now with that said, let me state all my concerns with this proposal in hopes that the closer is sophisticated enough to take the criticisms I see from not only those opposing/being neutral but from those supporting when crafting a closing statement (assuming this gains consensus).
    I think this proposal presumes that the current culture of AN/ANI will continue after this passes. If that culture were to continue, step 1 would work well. However, I think this proposal would cause AN/ANI to act differently. I think some AN/ANI regulars would be more of a reluctance to close administrator misconduct thread in a way that provides a definitive statement to trigger step 1 (more on this in a moment). I think there would also be pushback/challenges when a thread was closed but closed in a way that partisans found unsatisfying (either hoping to trigger step 1 or not wanting step 1 to be triggered). That will not be healthy for our community. Second, I think we'll need some new crats for this process to work. Quite bluntly, I was waiting for some crat support (being unsurprised at opposition/neutrality) before supporting because without crats willing to do this process it won't work. And, in my experience, the overwhelming majority of crats are very reluctant to act in ways that deny people sysop, even in the face of community consensus that they should do so (example). We're all volunteers, so I don't begrudge them this. However, I do worry that crats will only judge very clear statements as satisfying the criteria here perhaps to the point of absurdity. I have seen threads where there is clear consensus that an administrator acted wrong closed with statements like "Lessons were learned here". At the moment that's fine (indeed the right close for administrator who feels bad about a mistake), but would that be sufficient for this process? I believe the answer would be no for most crats (and would also be an example of a close ripe for being challenged that I already wrote about). So in the end I think the answer to this is just to elect some more crats who will being willing to implement whatever community consensus is derived here (again assuming this passes). Finally, I'm concerned that someone with 40% confidence in the community can continue on as administrator. We're so concerned about community trust we say that unless 3/4 of the community trusts you we're not willing to give it to you in the first place (at least not without further discussion) but if 59.9% of the community distrusts you but you had the good fortune (or actual skill/competency) to pass at one point, sure you can still be a sysop. If there were ever a scenario where a majority voted to desysop but it wasn't sufficient to pass, especially with all the other safeguards this proposal has, that outcome would be incredible divisive for the community. I fundamentally believe it is untenable for someone who a majority of the community, at a widely attended discussion, distrusts to continue as an administrator.
    In summary, is having some process better than nothing for me? Yes. Are the "bones" of this process good? Yes. Do the details need to be rethunk to work better? Yes. Best, Barkeep49 (talk) 16:10, 22 February 2021 (UTC)
54. Support It is better to have this process than not to have this. Some users are making assumptions on what the community will or will not do once this is implemented, but we will not know for sure until it is put in place. We should revisit this process with another RfC in six months to a year. My support for this process is under the assumption that it will complement the current ArbCom system, not replace it. ArbCom should not use this process as a reason to deny cases. Barkeep49 said above I have seen threads where there is clear consensus that an administrator acted wrong closed with statements like "Lessons were learned here". If this proposal passes I would closing statements to say one of three things: "Community determines there is not enough evidence to warrant a request for admin desysop", "Community determines there is enough evidence for a request for admin desysop", or "No consensus was reached". If there are a couple of AN reports that conclude with no consensus, it should be accepted as an ArbCom case. Z1720 (talk) 16:58, 22 February 2021 (UTC)
55. Support I believe that this process will help improve trust between administrators and long term editors who are sometimes suspicious of administrators. A straightforward process with clear benchmarks is complementary to and a good alternative to the ArbCom route. I have read the opposes and understand many of the points raised, but I conclude that the benefits far outweigh the risks. Cullen³²⁸ Let's discuss it 19:00, 22 February 2021 (UTC)
56. Support: We have had so many cases of ArbCom revoking admin access and even a former admin Fram being banned for inappropriate conduct without community discussion. I think ArbCom should be considered a very last resort as ArbCom is intended to be used to resolve long-term issues with behavioral conduct that community discussion is unable to handle. Aasim (talk) 19:30, 22 February 2021 (UTC)

    You're misrepresenting ARBCOM's role in WP:FRAMSUM there. They had nothing to do with banning Fram. Cabayi (talk) 16:04, 23 February 2021 (UTC)

    What I was referring to was that Fram was banned without community discussion by the WMF and I did not hear of any formal complaints made to the community at WP:ANB (not saying it did not happen) and even then there would be no way for community to step in and decide that this user's actions do not merit the admin tools, making it a lose lose situation; both a loss for the editor who is desysoped or banned without community discussion and to the community who had no idea that there were problems with one user's actions. Aasim (talk) 17:07, 23 February 2021 (UTC)

57. Support This is going to be a perennial proposal until it (or a variant) gets adopted, so might as well. – John M Wolfson (talk • contribs) 19:55, 22 February 2021 (UTC)
58. Weak support I see a lot of problems here, and things that won't work as smoothly as envisioned. However, I'd rather we have an imperfect process that can be improved than no process at all. The past month at ANI has featured at least two demonstrations of admins displaying serious competence issues that might not merit an ARBCOM filing, but also show that we need some sort of recourse. Grandpallama (talk) 20:04, 22 February 2021 (UTC)

    Weak Support in the name of starting somewhere, per what I wrote in the previous RfC. That said, as I wrote below, I'd like to see a 12-month trial period and a rule restricting how often someone can initiate this process against the same admin. — Rhododendrites ^talk \\ 20:19, 22 February 2021 (UTC)

    Thinking about it more, I'm torn between wanting to try something and wanting an assurance (trial period or otherwise) that if it doesn't work well, then it won't be hard to undo. Moving go neutral for the time being. — Rhododendrites ^talk \\ 03:37, 23 February 2021 (UTC)

59. Support, this seems like a very careful de-adminning process that would greatly limit the amount of cronyism that many fear a de-adminning process would create. It is clear that something about de-adminning needs to change, and while this isn't perfect, it seems good enough. If serious problems arise, it can be altered. Devonian Wombat (talk) 20:54, 22 February 2021 (UTC)
60. Support per numerous above. About time. But also per Barkeep. Gog the Mild (talk)
61. Support Power corrupts, absolute power corrupts absolutely.--Catlemur (talk) 22:53, 22 February 2021 (UTC)
62. Weak support There are real dangers here. AN/I is 80 % popularity contest, 20 % substance. Premature closes and edit-warring over closes already exists, and if this is policy, it will be guaranteed that a popular admin will not be stained with a condemning AN/I close. Sandstein's concern in the oppose section is a good one, although unblockables won't get blocked either way. Hopefully this would not deter the ArbCom from accepting some admin conduct cases because now a community process exists and the situations may not be "intangible" anymore. It would be unfortunate if that was the case because it would mean that popular but abusive admins wouldn't be scrutinized by anyone, and this process would just be used to desysop "out-of-touch legacy admins" who happened to step on the toes of an unblockable, as an extension of the mob mentality on AN/I. While these AN/I and three admin endorsement requirements are bad, I think this is an important instrument that should exist. The community has the power to grant adminship and so it should have the power to remove the bits as well. I wish it had been implemented in the beginning so it could have been refined already. --Pudeo (talk) 23:01, 22 February 2021 (UTC)
63. Support - people change.   ~ Tom.Reding (talk ⋅dgaf)  00:25, 23 February 2021 (UTC)
64. Support - Neutralhomer • Talk • 00:27 on February 23, 2021 (UTC)
65. Support it isn't what I would've done but it's better than nothing. A lot of Opposes are concerned that there will be many frivolous proceedings but I don't understand why that would happen -- having three administrators sign on seems to be sufficient to prevent frivolous proceedings. It's worth a shot -- there's a high probability this will be a welcome addition. Sam-2727 (talk) 00:37, 23 February 2021 (UTC)
66. Support A well-defined process makes everyone more accountable.  Mysterymanblue  01:19, 23 February 2021 (UTC)
67. Support: I have been waiting for something like this. This is a good attempt at a desysop policy which has been to date something sorely absent. I feel the proposal has sufficient checks and balances, and I support its implementation. The numbers can be tweaked, as many are saying. I also like the discussion below in the Hypotheticals. A lot of sensible discussion there. With more discussion, we can arrive at something workable. --Whiteguru (talk) 04:58, 23 February 2021 (UTC)
68. Support: You can do almost 90% of actions, edits, etc on Wikipedia without administrator privileges. Although administrator privileges are put in place so that important and critical actions are managed by trusted editors, it could easily be replaced by permission similar to extended-confirmed processes. Administrators only get access to a small amount of actions, which are important, but IMO doesn't hold enough importance to have its own position. SenatorLEVI 05:13, 23 February 2021 (UTC)
69. Support:. It will increase accountability. Desertarun (talk) 09:17, 23 February 2021 (UTC)
70. Support — I fully support the implementation of this, which would in turn compel admins to be fully held accountable of every action of theirs and follow WP:ADMINCOND to the letter which would invariably curb admin abuse. I do have few reservations, a major concern would be this, say for example a not so popular admin fucks with the “wrong admin” with the “right friends” I’d only imagine the not so popular admin getting de-sysoped so fast they wouldn’t know what hit them. Pros & cons really. Celestina007 (talk) 09:27, 23 February 2021 (UTC)
71. Support, largely per WTT. Admins should be accountable directly to the community, and I've always supported a community desysop process. I'm unsure about some of the details, but that's always going to be a problem with a proposal like this. If you keep it relatively loose some will oppose because of the lack of details, and if you make it detailed some will oppose due to its complexity, while both sets of people might support a desysop process in principle. While it might not be perfect (and no proposal will satisfy everyone who supports the principle), I think there are sufficient safeguards. And we can adjust it as we go forward based on the experience we gain. Boing! said Zebedee (talk) 11:26, 23 February 2021 (UTC)
72. Support this will help the community keep admins in check and will allow users a more straightforward way of voicing their concerns on administrative conduct. Willbb234^Talk (please {{ping}} me in replies) 12:06, 23 February 2021 (UTC)
73. Support in its broad form. All functionaries are appointed by the community and should be subject to removal by the community through a transparent process that can be initiated by the community. I agree with the proposal to require one or more functionary to support the request which I see as similar to requiring a senator to proceed with an objection to the Electoral College vote. Some of the detail may need tweaking over thresholds, timescales, etc., in a subsequent RFC. In particular, I think the policy should disallow two requests for desysop for the same person within a given time period (e.g., only one allowed every six months although ArbCom could still desysop via its procedures) and only one per AN/ANI report - no double jeopardy. QuiteUnusual (talk) 13:51, 23 February 2021 (UTC)
74. Support – The present arrangement is unsatisfactory. If an editor complains about an administrator's conduct at AN or AN/i, they are told it is the wrong forum. If they go straight to Arbcom, their request is rejected because of insufficient prior dispute resolution. This proposal seems a sensible way to resolve this problem. Cwmhiraeth (talk) 14:07, 23 February 2021 (UTC)
75. Support – As someone else said above, people change. Some of the details of the proposal seem like they might need to be worked on, but overall I'm in favor of more accessible and straightforward accountability. ❯❯❯ Mccunicano☕️ 15:03, 23 February 2021 (UTC)
76. Support -- I don't think requiring three admins to agree is a problem. I also think we need a community desysop program and goodness we've spent way too long saying "yes we need one but not this one". Protonk (talk) 15:29, 23 February 2021 (UTC)
77. Support the process seems good, although I think we'll have to see how it goes and what needs to be changed βӪᑸᙥӴ • Talk • Contribs 15:35, 23 February 2021 (UTC)
78. Support. I'll just repeat my comment from 2019 here: "It seems like a no brainer that if the community can promote an administrator without going through ArbComm, they should be able to demote an administrator through the same process. The current "nonbinding" system is worse than nothing, since it gives a false sense that we actually have processes in place while admins are free to (and have) modified their non-binding requirements on the fly to avoid having to follow through". --Ahecht (TALK
    PAGE) 15:46, 23 February 2021 (UTC)
79. Support - Long overdue imho. The policy etc can be tweaked along the way if things don't go hunkydory. –Davey2010^Talk 15:58, 23 February 2021 (UTC)
80. Support the imposition of a mandatory recall process and implicitly the removal of all individually crafted recall processes to ensure a level playing field. I'd like to see a sunset clause so that the functioning of the process can be reviewed after 6 months or a year, or after it's been invoked 4 times, and the numbers tweaked if necessary. Cabayi (talk) 16:22, 23 February 2021 (UTC)

    All administrators would be subject to community-approved procedures, but since they can resign at any time or just stop doing administrative actions, I don't think we can force them to forego their own personal standards for withdrawing from administrator duties. isaacl (talk) 19:05, 23 February 2021 (UTC)

81. Support Although I have faith in the Wikipedia administrators, they can lose competence morals over the years or as a ±result of their power. Painting17 (talk) 19:03, 23 February 2021 (UTC)
82. Support Provides a community-round input. Even highlighting ill-tempered behavior can assist individuals to check and balance each other more publically. Though disengaging and walking away is primarily the option to go in disputes, it's sometimes one-sided when tested against unequal powers. Can be changed once implemented, but it's necessary for community input in all adminship roles. We entrust individuals to carry out their roles to the best of their abilities in a correct fashion, be accountable for any and all behavior whether that be known at-large or minimally, and conduct their business civilly and respectfully. Though not perfect, repeated similar behavior in short-succession and overtime is not acceptable no matter one's role in the community. Adog (Talk・Cont) 21:06, 23 February 2021 (UTC)
83. Support because it is better than before. But I'd prefer more realistic requirements in order to prevent revenge accounts filing requests. With 25 edits one can hardly compel 3 Sysops to agree with them.Paradise Chronicle (talk) 22:35, 23 February 2021 (UTC)

Oppose

1. Per my comments in the discussion section. Overall I think this is needed, and I want to support it, but I have too many concerns about the specifics. Beeblebrox (talk) 22:05, 20 February 2021 (UTC)
2. Per Beeblebrox; also want to support, but have too many concerns. Particularly that this process, like many other community processes, is a feedback loop. - Ryk72 ^talk 00:00, 21 February 2021 (UTC)

   Feedback loop? · · · Peter Southwood ^(talk): 05:48, 21 February 2021 (UTC)

   Feedback in this sense. Over multiple iterations, "vote you off the island/out of the cool kids club" processes reinforce & ingrain community prejudices & biases; particularly processes with self-selected participants/voters. And, while I appreciate the intent and the thought put into the proposal, I consider the process above to be overly complex and, in places, unbalanced - "and has made at least 25 edits in the last 6 months" is unnecessary; "including at least three current administrators", step 3. & "60%" are detrimental, and not likely to change once the process is implemented. If we are going to have a vote process, admins should need to show that they retain the confidence of the community; with (the bar set at) at least 50% in favour of them retaining the tools(; probably higher). - Ryk72 ^talk 11:00, 21 February 2021 (UTC) - clarified Ryk72 ^talk 12:05, 21 February 2021 (UTC)

   50% is a problem though - why should administrators be able to stay as admins with only 50% support, when perfectly capable and competent editors can't pass RfA with 50% support from that community ? I know it's apples versus pears, but still... And yes, if it comes to it, I'm probably advocating lowering the bar at RfA, not raising the bar in a desysop discussion. Nick (talk) 11:54, 21 February 2021 (UTC)

   I agree entirely; which is why I have included, and emphasised, "at least". The bar should be at least as high as 50% support to retain; probably higher. The process, as drafted & proposed, requires 60% support for the desysop, and (assuming neutral responses are permitted) allows admins to retain tools with between 0% & 40% support for them to do so - this is problematic. - Ryk72 ^talk 12:01, 21 February 2021 (UTC)

   Once some has been an admin for some time, they usually have made a number of decisions that were correct but still angered some people. Consequently, a DeRFA process will most likely see those people support removal regardless of cause. As such, requiring a higher percentage to remove makes sense to counteract these impulses. Regards SoWhy 14:19, 21 February 2021 (UTC)

   I understand this line of thought. I agree with the first two sentences, and disagree with the last. I am comfortable with a lower bar to retain admin than to gain it initially; but not for that bar to be below 50%. I also agree with the thought above advocating lowering the bar at RfA. - Ryk72 ^talk 14:25, 21 February 2021 (UTC)

3. Parking here as there are quite a number of unresolved questions below which could change the content of what is being voted on. I'm supportive of a community desysop process in general. — xaosflux ^Talk 04:36, 21 February 2021 (UTC)

   I'm "leaning support", and will likely swap once the discussions below settle more. — xaosflux ^Talk 05:35, 21 February 2021 (UTC)

   I don't support adding the int-admin parts to this policy, it creates an overlap of existing other policy and doesn't improve the options for dealing with bad int-admins, no benefit for adding this component has been identified. — xaosflux ^Talk 12:37, 21 February 2021 (UTC)

   Oppose as unnecessary policy creep regarding interface administrators; Neutral on the components related to admins (still think there is some gaps regarding the process in relationship to timings of resignations); undecided on the de-bureaucrat addon. — xaosflux ^Talk 15:31, 22 February 2021 (UTC)

4. Oppose per those above. Very likely supportive of the creation of such a process, but cannot endorse these specifics. — Godsy ^(TALK_CONT) 05:10, 21 February 2021 (UTC)
5. I have concerns about the process described here; it has a double jeopardy kind of feel to it. I would like to imagine that someone who has behaved inappropriately should be encouraged to improve their behaviour. The process that is outlined here feels more punitive. In addition, "behaved inappropriately" is too vague - a close that included "trouts all around" could be construed as a conclusion that someone behaved inappropriately. I think we need something that incentivised improved behaviour, and that gives someone a sheltered window in which to improve. Guettarda (talk) 05:22, 21 February 2021 (UTC)
6. Oppose "The request must link to at least one thread at a community forum such as AN or ANI that closed within the last 6 months where the closing statement indicates that there was consensus that the administrator behaved inappropriately." We all make mistakes, we are all human, and while I think I am rather up to date with policy and guideline, there are always things I do not know. The 'at least one' still is 'one strike is enough'; 'community forum such as AN or ANI' can still be an obscure community noticeboard; 'the administrator behaved inappropriately' is way too vague, there are several actions that are within policy or guideline, but catch the right opponents and you will face that it is 'inappropriately' (especially on an obscure noticeboard). Have your fans all around and you will be fine even if you 'behave inappropriately', fall out of grace and even something within policy can be inappropriate. I fully support the fact that we need this, but this is, as written, is a shortcut to a ArbCom requiring levels which are way too far below what normally would go to ArbCom (we generally do not report to ArbCom at one negative AN(/I). --Dirk Beetstra ^{T C} 05:45, 21 February 2021 (UTC)
7. Oppose. The described ordeal sounds awful. If a person is on the wrong end of an AN/I thread, then they have to figuratively watch their back for six months (perhaps even consider stepping away from Wikipedia entirely to allow the six months to elapse). It doesn't allow the person from AN/I, if they learned from their mistake, to put the matter to rest for half a year. In the event that someone does get the ten required endorsements, then this person has to sweat it out for up to two weeks while working on their defense. Then when the Request For Desysop proper begins, this person has to (potentially) watch dozens of people pile on for a week about all the mistakes this person has made and why they're unfit for adminship. Sounds emotionally brutal. I prefer the (hopefully) tactful approach of ArbCom. That isn't to say that the people commenting on the RFD would necessarily be lacking in tact, I'm just saying that those in ArbCom are specifically tactful. Useight (talk) 06:17, 21 February 2021 (UTC)
8. I think it will render AN both high stakes, and less likely to correct Admins, because everyone will know how high-stakes it has become. Admins behaving badly need to reign themselves in and just stop, early, but they will have less encouragement to do so, because AN will 'vindicate' them in its lack of conclusion. -- Alanscottwalker (talk) 09:07, 21 February 2021 (UTC)
9. Oppose. Admin. cronyism has always been a major factor in AN/ANI discussions. Setting a requirement of "at least three current administrators, endorse the request" sets the inception of a successful community desysop debate too high. Leaky caldron (talk) 09:35, 21 February 2021 (UTC) Happy to support if the threshold is reduced to TWO. Leaky caldron (talk) 10:48, 21 February 2021 (UTC)

   If this proposal passes successfully, there will need to be close attention paid to how AN/ANI discussions are handled - the horse trading which goes on with ArbCom goes on with other administrators too, and one area which will need to be very carefully scrutinised is the closure of AN/ANI discussions which could lead to Community Desysop. There is a risk (intention or unintentional) that administrators commenting will contend the issue is not serious or severe, that there was provocation and there's a very significant risk of favours being asked for and performed which will see discussion threads being closed as the administrator behaving appropriately with no case to answer. There's an equally severe risk that the initial complainer at such a thread, if not an admin, will be subject to massively increased scrutiny, sanctioned or blocked (for the duration of the discussion or longer) and treated most unfairly. But that's outwith the purview of this policy and would need further attention should the proposal be successful. Nick (talk) 10:54, 21 February 2021 (UTC)

   Parking here as well. moving to support. Some outstanding issues that concern me, particularly on how this process will act in relation to ArbCom and I share some of the concerns of some opposers above. But I hope to move to support with some clarifications/changes; I believe in the idea that the community can take back what it gives, and is entitled to decide itself who it wants mopping on its behalf. ProcrastinatingReader (talk) 10:10, 21 February 2021 (UTC)

10. I agree that we need a way to desysop problematic admins. I'm not 100% in agreement with the decisions Arbcom has made as our community elected deadminship process. But they have proved a more nuanced and effective process than is being detailed here. When they need to move fast with a motion to desysop they can move faster than this process would allow, when they need to give time and treat people with the respect due to any of our volunteers they can do that as well. I think it would be a mistake to have two desysop processes operating under different criteria, so I'm opposing this proposal in favour of keeping Arbcom as our desysop process. I urge those who are unhappy with our current arrangements to define what extra criteria they think that Arbcom should desysop people for and file an RFC along the lines of "in future, Arbcom should desysop admins caught doing x" ϢereSpielChequers 12:19, 21 February 2021 (UTC)
11. Agree with many of the above. Insufficient protections against a howling mob.--Wehwalt (talk) 13:44, 21 February 2021 (UTC)

    Unless one believes in the existence of the putative "anti-admin brigade" (who's actuality was largely discredited a year ago), I suggest that a so-called "howling mob" (at AN or ANI) serves the purpose of attempting to deal with Admin bad practice. Not a bad motive that. Leaky caldron (talk) 13:59, 21 February 2021 (UTC)

12. While the proposal is generally well conceived, the need to include safeguards against abuse makes it rather complex with a relatively great number of steps that are likely to become focal points for wikilawyering and drama. And despite the safeguards, this process's existence is likely to make admins even more reluctant to take necessary action against popular and well-connected problematic editors (see WP:UNBLOCKABLES). But most importantly, I've yet to be persuaded that this is a problem in need of a solution. The relatively high number of admins desysopped by ArbCom indicates to me that the existing process works well enough. Sandstein 13:49, 21 February 2021 (UTC)
13. Oppose We already have a community desysop process: and its called Arbcom! Arbcom is a community process, as all the prominent members are from the community, and they are also selected by the community. That Arbcom is not a community process is essentially a misnomer, they're as community as community can be IMO. Do we need a parallel process to Arbcom? I believe not, it works well in my experience, and there have been no convincing arguments that this isn't the case. Arbcom's cases are extremely nuanced, and it has a large number of safeguards against abuse my editor cliques. No reasonable demonstration that Arbcom has failed has been demonstrated to me, and until this happens I will oppose unnecessary and considerably more flawed parallel processes. Jules (Mrjulesd) 16:19, 21 February 2021 (UTC)

    For what it's worth, WP:DESYSOP2019 closed with wide-spread support for an alternative desysoping procedure based on community input, but does not involve ArbCom. It's been decided to have one; we just haven't agreed on one. ~ Amory (u • t • c) 13:46, 22 February 2021 (UTC)

14. Oppose - whilst I am open to a idea like this in principle, there are too many concerns raised about the risk of abuse/lack of safeguards, and some far more careful thought needs to be given to the process itself. GiantSnowman 16:39, 21 February 2021 (UTC)
15. Oppose per Tony: Strongest possible oppose We already have a community desysop system: we elect trusted community members to hear evidence and then vote on conclusions. A system that provides some semblance of fairness while also holding administrators to account and also just as importantly making it clear that the people who ask for a hearing will also have their conduct examined. All previous proposals have failed because any one that would be fair is effectively a proposal to create ArbCom by another name.
    Additionally, there is this idea that it’s easier to desysop someone via community process than via ArbCom. I disagree completely. A popular admin who misbehaves repeatedly will never be desysoped by the community. They would by ArbCom. For all it’s flaws, the ArbCom process at least attempts to give both sides a fair hearing. No other project does that. TonyBallioni (talk) 12:44, 18 October 2019 (UTC) I've already commented, but I've been thinking about this most of the day, and the more I think about it, the more depressed I become at what this would likely lead to for our community. This is because the issue with a community-based desysop system is not that it will result in more desysops. It won't. In all likelihood, a community-based process would result in substantially less desysops (see Commons as an example). The issue is that we'd gain a tool for people to harass and attempt to silence good people who have no chance of being desysoped, but who work in areas where they've made enough enemies, you could probably start a valid request. I'll be blunt and say I'm probably one of those admins where you could find enough people to do any certification process, but where community removal would be unlikely to happen, and it's not something I'd particularly enjoy, even if as a whole I'm confident I retain the trust of the community. If I didn't feel I had that trust, I would have resigned already.
    The issue here is that any community desysop process will be a spectacle, where all of their flaws will be commented on via aspersions and an angry minority will be able to make their life suck for a week. Who on earth would want to subject themselves to that.
    People are focusing too much on the end-process goal here: yes, the community likely would be able to keep good admins from revenge requests, but that isn't the issue. The issue is the human being on the other side of the screen who will have to go through a week of humiliation, often by people who are likely to be community banned within the year. They'll have their worst moments highlighted rather than their norm, and the community won't stop it, because we give exceptionally wide latitude to people in forums like RfA/RfB/CUOS/ACE, and we'd be very likely to give the same latitude here.
    The end result is the bullying of other human beings, condoned in the name of accountability, targeted at sysops who have no chance of actually being desysoped. We should be better than that, and while ArbCom might be flawed, it is better than every single other process described below at attempting to give all sides a fair shake. That is what we should be focusing on. TonyBallioni (talk) 22:49, 18 October 2019 (UTC) — wbm1058 (talk) 17:23, 21 February 2021 (UTC)

    Yeah, I was wondering when people would bring that up. To be clear, my views have changed in that what I care about is fair outcomes to all involved, both people complaining and those under scrutiny. In the 16 months since the last discussion, a lot has changed on the project, and my belief is that implementing a form of community desysop with the appropriate checks will ultimately make it easier to remove administrators who are behaving problematically while also making a defense of ones own actions easier as well. In other words, I think we’d see more desysops that have community consensus that would not occur now, and that the more controversial cases would get a more straightforward hearing. Ultimately, I believe those will lead to fairer outcomes for the people involved, and better outcomes for the community. I didn’t think this 16 months ago, but my thinking has obviously changed. TonyBallioni (talk) 17:41, 21 February 2021 (UTC)

    Please explain the two most significant changes of the the last 16 months that have caused you to lose confidence in ArbCom's handling of desysops, and why they've made you change your mind. wbm1058 (talk) 18:17, 21 February 2021 (UTC)

    Gladly: first I’ve thought more about how this happens on other projects, and how it seems to work perfectly fine there on large projects. One of the main issues I was concerned about on en.wiki is AE/nationalist disputes, but I think the requirements surrounding certification there address my previous concern that you could get one side of a conflict targeting an admin.

    The other is that I think we don’t actually know that the community considers behaviour worthy of desysoping beyond the broad strokes of policy. I think in the last 2 years, a lot of concerns have grown surrounding inappropriate actions by administrators who are unfamiliar with current practice and who then disappear or continue behaving outside the norms in small ways. I think there’s very likely community consensus to desysop them, but that you’d have significant difficulty getting ArbCom to open a case. On the other end, there were cases like Portals where the desysop vote was close, at least one arb who said they might have been too hard, but where there were conduct concerns. The justification usually given in cases like that are is they can demonstrate community trust via an RfA, but I don’t know of anyone who has, and part of that is because how difficult the desysop mark can be, even if it might not have had community consensus at the time. Creating a process where we can directly see if the community supports desysoping in edge cases surrounding admin conduct, in my view is likely a process that would be more likely to reflect the community’s view on a specific case than the current “desysop and see if they can pass RFA.” As I said, I think it will likely create fairer outcomes both for people who think someone should be desysoped, and for those under discussion. TonyBallioni (talk) 18:37, 21 February 2021 (UTC)

    As I noted in my support comment, I went back to re-read the oppose comments from the proposal of eleven years ago, and if we're going to note editors' past comments, I can't help noticing that some of the opposes that have shown up here use remarkably consistent language now as then. Well, I guess there's something to be said for consistency. Just sayin'. --Tryptofish (talk) 22:46, 21 February 2021 (UTC)

    Commons is my 'other' project and I've been involved in several of the desysop discussion there - it's a completely different project with very different patterns of behaviour and very different issues which result in the desysop discussions. It really tends to be straight tool misuse on Commons, but as there's less opportunity for tool misuse and the vast majority of admins are pulling in the same direction (primarily managing intellectual property issues) the strong editing disputes that characterise many en.wp Arbitration cases simply don't appear on Commons with anything like the same regularity or intensity.
    I would also worry that A popular admin who misbehaves repeatedly will never be desysoped by the community. They would by ArbCom. is both correct but downplays that popularity - they're equally likely to be elected to ArbCom... Nick (talk) 09:35, 22 February 2021 (UTC)

    I also think it's worth noting that WP:DESYSOP2019 closed with wide-spread support for an alternative desysoping procedure based on community input. Even if Tony hadn't changed his mind, it'd still be worth suggesting a policy since consensus is to have one. Opposing this proposal on the grounds that we shouldn't have one is opposing that prior community consensus. ~ Amory (u • t • c) 13:52, 22 February 2021 (UTC)

    TonyBallioni, Something is still puzzling here. I hope I'm not mis-characterizing your point of view (and please correct me if I am), but I read it as, "I've changed my mind because ArbCom has become too activist, vis-a-vis actions against several people who I thought didn't deserve it". Let's assume for the moment that's correct and in response we enact community de-sysop. That doesn't change what ArbCom can do. If they want to continue to be activist, they can. How does this proposal fix that? -- RoySmith (talk) 16:15, 23 February 2021 (UTC)

16. Oppose without prejustice to any future and better version. The idea might be great, but it is hard to imagine that such complex procedure will ever work. My very best wishes (talk) 03:56, 22 February 2021 (UTC)
17. I land here, per Nick's response to Leaky cauldron and the emergent effects on AN and ANI, which are quite broken or misshapen as they are already. Moreover, WP:TINC, but it doesn't take long to see some editors (admins or not) get chummy with other editors, and then appear to make closes at such places, preventing the community, under this proposal, from using the process in question (no, not just GAMEmanship). There's aren't sufficient protections against those cliques foundering issues brought up at our behavior review boards. --Izno (talk) 03:58, 22 February 2021 (UTC)
18. Oppose. While well-intentioned, I share Sandstein's concern regarding the chilling effect this may have on correct but unpopular admin actions (such as blocking the "unblockables"). Sjakkalle (Check!) 10:48, 22 February 2021 (UTC)
19. Oppose Firstly, as Sandstein points out, this is a solution in search of a problem; ArbCom is willing to desysop in controversial cases, and nobody's pointed to an ArbCom case (or lack of case) that ended up with an egregiously bad result. Secondly, there is no way for the community to reject the opening of a vexatious anti-RfA if the requirements are technically met (well, there is IAR but I don't see any crats wanting to invoke that here in any circumstances). And finally, the threshold for removal is lower than for promotion, and there is no guidance on what the discretionary range for crats to discuss the matter is (if there is one at all); effectively turning this anti-RfA in to a vote from the perspective of the community. Iffy★Chat -- 12:00, 22 February 2021 (UTC)
20. Oppose I appreciate the principle, but I think this will make admins even more reluctant than they already are to do anything contentious, or anything which annoys a large group of editors. For example the unblockables problem will get a lot worse, because attempting to block an unblockable usually results in a thread on some noticeboard where the unblockable's friends attack the blocking admin. This would now probably lead to a desysop request, and even if the admin survives it will not be a pleasant experience. I also don't think that we should be desysopping admins for a single mistake unless the mistake is very serious, and the threshold of a single thread will allow this to happen. Hut 8.5 13:03, 22 February 2021 (UTC)

    It wouldn't be desysopping for a single mistake, it'd be allowing a consensus that a behavior or action was inappropriate to be used to garner a petition that, if endorsed by a number of editors (including peer admins), would then be submitted to the community for review. Right now, we have to get a bunch of AN/ANI closings then ask ArbCom to intervene; the community can express itself repeatedly at AN/I and when voting for Arbs, hoping the two collide. This would just institute a process whereby the community can vote itself. Almost by definition, if we consider an RfA to be the will of the community, then whatever a de-RfA decides would likewise be the will of the community. We just don't have a way of getting there. ~ Amory (u • t • c) 13:40, 22 February 2021 (UTC)

    A Recall election isn't the only way for the expression of the will of the community. In politics recall elections usually lead to expensive disasters. Elected officials need to be able to do their jobs while in office. Their accountability to the voters is ensured by elected offices having limited terms and by the elected officials periodically having to run for re-election. We might consider using a similar system with admins. Nsk92 (talk) 14:09, 22 February 2021 (UTC)

    I’ll add a bit to what Amorymeltzer, but I find it interesting that people are opposing for this reason since I added it to be an increase from the current requirements to file an ArbCom case: there are none. It is entirely possible to craft a case request without showing there is any agreement by the community that someone is acting problematically and convince 2-3 arbs that “this should be looked at but we don’t have to sanction”, which then snowballs into an acceptance. Basically the current desysop process is completely arbitrary as to what can be a cause for initiating it. While you can start a dozen ANI threads and not get a case accepted, you can go with no ANI finding a problem and have one accepted. This was meant to create a standard to prevent people from using the process as a way around normal dispute resolution and to create some standard as to when it’s applicable, as compared to the current standard of 'know which arbs care about specific issues and bring cases they’ll agree to hear.' TonyBallioni (talk) 13:50, 22 February 2021 (UTC)

    I think the distinction is that Arbcom is two-sided; if you file a frivolous case request or are playing pot-calling-kettle-black, you are likely to land in trouble yourself. If you do the same on this de-RfA what happens? Jo-Jo Eumerus (talk) 14:58, 22 February 2021 (UTC)

    There is no threshold to file an ArbCom case request, no, but filing an ArbCom case request by itself is not a big deal. Unless ArbCom accept it very little will happen. On the other hand this desysop request would be a big deal, and even if you survived the mere threat of one would be a significant deterrent by itself. RfA already has such a bad reputation that many qualified people are deterred from going through it, and this would be a lot worse. Another important difference is that meeting the threshold here could be little more than a unpopularity contest. An admin who has done something controversial (e.g. blocked someone popular) can easily get some experienced editors yelling at them on a noticeboard, which is all you actually need for this process to start. Convincing a majority of arbitrators is rather harder. Hut 8.5 18:19, 22 February 2021 (UTC)

21. Details can always be tweaked, but if we're going to do this, we need to get it at least broadly right at first or it will only further entrench the difficulty of desysopping. Unfortunately I think this proposal combines the worst aspects of AN/I while keeping none of the strengths of arbitration cases. Let's be honest, AN/I is a dysfunctional exercise in mob rule. Rooting the desysop process there is going to give control of it to the loudest voices in our community, not the community as a whole. The initial 48 hour window of opportunity accentuates this by encouraging people to rush to judgement. It will probably work okay for those rare cases where a single incident is egregious enough to justify a desysop – but those are also the cases that ArbCom is already good at dealing with. The cases we struggle with—and the cases the arbitration format can be good at, when the committee overcomes its constitutional lethargy—are where there is repeated, low-level misconduct over a longer period of time. AN/I routinely fails to do anything about this because its focus is on recent single incidents, deciding which party is most at fault, and reaching a quick "close". Arbitration is better at it because its allows enough time and space to discuss more complex issues, and the decision format encourages an explicit link between findings of fact and remedies rather than taking sides. What I'd like to see is a community procedure that replicates this—perhaps by listing specific instances of misconduct that, if reasonably demonstrated with diffs, can be a basis for a desysop request—but is more streamlined and easier to access than ArbCom. And doesn't have anything to do with AN/I. – Joe (talk) 16:33, 22 February 2021 (UTC)
22. Moving here, for originally the reasons in my neutral-leaning-oppose position, but simply inflated to the point of unavoidability. I'm particularly concerned about the issues raised here regarding how difficult it'll become to make hard or contentious decisions, considering how dogged people can get about them. Ultimately, this proposal looks far too easy to weaponize. Vaticidalprophet (talk) 18:23, 22 February 2021 (UTC)
23. Oppose This is a well intentioned attempt to improve the desysop process, but I think that our current 'bicameral' system provides for a better result overall, however imperfect it may be. There's a reason why governing systems work better and last a lot longer when there is an upper chamber of sorts, that sits above the fray, generally moving slower and more carefully than a unicameral one that is open to sudden and damaging changes by way of knee-jerk reactions from involved partisans, who may also be too shy to make controversial but necessary decisions that alter their standing within the governing body and population (the 'community', in our case). Desysopping can be the most difficult of all duties in this community. I feel it was right to place that power in the hands of an uninvolved elected committee, and that should continue. My main concern for any changes to this procedure would be dealing effectively with WP:UNBLOCKABLES, and Sandstein convinced me that this proposal will make this worse. RandomGnome (talk) 18:31, 22 February 2021 (UTC)
24. Oppose Many of the oppose voters expressed sentiments similar to mine. I've always felt that the urge to cut ArbCom out of the loop stemmed more from the frustration of would be lynch-mob leaders than any genuine "difficulty" the existing method held. What hadn't occurred to me was the notion that making it easier to get rid of admins would inevitably lead to admins declining to make controversial calls, something that sounds all too likely an outcome. Ravenswing 20:20, 22 February 2021 (UTC)
25. Oppose for 3 reasons: 1) Being an administrator is already difficult enough, without the need to avoid controversial decisions. We already see the lynch-mob mentality at RFA for candidates witha less-than-prefect background, and I can see this happening to admins who work in the darker areas of Wiki. 2) Whilst the Arbcom process may be difficult, I disagree with the premise that it is unnecessarily so. 3) I see no evidence that there is anything wrong with the current system. — O Still Small Voice of Clam 21:38, 22 February 2021 (UTC)
26. (I initially posted this under "Neutral", but having read it over, I think it might fit better under "Oppose". Mz7 (talk) 21:55, 22 February 2021 (UTC)) First, the good: I think this is a very well-thought-out proposal and is probably the best community-based desysop proposal I've seen. It addresses many of the most critical concerns that have previously caused community-based desysop ideas to fail. There is a relatively high bar for starting a review (it requires an initial AN/ANI thread, 10 established users must endorse within 48 hours, 3 of whom must be admins, and a supermajority vote (60%) is required to desysop)—these safeguards may adequately prevent frivolous requests as well as "chilling effects" where administrators are hesitant to make the right decision in a controversial dispute for fear of retaliation.
    That said, at WP:DESYSOP2019, I expressed a fair amount of skepticism about whether we really need a community-based desysop process, especially one that would result in an "anti-RfA" of sorts. It's no secret that a lot of us think that the RfA process is "broken" because it often overemphasizes isolated incidents and recent dramas, fails to require corroboration for any allegations or claims, and requires candidates to submit to an intense and often unpleasant examination of every nook and cranny of their Special:Contributions. And while it's not clear to me how these issues can be fixed, I remain skeptical about any proposal that repurposes the unstructured format of RfA into a request for desysopping. As I wrote in 2019, It feels like every time I think about reforming the desysop process, my thoughts always go back to the question: "What if we made a process that allows a group of trusted users, who are vetted regularly for their judgement and experience at knowing what's good for the project, be the main body in charge of reviewing administrator conduct?" That is the process we already have. Because I'm not convinced that the current system actually needs fixing, I find myself in this section. Mz7 (talk) 20:55, 22 February 2021 (UTC)
27. Oppose. This is well-intentioned and offered in good faith, but (1) there is no evidence that ArbCom and other processes aren't working to curb abuses (i.e., this is a solution in search of a problem); (2) there is too much of a risk of gamesmanship; and (3) I fear this will disincentivize admins from making the right call. Neutrality^talk 22:32, 22 February 2021 (UTC)
28. Leaning oppose, regretfully. - I would like to support a process such as this, but I have serious concerns about both parts 1 and 2. The fact that this is placing an AN(I) closure's wording as part of the requirement would make AN(I) closing even more toxic and political than it already is. I'm also not fond of the requirement for three administrators to endorse the petition. I can see why something like that is there to prevent frivolous trial-by-ordeals started by angry sockmasters, but the explicit requirement for three administrators is going to look like cronyism from the outside, and is going to start to make things inherently political. I think something should be done here, but this process has too many wikipolitical landmines for me to support one with this wording. Hog Farm _Talk 23:42, 22 February 2021 (UTC)
29. Oppose the proposal is very complicated and I think it's simpler to just have a "reverse RfA". Banedon (talk) 00:29, 23 February 2021 (UTC)
30. Oppose Sorry, I'd love to support, since I think a genuine Desysop Policy is long overdue, but this isn't it. I'm worried that if this takes off, that will be it for Desysop for the next five years. Plus, I seriously doubt any admin would close an ANI report in favour of a complainant when the complaint is about an admin. I'm not all that familiar with ANI, but I have never seen such an action in my 14+ years here. Has there been one? I'd say most regulars there would rather just let a complaint of this nature float its way into archive territory than being "closed", per se. So the rest of the proposal is moot, in my eyes. I agree with Banedon above: a simpler "reverse RfA" – i.e., "you screwed up bigtime, so let's vote" – process would be preferable to this Wikilayering. Homeostasis07 (talk/contributions) 00:52, 23 February 2021 (UTC)
31. Oppose per Sandstein, Neutrality and others. While well-intentioned, I am afraid this process would open the doors for abuse and an unnecessary drama.--Darwinek (talk) 01:35, 23 February 2021 (UTC)
32. Oppose 1. the edit threshold is far too low. 2. Why do you need 3 administrators to also sign off on it? Admins are just users who have special tools when the need arises, but this is a discussion, so it should be users deciding, not necessarily admin required. Sir Joseph ^(talk) 02:06, 23 February 2021 (UTC)
33. Oppose -- the process is too arcane and opens the doors for abuse as per Darwinek. -- Rockstone^{[Send me a message!]} 02:29, 23 February 2021 (UTC)
34. Oppose. Requires substantial reworking.

    1. "The request must link to at least one thread at a community forum such as AN or ANI that closed within the last 6 months where the closing statement indicates that there was consensus that the administrator behaved inappropriately."

    This is too much dramaboard bureaucracy. It looks like an objective test, but it throws the subjectivity back in time to a hapless thread closure who may or may not understand the implication of their thread close.
    Suggest:

    "The request must link to at least one thread at a community forum, such as AN or ANI, where a serious allegation of adminstrator is behaviour was not refutted."

    This leaves it up to the ongoing process to discuss and agree whether that was an unrefuted allegation of serious administrator misbehavior.
    Remove "closed" because not all serious discussions are formally "closed". Remove "within the last 6 months" because this creates an artificial deadline. Suggest "in recent months" if time is thought important, however I suggest better to include an "ongoing issues" clause.

    2. "The request will then be open for endorsements. If 10 extended confirmed users meeting the filing requirements above, including at least three current administrators, endorse the request within 48 hours, the request will be reviewed by a bureaucrat, and if it meets the requirements, certified as being an active request for desysop. If the required endorsements do not occur within 48 hours, the request will be archived as unsuccessful."

    Oppose these quorum rules of 10 extended confirmed users and three current administrators. Instead, mandate a particular standard of advertising. I suggest: The subject admin's talk page; WP:AN; WP:BN.
    Oppose this future definitive tense "will be reviewed". Bureaucrats should not be compelled to act under this procedure. Instead, give a bureaucrat the role of a subjective judgement of whether "there is agreed to be a case for desysop". NB. Bureaucrats know how to tell a consensus, this RfC should not define that.
    "If the required endorsements do not occur within 48 hours" Oppose 48 hours as drama-style-time. Instead, 8 days. This is a serious matter, not something to be rushed over a weekend.

    3. "Once certified, the administrator being discussed must transclude the request for desysop at Wikipedia:Requests for adminship within 14 days or resign as an administrator. If neither occurs within 14 days of certification, a bureaucrat will transclude the discussion"

    Oppose. I was expecting #3 to be the real discussion, not a rubber stamp process of amplifying the nearly six month old hard ANI thread close about an admin biting someone.
    Instead: 3. Start a re-confirmation RfA. Another week, yes, except don't mandate a week, leave it for the bureacrats to find consensus for reconfirmation, or not. If not, de-sysopped. --SmokeyJoe (talk) 04:46, 23 February 2021 (UTC)
35. Oppose. Per Dirk Beetstra, Useight, Alanscottwalker, Nick, Sandstein, Hut 8.5, Joe and others. (1)I think the rooting of this in ANI would have all sorts of unintended negative effects in practice; (2) I think it's easy for an admin to make correct but unpopular decisions that, over time, lead to the accumulation of a sufficient mass of disgruntled editors; and (3) I think the edit threshold needs to be increased, probably greatly. Essentially I'm happy with the current appeal to the Arbitration Committee, which has proved more ready of late to remove admin privileges, and I'd also support using the bureaucrats as a neutral jury. Espresso Addict (talk) 05:07, 23 February 2021 (UTC)
36. oppose. Seems like a good idea in principle but I'm worried about the requirement about the ANI thread closure having unintended consequences, as others have noted above -- seems like this could lead to ANI discussions to become much higher stakes than currently. CapitalSasha ~ talk 06:04, 23 February 2021 (UTC)
37. Oppose per others who have noted that this is a solution without a problem. We have processes for de-sysoping, and I have not seen any sort of pattern developing to indicate that they are not working. "Inappropriate behaviour" is undefined and could mean anything. Lots of potential unintended consequences here. — Preceding unsigned comment added by Peacemaker67 (talk • contribs) 9:40, 23 February 2021 (UTC)
38. Oppose - I'm supportive of a community-based path to de-sysop admins, but the proposed process is more restrictive and complicated than just going to ArbCom. Mr rnddude (talk) 10:34, 23 February 2021 (UTC)
39. Oppose, regretfully. I appreciate the thought and effort that has gone into this, but this will be too easily gamed and make ANI even more of an abusive circus than it already is. The reason abusive admins become abusive admins is because other abusive admins protect and cover for them at ANI, so my concern is this will just cause a rush to close ANI threads so that the necessary conditions can’t be met. Many opposers say the barriers are too low; my concern is that the barriers here are too high. So far, the arbs are doing just fine at desysopping, and while I wish the community could do it ourselves, this might weaken our chances to deal with problematic admins while increasing tension at ANI. SandyGeorgia (Talk) 11:26, 23 February 2021 (UTC)
40. Oppose - this procedure makes it a popularity contest which is along the same lines as what gave birth to ArbCom. I'm of the mind that it adds an extra unneccessary step to rid the project of abusive administrators who hound editors, flex their admin muscles against their opponents, and push their own agenda/POV. It's a tough situation because it's human nature for compatible people to form alliances. What one editor may frown on as abusive, another is cheering on. The editors we have chosen to sit on ArbCom have, for one reason or another, risen above the fray and have earned our trust; they have repeatedly demonstrated good judgment. ArbCom is also able to look at things privately to protect the abused whereas private information would not be submitted to the community at large. Atsme 💬 📧 13:35, 23 February 2021 (UTC)
41. Oppose. I don't think there are enough safeguards against harassment from spammers. The three admin threshold buys time, but I don't think this is sustainable in the long run. This proposal has the side effect of reducing thresholds at RFA, and therefore makes it more likely one of those patrolling-type spammers that slip through the cracks gaining adminship. For context, I have blocked four extended confirmed accounts for UPE in the last three days. There needs to be multiple instances of admin misconduct being demonstrated. MER-C 13:43, 23 February 2021 (UTC)
42. Strong Oppose The proposal goes completely opposite our WP:CONSENSUS policy, and focuses more on absolute numbers. What if 10 extended user endorsed and 90 rejected the proposal? Why should an administrator be left open to go through this public lynch mobbing and appeal for a desysop review request just because ten people had a common grouse against them, when a majority might not? Structurally misplaced, misconstructed and misdirected policy. Lourdes 14:03, 23 February 2021 (UTC)
43. Oppose. Administrators must almost inevitably antagonize some users as they go about their business, and those users are likely to turn up at such admin recalls to derail them. It also runs the risk of turning adminship into a popularity contest, in cases where the administrator has taken action against one or more users with substantial community support. We don't want administrators to start behaving like politicians, catering to influential constituencies instead of doing their jobs without fear or favour. This also seems to me to be opening the door to administrator harassment, particularly since there is nothing in the proposal to prevent frequent requests for desysop from the same parties or groups. Isn't it already hard enough to find people willing to stand for administration? Additionally, there is no mechanism in this process for an orderly presentation of evidence - or even any evidence at all - as there is at Arbcom, which is disturbing. Finally, as others have pointed out, this is a solution in search of a problem, since there is already a readily accessible means of desysopping wayward admins. Gatoclass (talk) 14:54, 23 February 2021 (UTC)
44. Oppose. Per Useight, WereSpielChequers, Sandstein, and Joe Roe. While I was very recently in favour of such community-based desysops (admins "deriving their just powers from the consent" of the community per Locke and Jefferson), reading through the arguments at WP:DESYSOP2019 and here as well as previous desysop Committee cases has convinced me that it would not be wise to institute such a change. Committee cases, love them or hate them, allow for greater nuance in argument. The proposed process would worsen the WP:UNBLOCKABLEs problem, and does not have safeguards against double jeopardy. Please ping me or post on my talk if responding as I am (supposed to be) on Wikibreak. Sdrqaz (talk) 16:00, 23 February 2021 (UTC)
45. Oppose Now, don't get me wrong. I think the community needs a process to remove administrators who have lost the trust of the community. But the way this proposal is worded is...fundamentally flawed. I actually don't have a lot of concerns with the ANI discussion requirement, but it comes to the endorsements requirement. For a first, there shouldn't be a requirement that three endorsers be administrators. Yes, the admin bit usually means you have a pretty good amount of experience, but unless something's really changed, admins are still editors, just with extra fancy buttons. Secondly, Loudres said it quite well. 10 people could say, sure, let's get rid of them. Then, you could have even 400 people coming in and saying that no, they shouldn't be desysoped. This proposal would allow for the voices of 10 to be treated as being more important than the voices of the 400. Obviously these are likely unrealistic participation numbers, but the point stands regardless of numbers. My final point is, while this isn't specifically a proposal error, I think it'd be better if these were in a separate venue from RFA. For example, a new page specifically for requests for desysops and discussions regarding them. EggRoll97 ^(talk) 18:37, 23 February 2021 (UTC)
46. Oppose Counterproductive, ochlocratic proposal which seems more likely to be abused than effective. All of my reservations have been clearly laid out by previous respondents. Most importantly, this is a bad solution to a non-existent problem. Neodop (talk) 19:52, 23 February 2021 (UTC)
47. Oppose Moved from "Neutral". As mentioned there, this process is redundant and the potential for using it to settle scores is not addressed anywhere by the original or modified proposal. I do not find the "Support" arguments convincing in terms of safeguards. The proposal is predicated on the idea that the editors that might initiate or comment on such a process are making individual decisions at a time when we know that we have major organizations, including state actors, who are coordinating propaganda at this project. This is an open invitation to such actors to remove opposition to their abuse of process. Eggishorn (talk) (contrib) 20:38, 23 February 2021 (UTC)
48. Oppose I do not think 3 is well thought out, as someone else said it should not be a rubber stamp, also a process such as this should ensure that it is being clearly done to make the work of ArbCom easier not that of Admins harder. Problematic admins should be investigated absolutely, but that process should also have inherit capacacity to protect against unwarranted attack. Not always easy to be sure. I think conceptually ths may be a good move but its not ready for implimentation. Cheers Scott Thomson (Faendalimas) ^talk 21:34, 23 February 2021 (UTC)
49. Oppose per Wehwalt, Sandstein, and Hut8.5. Gamaliel (talk) 21:43, 23 February 2021 (UTC)
50. Oppose - (1) Not needed; for good or for ill, ArbCom has made it clear they will handle WP:ADMINCOND issues at the first sign of trouble. (2) Will never be used; This is very much like a admin recall+. Despite many administrators being open to recall, there hasn't been a single request in almost 9 years (see this list of past recalls). (3) Can be gamed; Per Beeblebrox, this system can be gamed. There's also no effort to eliminate gamed votes from this strictly voting system. (4) Overly bureaucratic; see the flowchart I posted below. That's a lot of bureaucracy. Not to mention; this depiction of it shows there is at least one step that is superfluous. (5) bar is too low; tiny mistakes can be blown up into major issues. This is not compatible with WP:ADMINCOND policy. (6) Solution in search of a problem; I have said many times in the past that a proper analysis needs to be done before coming up with a solution. This hasn't been done. It's just a proposed solution without addressing how it solves any problems. Per the law of unintended consequences, there should be at least some sort of problem solving analysis before this was ever suggested. This proposed policy could cause just as many problems as it notionally stands to solve. But, we don't know that because there's been no analysis. (7) 60% is arbitrary; The threshold should align with requirements at WP:RFA, and allow bureucrats the opportunity to assess consensus...which is what they volunteered to do. This structure is nothing but a vote. That's antithetical to what we are, most especially in something as contentious as a de-adminship request would be. If you want it to be a strict vote, try making this RfC strictly a vote and see how people respond. (8) No evidence; Such a process could move forward without there being any evidence presented, other than the minimal requirement of a prior AN thread concluding against the admin. (9) AN thread could be poorly closed; I've seen threads at noticeboards closed by people who had no business closing any discussions, much less a contentious one such as admin misconduct. It is very rare for any editor to be brought up short for WP:BADNAC issues. This, too, is an opportunity for gaming the system. In summary; I respect the well meaning efforts of TonyBallioni in proposing this system. However, it is rife with very serious issues as I and others have highlighted. There are simply way too many problems here to make this go forward. This needs to go back to some sort of draft to develop it further, if at all. --Hammersoft (talk) 22:37, 23 February 2021 (UTC)

Neutral

1. Neutral This is obviously a "removal for cause"-type proposal and I don't think the current processes are unable to quickly or effectively address admins who are intentionally performing actions against the community interest. It is the admins who inadvertently or unintentionally perform such actions, or who perform no actions, that are a bigger issue. We have policies and procedures to address misbehavior but we have none to address the continuing retention of the tools by admins that do not perform admin tasks. The admins who obtained the bit in the early 2000's when admins status was subject to very little examination and have managed just enough to retain the status are retaining their hats not because they want to improve the project (they manifestly are not doing so). The misbehaving admin can be addressed through ANI, ArbCom, T&S (and possibly other processes I forget) so this proposal would be a fourth such process. There are no processes for the other category. We should address the lacuna in process before adding another to a current set of processes. Eggishorn (talk) (contrib) 22:31, 20 February 2021 (UTC)

   IMO, the only issue with admins who do not perform admin tasks is that they do not perform admin tasks, not that they retain the tools. We should be thinking about how to make such admins perform more admin tasks rather than trying to desysop them. Nsk92 (talk) 02:24, 21 February 2021 (UTC)

2. Neutral I would support this but i think the minimum support threshold should be changed from 60% supporting removal to 65% and requests for desysop between 65 and 75% support should be subject to the discretion of bureaucrats to make it aligned with how RfA's work 🌸 1.Ayana 🌸 (talk) 22:53, 20 February 2021 (UTC)

   This will be difficult to implement given the Bureaucrats were not elected to make this decision. Would the current Bureaucrats be happy to make such a decision and in turn, is the community happy for the Bureaucrats to do so ? Nick (talk) 00:16, 21 February 2021 (UTC)

   Neutral, leaning oppose Beeblebrox's concerns are deeply convincing, especially considering the potential for harrassment. I'm also concerned about the human tendency towards negativity bias -- that is, the possibility more people will come out with negative than positive opinions for even fairly uncontroversial administrators, such that only people with sufficient numbers of friends in high places can pass the desysop-RfA. Simultaneously, there are real concerns about legacy admins in particular that result in a "probably shouldn't drag to ArbCom, probably shouldn't have the bit" category. Not going in the oppose column yet, but have real concerns. Vaticidalprophet (talk) 23:04, 20 February 2021 (UTC)

   Moving to oppose. Vaticidalprophet (talk) 18:21, 22 February 2021 (UTC)

3. Neutral The first thing I did once I became an admin (2012) was start a similar proposal WP:RAS, which failed. Coren (former Arb then) was helpful and coauthored the attempt. Several others have also failed since then, to the point of it being a perennial subject. Back then, Arb was much busier than it is now, case wise, and I don't really see the need, but open minded if the idea can be fleshed out properly. The bottom of the RAS page has some links to previous attempts 2012 and older. Dennis Brown - 2¢ 23:55, 20 February 2021 (UTC)
4. Neutral. I know Tony will be disappointed at me not supporting. Like Dennis above, I launched a similar proposal just under a decade ago. There is still some work to do, and an alternative to Arbcom is sorely needed, but this isn't it. I have made a longer explanation in the comments section. I hope I will not have wasted anyone's time by asking them to read it. Kudpung กุดผึ้ง (talk) 07:23, 21 February 2021 (UTC)
5. Neutral, for now. I feel that in this case the worry about "what ifs" is warranted and one needs to think through the possible consequences of implementing this proposal more carefully. I would also still like to hear a stronger justification for why the proposal it is needed in the first place. A generalized sentiment that admins should be more accountable is, IMO, insufficienent as a justification here. The process described in the proposal is pretty brutal and arduous. The process may be necessary and I could support it, but I'd like to hear a more convincing explanation for why it is necessary (e.g. that the current arbcom desysop process is seriously deficient and fails to remove many admins who should be removed). In geneneral I can see less brutal and confrontational ways of increasing admin accountability, such as instituting admin term limits, with a mandatory reconfirmation RfA at the end of the term for those wishing to retain the sysop bit. Somebody in the support column mentioned that the lack of a community desysop process makes people more reluctant to support RfA candidates. A much much much bigger problem at RfA now is the lack of RfA candidates and the difficulty in recruiting them. As stressful and unpleasant as RfAs can be now, these desysop RfAs will be 100 times more contentious. It is likely that the prospect of potentially facing such a gory public spectacle will make the job of recruiting RfA candidates even harder. I am also concerned about the interactions of the proposed process with the existing ArbCom desysop process. It is naive to assume that the ArbCom desysop process will simply continue on its merry way, completely unaffected. It may well happen that the ArbCom will become much more reluctant to accept desysop cases, preferring/waiting for the community desysop to take place. ArbCom often looks to the community for guidance on important policy issues. IMO, a successful version of this proposal needs to explicitly state something to the effect that the two procesess are strictly independent and complementary, and, moreover, that, in the opinion of the community, the ArbCom should never consider the lack of a prior community desysop attempt as a reason to decline a desysop request. It is a more complicated question as to what is supposed to happen if a commputity desysop RfA fails and then a desysop case is filed at ArbCom. Nsk92 (talk) 11:53, 21 February 2021 (UTC)
6. Somewhat torn here. I support a community desysop procedure in principle, and I like the outlines of this one. I appreciate the steps taken to prevent the "howling mob", as others have called it; but I'm a little concerned about the specifics. First, is this going to turn any AN discussion about an admin into a "howling mob" situation? As things stand, all AN can do is to rap an admin on the knuckles; now the consensus of an ANI discussion is a necessary step to a desysop; it seems to me AN discussions are going to become much more of an ordeal as a consequence. I don't necessarily think that's a fatal flaw, but worth thinking about. Second, I understand that the three admins are meant to act as a sanity-check, but disputes among admins are not uncommon, and it's not unlikely that for any long-standing admin, three others who think they ought to be desysopped can be found. Admins are humans too; we have feuds just like other editors. Arbitrators are expected to recuse from cases where they're too close to the parties; ideally, I'd like to see the same safeguard here. That said, I'm not sure these are sufficient reason to oppose, so I'm going to park here for the moment and read what my colleagues have to say. Vanamonde (Talk) 20:06, 21 February 2021 (UTC)

   Tony, is there a reason the proposal reads "that closed within the last 6 months where the closing statement indicates that there was consensus" rather than simply "reached a consensus"? I do not in any way think this is intentional, but as written, this doesn't actually require a consensus, and therefore opens the door to further acrimony. I saw only because I was going over the wording in detail to see if my concerns were warranted, and had the thought that an uninvolved admin closure would help considerably. I know it's too far along for that sort of amendment, but worth noting, I think. Vanamonde (Talk) 17:01, 22 February 2021 (UTC)

   It was trying to require a formal close so people couldn’t just point to a thread being all “look! A complaint!” Basically having an objective standard here, which as I mentioned in my reply to Hut 8.5, I see the current ArbCom process as lacking. TonyBallioni (talk) 17:05, 22 February 2021 (UTC)

7. Stand aside I'm suspicious of the proposal, largely per Vanamonde and Beeblebrox, but have no intent to prevent its adoption. While I view direct democracy as an advantage, my impression from WP:DESYSOP2019 was that the community does not agree on whether direct democracy is a positive or negative. That fundamental disagreement cannot be resolved structurally which is why proposals, no matter how well we design the safeguards, repeatedly fail. Personally, I didn't follow up on the 2019 discussion because I came to the conclusion that any solution that would gain consensus would not differ substantially from ArbCom, so we may as well just work on reforming the structure and culture of ArbCom. That's not to say I oppose direct recall--quite the opposite--but it means that I would like some tangible benefit beyond direct recall. Put another way, direct recall is a major rift in the community, and bridging that gap requires some superordinate goal that we all agree would be helped by a resurrected RFC/U. Absent that broader, unifying goal, I doubt the community can agree on a recall system for the sake of a recall system. I would be happy if I were wrong in this case. I want to see a direct recall system, but that desire isn't enough for me to overlook the real problems editors in opposition raise. There are sufficient concerns with this proposal that I am not comfortable supporting, but I have no desire to block the proposal, so I stand aside. — Wug·a·po·des​ 01:47, 22 February 2021 (UTC)
8. I have long been in favor of a community-driven de-sysopping process, but I find this proposal overly bureaucratic. If I believe an admin has been grossly uncivil, for example, why should I have to look through six months of AN/ANI archives to dig up dirt on said admin or start a new thread just to rehash the same discussion at a separate venue? -- Calidum 02:43, 22 February 2021 (UTC)

   How is an AN thread endorsing a re-RfA overly bureaucratic? Searching the AN archives takes like a minute or two. ~Swarm~ ^{sting} 03:07, 22 February 2021 (UTC)

   Having a discussion just to have a second (really a third if you include the endorsement period) seems to be the epitome of bureaucracy. -- Calidum 04:21, 22 February 2021 (UTC)

   I'd also like to add that making AN/ANI a prerequisite for any desysop requests will only add to the battlefield mentality seen there, as any attempt to discuss an administrator could be seen as a pre-reverse RFA. My concerns about this proposal go beyond that, however. The group of users who would be able to initiate the process is too restricted; 48 hours is too short of a time for the endorsement period; requiring that any of the endorsers be admins is contrary to WP:NOBIGDEAL; and admins should be desysopped if more than half the community no longer trusts them with their tools, not 60%. -- Calidum 18:33, 22 February 2021 (UTC)

   What "battlefield mentality"? We're talking about a formalized community consensus finding that an admin has violated the admin behavioral standards, as a mere prerequisite to a discussion that can request endorsements, with the ultimate goal of an RfA that will only require 40% support. This proposal requires overwhelming community support, all across the board. ~Swarm~ ^{sting} 03:02, 23 February 2021 (UTC)

9. Neutral. I'm in favor of a community desysop process, and don't think this one is terribly far from what we need. But I have enough specific reservations that I can't quite get myself to supporting it. Specifically (in order of how things are mentioned in the proposal):
   • Get rid of the "at least 25 edits in the last 6 months" requirement. As I mentioned in an earlier comment, it both disenfranchises people who have been hounded into retirement, and is too easy to game by bad actors. So it adds complexity with no value.
   • Get rid of the dependency on closing statements. Lots of discussions never get formally closed. Also, making a negative close a trigger for this process will change both how people close discussions, and when/how people bring problems up for discussion. WP:ARBGUIDE says, The filing user is also expected to show that prior dispute resolution has already been attempted. Similar wording would work here.
   • Get rid of the "at least three administrators" required to endorse. This is supposed to be a community process. Rules like this just enforce the impression that admins carry more weight in forming community consensus.
   • This one's a bit of a nit, but the 48 hour endorsement window is too short. Lots of people would miss it entirely because they don't edit more than a couple times a week.
   • I really don't like the "must" in the administrator being discussed must transclude the request. That seems cruel. It's like being forced to carry your own cross to your crucifixion. Change it to something like, "may initiate the discussion by transcluding the request at a time of their own choosing in the next 14 days". It's the same thing, but sounds less spiteful.
   • Once the discussion is started, it should be up to the managing crat to place the required notices. You really want to make sure that's done correctly. The last thing you want is for a process like this to get derailed because of a defective notice.

   Finally, I'll just echo the sentiment others have noted. The gist of this is if I can't get 40% of the community to agree that that I still deserve a mop, I must have been doing some really bad shit and clearly need to find a new hobby. -- RoySmith (talk) 17:32, 22 February 2021 (UTC)

10. Neutral leaning oppose. The item #3 "Once certified, the administrator being discussed must transclude the request for desysop at Wikipedia:Requests for adminship within 14 days or resign as an administrator." is a non-starter for me. There's entirely too much shaming coming from a Cancel culture in wikipedia as is (not to mention online in general). Remove #3, and you might get a support from me. — Ched (talk) 19:31, 22 February 2021 (UTC)

    Ched, if #3 is removed, then how does the process work? Is the request always transcluded by a 'crat after a certain period of time (giving the admin no flexibility about the time of their RfDA), or does the whole process become non-binding (i.e. the admin can refuse to initiate the RfDA and nothing happens), or what? — The Earwig ⟨talk⟩ 01:02, 23 February 2021 (UTC)

    The Earwig, I hadn't really been thinking along any desysop lines - but let me consider it a bit and I'll try to come up with something. — Ched (talk) 01:12, 23 February 2021 (UTC)

    I think it doesn't have to be more prescriptive than something like "A bureaucrat will initiate the request for removal of administrative privileges within 14 days, unless the administrator resigns." The initiating bureaucrat will work out the timing with the administrator. isaacl (talk) 01:20, 23 February 2021 (UTC)

11. Neutral Admins should definitely be held to account when using the admin tools (I've subscribed to Wikipedia:Administrators open to recall since I got the tools), but this seems like an overly complex set of rules to start the process. I'd prefer something more along the lines of 'N editors in good standing' (where N editors could be quite a low number) + someone reasonable checking that it is a sensible request + a desysop process that is separate from RfA (since it should be a review rather than a request from scratch - but then if the editor is desysop'd then they would have to go through RfA to get the tools back). But that's the ideal, steps to improve the desysop (and the sysop) process need to be taken, hence this neutral vote. Thanks. Mike Peel (talk) 21:25, 22 February 2021 (UTC)
12. Declare reservations: I'll keep this short. RoySmith and Ched above me state numerous, and, in my view, well-articulated concerns about the proposal. I wish to reiterate the concerns regarding requiring an administrator to personally start a discussion regarding their removal, the 60% threshold (which I find is too low a bar to allow for removal of any administrator), the short time window, and the question of administrator endorsement (especially given long-standing feuds). All of these are enough for me to withhold a support vote, but, conversely, my personal views and circumstances are simply not enough to sway me to disagree with this proposal altogether. — Javert2113 (Siarad.|¤) 22:08, 22 February 2021 (UTC)
13. Neutral (moved from support) - I'd like to see a 12-month trial period (the main factor in moving from support) and a rule restricting how often someone can initiate this process against the same person. — Rhododendrites ^talk \\ 03:38, 23 February 2021 (UTC)

Comments

You might say it is implicit, but the the words "or resign as an admin" need to be in point 3. ϢereSpielChequers 20:59, 20 February 2021 (UTC)

I meant to add that myself. Added. TonyBallioni (talk) 21:01, 20 February 2021 (UTC)

Thanks. ϢereSpielChequers 11:41, 21 February 2021 (UTC)

• Why does the admin being discussed need to transclude the request for desysop? That should be the 'crat imho. GiantSnowman 21:06, 20 February 2021 (UTC)
  • That was added to give people the flexibility as to when they want to present their case if they are contesting the desysop. I'm sure they could as a crat to do it for them and no one would mind. The goal is not to force them into a discussion when they don't have time to respond because of real world commitments. I'm open to tweaks in the language around that, but it seemed to be the easiest way to address that criticism that has been raised previously during desysop reform proposals. TonyBallioni (talk) 21:10, 20 February 2021 (UTC)
• Why 60%? Why not 50%? Why not 75%? Why not WP:NOTAVOTE. GiantSnowman 21:06, 20 February 2021 (UTC)
  • RFA has numeric thresholds, as do other projects, and this seems to be the norm for these type of discussions. Our process typically requires consensus to sanction, not consensus to keep the status quo. 60% to me appears as a number that is in line with this concept, but is also not impossible to reach, which 75% arguably would be in most cases. TonyBallioni (talk) 21:10, 20 February 2021 (UTC)

    Shouldn't the threshold then be the same as for a successful RFA? Seems weird that you would need less support to remove someone than to appoint them in the first place. Instead of putting in a strict percentage, how about just pointing to the one's already in place for RFA? Also, RFA does have thresholds but they are not strict. You can fail an RFA with 70% and pass with 65%. DeRFA should have similar rules. Regards SoWhy 09:36, 21 February 2021 (UTC)

• I'm undecided on the general proposal, but two technical questions:
  1. What forum should the request-for-desysop be filed at?
  2. Why 48 hours? That seems like it could be awkward over weekends and holidays - it seems like the critical mass of people needs to be assembled before filing the paperwork, which may or may not be the intention.

  power~enwiki (π, ν) 21:14, 20 February 2021 (UTC)

  Re: 1, the way I picture it would be something along the lines of Wikipedia:Requests for desysop/Example. This would be linked to at BN, AN, and WT:RFA (just like this RfC). It'd contain the complaint and an endorsement section, and a section for a response.

  Re: 2, it seemed like a reasonable amount of time to allow for endorsements without being something that hangs around forever. I'd be open to something like 72 hours so it would always have a weekday, and actually debated that. I ended up with 48 because I thought that if a frivolous request is filed, you don't really need it there for 3 days. If a serious request is filed where the community agrees, you should be able to get 10 comments supporting it within 48 hours (see: most ANI or ARC threads.) There's also nothing preventing it being re-filed if someone misses the cutoff and would have endorsed to get it to 10. That being said, I'm very open to that number being adjusted. TonyBallioni (talk) 21:19, 20 February 2021 (UTC)

• OhKayeSierra, I'll address your point here since I assume others might have it. Currently, it requires endorsement from 6-8 admins/functionaries (i.e. arbs) to initiate a desysop request. What I was concerned about specifically dealt with issues arising from nationalists disputes. I can think of some admins where you could probably find 10 editors on the other side of an ethnic dispute to endorse a request, but you couldn't find a single admin who would.
  I agree it isn't perfect, but so long as we continue to have stuff like India-Pakistan, the Arab-Israeli conflict, Armenia-Azerbaijan this is going to be an issue. The other option to combat that would be to up the endorsement requirements from 10, but that might be too big of a burden to lift. This felt like the easiest compromise on the point. TonyBallioni (talk) 21:33, 20 February 2021 (UTC)
• Two questions about the endorsement stage: (1) Where will it be appropriate to link the desysop request during this stage? (We want to strike a balance between allowing canvassing and having it be totally hidden.) (2) What should people who oppose the dedysop be expected to do during this stage? Just sit it out since it's only for gathering affirmative endorsements, or comment their opposition, which seems like it would make the stage just a slightly less well-advertised version of the actual RfC? Also, if the goal is to allow the respondent to choose the timing of the RfC, comments after an endorsement has succeeded but before the RfC begins should be disallowed. {{u|Sdkb}} ^talk 21:48, 20 February 2021 (UTC)
  • The proposal states AN, BN, and WT:RFA during the endorsement phase. My thoughts would be there, and if there's an active ANI or the like, I also think it would be reasonable to link to as a part of that thread. The standard canvassing rules would apply, in my view.
    On 2, I think having a comments section is reasonable underneath the endorsements so that people can discuss. I also agree once certified there shouldn't be comments until transclusion. Basically we'd need to create a template along the lines of the RfA or AE templates, but these are details in implementation that can be worked out once we get a policy. TonyBallioni (talk) 21:54, 20 February 2021 (UTC)

    Ah, thanks for clarifying on (1); I got a little turned around. We'll have to come up with good shortcuts, as WP:RFD is already taken. {{u|Sdkb}} ^talk 22:31, 20 February 2021 (UTC)

• I have, in the past, strongly argued for a community-based desysop process, and have written such a proposal myself, and have been a "hawk" when it comes to removing problematic admins. However, I cannot support this proposal in its current form. One single thread in which it is concluded that an admin made one mistake is simply too low of a threshold. There are very few things an admin can do that are so bad that they should have admin tools yanked over a single instance, and in those rare cases, arbcom is actually equipped to act considerably faster than this process. In short, I feel that, as currently structured, this is still too open to gaming and use for harassment. Frivolous requests may not go forward, but after enough of them people will start to argue "there's been five request to desysop, the must be doing something wrong" and we'll lose good admins. Beeblebrox (talk) 21:58, 20 February 2021 (UTC)

  It's "one single thread" that's required before opening a process where many users must endorse proceeding before it is then listed for voting. That's quite a lot of hoops to jump through, even before the RFA. ~ Amory (u • t • c) 22:04, 20 February 2021 (UTC)

  My concern is that it will be end up being used to harass admins, even if the cases don't move forward. People will just use it to further bickering, even when they know they won't get a desysop out of it. Beeblebrox (talk) 22:07, 20 February 2021 (UTC)

  Had a lot of edit conflicts, but Amory captured what I was going to say more succinctly. I also worded in as "inappropriately" to make it so that it wasn't just a mistake i.e. community consensus to unblock someone isn't the same thing as saying it was an inappropriate action for the admin to block. Oddly, I designed the procedure not to harass admins. I think one of the things that's changed in the last 3 or so years is that case requests have become easier to game and use to harass people as well, and felt this would be an improvement in fairness to both sides of the dispute. Beeblebrox, something I considered adding was allowing the crat to delete it if certification fails if it was determined it was being used to harass admins or was frivolous because I really do share a lot of your concerns and this proposal was designed in part to fix some of those flaws in the current ArbCom system and both be less prone to harassment and easier to initiate if needed. TonyBallioni (talk) 22:12, 20 February 2021 (UTC)

• Question: If this process is implemented, is it intended to replace the ArbCom desysop process? If not, how are the two processes expected to interact with each other? Nsk92 (talk) 22:09, 20 February 2021 (UTC)
  • @Nsk92: ArbCom has the ability to impose binding sanctions, and a desysop is one of them, so this would not remove that (I don't think you could without amending ARBPOL, which takes forever.) I see as a benefit here that it provides guidance as to what the community wants to see before desysops. As an example, if there was an issue 10 months ago and now you're in a dispute with an admin, you couldn't argue for a desysop under this without getting consensus at AN that there was a current issue with conduct. Under the current system, you could run to ArbCom and depending on the topic, they could accept it. I think in an indirect way, this would help make that existing process more fair as well. TonyBallioni (talk) 22:16, 20 February 2021 (UTC)

Hmmm. Some degree of concern I have is that if this community desysop process is implemented, ArbCom will be much more reluctant to act on desysop requests. In fact, I am certain that this will happen. In some cases that might be a good thing but it is necessary to think about the possible consequences now. There are situations where ArbCom can, and currently does, move quickly to perform a desysop. The process described in this RfC is rather lengthy. I feel that it is important not simply to devise a community desysop process but also include some language that expressly addresses the interaction with the Arbcom desysop process. Nsk92 (talk) 22:32, 20 February 2021 (UTC)

My personal concern is if the standards for ArbCom cases on administrator issues become higher as a result of this. Ideally this proposal is simply an alternate route, and nothing about the current ArbCom process, or the requirements arbs expect for cases, will change compared to whatever they are now. Any editor should be free to choose which process they want to use, imo. There are some advantages of Committee scrutiny, especially for multifaceted disputes. ProcrastinatingReader (talk) 23:43, 20 February 2021 (UTC)

• Can this process be applied to current bureaucrats, checkusers, oversights or ArbCom members? Will it only remove the sysop flag?--GZWDer (talk) 22:19, 20 February 2021 (UTC)

  As proposed, I believe it will apply only to the sysop flag. Any admin who is also in one of the above groups would still be subject to this proposal regarding their admin actions. I don't think a community process regarding checkuser or oversight actions is possible given that by their nature the details of those actions are not able to be examined by most community members. Abuse of these permissions can be investigated by the arbitration committee and the m:Ombuds commission. Thryduulf (talk) 22:26, 20 February 2021 (UTC)

  I think that either CU/OS holders should either be immune from the process (must go to ARBCOM due to the potential of private information), or those permissions should be removed automatically as well by this process. The bureaucrat flag should go away as well as the admin flag. power~enwiki (π, ν) 01:45, 21 February 2021 (UTC)

  @Power~enwiki: As someone with the Oversight right, I'd say that if the issue is related to my actions with Oversight then the complaint should be addressed to arbcom for them to investigate. If the issue is related to normal admin work (say closing XfDs) then this process would be appropriate. If I was desysopped by the community I would expect ArbCom to be officially notified (by the crat who flipped the bit) and to investigate my continued suitability for the role. It would need to be an extraordinary set of circumstances for them to rule that I was, especially as a practical matter, oversight involves regularly deleting pages/revisions and viewing deleted pages/revisions. Thryduulf (talk) 02:46, 21 February 2021 (UTC)

  I think only bureaucrat and interface admin should be addressed here (since ArbCom can handle CU/OS). And they probably should, at least for bureaucrat since only stewards can remove that one. We could wind up with a situation where the community has desysopped but ArbCom won't remove bureaucrat and neither will stewards, since policy doesn't explicitly state it and stewards won't act outside explicit policy, especially not on enwiki. --Rschen7754 03:06, 21 February 2021 (UTC)

• I have minor concerns regarding inactive users. The first would be easy to resolve by adding a requirement that no desysop request may be opened unless the admin has made at least one edit in the last 5 days. The other is for editors who are not available during the RFA period. I think the way to handle this would be something like allowing admins to declare this (publicly or privately to arcom or a crat) that they will not be available to give an RFA attention within the next 14 days. Such admins would not be allowed to take any admin actions (or make major edits?) until they do stand at RFA - with deysopping the penalty for not complying. If an editor thought they would be available for RFA but it turns out they don't then crats should have the discretion to pause the RFA on that admin's request until they return. Thryduulf (talk) 22:20, 20 February 2021 (UTC)
• In the last paragraph, should successful remove be successful and remove? XOR'easter (talk) 22:29, 20 February 2021 (UTC)
  • Done TonyBallioni (talk) 22:35, 20 February 2021 (UTC)
• @TonyBallioni: Please add a brief and neutral statement directly after the {{rfc}} tag. At over 2,600 bytes, the existing statement above (from the {{rfc}} tag to the first timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Wikipedia policies and guidelines. --Redrose64 🌹 (talk) 22:29, 20 February 2021 (UTC)

  It looks fine on that page to me, and this is how I format every major policy RfC I've proposed. If there's an easy fix, feel free to make it, but please do not change my writing. The presentation on this page is more important than on the page the bot updates. TonyBallioni (talk) 22:35, 20 February 2021 (UTC)

  At Wikipedia:Requests for comment/Wikipedia policies and guidelines there is a link. That's all. Compare the other RfCs on that listing: with one exception, each one has a link; a statement; perhaps a signature; and a timestamp. The one exception is Wikipedia talk:Political endorsements, and that is also because it lacks a brief statement. --Redrose64 🌹 (talk) 23:35, 20 February 2021 (UTC)

  @TonyBallioni: It's now more than 24 hours since I pointed out this problem, is it going to be fixed? --Redrose64 🌹 (talk) 22:57, 21 February 2021 (UTC)

  No. I don't consider it a problem. TonyBallioni (talk) 23:03, 21 February 2021 (UTC)

  What, the fact that no statement is displayed at Wikipedia:Requests for comment/Wikipedia policies and guidelines is not a problem? Legobot cannot parse the statement because it is insufficiently brief, thus, it cannot process the RfC. This isn't some petty rule that I have made up - it is a fact. --Redrose64 🌹 (talk) 23:40, 21 February 2021 (UTC)

  I’ve responded on your talk page since I think that’s a better place to have this discussion, but yes, I don’t see a problem there. TonyBallioni (talk) 23:57, 21 February 2021 (UTC)

• I think the community forums in point 1. would have to be ANI or AN (and nothing else) - i.e. major and highly visible forum. I think that you would also need to confirm that the ANI/AN discussion was closed by an admin (or even two admins), who concluded that there were problems - i.e. not an NAC (and probably not a single admin). Britishfinance (talk) 23:05, 20 February 2021 (UTC)
• Am I right in thinking that step 3 is in effect a "reverse RfA", needing 60% to oppose to desyop? That would make sense to me as a fair process. Britishfinance (talk) 23:08, 20 February 2021 (UTC)
  • Fair? I'm finding it strange that an editor who is not an admin must get 65–75% support in an RfA to pass, but once they've become a practising admin and the community can actually see how they use the tools, they will only ever need a support of 40% in order to keep them. – Uanfala (talk) 16:19, 23 February 2021 (UTC)
• Could ArbCom use this process? E.g. instead of starting off a 2-month ArbCom investigation, ArbCom could just !vote to send the admin in question direct to step 3. (above)? Ultimately, step 3. might turn out to be a better system for ADMINACCT cases (e.g. general conduct vs. technical breeches/tool misuse)? thanks. Britishfinance (talk) 23:13, 20 February 2021 (UTC)

Arbcom almost always desysops by motion, quickly, without opening a full case. It doesn't take them 2 months. Nsk92 (talk) 23:19, 20 February 2021 (UTC)

I don't think that was the case for the recent desyops of BrownHairedGirl or Kudpung, which were I think ADMINACCT cases? Britishfinance (talk) 23:24, 20 February 2021 (UTC)

Britishfinance: to answer your questions, I agree, I was thinking AE might be another place in some circumstances so left some wiggle room. On point 2, yes, reverse RfA. I'm using 60%, but am fine with 65% as others here have suggested. That is the people who would need to support removal. On 3, I don't think arbs would open by motion, but all of them meet the requirements for initiating and endorsing a request, so they could do one as a community member if they felt it better than a full case. TonyBallioni (talk) 23:28, 20 February 2021 (UTC)

TonyBallioni, you could find that if step 1. was being contested amongst admins, that it could go ArbCom, who on confirming a valid close, would then send it direct to step 3. I have a feeling that step 3. would be an important tool for ArbCom to be able to send ADMINACCT-type cases to. Britishfinance (talk) 23:32, 20 February 2021 (UTC)

• I'm somewhat concerned that step 1 will make it more burdensome to close contentious dramaboard threads. — BillHPike (talk, contribs) 23:21, 20 February 2021 (UTC)
• I feel that explicitly requiring notices at WP:AN, WP:BN, WT:RFA, and WP:CENT is verging on WP:INSTRUCTIONCREEP. Perhaps just say "publicized at community noticeboards". — BillHPike (talk, contribs) 23:25, 20 February 2021 (UTC)

  I think it's good to be explicit. Those boards are highly watchlisted, and the idea is probably to ensure it gains wide attention. FWIW, the BAG nominations process also enumerates each board to advertise to. BTW, Tony, I presume the "request for desysop", once transcluded, will be advertised on watchlists like normal RfAs are? ProcrastinatingReader (talk) 23:30, 20 February 2021 (UTC)

  I intentionally avoided the watchlist suggestion, because I don't think it would contribute to meaningful discussion (i.e. it would overadvertise and people who aren't familiar with the situation would pile-on one side or the other.) That could be something discussed afterwards though if people felt it necessary. TonyBallioni (talk) 23:32, 20 February 2021 (UTC)

  Understood, thanks for clarifying. ProcrastinatingReader (talk) 23:41, 20 February 2021 (UTC)

• Per 'leaning oppose', I should note I strongly agree with the suggestions of a higher desysop-% required to lose the bit than the original 60% proposal, if this does go through. (I can see an argument for a higher percentage than needed to confirm an RfA in the first place.) Vaticidalprophet (talk) 23:57, 20 February 2021 (UTC)
• What happens if no bureaucrat reviews the endorsement thread? Best, Barkeep49 (talk) 23:57, 20 February 2021 (UTC)
  • Presumably the filer or somebody else would make a post at BN. I think we have enough active bureaucrats at this point that a post there asking them to confirm the requirements have been met would result in action. They’d have a clear policy directive to follow, and I don’t think it’s likely all of the active ones would ignore a request to do something the community has requested they do. TonyBallioni (talk) 01:45, 21 February 2021 (UTC)
• Comment. Could somebody try to articulate why a community desysop procedure is needed now? I've read the 2019 RfC (in which I did not participate) but did not really find convincing answers there. People supporting the idea there mostly postulate their support axiomatically ("yes, we definitely need such a system"). Or they say something to the effect that what the community bestowed, the community should be able to take away. But is it actually the case that the current ArbCom desysop system is significantly deficient? Is it too difficult to desysop admins for cause there? Nsk92 (talk) 00:13, 21 February 2021 (UTC)

• The ArbCom system has always been deficient. ArbCom are able to shape cases to suit their own opinions on the subject of the case, they get to choose whether to accept the case, they already limit the amount of evidence and can refuse to hear further evidence, and then get to propose outcomes which suit their outlook on editing. There's also extensive behind the scenes horse-trading to secure support for proposals. It's like a more or less shitty version of a Presidential impeachment. Nick (talk) 00:43, 21 February 2021 (UTC)

• "extensive behind the scenes horse-trading to secure support for proposals" This has no basis in reality. Neither does "get to propose outcomes which suit their outlook on editing" Beeblebrox (talk) 01:23, 21 February 2021 (UTC)

• Some thoughts: 1) would ArbCom still be able to desysop? I don't think that should be taken away entirely, especially for emergencies or private information-related ones. 2) The general categories of what is covered should probably be spelled out. Is this covering a) abuse of tools b) conduct unbecoming of an administrator c) inactivity? --Rschen7754 00:29, 21 February 2021 (UTC)

  1) Of course it would; the proposed text addition does not replace anything and does not modify Wikipedia:Arbitration/Policy. 2) The only required coverage limit is described in condition #1 of the proposal; this already excludes pure inactivity. There is no need for additional limitation. ~ ToBeFree (talk) 01:36, 21 February 2021 (UTC)

  (edit conflict) Re: 1), yes they would, as it’s a sanction and sometimes falls within private information. This would not remove their ability to desysop. I think that this would, however, greatly reduce desysop cases as it’d be another venue of community dispute resolution, and presumably the committee would defer to the community when possible, as has been their practice over the last few years for things like block reviews. 2) this was designed in place of cases, so mainly abuse of tools and conduct unbecoming. 3) I’m for stricter activity standards, but I think that’s a separate discussion and this would be unlikely to pass if they were bundled. This would create the opportunity to desysop someone who makes 1 edit a year and then makes an involved block, edit wars then protects the page, etc. that could be handled more easily this way if there was community consensus for it, which I suspect there probably would be in some cases.​ TonyBallioni (talk) 01:40, 21 February 2021 (UTC)

• @TonyBallioni:, a couple of questions on specific details - 1) is there a reason that such a long timescale from the Community discussion was selected (as it only needs to be the most recent case) - 3 months would seem to serve? 2) Is there any limitation to multiple requests for endorsements off the same thread? 3) Would it be beneficial to specifically include an option that allowed admins to just directly trigger the request for desysop stage - if this passes, I can see lots of individuals updating their voluntary recall standards or just choosing to do it in the event they feel they did act problematically but disagree it warrants resigning. Without a clear note that's possible, the first time someone would want to do it, would involve an additional discussion at what would presumably be a tense time. 4) Would normal canvassing restrictions apply to the endorsement stage? Nosebagbear (talk) 01:50, 21 February 2021 (UTC)
• I also partially agree with Britishfinance - some specific listing of forums that area sufficiently considered would be beneficial. For example, a DRV thread saying an admin made an improper close, usually 5-7 individuals, probably shouldn't count (if someone is often making poor closes, it should then be taken to AN(I), then could count). Nosebagbear (talk) 01:57, 21 February 2021 (UTC)
  • @Nosebagbear: on point 1, the reason for all of these numbers is because I write my RfCs in a way that I’m comfortable can get enough people behind them on both sides even if they aren’t perfect. I personally would prefer 3 months, but I think 6 is sufficient and avoids the objection that 3 is too short. If people prefer 3, that can be tweaked as the process is worked out. 2) Not necessarily beyond the social limitation. I had envisioned this as “here’s a thread where consensus shows they’re acting inappropriately”, followed by another instance, which could trigger a request. If someone’s doing involved actions regularly within 6 months, I’m not sure we should limit the thread. At the same time, I feel there would be strong social incentive not to keep beating a dead horse, and the community could sanction people who did. 3) I think that’s a reasonable suggestion. I don’t want to add it now since there’s significant votes, but I think a footnote in the policy noting it’s allowed would be reasonable if this passes. 4) Yes. Hope that clarifies.
    Also, as a general note, having done a few of these major RfCs all the issues raised in the comments can be clarified when the proposal is merged into the policy page in line with the closing statement. These RfCs tend to bring forth a lot of complex issues, and getting a framework down and then tweaking to reflect the full consensus from the discussion usually works best. TonyBallioni (talk) 02:04, 21 February 2021 (UTC)
• More on the resign as an administrator clause - this appears to result in a "voluntary resignation", meaning there is a path to resysop via simple request that then late puts a responsibility on 'crats to determine if this is a disqualifier --- any reason that this can't just be codified? I suggest that this component, and the entire policy in general include verbiage that specifically calls out that a future restoration of access must follow the "standard" process (i.e. RFA). — xaosflux ^Talk 04:25, 21 February 2021 (UTC)
  • Policy already says they wouldn't get it back (Wikipedia:Administrators#Restoration_of_adminship.) I'd oppose adding it here since there's already a clear policy on the issue, and I think adding an explicit text saying so would undermine the usefulness of the existing wording. Don't feel that strongly opposed to it, but I think the policy as a whole works better if we don't repeat what's already there. TonyBallioni (talk) 04:41, 21 February 2021 (UTC)
    • @TonyBallioni: so that's just kicking the problem down the road, and assuming the "cloud" will be revealed later - generally with arbcom desysops the cloud is prescribed, preventing any drama at BN later. — xaosflux ^Talk 04:47, 21 February 2021 (UTC)
      • No. It's expecting that bureaucrats will follow the already unambiguous policy that prevents this. TonyBallioni (talk) 04:51, 21 February 2021 (UTC)
• On the IADMIN stuff, the Wikipedia:Interface administrators policy already has a simpler path to community removal, and already includes mandatory removal on -sysop for any reason; so suggest this is all removed instead of making a competing (harder) process. — xaosflux ^Talk 04:27, 21 February 2021 (UTC)
  • Rschen7754 suggested this above when dealing with the crat/int-admin question. Someone already pointed out on the talk page that there are already other ways to do this (actually, I think I might have suggested it at the time...) I don't see a need to change the proposal again, though. Nothing contradicts and it's just another venue for removal if people want something more structured for whatever reason. TonyBallioni (talk) 04:41, 21 February 2021 (UTC)
    • @Rschen7754: I really can't see why anyone would want to go through this huge process to argue -iadmin for someone, when the first step should already cover it - what scenarios are you envisioning? — xaosflux ^Talk 04:47, 21 February 2021 (UTC)
      • Bureaucrat was more what I was concerned about; each wiki has their own rules regarding interface admin and I'm not quite up to date as to the rules for it, just wanted to make sure it was considered. --Rschen7754 06:33, 21 February 2021 (UTC)

    This proposal requires that an AN thread be closed with something inappropriate, then the rest can begin. The IAdmin policy only requires the first part: After misuse of the access by consensus (e.g. at Wikipedia:Administrators' noticeboard). That makes this, in my mind, an unnecessary complexity and simply confusing. I don't think this proposal should apply to IA, because we already have a weaker process to deal with such abuse. I agree with the idea that IA rights should be removed on desysop, but I believe that's current practice anyway (a non-admin cannot hold IA). So, the proposal should probably only apply to admins and crats. ProcrastinatingReader (talk) 08:56, 21 February 2021 (UTC)

• WT:RFA is for discussing the operations of WP:RFA, it shouldn't be a noticeboard for things - why is that needed? — xaosflux ^Talk 04:33, 21 February 2021 (UTC)
  • Because some people still watchlist WP:RFA to check for transclusions of RfAs. Since this is a similar process, allowing people to know when it is initiated on a highly watched page they're already watching for those purposes makes sense. TonyBallioni (talk) 04:41, 21 February 2021 (UTC)
• Could I ask for some examples (say, three) of AN/ANI threads that would have qualified under step 1? I think that would be useful in evaluating this proposal. More broadly, I'm somewhat concerned that this would worsen the dramaboard tendencies of AN/ANI: the last thing we want is to turn the noticeboards into an "admin complaint box". That being said, I hope someone can assuage my fears, because I really do think that this is a very well-thought-out proposal. Cheers, Extraordinary Writ (talk) 04:50, 21 February 2021 (UTC)

• As I was reading this proposal, two suggestions came to mind. The first is that, out of respect for concerns of harassment, within a set time period (say 90 days, arbitrarily), another request for deadminship cannot be brought against the same admin by the same party. Perhaps require a different 11 (1 + 10) people to initiate it, for example. If whatever new incident is egregious enough that it would attract enough support for removing the flag, asking for 11 different initiators shouldn't be a big hurdle.
  The second suggestion may be moot, because it was a thought I had before scrolling down to see the overwhelming support this has so far. Nonetheless: since the last RfC closed without a clear consensus for how to implement, with various misgivings about this or that approach, perhaps it would be a good idea to say that this is a 12 month trial run. Given how hard it has been to come to consensus about this, that would make it easier to fix if this turns out to be a bad idea while allowing for proof of concept. — Rhododendrites ^talk \\ 04:57, 21 February 2021 (UTC)

• I appreciate what TonyBallioni is trying to accomplish, and also that he is trying to allow a convenient time for the administrator under discussion. However, forcing the administrator to transclude his own desysop request seems.... cruel. I'm sure others will have better wording suggestions, but my feeble attempt is as follows: "Once certified, the administrator being discussed must indicate the starting time of the request for desysop, not to exceed 14 days subsequent to the certification. They may transclude the desysop discussion themselves, or indicate they would prefer a bureaucrat to do it on their behalf. If the administrator under discussion wishes to avoid the discussion, they may resign as administrator. If no indication regarding timing is recieved from the administrator under discussion, a bureaucrat will transclude the discussion at the end of 14 days." Thoughts? 78.26 _{(spin me / revolutions)} 05:08, 21 February 2021 (UTC)
  • 78.26, I think I mentioned this above, but it was my assumption that they could just ask a crat to do it and they would do it. I think I the specific wording could be tweaked if this policy passes without another RfC to allow that, or they could just ask. The reason I'm trying to avoid any more changes is that we've already had 30ish votes and I feel another mass ping would be disruptive. I've done several RfCs of similar scale before and when implemented, they're never tied to the exact wording of the proposal, but tend to be word smithed based on the close that reflects the full consensus of the discussion on points such as this. I don't think what you're suggesting would be out of line for that type of post-close tweak. TonyBallioni (talk) 05:15, 21 February 2021 (UTC)
    • I agree. This was intended as a point of discussion, and not intended to be a policy rewording requiring a separate vote. 78.26 _{(spin me / revolutions)} 05:28, 21 February 2021 (UTC)
• How do you deal with repeated requests being filed ad infinitum as a form of harassment? Any group of 10 people can easily meet the requirements to re-file the request as soon as the previous one is removed. Do we need a caveat saying the same person and/or endorsers can't repeatedly re-request? Tarl N. (discuss) 05:20, 21 February 2021 (UTC)
  • I don't think there's going to be any perfect system and that if we spelled stuff like that out, you'd probably get opposes for it being too complex. My view is that there would be a strong social pressure not to do that, and that the requirement that there be 3 current admins endorsing would also be a bit of a control: if they did this inappropriately, they could be desysoped for acting in a way inconsistent with adminship. The community can also sanction people for WP:POINTy behaviour. Basically I think it's the same reason why you don't see indefinitely repeated ArbCom requests: people's patience will wear thin. TonyBallioni (talk) 05:31, 21 February 2021 (UTC)
    • Sure but blocking someone for their "good faith" filing of a desysop would be pretty bold ("show me the policy saying I can only start one desysop a month"). And the blocking admin would have to want to be a target for a group of people known to use desysops as a weapon. Johnuniq (talk) 05:58, 21 February 2021 (UTC)
  • [ec] I am cautiously in favour of the proposal, but like Tarl N. see potential for this becoming a tool for harassment, and would like it to be made clear that this would not be tolerated, possibly some specific consequences for inappropriate behaviour. · · · Peter Southwood ^(talk): 05:36, 21 February 2021 (UTC)

    I feel like the community has very little tolerance for this type of gaming and am not concerned about editors being able to pull this off without consequences. Best, Barkeep49 (talk) 06:16, 21 February 2021 (UTC)

    Agreed. I imagine the social pushback against someone abusing the system in this way would be rapid. And if it turns out to be a concern once implemented, additional measures could be put in place to specifically address how the system is being gamed -- something that we just can't know at this point. -- Ajraddatz (talk) 06:32, 21 February 2021 (UTC)

• Questions: is this intended to effectively replace ArbCom as a method of first resort? In other words, will editors seeking arbitration be expected/de facto required to have tried this process first? Or is this just a secondary process, and an editor has the choice of whether they go via this or via arbitration? I support the idea that the community can take back what it gives, and has the right to decide which admins can mop on its behalf. Further, I get that there are some cases that arbs don't take up that the community still might want to act on. Still, I think I'd be opposed if this raises the bar to arbitration. There are some issues that community-based processes just cannot deal with, and if this proposal raises the bar for ArbCom intervention I think that'd be concerning. An explicit mention in the proposal along these lines would resolve this concern. ProcrastinatingReader (talk) 07:15, 21 February 2021 (UTC)
  • I also note the high bar to removal. An editor could retain their adminship with only 59% editors supporting removal, i.e. only 41% of editors in support of their adminship. If that were an RfA, it would be a clear failure. ProcrastinatingReader (talk) 07:18, 21 February 2021 (UTC)
• One area that does come to mind is that of avoiding double jeopardy - I would say that while a case request at ARBCOM is pending, the Community method can't also be used (in edge cases, it can always be tolled). I don't consider this to be an outlier, and if it doesn't add in now, then it won't even be considered for adding in until at least one person has had to deal with both trying to occur at the same time. I would note that while TB's proposal is decent, I am a little offput by them saying that they don't want to make certain changes because a number of people have !voted. Indeed, that's why voting shouldn't have been opened until further discussion had taken place. Nosebagbear (talk) 12:02, 21 February 2021 (UTC)
  • I think that falls into the category of things we should deal with socially rather than with a specific policy. We could adjust this for many hypotheticals, but it would never be perfect and it’d become unwieldy very quickly. As for workshopping it for a week, I think that’d have been the quickest way to get it to fail as no kind would be able to create a perfect procedure, and it’d end up being opposed for imperfection after a specific minor issue wasn’t addressed. A lot of the things being discussed here are not substantive changes, such as who transcludes. Those are the type of things that in my experience are usually best cleaned up post-close by tweaking the policy page to be in line with the closing statement and fixing any glaring minor issues. That’s why I’d prefer to do it then rather than mass ping a bunch of people multiple times.​ TonyBallioni (talk) 13:35, 21 February 2021 (UTC)

---

• Some in opposition find this procedure too prone to an angry mob, while others in opposition find it too entrenched to matter due to the three-sysop requirement. I'm supporting, but I'm curious if anyone opposing (or leading that way) finds both facts to be concerning? I suppose that imagination would be: (1) the act of opening of a request for endorsements could be repeated to the point of abuse, and then (2) systematically opposed by trenchant sysops. Is that roughly right? Otherwise the two views seem largely mutually exclusive. ~ Amory (u • t • c) 15:14, 21 February 2021 (UTC)
• From where I stand the problem isn't with removing a few errant admins, it's with keeping the majority of them accountable (in other words, giving WP:ADMINACCT teeth). Wikipedia admins receive lifetime appointments - a rare luxury in most other organizations, and for a reason. What we ought to have is limited terms - 2-3 years, after which the admin must face community review. This will force admins not only to "behave", but also to listen.

As for this proposal, it has two problems: the first is the requirement of supportive closing statement, which means admins would have to criticize one of their own loudly enough to merit a mention - a rare occasion; the second is the requirement to "transclude" something, which is a technical point and doesn't belong in a substantial discussion (cf. "law" vs "regulation"). François Robere (talk) 16:44, 21 February 2021 (UTC)

Remains to be tested, but I think we're more likely to see sysops openly and honestly share criticisms with such a policy. At the moment, there's little incentive for invective unless/until there's an ArbCom case, which, despite some recent(ish) examples, is fairly rare. ~ Amory (u • t • c) 16:54, 21 February 2021 (UTC)

• I don't know where I stand on this yet, but one thing that immediately jumped out at me was the at least 25 edits in the last 6 months requirement. I'd strongly suggest dropping that. I understand the desire to limit this to people who are contributing, but this is a poor way to do it. On the one hand, a bad actor who fails the 25-in-6 requirement can just make 25 junk edits, the same way people game WP:ACPERM now. On the other hand, if somebody is legitimately abused by an admin to the point that they quit the project, they may want to come back a year later and explain what said admin did to them which was so horrible. We disenfranchise those people. -- RoySmith (talk) 17:40, 21 February 2021 (UTC)

  I've done a bunch more reading, and I'm still not sure where I am. I will add another comment, however. There's general agreement that we need more admins. And I think there's also general agreement that the hazing atmosphere at RfA chases away reasonable candidates. So far, so good.

  One of the premises stated by several of the supporters is that by making it easier to remove bad admins, we'll make RfA more civilized. The consequences of making a wrong choice won't be as durable, so people won't be so nit-picky. With a kinder and gentler RfA, we'll attract more candidates. That's a plausible theory. But, another plausible theory is that RfA won't get any better, because it's in some people's nature to be nit-picky. And if that's the case, then we'll make it even less attractive. If we can't convince people to subject themselves to hell week on the chance of winning a mop for life, we certainly won't be able to convince them to try for a mop that's easier to take away. I honestly don't know which is more likely, but I certainly don't agree that this will necessarily attract more candidates. -- RoySmith (talk) 20:00, 21 February 2021 (UTC)

• I'm disappointed by the opposition tbh. Bunch of users saying "I would support this in theory, but there are too many concerns". When there are literally next to no specific, logical concerns even being articulated. The proposal contains protection after protection against a mob mentality, from an existing recent consensus that an admin breached the admin behavioral standards, to activity restrictions, to endorsement restrictions, to admin endorsement restrictions, to the requirement that the final re-RfA requires a supermajority of support for removal, and that you only have to hit 40% support to retain the bit. People are really saying that this is unleashing the mob? Really? I can be a real asshole. I can and have crossed the line way too many times. And even I don't have a single community discussion to my name with a consensus saying that I violated admin behavioral standards. Not in the past decade, much less in the past six months. This proposal literally bends over backwards to accomodate admin protection. If everything goes absolutely terrible for me, and I am forced to run a re-RfA, and I can't hit fucking 40% support, do you think I or anyone else could possibly claim that the process is unfair? That this RfA which is advertised on CENT and AN and BN and every watchlist is unfair to me? That it's unrepresentative of the community?? Obviously not. If 10 users including three admins request your removal, and you run an RfA and can't pull 40% support, do you really deserve to be an admin? Hell no. ~Swarm~ ^{sting} 02:42, 22 February 2021 (UTC)

  I think that's as clear an articulation as any of several of the flaws in the proposal. By no means all of them, but it did capture a lot. FWIW, I've tried to be specific in my follow up comments. - Ryk72 ^talk 10:51, 22 February 2021 (UTC)

  @Swarm: You're free to say the reasons provided by those opposing are insufficient, but it's completely inaccurate to say "next to no specific, logical concerns" - numerous ones have been provided. To give examples: no policy defence against multiple issuances based off the same threads; no coverage for what happens if pending ARBCOM cases and community desysops occur at the same time; 6 months is a very long time from the most recent problematic AN/ANI thread; no formal consideration of which forums count as sufficiently clear to be authorised to count for the purposes of hurdle 1; no clarification on whether timing starts six months before being passed or just on passing etc etc etc. Don't trade accuracy for rhetoric Nosebagbear (talk) 14:50, 22 February 2021 (UTC)

Except no, there's not a single policy-based or rational objection, even now. ~Swarm~ ^{sting} 01:45, 23 February 2021 (UTC)

Swarm, I am in the neutral column for now, but I find a number of objections raised by the opposers to be perfectly rational. In particular, Sandstein and several others raise the point that implementing this proposal is likely to make the WP:UNBLOCKABLES problem worse and more generally make admins more reluctant to issue difficult blocks and perform enforcement actions in complicated disputes. IMO, these concerns are justified. Nsk92 (talk) 02:39, 23 February 2021 (UTC)

• TonyBallioni and anyone else who's working hard on this, I have a few concerns.
  1. Since hurdle 1 is linking matters to a single incident - how will we handle "double jeopardy" concerns? Would multiple petitions be able to be made regarding the same AN thread?
  2. Would there be a central location to record these - which has it's upsides (transparency and ability to check history) and it's downsides (concerns of "no smoke without fire")?
  3. If a petition is accepted, there is a potential 2 week window where the admin is effectively under a cloud. Should we be accepting their judgement as an admin in that time, or would it be a good idea to put in a clause that they should not take admin actions in that period?
  4. What of the personal cost? Having been involved in many desysops (between my work on Arbcom and my involvement in recall requests) and when a user is desysopped, it is a difficult process for them on a personal level. Given that the individual would have been invested enough in Wikipedia to become an administrator, do you have any thoughts on how reduce the unpleasantness of the process, therefore increasing the likelihood of keeping them as an editor? Worm^TT(talk) 11:02, 22 February 2021 (UTC)

That No.4 is very interesting, Worm and deserves some quick calculation: How many desysoped admins have continued to edit? How many desysoped admins were indeed highly visible and/or totally engaged on Wikipedia? I know I've completely stopped doing any pro-active editing. Kudpung กุดผึ้ง (talk) 11:38, 22 February 2021 (UTC)

Very hard to judge Kudpung, but according to this table, in the last 5 years, 11 admins have been removed for cause, and only 1 has stopped editing completely, 1 stopped about 4 years later, and 9 have edited in the last week. Worm^TT(talk) 14:03, 22 February 2021 (UTC)

It's not that hard to judge, Worm . If one takes the trouble to load their edit counts, most of their editing patterns since they were desysoped are like mine: only a tiny, tiny fraction of what they used to do. Most of them had been fairly prolific editors. Speaks for itself - without predjudice for the actual reason for having their bits yanked. Kudpung กุดผึ้ง (talk) 15:24, 22 February 2021 (UTC)

Kudpung, indeed - but again edit counts don't tell the whole picture, as much of the count was tied up in admin actions. However, I don't disagree that there is a drop when an admin is desysopped for cause. Creating a new route to desysop for cause should acknowledge that. Worm^TT(talk) 15:39, 22 February 2021 (UTC)

• IANATB, but while I too would prefer a "double jeopardy" clause, the time limit helps a bit in that regard. While not stated, I imagine it'd be quite hard to clear any of these steps for something already litigated. For item 2, we have Wikipedia:Administrators open to recall/Past requests, so I'd imagine so. On 3, it's not something typically done at ArbCom so why would it be here? ~ Amory (u • t • c) 11:48, 22 February 2021 (UTC)

  I was writing long enough in my support above, but I thought about a different form of double jeopardy: can an administrator be subject to both an ArbCom case and the community process? Realistically I think it's not likely that ArbCom would accept a case where the community had gone through the process and not removed sysop (but there would be lots of pressure in the insufficient majority situation I discussed above so certainly possible). But what about the reverse? A person goes to ArbCom, there's a case, ArbCom declines to remove sysop. Could the community still launch this process? I think yes and I think it also unlikely that the community would remove sysop (in other words I expect both the community and ArbCom to respect the decisions the other group reacheds) but it would be further unpleasantness for the specific admin. I think we can't remove this form of double jeopardy but I am definitely in favor of removing the double jeopardy that Worm outlines here. Best, Barkeep49 (talk) 16:16, 22 February 2021 (UTC)

  Amorymeltzer, What is "IANATB"? -- RoySmith (talk) 21:03, 22 February 2021 (UTC)

  @RoySmith: Worm asked some questions of TonyBallioni and anyone else who's working hard on this. I care about the issue, but I wouldn't presume to say I've been working hard on it. Certainly not to the degree Tony has in creating this, so when I answered, I wanted to clarify that I Am Not A TonyBallioni (it was light-hearted). ~ Amory (u • t • c) 21:54, 22 February 2021 (UTC)

I posted this as an addendum to my "support" comment, but what with all the multiple sub-discussions here, I'll comment on it again. Instead of simply requiring a past AN or ANI incident, I'd suggest that there also be diffs showing that the admin subsequently rejected or disregarded the consensus of that discussion. In other words, if the admin said that they didn't accept that they had done anything wrong and kept on doing it, then that would be reason to invoke the procedure proposed here – but if instead the admin had said that they would go along with the community's will and not do it again, and kept their word, then there would be no opportunity for desysop. I think that would remove much of the potential for misuse of the process, and the need to be looking over one's shoulder. --Tryptofish (talk) 21:13, 22 February 2021 (UTC)

I agree in principle but disagree in practice. I think the criteria as it sits there now will cause enough angst and challenge for the crats. I don't want to layer another criteria, and one requiring even more subjective judgement, on top of the process. Instead I think we need to have faith that the community will reject a proposal where the admin has already been "I was wrong and I'll do better" for first time offenses. For second incidents and beyond it then does become a matter of judgement for the community to decide if they're going to stop or not. Best, Barkeep49 (talk) 21:48, 22 February 2021 (UTC)

I think it will be addressed at the endorsements level before the Crats have to go through any travails over it. And there's a matter of calibration with respect to trusting the community. It seems to me to improve the process if "I was wrong and I'll do better" is explicitly placed off-limits from the get-go – or at least it makes the proposal more responsive to the concerns of many of the editors who oppose it in its present form. --Tryptofish (talk) 00:27, 23 February 2021 (UTC)

---

• What would be in "request for de-sysop"? I apologise, but I don't understand. I mean, if an editor alleges admin XYZ is a meanie, and provides evidences, and if that RfC is supported by 10 ex-cons, including 3 admins. Then is that accused admin supposed to transclude request for de-sysop at RfA? And whats going to be that request? A defence statement? I think its going to be a standard RfA + a defence statement, am I right? —usernamekiran (talk) 20:53, 22 February 2021 (UTC)

• Is "there was consensus that the administrator behaved inappropriately" meant to refer to any inappropriate behaviour, or behaviour in the role of an admin (using tools, closing discussions etc)? I would definitely be in favour if it were the latter, but think the former is open to abuse by editors with grudges. If it is meant to refer to the latter, could the wording be changed to "there was consensus that the administrator used their status or tools inappropriately". Cheers, Number 57 22:01, 22 February 2021 (UTC)

• Comment. Let me make another pitch for an alternate approach to making admins more accountable: Making an admin appointment time limited for a specific term (say 6 years), and requiring a reconfirmation RfA at the end of the term for those wishing to retain the sysop bit. This system will avoid many of the problems being raised regarding this community desusop proposal. There will be no link to ANI and no need to solicit negative endorsements. A reconfirmation RfA process provides a much more positive and less confrontational format for analyzing an admin's record than a desysop RfA. The process will be more uniform and will expose to community accountability all admins and not only those who obviously strayed or happened to majorly piss off the wrong user. Admins who are relatively inactive as admins (do not perform many admin tasks) will be forced to think about their situation more cartefully. Some of them might be lost, bit others will start being more active and pulling their share of the job. The ArbCom desysop process won't be affected. During their 6-year term admins will be able to concentrate on doing their job without the prospect of a nasty public recall election hanging over them. The situation will be more predictable and stable. Admins who make difficult blocks and have dealt with WP:UNBLOCKABLES may still face flak at reconfirmation RfAs, but the process will still be much less overtly cliquish and partisan than the community desysop process is likely to be. All admins will have to shape up a bit. Nsk92 (talk) 10:45, 23 February 2021 (UTC)
• including at least three current administrators Do non-admins' views need to be endorsed by their betters? Crispclear (talk) 13:39, 23 February 2021 (UTC)

  [1]--Ymblanter (talk) 15:34, 23 February 2021 (UTC)

  If somebody created 9+ dummy accounts just so they could certify a request against their hated enemy admin and if nobody noticed that they had done so, then the worst that could happen would be that the request was opened for discussion. It's a check against something that would never be likely to happen and wouldn't matter if it did. Crispclear (talk) 16:05, 23 February 2021 (UTC)

  Many blocked users keep several active socks at the same time. I have seen recently a user blocked after being reported by a sock, and another one coming close after being reported by a sock. Whereas indeed this is unlikely that ten socks of the same user would certify a desysop, the fact is that becoming administrator is virtually the only relevant situation where vetting of the community is needed. This might be good or bad but it is what it is.--Ymblanter (talk) 16:14, 23 February 2021 (UTC)

  But even if this imaginary user managed to use their 10 accounts to get the desysop request certified, that would still only move it to the discussion phase where they would need another 3 dummy accounts for every 2 genuine users that voted to not revoke sysop. If 20 people voted to against revoking, the user would need 30 undetected dummy users to vote for it. Honestly, if they've gone to that much trouble and they've manage to do it undetected in a forum where they are going to be scrutinised, then we a) have bigger problems than one dodgy admin and b) we should probably reward them for the effort. Crispclear (talk) 16:31, 23 February 2021 (UTC)

  @Crispclear: - one reason is that you are assuming that there is no negative short of an admin actually being desysopped. Except, that's not the case. A regular RfA is already somewhat unpleasant, and you choose when to do them. We can assume that any desysop RfA will be, at best, as good as a normal one, and at worst, horrific. Being subjected to by one, even if ultimately a candidate is confirmed, is a major negative. Nosebagbear (talk) 20:03, 23 February 2021 (UTC)

• Comment. I looked up the procedure on German Wikipedia and they use a different recall approach that seems better to me. Instead of desysop RfAs they have mandatory reconfirmation RfAs that are triggered by a certain certification process. (In their case, if 25 users within a month or 50 users within 6 months endorse a call for a reconfirmation RfA for a given admin). When a reconfirmation RfA happens, the threshhold for passing it is the same as for passing an initial RfA. The community votes not on whether to desysop someone but on whether someone satisfies the requirements for being an admin. I think their approach is less confrontational and negative than the proposal we are considering here. If we were to use their model, we'd need to adjust the numbers required for certification, and perhaps require some of the endorsers to be admins. I would also have liked the current proposal better if, even under the same certification process as currently proposed, the subsequent RfA run as a reconfirmation RfA rather than as a recall/desysop RfA, with the same passing threshhold to be used by crats as for new RfAs. Nsk92 (talk) 16:18, 23 February 2021 (UTC)

I can agree with this proposal. I am worried that a community desysop proposal can quickly get very messy and contentious as users pile on painting the admin in the harshest light. I am not sure if a reconfirmation RfA solves those problems, but it at leasts people would be more likely to advocate for a positive outcome. --Enos733 (talk) 17:11, 23 February 2021 (UTC)

On hypotheticals

Policy is never perfect on the first go. Governments employ armies of policy analysts and advisors whose entire job it is to revisit and revamp existing rules and procedures to meet changing landscapes and address unforeseen consequences. The work is considered to be iterative -- a policy is made, evaluated as time goes by, and modifications are made as necessary to accomplish the intent behind the policy. The standard for the first iteration is that it adequately takes into account potential risks while providing the intended benefit.

The process that Tony has proposed has ample safeguards against the process being used as harassment, double what most sister projects use as their standard before a desysop request. Rather than worry over every potential hypothetical scenario, I suggest that we focus on two things: first, the evidence, which is that on Meta/Commons/Wikidata (the three desysop processes I am familiar with) the desysop process is not abused as a form of harassment. Second, the fact that this proposal is good enough, meaning that it will accomplish the desired benefit and has explicit thought placed into mitigating the risks. And if the process doesn't work as intended, we can change these rules once they are made.

We as a community have decided that there should be a community desysop process. Let's try to get one in place within a decade after that decision was made. -- Ajraddatz (talk) 06:29, 21 February 2021 (UTC)

• Some alternative system is clearly needed and as TonyBallioni is no friend of Arbitration Committees this proposal comes as no surprise. WP:BARC launched by me with support from Worm That Turned almost a decade ago was an attempt at community desysoping without the ANI-style interference or uninvolved users and holders of superior rights jumping in with further threats and/or harassment without having first familiarised themselves with the background. While some suggested it might give the ‘crats something to do with their status and position, there is still plenty of resistance from the community to forcing tasks onto the ‘crats they have not signed up for; the 'crats themselves said little on the subject. One user appears to defend both solutions. We learned through our BARC that the ‘crats should first be asked if they would accept such an extension to their mandate.

There are several very different reasons for a desysoping ‘for cause’. Some are clear cases of blatant misuse of the tools, wheel warring, using their tools for pay, etc, while there are other reasons that are more subjective and where the evidence is not necessarily clear , is circumstantial, is purely vindictive, or just plain railroading. Compared to the number of admins desysoped 'for cause' over the years, the Arbitration Commitees have a much, much higher record of impropriety among their own ranks and/or former members. Some Arbcom policies are already too vague and open to any interpretation one wants to make in order to make a case stick, especially in the well known Wiki culture of cherry-picking and taking things - deliberately and convincingly - out of context.

Between this proposal and Arbcom, is a choice between the devil and the deep blue sea. As an already desysoped user, I ‘m not really bothered much about the outcome of this RfC, but as a retired user, I will come out of retirement to protest about any cases that might be leaning towards an unsafe verdict based on claims and ‘evidence', offered by uninvolved, wannabe Wikipolice - as some users here are already aware, and especially if an admin is standing in the dock and likely to receive a punishment for which the Arbcom policy allows no appeal.

This means finding an alternative desysop procedure that limits the participation of the peanut gallery rather than giving them even more scope and power. In recent times, various compositions of Arbcom have shown that while the Committee might not be corrupt, it does favor the claims of highly vociferous, non involved users as well as those of its own members, and although it is jury, judge, and executioner all rolled into one, it tends to simply read and execute a community consensus and it does fail to check the veracity of the accusers’ claims, choosing a solution which they think the community wants to hear rather than the good of the Wipipedia. Hence I’ll reprint Nick’s comment in its entirety: The ArbCom system has always been deficient. ArbCom are able to shape cases to suit their own opinions on the subject of the case, they get to choose whether to accept the case, they already limit the amount of evidence and can refuse to hear further evidence, and then get to propose outcomes which suit their outlook on editing. There's also extensive behind the scenes horse-trading to secure support for proposals. It's like a more or less shitty version of a Presidential impeachment,

I won't repeat here all the various comments by Beeblebrox, Tarl N., and Peter Southwood, but they are spot on and I certainly endorse them. Kudpung กุดผึ้ง (talk) 07:17, 21 February 2021 (UTC)

Regarding Kudpung's comment about "Arbcom has made an easy task of it for themselves in recent times - almost lining admins against the wall and shooting them in one session" - I beg to differ. In the case of RHaworth, it took years of multiple ANI threads, talk page notices, chats in the pub, and the final Arbcom case only happened because something egregiously wrong happened that tipped it over the edge. More to the point, it destroyed RHaworth the editor who's now just a bitter grump about being desysopped, as opposed to somebody I could work with writing about architecture in South London. And the desysop of Fram only happened because of a deus ex machina (whatever your views on Fram, you cannot deny a significant amount of people opposed his adminship as demonstrated in the subsequent RfA - for the record, I think Fram has got better since and don't have strong views on him running an RfA now).

I'm also really surprised to see Leaky caldron opposing this. I would have assumed he'd be strongly in favour of getting increased administrator accountability and improving the sanction mechanisms. Ritchie333 ^{(talk) (cont)} 10:26, 21 February 2021 (UTC)

Ritchie333My oppose, I should have made clearer, is not about the proposition per se and on reflection guarded support or neutral would have been more appropriate. The primary concern I have is that requiring the advocacy of 3 fellow members of the admin. brigade will be insurmountable in the case of some high-profile individuals. 2 active Admins. supporting should be more than enough to back a community case. Leaky caldron (talk) 10:59, 21 February 2021 (UTC)

Leaky caldron, I viewed that as something that could easily be changed by the community if it isn’t working. Again, the requirement was put in place specifically to deal with ethnic dispute cases, where I could see there being two admins on one “side” of a dispute certifying a baseless case (there’s a lot of ethnic disputes and a lot of legacy admins.) Three felt like a safe number to deal with this. I think adjusting it downward is certainly possible, but my goal with this proposal was what Ajraddatz pointed out, to provide a framework that could be adjusted with experience, and I felt that 3 admins worked for those purposes since I knew a major concern would be harassment. TonyBallioni (talk) 13:27, 21 February 2021 (UTC)

[ec] I agree that policy is seldom, and should not be expected to be, perfect first time round. I have seen this in several iterations of Health and Safety policy that I have been involved in, but from that experience I have seen that a relatively gradual change generally causes less overall pain and astonishment than a revolutionary swing, which is often followed by a swing in the opposite direction as a reaction to the change when it is seen to be excessive. From an engineering viewpoint we want a heavily damped oscillation around where we think we want to be rather than overshooting and setting up an unstable positive feedback loop. A trial period with a specific time limit, and a date for the next review is probably a good idea, and is standard practice in OHS (OSH for some). I would like to see minimum pain inflicted on all involved in the early stages, as there will be some with their knives out, either for revenge or to further an unmentioned agenda. On the other hand, I also think that there are enough of us who will be watching the process that it would be foolhardy to try to get away with vindictiveness or political dirty work. There may still be unnecessarily unpleasant consequences, as some of our community do not seem to understand the policy on no personal attacks, which should be strictly enforced by clerks appointed for that specific purpose and who have demonstrated their competence in identifying the range of ad hominem arguments common in our disputes. · · · Peter Southwood ^(talk): 13:51, 21 February 2021 (UTC)

The problem I have with this is that, little as I trust arb com decisions, I trust AN/I much less. (and I've said both of these before I was elected to arb com, while I was on arb com, and I think the same now that I am not longer on arb com.) Arb com often fails to act because of its tendency to tolerate people until they do one specific horrible thing, and even when it does act, is not necessarily consistent. AN/I proceeds much too rapidly, tends to make decisions based on the views of very few people, and is far too susceptible to grudges and cabals. I dislike using AN/I as the gateway to anything, and if we do use it , we should require at leasttwo separate incidents. (there's no need for community desysop when quick drastic action is needed--arb com does these well--and a good many of these involve privacy and are therefore not done in public). DGG ( talk ) 02:46, 23 February 2021 (UTC)

I'm with you on ANI, but the hardest parts of creating this process have always been buy-in and entry into the community discussion. We know how to have discussions aimed at some sort of consensus, so getting there requires some established system that all folks can accept, even begrudgingly. ANI is bad, but AN/I is what we have. They're established, well-trod, and aren't going anywhere. We've no reasonable alternative without creating something whole cloth, which I don't think would have buy-in. ~ Amory (u • t • c) 11:15, 23 February 2021 (UTC)

ANI can be, and should be fixed beginning with the aspersions, PAs, gaming and POV railroading. Most admins already know what goes on at the drama boards, but oftentimes, when they have no dog in the fight, prefer not to get involved, and who can blame them? Ironically, those are the admins we need in the discussion. The discussion itself should be carried on in an orderly and civilized fashion. Editors have long since learned that some admins don't read diffs beyond the first 3 to 5, and it's highly unlikely that they took the time to read them in context...or if there are many, they'll choose a few at random. I don't doubt that they depend more on the input of other editors/admins they trust. What I find most disconcerting is how the aspersions and PAs are ignored, even past ArbComs are guilty of that behavior to a lesser degree, whereas I see it as the 1st place where changes need to be effected. Uninvolved is another criteria that not only needs serious thought, it needs implementation ASAP. What we have now is the family & friends of the victim and the family & friends of the accused sitting on the jury, and it's very possible that one will outnumber the other depending on popularity & tenure, and to support that statement I will refer to my favorite reference, the hegemony of the asshole consensus. There should be a separate section for UNINVOLVED EDITORS iVoting at ANI, and only those iVotes should be taken into consideration. Clerks should quickly warn an editor who has cast aspersions, remove the aspersion and prevent that editor from participating in the iVote unless that editor can provide the necessary diffs to support the aspersion(s). The same applies to blatant PAs. The iVotes of the "regulars" at ANI should not count at all if they have a history with the editor "on trial", be it in that particular case or another - history matters. I do believe that if we begin there, we will be on the right path to reducing drama and helping to make ANI/AN/ArbCom a far more collegial place to work out our differences. Atsme 💬 📧 14:39, 23 February 2021 (UTC)

Excuse me if it has already been addressed above (I only read about half of these points). Do we have any ideas as to how a RfDs (desysop) would actually work in practice. Would you open the page with the person nominating the user justifying why it is necessary? Does this include questions as it does in a regular RfA? I feel like we need a procedure for this, but there are some questions about how exactly it works that I'd want confirmed before implementation. Best Wishes, Lee Vilenski ^{(talk • contribs)} 19:55, 23 February 2021 (UTC)

Process flowchart

I thought it might be useful to produce a process flowchart to illustrate this process. --Hammersoft (talk) 22:10, 23 February 2021 (UTC)