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)

   To expand a bit, I take the concerns seriously, but it seems they're split between either "too strict" or "too loose," which (at risk of an argument to moderation fallacy) I'm hoping suggests this will be Fine. It seems a lot of the remaining opposition is based on mere opposition to the whole concept itself, and thus our prior consensus from WP:DESYSOP2019. I'm not sure what to make of that, but it's going to be intractable if every time a decision is made, trying to enact that decision fails because everyone who initially opposed the idea opposes any work to enact the will of the community. ~ Amory (u • t • c) 12:05, 24 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)

    I agree with Rschen below, The only way we're going to get a better proposal at this point is to get more data. Data > opinions. There are as many people who oppose this because it is too strict, as there are people who oppose this because it is too lax. People argue that no one will be desysoped, or that there will be mobs with pitchforks and torches. We can argue about this for another 10 years, or we can try something and collect some data. Some of us are wrong; let's find out, at long last, who. Let's test it. I note that in 10 years we haven't had a recall, even though over a hundred admins are voluntarily recallable. So that should ease the "mob" concerns. I also note that no matter how cumbersome this system is, it's less cumbersome than no system at all, which is what we have now. That should easy the "too strict" concerns. I think just about every part of this proposal should change: I disagree with every threshold, every step of it, almost every detail. But I still support, because it's better to try it out and see how it works in practice, rather than arguing endlessly about theories. Levivich ^harass/_hound 20:23, 25 February 2021 (UTC)

    I strongly agree with the crux of L235's oppose !vote below (We don't need another process for removing admins for misconduct; we need one to remove admins for losing the community's confidence.), and it almost made me reconsider my support. But I still support this, because even though it's too much geared towards misconduct and not enough towards community confidence, that can be fixed by changing the details. As I said above, I disagree with almost all of the details, which basically means I think this proposed system will fail. However, I think we will gain a lot of very valuable information by seeing exactly how and where it fails: is it in the closing of ANI threads about admins? In the endorsement phase? In the transclusion? In the final tally threshold? I know I don't agree with all those details, but I'm not sure which needs to be adjusted and exactly how. We really won't find out until we try. Levivich ^harass/_hound 04:26, 3 March 2021 (UTC)

    Levivich, sorry, I had to start responding to the "We really won't find out until we try"/".. basically means I think this proposed system will fail." type of remarks. As this proposal is currently written, all you need is a) being a not all too popular admin and b) one negative AN/I thread. Except for the WP:UNBLOCKABLES that is the far majority of admins (many are active in not-too-popular areas of wikipedia, making not all too popular decisions, I guess that about half of the community is inclusionist who is not happy with many deletions as they think the article can be improved, and the other half of the community is more deletionist and disagrees with the easy keeps; I have had admins yell at me because I (rightfully) blacklisted a (heavily spammed) link they needed one time, heck, I had an admin bluntly removing it because they needed it, immediately after which the spam-socking happily restarted). Trying this proposal as it stands runs the risk that we first desysop 10-20% of our admins, and then conclude 'meh, maybe this was not a good proposal after all'. IF we want to try this, we should set our selection standards on the stringent side, and then slowly loosen them, not 'one strike and you are out', cause collateral damage, and then decide the proposal failed. And those may then not necessarily have been removed because they lost confidence of the community. Dirk Beetstra ^{T C} 07:34, 3 March 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)

    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) (moved to neutral User:力 (power~enwiki, π, ν) 01:50, 31 March 2021 (UTC))

20. 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)
21. 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)
22. 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)

    Some additional thoughts: The only way we're going to get a better proposal at this point is to get more data. We can make adjustments at a later date when we see how this proposal works. I also do think that we have to account for a post-WP:FRAM world here, and pressure from the WMF to hold our administrators more accountable for their conduct, even if it does not relate to tool use. --Rschen7754 01:38, 24 February 2021 (UTC)

23. 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)
24. 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)
25. 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)
26. 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)

27. 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)
28. 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)
29. 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)
30. 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)

31. 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)
32. 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)
33. 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)
34. 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)

35. Support I concur precisely with Tide rolls' comments; happy days, Lindsay^Hello 16:31, 21 February 2021 (UTC)
36. 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)
37. 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)
38. 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)
39. 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)
40. 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)
41. 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)
42. Support per Pythoncoder. JJP...MASTER!_{[talk to] JJP... master?} 22:19, 21 February 2021 (UTC)
43. My feelings mirror MSGJ's. SQL^{Query me!} 23:32, 21 February 2021 (UTC)
44. 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)
45. The perfect is the enemy of the good --Guerillero ^{Parlez Moi} 04:08, 22 February 2021 (UTC)
46. 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)

    Everyone wants the system to only be initiated by "real" editors. But we don't need to have "admin" be the way to distinguish "real" editors from EC socks. Another possible way to vet initiators is to require "veteran" editors, however defined: maybe 1yr/10k edits, maybe 2yr/20k edits... require 10 of those to start a petition. I don't think a sockmaster can create 10 of those kinds of accounts, and if they do: I mean, if they can run 10 accounts with 20k edits for 2 years... then shit, let them start the de-RFA process, they've earned it! :-D Levivich ^harass/_hound 18:38, 26 February 2021 (UTC)

    @Levivich: To be honest, it should probably just be like 1 or 2 admins. It might be good to have someone who has gone through a successful RFA (and knows what it can be like) weigh in affirmatively on the matter before such a drastic action should be taken. –MJL ‐Talk‐^☖ 18:43, 26 February 2021 (UTC)

    No admin will ever want to certify one of these, I predict. And if any admin ever certified one of these, it would only be because the circumstances were such that Arbcom would desysop anyway. I don't think a community desysop process works if it requires an admin's sign-off. In parliaments, when there is a vote of no confidence in the prime minister, one doesn't need a member of the leadership to sign off on it, because no member of the leadership ever would. (I still support this, cuz I might be wrong.) Levivich ^harass/_hound 18:48, 26 February 2021 (UTC)

    This is factually not correct. When I applied to BN to get my tools back (this was I believe in June 2018) I had about five admins strongly objecting, one saying that I should be happy I have not been blocked indef. I am sure they would have certified the desysop. I got the tools back. There was no serious talk about an ArbCom case of any real substance.--Ymblanter (talk) 18:55, 26 February 2021 (UTC)

    @Ymblanter: Noted and stricken. (edit conflict) –MJL ‐Talk‐^☖ 18:40, 26 February 2021 (UTC)

    I amended my comment to reflect a misunderstanding I had with the 65% threshold as I don't think that should be changed. I also want to note that I hold a lot of weight regarding Sandstein's oppose !vote, and I think that any process that could punish an admin for taking action against an UNBLOCKABLE is fundamentally flawed. However, as Swarm notes, getting 40% of users to support you in an RFA is rather trivial, and I have to imagine there is enough will in this community for that amount of users to want to retain such an admin. (edit conflict) –MJL ‐Talk‐^☖ 18:40, 26 February 2021 (UTC)

47. 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)
48. 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)
49. Support Agree with the proposal. Abhishek0831996 (talk) 13:25, 22 February 2021 (UTC)

    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)

    And again, Joe Roe and Hammersoft make me reconsider this position. I guess this is a proposal I really want to support, but my comments above are mostly concerned that this might inadvertently entrench the difficult of desysopping further (I suspect ArbCom will take on even less sysop misuse cases than now if this passes, making the most popular admins harder to desysop) and Joe Roe makes good points in that regard and some of Hammersoft's are interesting on other aspects of this proposal. ProcrastinatingReader (talk) 12:12, 24 February 2021 (UTC)

50. Support – worth a try; can be tweaked later if needed. Graham87 15:29, 22 February 2021 (UTC)
51. 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)
52. 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)
53. 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)
54. 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)

55. 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)
56. 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)

57. 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)
58. Support per numerous above. About time. But also per Barkeep. Gog the Mild (talk)
59. Support Power corrupts, absolute power corrupts absolutely.--Catlemur (talk) 22:53, 22 February 2021 (UTC)
60. 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)
61. Support - people change.   ~ Tom.Reding (talk ⋅dgaf)  00:25, 23 February 2021 (UTC)
62. Support - Neutralhomer • Talk • 00:27 on February 23, 2021 (UTC)
63. 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)
64. Support A well-defined process makes everyone more accountable.  Mysterymanblue  01:19, 23 February 2021 (UTC)
65. 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)
66. 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)
67. Support:. It will increase accountability. Desertarun (talk) 09:17, 23 February 2021 (UTC)
68. 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)
69. 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)

    As per Iridescent, to clarify: My support is for "...a consensus with a minimum support threshold of 60% supporting removal..." (my emphasis) as stated in the proposal. If that is changed, the RfC needs to be re-run, and I would certainly oppose were the 60/40 swapped. Boing! said Zebedee (talk) 11:14, 27 February 2021 (UTC)

70. 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)
71. 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)
72. 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)
73. 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)
74. 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)
75. 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)
76. 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)
77. 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)
78. 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)

79. 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)
80. 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)
81. 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)
82. Support I think the requirements here are tougher than most of the admin recall criteria, and there the list of past requests did not leave me to believe the process would be gamed or able to be gamed (few people I see were a) wrongly dragged to recall, and b) desysopped via that method.) I understand the concerns about excessive bureaucracy, but a) it's a sight better than the bureaucracy of an arbitration case, b) that layered method is what will prevent it from being easily gamed. Der Wohltemperierte Fuchs ^talk 23:17, 23 February 2021 (UTC)
83. (edit conflict) Support - Any method is better than no method. We can raise or lower thresholds, adjust specific timings, or otherwise fix any flaws in the process later. At some point we're just letting the perfect be the enemy of the good.
    For example, I think that 60% is too high of a threshold, but I'm not going to oppose on the grounds that I believe that if even a majority of editors believe an admin has abused his position to the point of requiring a desysop, he should be removed. I also don't believe that any of the people certifying the request should be required to be sysops. However, again, any enforceable method allowing administrator recall is better than what we have now—nothing.
    Incidentally, myself and a number of other admins are open to recall, and I think there has been exactly one recall attempt (which also succeeded) in my 10 years on this site, so I rather doubt that this process will be significantly abused by trolls or revenge editors. In the event that some random disruption-only sock files a clearly-frivolous request, we can just treat it the same way we treat any other act of vandalism. Reaper Eternal (talk) 23:18, 23 February 2021 (UTC)
84. Support this and any other proposal that enables community desysop.—S Marshall T/C 23:21, 23 February 2021 (UTC)
85. Support as a good starting point. It won't be perfect, but there will be opportunities for it to be improved. — J947 ‡ ^{message ⁓ edits} 01:59, 24 February 2021 (UTC)
86. Weak Support Ⓩⓟⓟⓘⓧ _Talk 02:34, 24 February 2021 (UTC)
87. Support Much-needed remedial step. We should always remember that the purpose of this process is not personal punishment; rather, its function is primarily to maintain the purpose of Wikipedia.Nalbarian (talk) 02:52, 24 February 2021 (UTC)
88. Support This proposal seems both fair but also efficient. Jmbranum (talk) 03:37, 24 February 2021 (UTC)
89. Support. Long-needed and a fine place to start. In the long run, I share the concerns about tying this to ANI (which tends to require multiple visits to "get it right") and would prefer something more like the German system of rolling thresholds for reconfirmation, i.e., enough discontent to show that such an expenditure of effort has more than a snowball's chance. czar 04:51, 24 February 2021 (UTC)
90. Support - I'm all for this. GamerPro64 06:12, 24 February 2021 (UTC)
91. Support All unchecked power leads to abuse. Keepcalmandchill (please ping in responses) (talk) 06:14, 24 February 2021 (UTC)
92. Support I would prefer only noticeboard discussions that were closed by an admin to be a trigger for the process, but we can see if that's becomes an issue or not going forwards. Scribolt (talk) 06:54, 24 February 2021 (UTC)
93. Support. This proposal was well thought-through and although it still jars me that the Wikipedia community is drifting towards proceduralism, that phenomenon seems to be working on the whole. My main basis for supporting this proposal is ArbCom. I now trust the community consensus far more than I trust the judgement of committee members. It's simply a numbers game – pick any ten community members and you'll get a fair few that don't really hit the nail on the head when they opine on a particular issue. It isn't their fault; they just aren't the most clued-up, or they didn't read the material carefully enough, or they are too busy thinking about something else. Unfortunately, in a scenario where the community is not deciding, but rather ArbCom, then those people have proportionately far more influence than they should. Community vote-discussions tend to allow the right views to float to the top and become prolific, placing far less reliance on individual people than in a committee decision-making model. All the old arguments for making an exception when it comes to administrators, and vesting the power of desysop in ArbCom, no longer wash. I do not get the sense that desysopping decisions are better made by ArbCom – the opposite is now true. AGK ■ 10:01, 24 February 2021 (UTC)

    The proposal isn't well thought through at all, as evidenced by the many comments in the oppose section. Even if it does pass, it will need considerable revision before it is truly workable IMO. With regard to the community as a whole being better judges than Arbcom - if that were the case, why the need for Arbcom at all? Because the community has proven again and again that there are certain issues that it finds intractable. Arbcom has for the most part served the community very well. Arbcom members are generally on their best behaviour, because they know that any display of rashness or bias will discredit them, unlike community discussions where participants have no compunction in adding the most prejudicial statements because of the greatly attentuated degree of personal responsibility. And importantly, Arbcom has procedures to ensure that all parties get a fair hearing, there are no such safeguards in this proposed process; once a request is confirmed, it's basically just going to be a chaotic !vote-fest with no procedural safeguards at all. Gatoclass (talk) 11:30, 24 February 2021 (UTC)

    The procedure is simple and workable; none of the opposition made a credible case otherwise. ArbCom was created to solve the problems of a different community. If you’re questioning why we now need it, so be it. Finally, if RFA works then so will RFDA. AGK ■ 12:09, 24 February 2021 (UTC)

    #Support I honestly believe that this is a great idea, for I have long thought that admins are like kings. 🐔 Chicdat  ^{Bawk to me!} 11:09, 24 February 2021 (UTC) Moved to oppose. 🐔 Chicdat  ^{Bawk to me!} 10:22, 15 March 2021 (UTC)

94. Strong support. Like others, I have no idea if the numbers are perfect, and I expect them to change with experience. What this does, is add an additional tool to desysop an admin. For the majority of my Wikipedia editing (even in contentious areas) WP:COOL and WP:AGF has worked for well for me. In the exceptional cases, I have seen WP:ROGUE admins, but even more pervasively the phenomenon of WP:UNBLOCKABLES non admins. I am convinced that increasing the number of ADMINS is the solution, and this will happen, if we reduce the pressure of this lifetime appointment. So ironically, by improving recall process, we also will retain/recruit more admins and make them less fearful of retaliation for removing abusive editors, simply because they won't be as alone. Shushugah (talk) 13:39, 24 February 2021 (UTC)

    There is a much easier solution. Change adminship from being a lifetime appointment to a limited term one, say 5 or 6 years. Require a binding reconfirmation RfA (with the same passing threshold as new RfAs, so that no new standards need to be invented) at the end of the term for those admins who want to continue as sysops. All admins, not just the ones who seriously step over the line, will be held accountable by the community. Leave the ArbCom to deal with removal of adminship for cause. Nsk92 (talk) 15:37, 24 February 2021 (UTC)

    I would support that as well, maybe even prefer it, because it would allow for RFAs to be done in a cordial manner. However that's not the proposal presented to us here. Do you know if that has been discussed before? I can imagine the fear of losing too many admins pending re-confirmation was one reason why it wasn't proposed instead. Shushugah (talk) 15:49, 24 February 2021 (UTC)

    It has been discussed many many times. The obvious drawbacks, loss of the "longtail" of admins who occasionally use the mop, but whose recent activity levels would make it difficult to pass RFA, and as with a non Arbcom desysop system, the strong discincentive for admins to involve themselves in controversial areas have kyboshed proposals so far. BTW it would be good to increase the number of admins, but is the experience on projects like Commons that making deadminship easier gets more RFAs? ϢereSpielChequers 16:15, 24 February 2021 (UTC)

    I myself have not followed these prior discussions and have no specific memory of them. I do rememember seeing a few non-binding voluntary reconfirmation RfAs and I think they all passes pretty easily. Regarding admins with low levels of admin activity, I would not view them losing the admin status as a serious loss for the project. But a regular reelection system might give them the incentive to start using the mop more regularly. Nsk92 (talk) 16:27, 24 February 2021 (UTC)

95. Support There definitely needs to be a mechanism for removing abusive, clueless or otherwise rogue administrators, and this is as good a means as any. True, the need to go to a drama board first has its shortcomings. Ordinarily there is automatic support for an admin, especially one of long tenure, which is why abusive administrators can frequently be found to say "sure, go ahead, go to ANI!!" when challenged. But the phenomenon of the abusive administrator is a fact of life at Wikipedia and that is just one of the annoyances needed to engage in this hobby. One suggestion: I would keep the arbitration committee route. It is not clear whether it would be retained, as another alternative, in this proposal. Coretheapple (talk) 16:57, 24 February 2021 (UTC)

    The arbitration option definitely will stay! That has been affirmed, because sometimes there are sensitive information/topics that would be inappropriate with this proposed forum. Shushugah (talk) 17:59, 24 February 2021 (UTC)

96. Support - sensible propoal. Not perfect, but better than nothing. PhilKnight (talk) 18:17, 24 February 2021 (UTC)
97. Support Is it perfect? No. However, we need some sort of community de-sysop procedure, considering that Arbcom often moves slowly and admins should be ultimately answerable to the community. There are a couple issues - ANI threads often don't reflect what the consensus would be among the broader community, and they're easier to manipulate - but it's an improvement. ThePlatypusofDoom (talk) 18:53, 24 February 2021 (UTC)
98. Support a time-limited trial. I'm extremely sympathetic to the argument that this would hang a millstone around the neck of anyone who gets even the most minor finding against them at a drama board—as worded, even the most anodyne "Admin:Foo is reminded to use the upright= rather than the width= paramater when resizing images" finding would cock a pistol at Admin:Foo's head for the next six months. That said, the history of Wikipedia is full of things which people expected to fail and which caused no problems at all. I'd support running this for a few months, with a strict sunset clause saying that unless there's a clear consensus that it works it will expire on a set date, to see if it actually has any useful effect. Yes it will be potentially unpleasant and a timesink for anyone caught up in it, but speaking as someone who's been hauled off to Arbcom for alleged abuse I can assure everybody that the existing mechanism is neither fun nor quick. ‑ Iridescent 20:07, 24 February 2021 (UTC)

    For clarity and to avoid and doubt down the line, if the proposal below to require 60% support for the admin to retain the tools passes, then switch to strong oppose. Assuming (based on figures from when TFAs were more common) that once the novelty of the first few wears off these things will attract around 100 participants apiece, that means it will only take 40 malcontents to strip an admin of the bit. Any admin who hasn't managed to upset 40 people over their time is probably so inactive they should be stripped of the bit for inactivity; a 60% threshold for retention would effectively make this procedure unsurvivable, and as such either it would retain the requirement for bureaucrat certification and thus make the 'crats into the Admin Removal Panel, or it would allow any group of unhappy people to trigger the process and wipe out the admin corps completely. ‑ Iridescent 10:19, 27 February 2021 (UTC)

99. Support If we can vote to give them the ban-hammer, we can take it away. Chris Troutman (talk) 21:54, 24 February 2021 (UTC)

    In real life, elected officials are almost always elected for a fixed term and made to stand for a reelection. Recall elections are rarely used but when they do happen they often lead to disasters. Instead, different procedures are used for removal of elected officials for cause while in office (impeachment for presidents, expulsion for members of Congress, etc). For other wiki functionaries (e.g. arbitrators, stewards) we have limited term appointments requiring re-elections, but not for admins. Somehow admins get lifetime appointments, like U.S. Supreme Court judges. Nsk92 (talk) 22:12, 24 February 2021 (UTC)

100. Tentative Support , probably for a a time-limited trial initially. It's hard to predict how it would actually turn out. Johnbod (talk) 04:43, 25 February 2021 (UTC)
101. Support The de-facto current system is equivalent to saying that the only way to review the conduct of a police officers is if the US Supreme Court hears the case.....a recipe for non-review. I'd like to see a system that could also give admonishments, direction and guidance, but at least this is something. North8000 (talk) 05:18, 25 February 2021 (UTC)

     It can be tweaked later if needed. Suggest noting this. North8000 (talk) 21:58, 3 March 2021 (UTC)

102. Support We should have such a process. The suggested one is a good starting point. Alaexis_¿question? 08:06, 25 February 2021 (UTC)

     I looked at this early on and my initial reactions were mixed. On the one hand I am strongly supportive of the notion that the community should be able to handle a desysop - it is something I've supported for most of my time here, and it is something that I feel most of us want. On the other hand I am uneasy about this proposal for fear of a knee-jerk reaction to a single event with a subsequent pile on - we have seen these things happen; and much of the proposed system is too problematic, too bureaucratic, and doesn't allow scope for 'Crats to make an assessment of the arguments, etc

     I don't think this is the procedure we should have. But, I am hesitant to impede or complicate a proposal for a community desysop, because previous proposals have come unstuck on similar minor issues. Given that pretty much nothing we have ever done on Wikipedia has started out perfect, but has improved over time as we have worked on it, it is better to have a community desysop procedure, imperfect for sure, but with the natural tendency that Wikipedia has of improving the process as we go along, than to reject this proposal because it is a stub rather than a featured article.

     I feel we should accept this proposal and work on it to make it work. I feel we can accept this proposal as it stands and adjust as we go along, though with three important amendments: 1) "If [net] 10 extended confirmed users .... " (pointless to start a procedure if ten are in favour but 110 are against - so it should be a "net" 10, not a simple 10), 2) That once certified, the admin's tools are temporarily removed or relinquished (as is standard in all occupations if someone is under investigation) 3) That the same rules then apply as for a reconfirmation RfA - does the community have trust in the individual, with the same 'Crat interpretation of consensus, and the same percentage thresholds (this is a system we know and understand, it allows the community to look at the totality of the individual, and is more balanced and neutral). SilkTork (talk) 11:05, 25 February 2021 (UTC) Moving to oppose as this appears to be too problematic. SilkTork (talk) 13:40, 27 February 2021 (UTC)

103. Support Expecting Administrators to police themselves is as unlikely to work as expecting police to do so. FlailingEnglish (talk) 11:11, 25 February 2021 (UTC)
104. Support Long overdue. I have come across some abusive long-term admins and wondered how they managed to stay an admin for so long. Hzh (talk) 12:47, 25 February 2021 (UTC)
105. Support. Something like this is long overdue. The proposal is certainly not perfect but we can tweak it later. Majavah (talk!) 14:39, 25 February 2021 (UTC)
106. Support Having a policy is better than having no policy. ‐‐1997kB (talk) 15:58, 25 February 2021 (UTC)
107. Support This is a bit more onerous than I'd propose myself, but on the other hand, that will certainly keep it from being used frivolously. If the community tries the procedure and it fails, it can be tweaked once there's evidence of what does and doesn't work. And ARBCOM can always act if necessary. (Declared alt, look who created the userpage) --IamaPOVpushingSPA (talk) 17:33, 25 February 2021 (UTC)
108. Support There are rather too many sysops who think that they own wikipedia, usually citing their 'length of time on the project' as a reason for their behaviour. Having an easy way to remove them would be beneficial, surely; a way to remove them without getting bogged down in all wikipedia's bureaucracy and long-winded processes. Fortnum (talk) 18:26, 25 February 2021 (UTC)
109. Support in principle. I used to oppose such proposals, concerned about grudge-settling and feeling ArbCom could take care of real problems. But I increasingly think we need more 'community' admin accountability, and a community de-admin process is preferable to periodic tightening of the admin inactivity policy that doesn't actually address the underlying issue, which is behaviour not activity. However, a few details bug me: a) not sure 25-edits-in-6-mos is useful; b) 48 hours is too short; c) I'd leave up to bureaucrats to determine consensus to desysop rather than prescribing 60%. However, those concerns aren't enough to make me oppose or even stay neutral to something which is worth a try! Martinp (talk) 18:59, 25 February 2021 (UTC)

     Reaffirm support, having reviewed the discussion on this page since my !vote. Like Tony, my opinion has changed in the past 12-18 mos, primarily since it's clear concerns about admins deviating from good behaviour but not enough to meet the Arbcom desysop standard, are felt keenly enough to make passing RFA harder than it need to be. So I hope a reasonable community desysop procedure can actually make RFA less toxic and make the community more willing to take a chance on someone. 2nd, I'm not persuaded by the concerns about hounding, ganging up on admins, etc. Yes, it would be possible the game the system enough to start the initial stages of this desysop process. But a "hands-clean" admin really needs to pay no attention until 10 extended-confirmed users, including at least 3 admins, sign the request. That's a tall order. 3rd, as I've said I'm not keen on prescribing % for the de-RFA to succeed, but my support here is conditioned on it being consensus for desysop is needed, not consensus for retaining +sysop. I'm not categorically opposed to time-limited adminship + reconfirmation needed consensus, but this proposal isn't it. Martinp (talk) 18:33, 2 March 2021 (UTC)

110. Support The current process for removal is too complex and time consuming, since it usually requires Arbcom which can be fairly long and drawn out even at the best of times, and this seems to be a good compromise between being too easy to desysop admins and being too complicated for it to ever be used. Jackattack1597 (talk) 19:35, 25 February 2021 (UTC)
111. Weak support Certainly a good faith well thought out proposal with some good arguments both for and against. I confess to too limited a time to analyzse fully, and there might be a risk the process could be gamed or abused in which case it might need to be reviewed or tweaked. I've ultimately come down on weak support. Djm-leighpark (talk) 20:31, 25 February 2021 (UTC)
112. Support Something is better than nothing. I read all opposes and am not convinced that anyone found a fatal flaw. Having well-meaning but hot-headed admins feel threatened by a process that is more lightweight/effective than ArbCom is in my view a feature, not a bug. My two cents of bikeshedding (stuff I would like but I would certainly not withhold a support over them): (1) do not have the target admin transclude the request, that is just mean; (2) drop the admin endorsement requirements (if admins can veto an admin desysop, that creates the situation for a Croatian Wikipedia-style death spiral; replace that by 10 WP:XC-editors or similar if needed); (3) require that the AN/ANI thread finding fault was closed at least one week before and the opening of the desysop request (this allows the "mob" to cool down before handing out a second sanction; replace "one week" by "one month" or whatever if needed). Tigraan^{Click here to contact me} 21:36, 25 February 2021 (UTC)
113. Support. I am not instinctively in favor; I don’t think it will help me personally because to date I have never wanted to deal the prerequisite of hauling an admin to ANI, and I don’t think it will make standing for RFA more appealing (adding the prospect of a second gauntlet isn’t much of a sales pitch!) But consequently I think this is very unlikely to change things dramatically, and the supporters make an impression on me, so if they think it might help at the margins, I’m ok with trying. I do assume we’ll be tweaking it in six months or a year, if it gets used at all. Which is fine. Like I say, I see it as a low-risk proposition. Thank you Tony for your continual efforts to look for opportunities to improve the project. Innisfree987 (talk) 23:49, 25 February 2021 (UTC)
114. Support, as this will hopefully encourage WMF to hand desysoping to the community rather than do it arbitrarilly themselves. And, apart from that, we've needed an impeachment process for some time, and this fits the bill nicely. schetm (talk) 02:59, 26 February 2021 (UTC)

     Um... @Schetm: Could you bring the rest of us up to speed on these arbitrary desysops by the office? I'm not aware of any such activity on this project. Beeblebrox (talk) 18:29, 26 February 2021 (UTC)

115. Support in principle, with details for later determination. There are two types of reasons why someone should be required to step down from being an administrator. One, which arb com handles adequately, is gross or repeated violations of clear policy on the use of admin rights, or gross or repeated use of admin rights in such a way as to seriously violate general WP policy. The other, which is not really dealt with at all, is of failure to retain the confidence of the community. When admins are elected, both types are considered: they must know admin policy and give no indications that they are prone to violate policy in general, AND they must have the confidence for whatever reason of 65 to 75% supermajority of the community. No explicit reason need be given for a positive or negative vote, just the implication that the voter thinks they can properly do the job and has their confidence (though sometimes more specific reasons are taken into account one way or the other by the Bureaucrats, and more specific reasons can greatly influence other voters.). Much of the job of admins is following the rules in unambiguous situations, but depending on what they choose to do, it also involves judging informed community consensus in ambiguous situations. This sort of judgment cannot go by strict guidelines (if it did, there would be no ambiguous situations), and requires the general trust of people in the community that the decision will be justified and rational. Most active admin do in general retain this trust, but there will always be some who subsequently act erratically or irresponsibly or come to view their private opinions to be the consensus. People who the community thinks it cannot trust in the regard are not elected as admins. People, who after they have used their rights, the community concludes no longer have that trust or can be shown to never really have been worth of trust, should no longer be admins. Arb com is not equipped to make these judgements. Most arbs are people who are not necessarily representative of the community in all senses--nor should they be, for they are elected on they basis that they, out of all the community, are especially suited for the sort of difficult judgments needed, and their total commitment to maintaining privacy. based on my 5 years there, most arbs, myself included, can not be sure that we are really expressing the full range of community opinions--unlike admins, arbs are expected to make their own judgments, not just execute what the community would judge correct in the way that admin do.

     The only way the true views of the community can be told is by having the community in general express them, and the only fair way of judging that we accept is that of voting. Voting may or may not give the ultimate "ideal" result, but it does give the overall view of the total community of active and interested editors. And in a system like ours, which is not hierarchically dictated by an aristocracy or a government or board of directors, only that general view is what ultimately should matter.

     The reason for requiring a lesser amount of numerical support to desysop than to sysop is that no very active person can avoid having raised antagonism, and being susceptible to censure by cliques--this goes as much for admins as for arbs. What the exact percentage should be and the other detailed conditions cannot really be determined in advance--it is reasonable that we adopt this for a one year trial, and then reconsider. DGG ( talk ) 04:55, 26 February 2021 (UTC)

     Regarding your last point, about a lower support threshold. We have have several reconfirmation RfAs, all by "active persons", and they all passed easily with 75%+ support. Here are a few examples: Wikipedia:Requests for adminship/Harrias 2, Wikipedia:Requests for adminship/LessHeard vanU 2, Wikipedia:Requests for adminship/HJ Mitchell 3. IMO, as long as any type of an RfA format is used, we simply cannot accept an editor having an admin tools if they have less than 50% community support for doing so. 40% support is not community support. If the bar for retaining the tools is to be set that low, the process should not be used at all. Nsk92 (talk) 11:27, 27 February 2021 (UTC)

116. Support Overdue. I do not trust admins any more than other users fundamentally. Revoking their status in a recorded fashion is the only way the community can put admins in check. KitsuneLogic (talk) 09:02, 26 February 2021 (UTC)
117. Support. While not perfect, it represents an improvement over the existing system. RecycledPixels (talk) 17:06, 26 February 2021 (UTC)
118. Support-Conditional to upping the percentage required to remain a sysop. If we correct the wording to have a requirement of 60% for retention, not %40. We need something - ARBCOM is under-staffed for handling these things, no matter how diligent they are. I would hope this would be a safety valve to keep situations from festering over a long period until they end up involving the WMF. Also, perrhaps requiring a 60% retention will mitigate the scenario of an errant or abusive admin being rertained because they have enough friends to save their adminship. Nothing will ever be perfect, but the system is currerntly too flawed, and we need an improvement. — Maile (talk) 22:54, 26 February 2021 (UTC)

     @Maile66: Can you expand on why you feel "ARBCOM is under-staffed"? I have not seen anything to suggest it is. Stifle (talk) 11:17, 11 March 2021 (UTC)

119. Support Better than the current process and at least 10 years overdue. The community needs a method to remove admins for cause. If the community elects them they should be able to remove them the same way. ♟♙ (talk) 00:31, 27 February 2021 (UTC)
120. Support per EnPassant CanadianOtaku ^{Talk Page} 04:37, 27 February 2021 (UTC)
121. Support Should be more straightforward, but change is needed to help get rid of the truly terrible administrators. The many, many good administrators would remain unaffected. If it shakes up the mob mentality of the good ol' boys club, I support it. GaryColemanFan (talk) 06:44, 27 February 2021 (UTC)
122. More or less per Iridescent. I don't think the percentage of support needed to keep is important but it must be at least 50%+1 per Iridescent's follow-up comment. Jo-Jo Eumerus (talk) 11:33, 27 February 2021 (UTC)
123. Support This is actually pretty similar to my personal recall process. I’m a pretty firm believer that adminship is bestowed by the faith of the community, and that losing that faith means you shouldn’t have said privileges in the community any longer. It’s a privilege to be an administrator, not a right. I do agree it should be a little difficult to do, since it is a serious thing and one must have good evaluation on if the faith of the community is truly lost. Red Phoenix ^talk 16:53, 27 February 2021 (UTC)
124. Support. Making it easier to remove problematic admins will make RfAs easier to pass, because the desysop process provides a fallback in case the administrator behaves inappropriately. I believe this will result in a net increase in admins. I prefer a threshold above 60%; I believe that desysopping should be as much a consensus-based process as RfA, which means a 65-75% discretionary range. But this is a step in the right direction. feminist (talk) 16:57, 27 February 2021 (UTC)

     If you look carefully at RfAs for the last couple of years, you'll see that successfull candidates tend to pass quite easily and the process has gotten less contentious. Candidates who crash and burn at RfA now are still going to crash and burn, even if this proposal if implemented. The real problem at RfA is that the number of regular WP editors isn't growing significantly but the actual job of being an admin is getting more and more complicated and daunting. Having the prospect of a public spectacle like the one envisioned in this proposal won't make people more willing to run for RfA, quite the opposite. Nsk92 (talk) 02:09, 28 February 2021 (UTC)

125. Support Admins should be accountable to the community at large, not just to ArbCom. There are enough checks and balances in place to make me think that abuse of the system is unlikely. PinkPanda272 (talk/contribs) 18:49, 27 February 2021 (UTC)
126. Support Long overdue. Headbomb {t · c · p · b} 21:09, 27 February 2021 (UTC)
127. Supportive of the concept, but I'm not the biggest fan of how it's laid out above; it seems too complicated to actually accomplish anything. "Any user who is extended confirmed and has made at least 25 edits in the last 6 months" is too restrictive; any registered user can support or oppose an RfA so anyone should be able to initiate or vote on a request for removal. "10 extended confirmed users [...], three current administrators" is too bureaucratic. I don't understand why we would need admins to vet other admins if all but two actions are public. I could understand it if the concerns revolved around the use of the delete button, but other than that I feel as though anyone should be able to hold admins accountable, not just other admins. Further, the within 48 hours requirement is again too procedural. I can appreciate that we're trying to avoid the pitfalls of ArbCom's half-a-year turnaround on cases, but I think leaving discussions open for undisclosed lengths of time results in better discussion, especially if we're then going to proceed into a seven day RfA procedure. We may need more than nine days or we may need less. By involving RfA we've reserved at least seven days, so leave the preceding discussion unrestricted (for the most part). Anarchyte (talk • work) 09:56, 28 February 2021 (UTC)
128. support a good process but a bit complicated 007sak (talk) 11:10, 28 February 2021 (UTC)
129. support That flowchart was enough for me to grasp the process (though I think it could use a bit of work). I'd have added a thing about the admin being about to give up the bit for a while to put off the RfA during that time (maybe with a limit of 3 or 6 months) as I could see that one might well not have time to deal with an RfA in an arbitrary 2 week time period. I think the 60% needed to remove is perhaps *too* high, but I get the idea that hysteresis is needed. I might have picked 50% or 55%. Hobit (talk) 12:55, 28 February 2021 (UTC)
130. Support: I gave this a lot of thought and read every argument on this page. What pushed me over the edge was two things. First, it will be a lot easier to pass a 60%/40% process and later modify it to 65%/35% or 75%/25% than it would be to blindly get the percentages perfect the first time. Second, I have been thinking about WP:FRAMSUM, where in my opinion the W?F bullied arbcom into looking into something that they would have rejected if you or I had filed it. I don't think a community sysop process is so easily bullied, and I believe that a community sysop process gives Arbcom a good "out"; instead of just rejecting certain requests they can reject-while-suggesting-the-community-sysop-process. --Guy Macon (talk) 13:57, 28 February 2021 (UTC)

     Err, I think you need to re-read those arguments you mention again, particularly the section "It is not 60%, it is 40%" in this page. The main objection to the percentages proposed is that the 40% proposed threshold in favor of retaining admin rights differs too radically from the existing RfA standard of demonstrating community support for someone to have admin rights (65% support). Regarding Framgate and WMF, that type of situation happened exactly once in the history of Wikipedia. On the other hand, ANI/AN threads concerning admins happen all the time. The amount of drama and cliquish behavior there will increase greatly if this proposal is implemented. Nsk92 (talk) 15:20, 28 February 2021 (UTC)

131. Support. I believe admins serve at the pleasure of the community, so the community should have some direct way to dysysop a problematic admin. I support the creation of such a process, then we can see how well it works and modify if necessary.--Mojo Hand (talk) 15:31, 28 February 2021 (UTC)
132. Support: A very valid point is raised. I fully agree with it. Hindustanilanguage (talk) 16:08, 28 February 2021 (UTC)
133. Support I'm not overenamored with the specifics detailed, but on the whole it would be an improvement. Hrodvarsson (talk) 20:29, 28 February 2021 (UTC)
134. Support: We need a better way to remove bad admins. This proposal is far from perfect, but at least it is an improvement. Wikiman2718 (talk) 21:39, 28 February 2021 (UTC)
135. Support A process is needed for this, and this seems like as good a solution as any. Natureium (talk) 22:24, 28 February 2021 (UTC)
136. Support The threshold for removal is sufficiently high, and the time frame sufficiently short, that the process will not be disruptive to administrative function (such as worrying about a desysop over every somewhat controversial or bold actions). Zoozaz1 talk 00:44, 1 March 2021 (UTC)
137. Support This is the first rationale desysop process I've actually seen and it makes a lot of sense. I'm happy to see it progress to acceptance. scope_creep^Talk 16:23, 1 March 2021 (UTC)
138. Support Not perfect, but I trust will be iterated and improved over time. Legoktm (talk) 20:46, 1 March 2021 (UTC)
139. Support It's still overly complicated and so will still disadvantage all but the most experienced users. But it's better than nothing. Sysops don't serve syops. They serve the project and the community. They therefore should not be answerable only to a tribunal of other sysops. GMG^talk 21:39, 1 March 2021 (UTC)
140. Support, with a review after 1 year. There's general agreement that an alternative desysop process is desirable, and this one seems well thought out with sufficient safeguards. I expect Arbcom will still be a viable route for desysops too, although hopefully this will allow them to focus more on their original role of dispute resolution rather than having to be the admin conduct police. I'm also hopeful that the improved accountability for admins will lead to greater willingness to promote new ones. the wub "?!" 00:00, 2 March 2021 (UTC)
141. Support Balanced and fair approach. Mpajor2020 (talk) 09:09, 02 March 2021 (UTC)
142. Support, lacking a better option. Benjamin (talk) 09:33, 2 March 2021 (UTC)
143. Support Many opposes are based on the argument that we need a community-based desysop process, but that the proposal is somehow flawed (e.g. procedure too complicated). In light of the fact that we can make changes to it future as we learn and see what works and doesn't, I think that the benefits of establishing the process outweigh the costs. wikitigresito (talk) 14:05, 2 March 2021 (UTC)
144. Support provided the endorsements process is changed—requiring 10 extended confirmed users, 3 of which are admins, in 48 hours seems an unnecessarily high bar to just begin a discussion. I don't think there should be an admin requirement (since it is a smaller population of users and the precise group that's meant to be checked by a desysop procedure) and the deadline should be something reasonable like a week. I'll also be responding below, but I think other arbitrary requirements should be removed as much as possible to simplify the procedure. Making the process inaccessible, out of fear of abuse, will just delegitimize it. —Wingedserif (talk) 15:54, 2 March 2021 (UTC)
145. Rather hesistant support. My concerns expressed in the neutral section remain; briefly, I am worried about the effect on AN/ANI, and I'm also worried about wikilawyering with respect to the specific wording used. But the oppose opinions have convinced me that we're fundamentally unlikely to ever see more support for a community desysop proposal, as there's an even split between those believing this is too high a bar for a desysop, and those believing it is too low. So despite my reservations I'd rather work to fine-tune a proposal that seems to be in the goldilocks zone as far as the entire population of !voters is concerned. In that respect, I would ideally like to see some sort of moderated discussion at AN/ANI, or a clerking requirement, or something to mitigate the anything-goes culture we've developed there. Second, I'd strongly oppose any attempt to change the desysop threshold to 40% supporting removal, per Iridescent above; if we want to keep any admins working in our contentious areas, 40% is way too low a bar. Vanamonde (Talk) 16:46, 2 March 2021 (UTC)
146. Strong support. I'm not sure I love all of the details of this proposal. However, we have reached the point where any half-way reasonable proposal is better than what we have now. The only specific part of this I dislike is the AN/ANI section, but honestly, it's inconsequential prepared with everything else. We can revise the procedure later in light of more experience. I also implore whoever closes this proposal to consider the strong consensus among the community that something should be done. If this is on the edge of a no consensus close, that should weigh in favor of closing it as adopted. Tamwin (talk) 04:23, 3 March 2021 (UTC)

     That's a perfect example of the Yes Minister fallacy: "We must do something. This is something. Therefore we must do it." — O Still Small Voice of Clam 12:49, 3 March 2021 (UTC)

147. Support This seems like a good starting point to a community-based desysop process and there's no reason it can't be tweaked later. Plus, it's clearly needed. --Adamant1 (talk) 06:43, 3 March 2021 (UTC)
148. Support. The proposal seems to be a reasonable balance between formalising admin accountability by community discussion, while keeping sufficient procedural safeguards to discourage frivolous litigation. Deryck C. 13:45, 3 March 2021 (UTC)
149. Support. Good call, Tony. It's about time too! nagualdesign 17:21, 3 March 2021 (UTC)
150. Support - long overdue. Smallbones_(smalltalk) 17:56, 3 March 2021 (UTC)
151. Support with a trial period. There's only so far one can get with theoretical considerations on something like this; the proof is in the pudding. Let's give 'er a whirl, and if ANI explodes with bad faith "primer" reports or everyone is unhappy for other reasons, we back off. --Elmidae (talk · contribs)
152. Support Definitely. A balanced and easy approach. I like it. Consensus! ─ The Aafī ^(talk) 16:55, 4 March 2021 (UTC)
153. Support - it's a high standard and there needs to be a policy like this in place for the very rare instances of admin abuse (I've personally never encountered a truly rouge admin, but it's possible to imagine). The idea that 'admins need to be able to make decisions that will be unpopular' is true, but also a gross fallacy in this context. If it is possible that someone can be improperly demoted under these complex procedures, which would require approval of three admins before even being officially initiated, and then need 60% approval of the community at large, then the entire system is broken. Respectfully, I can't imagine how this would have a 'chilling effect' on any rationally-minded admin. ‡ Єl Cid of Valencia ^talk 16:59, 4 March 2021 (UTC)
154. Support A balanced approach, it will make admins more careful with their actions which is always needed for some admins. USaamo ^(t@lk) 03:33, 5 March 2021 (UTC)
155. Support --Hnsjrgnweis 10:52, 5 March 2021 (UTC)
156. Support Better than the statuus quo, and proides a platform for improvements.Tazerdadog (talk) 22:00, 5 March 2021 (UTC)
157. Support 48 hours should be changed to 72 hours, otherwise a lot of people won't even know the desysop proposal exists. I don't think this will discourage admins from working in contentious areas as I think other admins will use common sense and not support a frivolous proposal. –Gladamas (talk · contribs) 03:57, 6 March 2021 (UTC)
158. Support per above. ~ HAL333 00:20, 7 March 2021 (UTC)
159. Support - I support this as a step in the right direction. Although obviously elements of the current proposal are palpable nonsense (especially the 48 hour limit). As others have said, the chances of successfully using this process to remove a deadbeat admin must be vanishingly small. Bring back Daz Sampson (talk) 18:15, 7 March 2021 (UTC)
160. Support – This is an impressively well thought through proposal by TonyBallioni. A mechanism outside of ArbCom has long been necessary, especially for cases such as these:

     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.
     — User:TonyBallioni 18:37, 21 February 2021 (UTC)

     207.161.86.162 (talk) 03:41, 9 March 2021 (UTC)
161. Support. Better to have a flawed procedure than staying in status quo. The number of admin needed to start the process should be 2 or even 0, but I agreed that you need some admins to weed out frivolous actions. Though in that regard, long time editors should also have a right to start process, as long time editors may not be administrators, and WP:TROPHY clearly stated that admins is not a higher rank than the rest of the editors. The process would be improved over time, and despite flaws it is better than having no process and reset the whole thing the next year. At least with some flawed process we can focus on the flaws, not the whole process. As a process it is needed to weed out really bad admins. This whole process will only hurt the really bad admins. SunDawn (talk) 08:28, 9 March 2021 (UTC)
162. Support. I could quibble with details, but we need a community deadminship process and this has sufficient safeguards to not be used frivolously or have a chilling effect. Fences&Windows 00:52, 10 March 2021 (UTC)
163. Support Something is needed, not a fan of the percentages being proposed (only takes ~40% to "keep" the sysop bit if everything else is met), but this is still better than having nothing at all. And none of this precludes using Arbitration if this system fails. —Locke Cole • t • c 04:20, 16 March 2021 (UTC)
164. Very Strong Support We, as a comunity, elect the admins. We should have the right to take it away. NightWolf¹²²³ 14:47, 19 March 2021 (UTC)
165. Support a community desysop process. This one actually seems weak to me, but as others have said, it's a place to start. It shouldn't be easier to sanction an editor than to remove administrator privileges. We could also implement a process for temporary removal of admin tools. Adminship is not sacred, and losing a privilege most people don't have is not a punishment. Kolya Butternut (talk) 17:50, 21 March 2021 (UTC)
166. Support I think this is a reasonable proposal with the appropriate safeguards to address community concerns from previous discussions. Specific tweaks to the details of implementation can be added as needed, if it passes. DanCherek (talk) 01:22, 22 March 2021 (UTC)
167. Support: I have read the supports and opposes. As mentioned I also have faith in Admins and ARBCOM. The title is Requests for comment/Desysop Policy (2021) and this is where the concerns should be brought to light, and solutions offered "if" it seems (as it does) there is general support, and the move foward from there. I do see there is what appears to me to be some fear mongering. Of the +/- 45 Admins (one Steward for sure) in support, I do not see justification for, as Wehwalt put it: "Insufficient protection against a howling mob", and it does not seem to be an issue that cannot be worked out. Several Admins that opposed was in agreement that there needs to be a process (including the first 4) but have concerns. It was mentioned there was wide-spread support for an alternative desysoping procedure based on community input, but does not involve ArbCom. (Wikipedia:DESYSOP2019) that I haven't read yet. Maybe I have missed something but 10 editors can only "start" such a procedure correct? It would then go to the "community" that would not likely fall into a web of deceit because of some disgruntled editors. Having an alternate (to ARBCOM) procedure and not needing it is better than not having a community process at all. Arguments that "we have a community process" because ARBCOM is the community is not the same. It may work, and fairly well, but on the chance there is a flaw, there should be a community based resolution. We (Wikipedia) learned by a process (FRAM) that the community holds more power than many imagined over being strong-armed. There was comments from members of the WMF that were 100% inappropriate. Comments like I had seen, if made by a an Admin, would be grounds to examine if that person's actions were reason to consider desysopping. If consensus is for "considering" such a procedure then it is time to do just that, keeping in mind that some deem it "Requires substantial reworking" (SmokeyJoe) -- Otr500 (talk) 17:27, 5 April 2021 (UTC)
168. Support: we in ru.wp had a case with admin Sealle, who violated WP:SOCK, there was a consensus that confirmation/removal of flag needed, but there was no procedure except ArbCom. And ArbCom (I was among arbitrators) was not shure also — should it be confirmation or removal of flag (in our wiki violations of the rules were not harsh). It was completely obvious that the administrator had lost the trust of the community. And an administrator without the community's trust is a source of decisions that will be challenged simply because he has lost trust. We in ruwiki decided that there must be some kind of out-of-arbitration procedure for removing the administrator flag ru:ВП:Г-КОНФ: 76 % was for that. We also then conducted a survey, gathered a group to summarize it and established that the administrator flag should be confirmed by voting, that is, in the same way as this flag is obtained. ru:ВП:О-КОНФ2. Where the discrepancies have arisen is in the mechanism for launching confirmation. Should this be done by an initiative group (potentially a conflict-generating mechanism) or should it be done regularly (for example, every 5 years, but a lot of unnecessary fuss anyway). Opinions were divided, now we are looking for additional approaches to this problem, for example, a simplified launch of confirmation through ArbCom under certain conditions or some kind of "court of honor" / "code of conduct" for administrators. ·Carn·!? 14:27, 14 April 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)

   Also oppose using WT:RFA as a noticeboard, if these need to be on RFA they should be on a new section of WP:RFA. — xaosflux ^Talk 15:12, 25 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)

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)

    The big flaw with RfCs such as WP:DESYSOP2019 is that they imagine that a desysopping process can be created that is superior (or at least not inferior) to the current process (i.e. Arbcom). When a process is formulated, a nasty realization occurs; that it is almost entirely inferior to the current process. And to compete with the current process, the formation of an Arbcom-like body would have to be considered, which would be essentially pointtless, The "proof is in the pudding" so to speak, and this pudding leaves a nasty taste.--Jules (Mrjulesd) 11:56, 25 February 2021 (UTC)

    Except that's not what folks are saying. Whether it's "solution in search of a problem" or We already have a community desysop process: and its called Arbcom!, neither indicates any comment beyond "I didn't want it in the first place." Opposes saying it is almost entirely inferior to the current process are great, but, as an example, I see no judgment on the current proposal in your opposition, just opposition to its very existence. ~ Amory (u • t • c) 14:36, 25 February 2021 (UTC)

    Point taken. But my point is that you can have RfC like WP:DESYSOP2019 for a "communiy desysop process" (as if it doesn't exist), but unless you provide details of an actual process they're moot, because what if a satisfactory non-committee process doesn't exist? But if you want some concerns please see User:Hammersofts contributions, especially File:2021DesysopProcessFlow.gif. --Jules (Mrjulesd) 14:50, 25 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)

    I liken a community desysop to the removal of a State Rep from the US Congress for unethical behavior via general election vs removal by the Committee on Standards of Official Conduct - at least, there are some very close parallels. Atsme 💬 📧 11:32, 24 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)

    @TonyBallioni: I'm not sure if you saw my question above. -- RoySmith (talk) 14:51, 3 March 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 4 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)

    Adding a fourth reason - at present, candidates at RFA can choose the time of their nomination, to be a week when they are likely to be availble to answer questions, and can deal with any stress that occurs. With a de-sysop procedure, the candidate would have no say in this, other than a 14 day window. They may even be on holiday or on a wikibreak during this time. Indeed, some users may even game the system to force the issue if the knew the candidate was unlikely to be able to respond well. This would lead to the candidate for desysop being unable to defend themsleves properly. — O Still Small Voice of Clam 11:15, 25 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) ETA: I'm seeing a lot of comments along the lines of admins should be responsible to the community, not to ArbCom, and ArbCom doesn't represent the community, but ArbCom members are elected by the community for this purpose (among others). More than 1700 editors voted in the last ArbCom election, far more than are likely to participate here, and all the elected candidates got at least two-thirds net support. Espresso Addict (talk) 01:14, 28 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 an 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)
51. Oppose (moved from 'Neutral') per Hammersoft and comments by Atsme and DGG. Kudpung กุดผึ้ง (talk) 01:56, 24 February 2021 (UTC)

    Kudz, I think you may have been onto something relative to the bureaucrats - I think they should elect (among themselves) a 9 member Ethics Committee for hearing only admin cases - admin complaints go to them, period, the end. Atsme 💬 📧 11:43, 24 February 2021 (UTC)

    We don't need more committees or bureaucracy, please. Bureaucrats aren't chosen to deal with admin complaints - ArbCom are, annually. ProcrastinatingReader (talk) 11:56, 24 February 2021 (UTC)

52. Oppose - Arbcom is an existing community process and although it is difficult and lengthy, so is RfA. The community lacks admins and this seems to be an unnecessary shortcut that may encourage their loss for possibly frivolous reasons, or by canvassing efforts. —PaleoNeonate – 05:35, 24 February 2021 (UTC)
53. Oppose - Per Hammersoft, essentially. --Jack Frost (talk) 08:53, 24 February 2021 (UTC)
54. Oppose Joe Roe makes some solid points above. The ArbCom is doing a good job desysopping problematic admins. This proposal looks like an attempt to contain ArbCom's power. Indeed, as Wbm1058 shows, TonyBallioni himself used to be strongly opposed to community desysop. Forgive me for assuming bad faith, but it seems as if Tony is more interested in putting ArbCom in a cage and not concerned about abusive admins. The requirement of 60% support for desysop is way too high – put another way it allows retention of adminship with just 40% of community support. Even Fram had as much as 47% support — if this process had existed back then, the ArbCom would have likely deferred the desysop-or-not question to the community and Fram would have continued to be an admin. The proponents appear to say that the ArbCom desysop process would be independent of this process – but really? Rather, ArbCom would start asking themselves the question "is he/she likely to have 40% community backing?" in deciding desysop cases – which would lead to fewer desysops overall; and they would be entirely right to do this, because otherwise it creates an unfair asymmetry of one process being more difficult than the another. At requests for arbitation, there will be comments like "Decline please, the community can handle desysops". I suspect this would put an end to ArbCom desysops. – SD0001 (talk) 09:32, 24 February 2021 (UTC)

    That's a very good point that a community desysop process will likely mean an end to Arbcom desysops. Arbcom members will, I'm sure, be only too happy to handball any desysop request to the community for resolution once such a process is established. Gatoclass (talk) 10:42, 24 February 2021 (UTC)

55. Oppose for many reasons I will explain, but want to note only commenting here because the RfC showed up as a banner on my userpage. My oppose is based on the fact that the proposal is supposed to address the following concerns:

    • 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

1) This proposal appears to be just as difficult as an Arbcom process for an ordinary editor because even with the very low editing requirements of 25 edits in the last 6 mo's, it would be nearly impossible for an editor to get a closing statement at AN/I against a popular admin that just says they, "behaved inappropriately" without getting boomeranged. In order to get that kind of closing statement at AN/I, they would need evidence of egregious behaviour, in which case they would not need AN/I since they would have sufficient evidence for ArbCom.

2) The idea that admins might face harassment is a fear-based argument that has no basis in reality. If there were hordes of invisible enemies waiting to pounce, then they would have amassed themselves at the previous discussions such as the one in 2019, as well as this one.

3) If the process has worked before in other systems[projects], then there is evidence that it does work, but nothing in this proposal appears to have anything at all in common with what we know works in the other systems[projects].

4) As far as the rest of the requirements go, they feel too creepy to me, which, does not address that issue of being any easier than ArbCom.

5) Our current threshold for allowing an editor to attain admin status is 65%. What this logically means in proportionally inverse terms, is that the community has consistently determined any editor who has done absolutely nothing wrong is unfit to hold the tools if only 35% deems them unworthy. This proposal is essentially asking that any admin who has been accused of wrongdoing, and whose community trust has come into question, should somehow be privileged to have an absurd threshold of 60% before they are deemed unworthy? Huggums537 (talk) 09:38, 24 February 2021 (UTC)

6) Also adding that I oppose the part, Users commenting must meet the requirements for filing a desysop request to support or oppose... because any form of limiting the community on being able to participate is contradictory to the idea of what the very definition of a community desysop means. That is not community desysop, that's "members only" desysop. Huggums537 (talk) 22:50, 26 February 2021 (UTC)

Just for explanatory purposes, and in case I didn't say it right, what the proposal is essentially saying is;

If 35% of the community can deem an editor unfit to hold admin tools for doing nothing wrong,

then we should write it into policy that it shall take 60% of the community to deem an editor unfit to hold the admin tools when they are accused of wrongdoing, or their community trust comes into question.

Does this really actually sound reasonable to anyone? Huggums537 (talk) 10:14, 24 February 2021 (UTC)

"Reasonable" depends on the context of your question - reasonable as compared to what? This also to brings to mind Asch’s study, and conformity. Consensus is not/should not be about the numbers. There may very well be a situation where 10% of the participating editors have provided extremely strong evidence that others may be dismissing because of alliances or popularity of the admin in question, or equally as bad, conformity. We don't want the community or even an "ethics committee" to say, well that's a popular admin, there's a lot of peer support, we should not desysop. It may also be decided that a probationary period would work for a first offense so there are other options for a committee to consider. ArbCom should not be thought of or as the grim reaper.💀 Atsme 💬 📧 14:17, 24 February 2021 (UTC)

The the Asch conformity experiment is one of my favorite among the "classics". Thanks for sharing. Huggums537 (talk) 15:07, 25 February 2021 (UTC)

56. Oppose, mainly per Huggums537 (moving here from Neutral). I still have the concerns expressed in my earlier Neutral comment, but upon further reflection, I find the proposed system unworkable, particularly because of issue 5) raised by Huggums537. The 60% requirement is ridiculous. We have a well established standard for demonstrating community support that a user should have admin tools: 65% support at RfA. We should use the same or a similar standard for seeing if an admin whose continued suitability for adminship came into serious question still has the community support to be an admin, once a recall effort has been properly certified. With the 60% requirement you couldn't really desysop anyone except the most egregious cases, and for those cases it will be much faster and easier to go to ArbCom. It will be a community desysop process in name only. It will either not be used or used with the purpose of not really desysopping someone (even the most unpopular admins can usually master 40% support) but just making someones life difficult and unpleasant. The system will fuck up ANI even more than it already is and likely destabilize the existing ArbCom desysop process. That's not the way to increase admin accountability. If something like this proposal were to be tried at all, it would need to be on a probationary basis, say for 1.5 years, with another RfC required after that, to determine if the system should be scrapped, reauthorized or modified. Nsk92 (talk) 12:52, 24 February 2021 (UTC)

    I hope that everybody will read carefully the oppose of Dennis Brown (currently number 83 in this column). He raises several key problems regarding the idea of a community desysop as such, and to me these objections are even more important than 60%-40% issues. I endorse every word of what he says there. Nsk92 (talk) 00:46, 28 February 2021 (UTC)

57. Oppose: It doesn't seem to me that the current ArbCom processes are demonstrated to be deficient and in need of remedy, and the evidential basis for this proposal, if enacted, seems likely to lead to negative consequences at AN/I, with the possibility of extended skirmishes and attrition over concluding cases. AllyD (talk) 14:29, 24 February 2021 (UTC)
58. Oppose – This is a solution in search of a problem. We already have a mechanism for removing administrators for misconduct – it is evidence-based, it has better protection against a mob mentality, and its decisions can be appealed to the community. This proposal just creates a duplicate, inferior process, and would thereby weaken the one we have. – bradv🍁 15:23, 24 February 2021 (UTC)
59. Oppose - In addition to agreeing with many of the arguments made above (especially those by Hammersoft and Mz7), I fundamentally think that this sets a bad precedent. The process is too susceptible to manipulation by a small group of users. While I don't think de-sysops would be happening all the time with this system, I think the amount of de-sysop attempts would shoot up and waste a lot of time for everyone involved. It could have a chilling effect on admin actions. We are always looking for more admins and more administrator activity. We have a procedure in place for removing bad admins already. This proposal won't lead to any improvements to the encyclopedia. Ganesha811 (talk) 16:03, 24 February 2021 (UTC)
60. Oppose - I try to avoid bringing or participating in ANI discussions, let alone ArbCom. But my read of this is that this makes things worse. The proposal doesn't identify a discernible problem. At best I can see a general justification that ArbCom is slow. But this proposal isn't faster so much as it has less consensus-building and fact-finding, which are two principles I see as fundamental to Wikipedia.

    I do think that our accountability systems are flawed. We are good at the edge cases -- we call out the egregious, and we tolerate the tolerable. But I've seen a number of people who are forgiven for pushing the envelope over and over, until they finally step on a political landmine and get blocked. It creates months or even years of disruption before the problem is addressed. An ugly component of that will be the factionalism and WP:BATTLEGROUND mentality at conduct discussions. For many conduct issues, you will see two factions fighting over an all-or-nothing solution, an instant block versus complete amnesty on the basis that the bad conduct was only an emotional reaction to people who want them blocked. I can't tell you how incredible stupid and frustrating that is to watch, and I'm thankful I avoid these discussions. But the all-or-nothing approach leaves a massive exploit in the middle, where you can vaguely be a dick as long as other people have been a dick to you, usually bolstered by your more passive aggressive dick friends.

    The easiest solution would be to start being far more liberal with warnings. Yes, warn an editor for making snarky unproductive comments. Warn an editor for commenting on other editors instead of content. Warn both sides of some disputes (though the warnings should be specific, as bad conduct is never the same on both sides). What this would do is (a) draw a clear line each and every moment that something unproductive happens instead of shrugging it off until it becomes truly destructive, (b) use escalating warnings to make editors acknowledge their problematic behavior and push them back towards collaborative editing, (c) stop using blocks or other sanctions as a primary remedy, which would also (d) disempower factions who hope to "catch" or "bait" someone into getting blocked, and (e) leave a super clear trail of warnings wherever you have a pattern of unrepentant bad conduct, as those behavior patterns are the real thing that we want to weed out.

    I suppose there's a better place for me to raise this as a solution, but I see this as entirely on topic. A lot of people keep trying to resolve this by making it easier to sanction people, but I think we need to make it easier to create a trail of fact-finding. Not just for an eventual sanction, but for the editor in question to reflect on their behavior and discourage them well before it becomes a disruptive pattern. I imagine it would work just as well on admins as on anyone else. Shooterwalker (talk) 16:47, 24 February 2021 (UTC)

61. Oppose. I don't usually come in from the trenches to vote on things like this, because when you work on content a lot you don't have time for drama, and in fact I wasn't aware of the discussion two years ago. I got notified for this one, though, and after looking things over I do not think it wise. Well-intentioned, I agree, but unwise no less.

    For the broad case against it I do not think anyone can add to Hammersoft's arguments, but there is another issue that I have only seen one oppose !vote here touch on: the effect this will have on our other forums for resolving these issues.

    I don't always agree with Sandy, but she is dead on here that this will not work in the sense that it is unlikely to bring any abusive admins to heel, and consequently IMO in a few years we will be hearing complaints that this "RFdS", or whatever it will be called, is "broken" by people who will not be able to bring themselves to the realization that it was born that way since they weren't part of this discussion and won't want to dig deep into it to see !votes like these which predicted those very issues. And since they would be the sort of people disinclined to consider that ArbCom might just be working, at least better than they think, they'll just be more likely to fall deeper into despond, edit less, and then quietly leave.

    As for the rest of us ... well, I agree with Sandy that the likelihood of swift AN/I closes could go up, that's one thing that could certainly happen, but it won't be the only effect this procedure would have over there. Frankly, I see this procedure as leading to even more AN and AN/I threads than we currently have over this, which will of course inevitably lead to even more ArbCom requests than the committee is already considering (and that's not even bringing in AE), which they'd probably say is more than enough and who are the rest of us to disagree with them? And, of course, the heated discussions this process will naturally produce will lead to yet more and more numbered difflinks in these threads for anyone trying to resolve whatever there is to resolve there to peruse.

    In short, this proposed process will be a net detriment to the project, and serve only to make more complicated what already has a tenuous relationship with simplicity. Daniel Case (talk) 20:04, 24 February 2021 (UTC)

62. Oppose: While I certainly think that a community-driven procedure for revoking adminship is needed, I do not think that it has to be this complicated. My personal views tend to be that if there is consensus for something to happen, it should. Similarly, if there is community consensus to revoke admin rights, that should happen. The ArbCom process is not perfect, and a community process to supplement it would be welcome, but this proposal has too many issues (as mentioned by others) for me to support it. — Twassman [Talk·Contribs] 20:58, 24 February 2021 (UTC)
63. ’’’meh’’’ this process is too convoluted to hold bad admins to account and you can bet your life that the conditions to be met will never be achieved for powerful admins with lots of friends willing to close discussions with neutral conclusions. I foresee stupid arguments about whether fault should be ascribed or closes being reverted and warred over etc etc. Is this going to hold abusive admins to account? No! So either make the process achievable or don’t put the community through any more unnecessary drama. Spartaz ^Humbug! 21:26, 24 February 2021 (UTC)
64. Oppose. (1) It would be a vote of no confidence in Arbcom which I don't believe it deserves. (2) I support User:Hammersoft's well considered rationale. Moriori (talk) 00:16, 25 February 2021 (UTC)
65. Oppose - with respect to the proposer, personally I don't see how a process with this many extra steps and arbitrary minimum qualifications and requirements to post notices in so many places would be an improvement over just writing out evidence in an Arbcom request. I share the concerns about harassment (you can read what I wrote two years ago about this point specifically) but that's going to be the case with any community-decided desysop process, so let's not dwell on it. My concerns with this proposal specifically are all the extra bureaucracy for no benefit, and that the arbitrary thresholds are much too low. The 2003 California gubernatorial recall election required 12% of the previous election's voters to certify the recall; it's fair to say that an average successful RFA attracts about 200 electors (see User:Ivanvector/RFA statistics#Table 2: RFA participation), which would make a fair threshold two to three times higher than what is proposed for certifying an admin recall. That's really just a statistic; I'm much more concerned about this creating a way for bad actors to pay to remove admins they don't like, or at least to create headaches for them, and I don't think that there's any way for a community desysop process to mitigate that concern. I agree that Arbcom is too reluctant to consider cases of admin accountability, especially "loss of confidence" cases, and we should be talking about addressing that in a way that the community can compel Arbcom to consider cases where something like an ANI discussion has resulted in an admonishment or referral, but leaving the ultimate decision to the body we elect and trust to carefully consider evidence and make rational decisions (and we also have WP:LEVEL1 and such); you know, the way that this has worked just fine for 20 years. That way, you don't get 50 users at ANI calling for an admin's mop and Arbcom just not doing anything about it, but you also don't get a mob of nationalists brigading an admin who won't support their POV war. Ivanvector (^Talk/_Edits) 00:33, 25 February 2021 (UTC)
66. Oppose To be blunt, we shouldn't be creating a new process that's harder to use than the existing process. If I'm not mistaken, all that is required to file an ARBCOM case is either a note on a project talk page, or a direct edit to the case request page if you are a confirmed user. All of the restrictions and prerequisites that are being proposed here are much greater than what is required to initiate an Arb case request. Any new process to supplement ARBCOM should be easier to use, not harder. — Preceding unsigned comment added by 192.196.218.211 (talk • contribs) — 192.196.218.211 (talk) has made few or no other edits outside this topic.
67. A solution in search of a problem. No. ◦ Trey Maturin 03:51, 25 February 2021 (UTC)
68. Oppose I would strongly support a new deysop procedure, but not this one. Admins are simply just not held accountable right now. To all those complaining that admins would be harassed if a community deysop were allowed, I have little concern about this. What I'm more concerned about is editors being harassed by admins and having little to no recourse. I myself have been subject to administrative harassment. However, this current proposal is so convoluted that it would be nearly as difficult (and perhaps more so) than the only current process. It requires a minimum of three separate discussions with all sorts of time limits and hurdles of getting support for a large numbers of different types of users. A better proposal would be two steps: An active extended-confirmed editor open a discussion that provides evidence (diffs) and gains support from a minimum of 10 other active extended-confirmed users (and they don't have to be admins). At this point, the formal discussion is created, the entire community is notified, and the admin can be removed by a simple majority. An additional proposal that I would support would be to make every admin goes through a new RFA every 4 years.--Rusf10 (talk) 04:16, 25 February 2021 (UTC)
69. weak Oppose I think Hammersoft explains the issues well. As an arbitrator, I feel that the committee is the entity best-placed to review admin conduct, although for some reason that message is lost and instead we have (in my view fallacious) view that there is no way to remove tools, which in turn leads to stricter voting at RfA etc. I don't think it is a terrible idea, but I have concerns over its ability to offer a more structured or nuanced review than currently exists at AN/ANI. Cas Liber (talk · contribs) 05:02, 25 February 2021 (UTC)
70. Oppose. This seems like a recipe for mob action after any difficult decision, making hard cases all that more difficult. Tarl N. (discuss) 05:17, 25 February 2021 (UTC)
71. Oppose with regret. There are just too many problems that have no clear safeguards to support it with a clear conscience. I will not repeat them as they have already been listed above and discussed below by several people. If the strength of logical argument is considered by a closer, it should not be necessary to repeat them. If the closer is counting votes, this is mine. I recommend that the issues raised be considered and where necessary, addressed, and an amended proposal made. Perfect may be the enemy of good enough, but I do not think this process will be good enough as proposed. — Preceding unsigned comment added by Pbsouthwood (talk • contribs) 05:44, 25 February 2021 (UTC)
72. Essentially per Guettarda, Useight, Hut 8.5, and Mz7. GAB^gab 16:47, 25 February 2021 (UTC)
73. Oppose While on principle, I'm of the opinion that if the community makes admins, the community un-makes admins. However, unless I've grossly misread the proposal, this proposal allows for admins to heavily stack the confirmation process in the first 48 hours. That's before the 2-week discussion about whether or not they should remain an admin. Furthermore, as these proposals must be placed at AN or ANI, it will inevitably be admins that first pick up on any such proposal. I'm afraid that this might result in a possible conflict of interest - admins naturally are expected to have closer collaboration with each other, and therefore may not be as disinterested a party as non-admins. I'd like to see an amendment that removes the 3 admin concurrences to desysop. BrxBrx(talk)^{(please reply with {{SUBST:re|BrxBrx}})} 16:57, 25 February 2021 (UTC)

    Not sure what you mean by "stack" the process in the first 48 hours: do you mean that more than three admins can choose to certify the request? Since only certifying opinions are being requested, it's not possible to stack the vote against certification. Although personal conflicts of interest is a reasonable concern, I don't think the venue plays a role. isaacl (talk) 17:28, 25 February 2021 (UTC)

74. Oppose per my original support comments. I guess I want to convince myself to support this, but I can't shake off the feeling that this proposal will make things worse. In particular, this proposal requires 40% community support to keep the rights (which is very low) (see SD's oppose comments). I also suspect ArbCom is going to start looking for more reasons to decline cases if this passes, especially if an editor has already been through the process under this proposal (and, say, ended up with 45%). If that's the case I think this proposal would actually be a net negative. An explicit mention of the relationship of this process in relation to ArbCom in the proposal text might've relaxed my concern, but it not being codified is worrying to me. Plus, there's the double jeopardy issue and the processes are likely stressful for the admin, too. ProcrastinatingReader (talk) 22:49, 25 February 2021 (UTC)
75. Oppose I am generally supportive of the notion of community desysopping, but I have many objections to the details: 1) The recent edit eligibility requirement is not useful. 2) "Behaved inappropriately" is too vague. 3) An admin might be unable to answer the request for 14 days due to personal issues. Perhaps we can say that admin permissions will be automatically removed if they don't respond in 14 days, but they may choose to run the recall election any time in the next year and will have their bit restored if they survive the election. 4) 60% is too high, if an admin loses the support of a simple majority of editors, they should no longer be admin. -- King of ♥ ♦ ♣ ♠ 04:37, 26 February 2021 (UTC)
76. Oppose I find myself here not because I oppose the principle, but I do not think this proposal serves the community well. I am quite concerned about the "angry mob" problem that can develop (already there are many who think RfA is contentious, this process will only make it more so), and good admins may just pack up their bags and other may not want to engage in the more difficult admin problems. While I don't think there is necessarily another way outside of a contentious community forum, we should tighten up the criteria for a recall effort. My preference would be to have two bureaucrats decide if there were sufficient grounds for the effort, rather than three administrators. --Enos733 (talk) 05:15, 26 February 2021 (UTC)
77. Oppose. Let's be fair: while a community-based desysop procedure is needed, this system suffers from two-three serious defects that are likely to prove significant impediments from this procedure from becoming very practical. The first is the "angry mob" problem; the second is the fact that many admins (and for that cause most established editors) tend to have several "friends", so to speak, and likewise some users who don't like them: this is likely to influence the results of the desysop request. Thirdly, having an explicit 60% level violates WP:NOTVOTE: we are not voting, consensus is necessary in this request. JavaHurricane 06:24, 26 February 2021 (UTC)
78. Oppose. This process appears to be at least as difficult as desysopping via ArbCom, and in my view more likely to result in harassment towards admins who make tough calls. I don't think this proposal achieves the specified goals. GorillaWarfare (talk) 20:31, 26 February 2021 (UTC)
79. Oppose. One of the main issues being addressed by the WMF de-sysopping seemed to be admin rudeness driving away new editors. If this process excludes such editors, how is it useful in addressing such an issue? Otherwise, I don't see the admin corps as needing to be reined in: usually, they are knowledgeable about policy, careful about applying it, and amenable to reproof when they overstep (I was impressed by how calmly the recent targets of the WMF process made their cases and how quick to see that it was all for naught). This process is short on giving rationales (why 10 extended-confirmed and 3 admins?) and seems needlessly complex. Dhtwiki (talk) 02:20, 27 February 2021 (UTC)
80. Oppose. I support the general idea of a community desysop, but the details of this one are too problematic. I feel we need to work on getting the details right first. SilkTork (talk) 13:42, 27 February 2021 (UTC)
81. Oppose ..... my opinion on this issue has been the same before my adminship, during it, and after my own desysop ... existing processes for desysop are sufficient and the threat of a re-RFA will only add stress to an already stressful volunteer position. —Soap— 23:25, 27 February 2021 (UTC)
82. Oppose I agree with certian points that Hammersoft has raised. I would really like to support a community de-sysop proposal, but I feel the problems outweight the benefits. The importance of a community led de-sysop process is important, as the relationship between arbcom and the community should be such that arbcom is presented with the issues which the community has been unable to resolve using the processes and routes avaiable. This is the case for most issues where ANI / AN discussions happen which propose and can deal with problems and I don't see why this then can't be the case for de-sysops (such that a de-RfA process would be a route). However, this proposal has several issues which for me lead me to oppose, especially around the 60% support to remove mark which I think does not relate well to a RfA. In a RfA, there is the discresionary zone which crats can use the crat chat to decide assess consensus. Any de-RfA process shouldn't be too disimilar to a RfA, so having a crat chat does not seem a bad idea. Further, the AN thread may not be closed as not all are, so this could lead to reconfirmation RfAs which should go foward not going foward. Also an AN thread may not also be closed well, and such there should be an avenue to discount bad closures. Dreamy Jazz ^{talk to me | my contributions} 00:16, 28 February 2021 (UTC)
83. Oppose (moved from neutral) - I've had some time to think about this, and again, I've been down this road proposing similar policy in the past and watching many others do the same. In short, Arb just isn't that busy and if anything, they have shown they can act fast (or sometimes too fast) at removing the admin bit. As for the complexity of filing an Arb case, I find that a hollow reason. When there is support to get an admin desysoped, there are always plenty of people who can fill out the paperwork rather quickly, or help you. Plus, it isn't that hard and if you do it wrong, the clerks will help clean up the request. The actual evidence section (which matters most) isn't that different than ANI, so really, it isn't that different. What is different is the pace, and the structure and a set of rules that makes the event less drama and more investigative. The more I look at this idea (and other similar ideas), the more I feel the idea of a community desysop method is out of date. Arb is more open to input and has a much lighter load, it is probably the best choice for handling requests, as the decision makers are themselves chosen by all the editors here for precisely issues like desysopings. Dennis Brown - 2¢ 00:18, 28 February 2021 (UTC)
84. Oppose I agree with the general principle, but I do not agree with the proposal. I'd rather a scenario where the community petitions Arb for a desysop. SportingFlyer T·C 00:47, 28 February 2021 (UTC)
85. Oppose Condition #2 is too arbitrary. It depends more on how many people see the request in a specific time frame than on the severity of the infraction. ~EdGl talk 01:37, 28 February 2021 (UTC)
86. Oppose. Like others, a removal process may be worth pursuing, but this proposal isn’t it. It would just be trollfest bait for anyone who gets appropriately called on their behavior. In theory, a request for desysop should at least require multiple filers and perhaps a extensive vetting process. Montanabw^(talk) 01:49, 28 February 2021 (UTC)
87. Oppose While not a bad effort, this proposal doesn't seem workable. The process for activating it doesn't 'feel' right as the bar for editors who can initiate desysops is too low. This will lead to admins being harassed by bad faith requests for desysop (25 edits in 6 months is not the definition of an 'editor in good standing'). The requirement for three admins to endorse the proposal makes sense though. The requirement that admins be forced to transclude their own request for desysop is very poorly considered - if the criteria are met, this should be automatic and handled by a trusted editor like an ArbCom member or clerk rather than forcing the admin to do what could be a distressing act for them. Nick-D (talk) 10:15, 28 February 2021 (UTC)
88. Oppose The goal for a desysop policy is not a bad one, but I do not agree with the details and specifics provided here unfortunately. Garnarblarnar (talk) 15:40, 28 February 2021 (UTC)
89. Oppose In principle I agree with the proposal. I take issue with its mechanics which, in my mind, don't provide us enough safeguards against misuse. At a minimum I'd want to see point three amended to read "within 14 days of their last edit since certification or resign as an administrator". However, there are enough other loopholes that could be exploited here that even this amendment would be insufficient to swing me to the support column. Again, though, I do appreciate the spirit of the proposal. Chetsford (talk) 19:58, 28 February 2021 (UTC)
90. Oppose While I believe that this was proposed wit good intentions, I think that this will make it way too easy to purge admins that people don't agree with. The RfA process is already hard enough to pass in the first place, I think that there should be further reqs to desysop an admin. Andrew nyr (talk, contribs) 20:48, 28 February 2021 (UTC)
91. Oppose While I support a process to desysop a wayward administrator that doesn't take months, I think 60% approval is too low. I think the percentage approval to desysop should be in the same range as a successful RfA, with bureaucrats making the final decision on close calls or within the discretionary range. I also think the process should last two weeks, basically, like a RfA in reverse. Being removed as an admin should not be easier than the process of becoming an admin and I think any active admin who has made a few unpopular decisions could easily reach 50-60% disapprovals from the noticeboard crowds. Participants in a Recall should have the same bar as participants in an RfA. While I oppose some of the specifics of this proposal, I do support a streamlined process of desysoping an admin. Liz ^{Read! Talk!} 21:55, 28 February 2021 (UTC)

    I'm starting to realize that what everyone really means by "reverse RfA", is really just "do another RfA". What puzzles me the most is how some people seem to think an admin who had the tools, but blew it by some kind of wrongdoing or loss of community trust should have the same bar as an RfA of someone who did nothing wrong. I'm still tryna wrap my brain around that one. It was my impression "the noticeboard crowds" were usually a bunch of admins and other "friendlies" just as well as community members... Huggums537 (talk) 01:56, 1 March 2021 (UTC)

    Since a review of the candidate would include reviewing any past missteps, participants would include them as part of their assessment. Any desire for additional evidence beyond what is ordinarily sought is baked into the weighing made by the commenters of the pros and cons. isaacl (talk) 02:46, 1 March 2021 (UTC)

    I see the point you are trying to make, but it's still a False equivalency because I bet my bottom dollar there's never been an RfA candidate who had a pending AN/I case against them. Huggums537 (talk) 03:24, 1 March 2021 (UTC)

    I'm not sure what you're thinking I'm making equivalent. When participants decide if a candidate is sufficiently trustworthy and otherwise suitable to have (or continue to have) administrative privileges, they'll weigh if the pros outweigh the cons. They'll consider any raised issues whenever they happened—recently, six months ago, a year ago—and factor them in. isaacl (talk) 03:33, 1 March 2021 (UTC)

    Hypothetically, you're taking an admin accused of wrongdoing, who presumably has a current AN/I desysop case against them, and trying to make that equivalent to a candidate for RfA by giving them the same procedure, bar, and criteria, except you can't equivocate equate the two because an RfA candidate would never be allowed to participate in an RfA if they had a pending AN/I case against them. So, theres no reason an admin accused of wrong with a pending AN/I be given the same bar, or even given another RfA at all when other candidates aren't even allowed to participate in RfA if they have a pending AN/I. Huggums537 (talk) 04:59, 1 March 2021 (UTC)

    I'm not saying the two candidacies are equivalent; I'm saying people will evaluate candidates on the basis of all available information. Anyone can submit a request at any time. If there's an open discussion at the administrator's incidents noticeboard, that will get factored in. If the request gets rapidly closed due to overwhelming dissent, so be it. Participants will automatically adjust their standards when putting forth their views. isaacl (talk) 05:13, 1 March 2021 (UTC)

92. Oppose, a solution in search of a problem. This proposal gives the impression that someone wants to get rid of an admin and thinks it is too hard. How many active admins do we have? 500? If anything, we need to make it easier to make people admins.--Berig (talk) 08:01, 1 March 2021 (UTC)

    I'm sorry, but this almost just reaches the cusp of coming off as being like an unsubstantiated claim against the nominator of this proposal, which doesn't provide any evidence that there's been any AN/I closures against another admin whom they've opposed in the past 6 months that I'm aware of. That is the kind of evidence you would need in order to come to that kind of conclusion. Please be careful what you are suggesting, even if it might be unintended, unless you have some kind of evidence like that. Thanks. Huggums537 (talk) 16:30, 1 March 2021 (UTC)

    I think maybe this editor really meant no harm by their comment, and was just trying to express an opinion. Striking my comment accordingly. Huggums537 (talk) 17:20, 1 March 2021 (UTC)

93. Oppose, I see no reason to believe here that ArbCom is unwilling to desysop admins when necessary. As Bradv stated above, that process is evidence-based and deliberative, and that's how it should be done. Seraphimblade ^{Talk to me} 14:53, 1 March 2021 (UTC)
94. Oppose because we need more admins, not fewer, and this process would fix what isn't broken. Jonathunder (talk) 15:49, 1 March 2021 (UTC)

    Of course it is broken. It is absurd to say such a thing. Why is it in process, if it wasn't broken? scope_creep^Talk 16:28, 1 March 2021 (UTC)

    There is a wide variety of opinions in this oppose section, but a significant proportion is opposing because they don't think the current process needs fixing, so it is unfair to dismiss this concern as "absurd". Mz7 (talk) 17:21, 1 March 2021 (UTC)

95. Oppose Basically everything said above. We need more administrators, not fewer. Arbcom is a much better venue to deal with administrator misbehavior. This just stinks of "mob justice". The threat of this could lead to chilling effects on administrators willing to work and make difficult calls in controversial areas. IronGargoyle (talk) 01:00, 2 March 2021 (UTC)
96. Oppose per most of the above. But I will make two specific observations. First, this appears to be a solution in search of a problem. Secondly, no credible argument has been offered for why ARBCOM is, or should be seen as, incompetent to deal with allegations of Admin misconduct. And if ARBCOM is not incompetent, then what are we doing here? -Ad Orientem (talk) 01:12, 2 March 2021 (UTC)

    @Ad Orientem: AFAICS, the question is not about ArbCom being unable to deal with the problem as it is more of something that could be taken off of ArbCom's hands, or at least this would reduce their workload in this area (since ultimately, the argument goes, admins are accountable to the community, which elected them). Whether that addresses other issues and concerns with the proposal is another matter. Cheers, RandomCanadian (talk / contribs) 01:36, 2 March 2021 (UTC)

97. Oppose. This is too much of a "one-strike" policy. Desysoping should be based on an egregious breach of trust or a long term pattern of incompetance. The proposed policy above sets the bar too low for removal of admin privledges, effectively allowing for removal with just one mistake. A mistake, especially on a site whose rules and policies are in constant flux, can and should be forgiven. I think Arbcom already works well enough for desysoping. If anything, effects to improve desysoping should revolve around streamlinging and expediating that process. Jason Quinn (talk) 02:06, 2 March 2021 (UTC)
98. Oppose. Arbcom is incompetent but adding new trollbait processes does not help either. jni^{(talk)(delete)} 07:02, 2 March 2021 (UTC)
99. Oppose, yet again, we have a solution in search of a problem. We need more admins, not fewer, and giving people with axes (or should that be swords of Damocles?) to grind a venue like this will simply mean admins will be further discouraged from handling anything remotely controversial.
    I might be convinced to support a 1-year trial with a cast-iron guarantee that after the one year trial period, the process ends, and a full, complete and positive consensus after discussion is required to re-enact it. Stifle (talk) 11:59, 2 March 2021 (UTC)
100. Reading SD0001's comment below, I realised it is not 60% but 40% support is enough to remain Admin. Why should someone need firm majority support to become an Admin but minority support is enough to remain Admin? This proposal would only be good for desysoping out of touch legacy Admins who don't have much friends but will make desysoping of the WP:UNBLOCKABLES even harder than the current system. I wouldn't have opposed based on the percentage alone but there are many other problems with this proposal which others have highlighted above. AVSmalnad77 ^talk 15:52, 2 March 2021 (UTC)
101. Oppose per comments made above by bradv, neodop, wbm1058, Sandstein, and many of Hammersoft's points. Cbl62 (talk) 17:24, 2 March 2021 (UTC)
102. Oppose. This proposal is like one that I would write myself, but with one essential detail wrong. This proposal seeks to create a means of removing admins who have engaged in misconduct – which is exactly the wrong group to target, since ArbCom does that quite well and the community does it comparatively poorly. Admin misconduct cases are often huge and expansive, involving many years of conduct history and hundreds upon hundreds of diffs, that require weeks of effort by dedicated people. Does anyone really think dramaboard discussion is a superior means of investigating and resolving those cases? Or another RfA-like process? What we really need is a community process for desysopping admins who have not engaged in specific identifiable acts of administrative misconduct but rather have lost the confidence of the community (e.g. for bad judgment, for a pattern of incivility that doesn't rise to a sanctionable level, etc.). So I would support this proposal if it applied only to non-misconduct cases in some way, and explicitly did not apply in the case of actual misconduct. In this case, I must regretfully oppose because I think it would, by implication and in practice though not formally, weaken the existing processes we have (ArbCom) without providing a good or adequate substitute. I'm happy to elaborate on my thoughts if anyone has questions. Best, KevinL (aka L235 · t · c) 20:13, 2 March 2021 (UTC)

     This, by the way, was the fundamental problem with WP:BARC and similar ideas. We don't need another process for removing admins for misconduct; we need one to remove admins for losing the community's confidence. KevinL (aka L235 · t · c) 20:19, 2 March 2021 (UTC)

     To a much greater degree than other oppose arguments, I find your argument very interesting and worth further thought – thanks for raising these issues! I'm trying to visualize mentally what would be entailed in an admin not having done anything wrong procedurally, and not having done anything wrong with respect to "conduct [un]becoming an administrator", and yet having led to a consensus loss of community trust. As written, the proposal here is framed in terms of a noticeboard consensus that the admin "behaved inappropriately". I think that is broader than a specific misuse of tools, and clearly encompasses inappropriate/unbecoming conduct. It seems to me that someone who has lost community trust will have been the target of some sort of noticeboard discussion, but maybe I'm missing something. --Tryptofish (talk) 22:49, 2 March 2021 (UTC)

     Aggressive responses over a long period of time is a typical example of behaviour that can fail to produce any single discussion that amounts to more than a half-hearted rebuke ("the behaviour wasn't ideal, but it arose out of a passionate defense of Wikipedia ideals"), and yet be part of a long-term pattern that possibly fails to meet the expectations of the community, and so could warrant review. How to proceed from "could warrant" to deciding on whether or not to have a review is the crux of the problem, of course. isaacl (talk) 23:09, 2 March 2021 (UTC)

     Yes, I think that's it. Perhaps there should be a possible trigger that would consist of a pattern of (related?) discussions over time. On the other hand, KevinL argues that issues that accumulate over time are better suited to ArbCom than to the community, although I would argue that "community trust" is indeed something for the community to determine. --Tryptofish (talk) 23:34, 2 March 2021 (UTC)

     Continuing along those lines, the proposal here clearly would allow for multiple AN/ANI discussions, as opposed to requiring that there be no more than one. I can picture arguments over "behavior wasn't ideal" being equal or not-equal to "behaved inappropriately". But I think the proposal here could be used to examine a case that fits this description, and it would, appropriately, be up to the community whether or not a repeated pattern of "not ideal" reaches the threshold for desysopping. --Tryptofish (talk) 23:41, 2 March 2021 (UTC)

     @Tryptofish: Another case to consider is what I call "squatting admins" who do the bare minimum to stay above our inactivity requirements. I mention this in my opening comment at WP:DESYSOP2019: I think a process by which the community can tell a squatting admin "thanks for all you've done for the community, but you've clearly moved on and we'd like to let you move on" could actually be healthy. They'd have done nothing wrong or ArbCom worthy, but with the coming-and-going of contributors may not have the trust of the current community. Some way to test that and weigh the costs and benefits to continued tool access is one situation I see coming up more often than outright misconduct. — Wug·a·po·des​ 21:49, 5 March 2021 (UTC)

103. Oppose. Anybody ought to be able to propose such a thing, and do so anonymously. Too complex a procedure here. Hyperbolick (talk) 22:21, 2 March 2021 (UTC)
104. Oppose. The attempt is noble, but it can't work for so many reasons: Most comments here are based on a pejorative negative platform as in, identify and punish (desysop). As Hammersoft says, these are real people, I'd add, not names on a screen. There is very real abuse and incivility on Wikipedia; some of it is obvious, vicious, deliberate. The real abuse is not the admin who is tired and frustrated and whose language indicates that state of physical and mental fatigue. The real abuse and incivility are the lies, the manipulations in attempts to control content and power. Arbitrations are not necessarily the answer either. They work best for egregious cases when arbs must put in a huge amount of time to ascertain actions and context which will describe what the real issues are. But no one wins in an arbitration. The stress of a long arbitration creates fatigue for most people and if they loose and are shamed, more so. The system built in Wikipedia's early days no longer functions. I discussed this before so won't go into it again. But in the end, an outdated system based on a pejorative platform, where true abuse is hard to spot can't be fixed with another notice board kind of system where pile-ups are possible. If we base our collaborative community on negativity and stress, we will create negativity and stress and we'll lose editors and admins. The beginning days and functions of the then new Wikipedia are not sacred. This is an ongoing experiment and flexibility, and a focus on editors as human beings who function best in supportive environments will be needed for Wikipedia to grow and be healthy. Anyway. Littleolive oil (talk) 00:30, 3 March 2021 (UTC)
105. Oppose Given the very valid concerns expressed over the specifics of this implementation, given how rarely admins are desysoped for cause, given how this solution might be fixing a problem which does not necessarily exist (ArbCom is competent to handle this for sure, issues about community trust aside), and finally given the convincing pleas by KevinL and by Littleolive oil, I cannot support this proposal. RandomCanadian (talk / contribs) 03:18, 3 March 2021 (UTC)
106. Oppose, for two reasons. First: a public process has the potential for spectacle, so without an overriding reason to use such a process, it should be generally be avoided. Second: the only cases where this process would work better than the existing Arbcom process is when the sysop is already unpopular, or when Arbcom does not otherwise have the capacity to handle all such cases. But these are not sufficiently good reasons because (1) we do not have a particular problem with unpopular sysops that need to be removed; and (2) Arbcom is not currently (nor do we expect it to be in the near future) overburdened with workload. — Eric Herboso 05:07, 3 March 2021 (UTC)
107. Oppose. There is part of a good idea in here but the specifics make it too easy to create a circus of trouble while going too quickly to the electric chair. Process as opposed makes it too easy to take down a disliked admin or one who genuinely made an error in judgment without showing enough good faith to that admin, while complicating things for that admin to react, defend, or improve. Doczilla _{@SUPERHEROLOGIST} 09:21, 3 March 2021 (UTC)
108. Oppose. I really wish there was some process for the people to decide directly, but it is quite hard in this case, when it is up to evaluating people. I also note that a representative_democracy, meaning the ARbCom, is a valid way of a community expressing itself. As to the current proposal, I think the problem is not as much in what it says, which is mostly sensible, as in what it does not say. Two things it does not say. One, it does not require to warn the admin of the request! Two, it imposes no kind of limits on the number of request or endorsements by any user, so there may be a set of 'vigilantes' harassing some admins on and on. The 60% rule is not well thought, it allows for a 2-1 vote to desysop someone... unlikely, yes, but it must not be enough to desysop, never. There should be a minimum number of votes or, better, a variable threshold, say starting at 100% with 10 votes, down to 50% with lots (hundreds...) of votes - Nabla (talk) 19:55, 3 March 2021 (UTC)
109. Oppose. The correct number of admins required to initiate such a process is zero. De-sysops are rare on wikipedia due to admin cronyism, and any process that doesn't address this issue is useless. Admins are selected by community-driven processes, and need to be deselected by similar community-driven processes without putting massive barriers in the way. Many admins here are routinely uncivil, and would not survive a recall/reconfirmation process. MaxBrowne2 (talk) 21:08, 3 March 2021 (UTC)
110. Oppose. Admins are expected and often required to take actions that many editors will not like. I'm afraid admins will be even more reluctant to take necessary action against popular editors if they're subject to recall. Also, over the past few years, ArbCom has shown it is very capable of using its desysop powers when needed. Basically, I think this proposal is both unnecessary and harmful. Red Rock Canyon (talk) 23:58, 3 March 2021 (UTC)
111. Oppose with regret and without prejudice against future proposals on this topic. This is a well-intentioned and very well considered effort. I am concerned about the chilling effect this may have on admins and their willingness to do good but sometimes unpopular work. Admins should be encouraged to have recall policies and ArbCom should continue to function as well as it can. - tucoxn\^talk 20:17, 4 March 2021 (UTC)
112. Oppose for several reasons. I feel a community consensus could be a good thing but I feel that this system is too complex and enforcing general rules could lead to overcorrections at times. While I do think the idea of having some sort of community consensus to desysop people, I feel like this proposal isn't the right way to do it and over complex in many ways. Just like with editors, I feel like "one and done" should only be reserved for the most egregious mistakes and I feel the standard of assuming good faith should go not just to the editors but to the admins as well. This policy, in my opinion, goes against good faith and I feel like a lot of desysops discussions would be disgruntled users firing back at admins doing their jobs. I feel like with many admin errors, a simple discussion on their talk page will fix the error (or an RfC). I did see a user here propose that crats delete any discussion that would obviously fail or doesn't meet criteria, but I feel like this would negate the point of having a community consensus. While I'm not against it, I feel like the above proposed ruleset would do more harm than good in the end. Jns4eva (talk) 05:35, 5 March 2021 (UTC)
113. This is a perfectly fine proposal. I'm just not convinced that the current desysop procedure is broken. Recent ArbComs have a pretty good record of resolving administrator conduct disputes. – Teratix ₵ 06:14, 5 March 2021 (UTC)
114. Oppose - This is what we have ArbCom for. Graham Beards (talk) 19:29, 5 March 2021 (UTC)
115. Strong oppose. This perennial proposal lacks safeguards and as noted by others penalizes admins who work in difficult areas (where we need them most). The arbitration committee, while imperfect, has shown an ability and willingness to deal not only with egregious abuses of authority but also ongoing patterns of poor judgment. UninvitedCompany 01:05, 6 March 2021 (UTC)
116. Oppose, and oppose any modifications of this proposal. After watching this for a while, I can't be inclined to support. Is this even solving a necessary problem? The only cases this should be used in, imo, are where an admin is doing something egregiously bad - in which case ArbCom should take care of it (if not, why are they there?) Potentially subjecting admins to a re-RfA is going to be very stressful and chase off a lot of good admins - or prevent them from working in potentially controversial fields. The whole reason the RfA criteria and scrutiny are so high is becasue this is the only time most people will get a say in whether someone is an admin. At WP:PERM admins often grant rights temporarily - but adminship is permanent, so of course it lends itself to more scrutiny. Requiring people to go through potential confirmation RfAs, even with a high bar, is simply not a good idea. Now, would a world where admin terms are temporary, and criteria for passing an RfA are lower, be better? Maybe, but that's not the one we live in, and I'm very cautious about fixing something that's not broken, especially with the potential danger of chasing away admins in the process. Elli (talk | contribs) 23:05, 7 March 2021 (UTC)
117. Oppose – the question is not whether the community should have a desysop process, but rather how the high the bar of initiating the process should be set: it must be (1) high enough to insulate admins (and potential admin candidates) from undue fear in doing their duties, and (2) low enough to ensure that admins that have lost our trust can be removed. I believe that the current ArbCom process is the right level for this bar to be set, and that the proposed process would lower the bar too far (I think Hammersoft has examined this well; while this proposal has been hardened over previous ones, it remains fundamentally weak to gaming, bad faith, score-settling due to where the process originates). Bad admins should fear the community removing their tools, but having the process originate from AN and ANI would create a chilling effect over every admin's actions to a degree that I think is underestimated by this proposal's supporters. I strongly believe that there is an grey area within (1) blatant admin misconduct, (2) subtler misconduct, and (3) a loss of community trust that doesn't rise to the level of either. All three categories are plainly grounds for de-sysop, but ArbCom often lacks the political capital to deal with the last effectively. The last category is the space where the community process should be inserted, and I point to proposal raised by Tryptofish below (a desysop initiated by ArbCom remedy or motion) as where a future proposal needs to be. — Goszei (talk) 23:21, 7 March 2021 (UTC)
118. Oppose per GorillaWarfare. Ed ^{[talk] [majestic titan]} 05:07, 9 March 2021 (UTC)
119. Oppose per many above. I waited a while deciding whether to support because I understand the sentiment behind it but in the end, I don't see how this system would be superior to the current system of ArbCom handling these cases. Any system to replace or compliment ArbCom in this area needs to include the same safeguards ArbCom has against abuse of the system to penalize admins who do necessary and correct work in difficult areas. This system will most likely decrease the number of admins willing to work in those areas for fear of being desysoped by the friends of those they sanctioned. Regards SoWhy 11:17, 9 March 2021 (UTC)
120. Oppose. This proposal essentially gives a blank cheque to people in divisive/sanctioned topic areas to turf out any admin they do not like. —A little blue Bori v^_^v ^{Takes a strong man to deny...} 17:14, 9 March 2021 (UTC)
121. Oppose, overly bureaucratic, and I think the ANI involvement is counterproductive and will have unintended consequences. —Kusma (t·c) 21:44, 9 March 2021 (UTC)
122. Oppose, per the many issues raised, I morally support a proposal such as this one but can't support it in its current form. Asartea ^{Talk | Contribs} 16:00, 12 March 2021 (UTC)
123. Oppose due to the many issues raised, particularly Beeblebrox's concerns. I feel that this would be a good way to harass admins, especially those involved in contentous areas (i.e. bring every little mistake you can find to ANI, getting it closed as "yeah they shouldn't have done that", and then repeatedly go "There's been 15 attempts already, they must need to be desysoped"), and I find it hard to set up a proper barrier without either requiring secretive off-wiki coordination or running in to WP:TROPHY concerns, both of which are unacceptable. — csc^-1 23:34, 12 March 2021 (UTC)
124. Oppose. I find this proposal flawed in both specifics and motivation. Authorising "grand juries" to make broad judgements about administrator fitness based on as little as one unfavourable ANI thread is a recipe for all kinds of gaming and gang-ups. I agree with some above have said about ANI – it's essentially mobocracy with a veneer of process, and in that respect is far from authoritative. Virtually anyone can close a discussion and the "consensus" is mostly down to whoever happens to be patrolling the board that day... or, potentially, whoever is most determined to push their agenda.
     As to other specifics: "behaved inappropriately" is too vague a charge, the transclude-in-14-days-or-resign part strikes me as unnecessarily degrading (and odd – if the case has "gone to trial", the trial should begin immediately) and I find it strange that de-sysopping discussions should be publicised in such different ways from RfAs.
     On the motivation, I see little need for this process when we have an ArbCom that is fully capable of taking action against an administrator when members of the community make a good case with good evidence. Since the closure of the last de-sysopping RfC in January 2020, there have been three arbitrations resulting in a de-sysopping, and since the start of this RfC, another administrator case has been opened. Arbitration may be a lengthy process, but at least it isn't a mere pile-on, and everyone involved is required to act with decorum and restraint. I don't think the same could be said for what is being proposed here.
     Finally, in response to the supports along the lines of "other proposals have failed and some kind of process is better than nothing" – the fact that other proposals didn't pass doesn't mean that this one should. SuperMarioMan (Talk) 23:22, 13 March 2021 (UTC)
125. Oppose As per my unanswered comment below, I might have been able to get behind this proposal had the requirement been for the ANI closure to have concluded that an admin had misused their tools/status, but allowing a desysop process to start based on a non-admin related error of judgement is far going too far. As Dirk Beetstra says above, we are all human and we all make mistakes. I'm sure there are a few things I could have been trouted for over the years, but I don't think any of them come close to being justification for starting a desysop process. There are many editors out there with grudges against admins who would love to get the opportunity to take them down a peg (I get occasional unwanted pings snarking at my status as an admin due to a dispute over a notability guideline) and unfortunately, as many have pointed out above, I suspect this will be used to harrass admins who regularly deals with a topic area with a significant group of editors with a clear POV. My RfA attracted two groups of nationalist editors I had pissed off (including one editor that canvassed for oppose votes), and although it narrowly passed in the end, I really would not want others to experience that. Cheers, Number 57 14:38, 14 March 2021 (UTC)
126. Oppose I worry that those administrators who work in the most difficult areas would be unduly harassed by this proposal. I think that those contributors who undergo the rigours of RfA and are rewarded with the trust of the community, should continue to receive the trust of the community. In the case that administrator behaviour comes into question, that editor should either be open to the recall process (their choice) or have their behaviour scrutinised by a body who have also been rewarded with the trust of the community; that body being at this time the Arbitration Committee. In the main, admin behaviour does not seem to be a significant problem, but it can cause a lot of drama and time-wasting. Increasing the number of admins would help to reduce the problem with a reduction in pressure on the current corps. Let's concentrate on increasing admin numbers rather than devising schemes that would reduce them. Poltair (talk) 08:34, 15 March 2021 (UTC)
127. Oppose mostly per Hammersoft. For my full opinion, see section #Oh, adminship below. 🐔 Chicdat  ^{Bawk to me!} 10:24, 15 March 2021 (UTC)
128. Oppose The devil is in the details. This proposal is unworkable and would cause all kinds of trouble for admins who take on the very difficult task of working in the hard areas. -DJSasso (talk) 15:25, 16 March 2021 (UTC)
129. Oppose per Hammersoft data of de.wiki. I can only support a easier de-adminship or reconfirmation with a easier RfA, which is not current reality in en.wiki. RfA requirements is too high and everyday we are getting fewer administrators to actively work in en.wiki. Carlosguitar ^{(Yes Executor?)} 11:17, 17 March 2021 (UTC)

     Although I voted support, I understand your argument here. Would you support/ be interested in drafting a DRFA proposal which would tie the RFA % to the inverse of the DRFA percentage. ( IE: If the DRFA percentage to remove an admin was roughly 60%, the RFA percentage to make someone an admin would lower to roughly 60% with a discretionary range from 55-65.) Jackattack1597 (talk) 18:54, 17 March 2021 (UTC)

     I would support reducing percentage to success a RfA, not sure if I can help drafting. But would be interesting to study previous proposals to reform RfA and understand why we did not reach consensus to redesign the RfA. Carlosguitar ^{(Yes Executor?)} 15:30, 18 March 2021 (UTC)

     What do you think the ideal percentage would be? 65% with discretionary from 55-65, or 60 with discretionary from 50-60, but a hard floor at 50 since nobody should ever become an admin without majority support. ( IE: If it is 49.8% support and 50.2% oppose it fails automatically. ) Jackattack1597 (talk) 00:32, 22 March 2021 (UTC)

130. Oppose. I'm really not sure what problem this is trying to solve, but I am aware of many problems this would create. Chicdat and Hammersoft have articulated my own opinions well in the "Oh adminship" section of the discussion below. WaggersTALK 15:56, 17 March 2021 (UTC)
131. Oppose. While a community desysop policy of some sort is welcome, the numerous concerns (e.g. harassment of admins in contentious areas, thresholds, ease of use) raised in this section show this isn't it. Really this would have been better off as an RFA to figure out what the community consensus is on thresholds, features of such a policy instead of jumping to propose one. ---- Patar knight - ^chat/_{contributions} 06:16, 18 March 2021 (UTC)

     Do you mean an RFC to figure out the community consensus? Many of those have been attempted before, but no one proposal at them has ever gotten consensus, and this looks like it won't get consensus either, unless the closing admin says 55% is sufficient consensus. Jackattack1597 (talk) 00:21, 22 March 2021 (UTC)

132. Strongest Possible Oppose - I strongly oppose this and all such community basesd desysop proposals. This is clearly not what we need or even require. The situation where an admin becomes problematic or behaved inappropriately is usually very rare and occasional. The current processes which are there is completely fine and I don't see even a 1% need to implement proposals like these. It is already very hard to become an admin and help Wikipedia and what we need is more admins so that there is never a shortage of admins and an admin crises on Wikipedia. Problematic admins can be dealt on a case by case basis by Arbcom, just like they normally have been. Admins are people who are required to take tough calls in many situations which will usually upset someone or the other and this process will just give those people ammunition to use against that specific admin for them doing their rightful duty. This will prevent even more people from becoming admins which will eventually lead to an admin crises on the English Wikipedia in the future and gravely harm the project and its future. We need to create a more friendly and helpful environment for all which helps promote harmony and improve the encyclopedia and not create more battle grounds as there are already more than required. Wikipedia really needs more admins, not less. TheGeneralUser (talk) 19:49, 20 March 2021 (UTC)
133. Strong Oppose per Useight. It is hard already to be an administrator, we don't need them watching their back every time someone mentions them in an ANI thread. This is a good idea at heart, but certain specifics that require admins to be able to be desysoped are too easy in my opinion. ―sportzpikachu _{my talkcontribs} 00:03, 24 March 2021 (UTC)

     Note: reread the proposal again, and having the discussed admin transclude their own desysop is just too humiliating, considering that every sysop has made a few enemies here and there and 10 excon users who don't like a sysop can easily be found, the 2 other sysops might be a harder task, but having the discussed admin to transclude their own desyop is just a bit too much. ―sportzpikachu _{my talkcontribs} 00:07, 24 March 2021 (UTC)

     @Sportzpikachu: Personally, I see that as an important step in making sure they are involved in the process and participate in it. Otherwise, where is the impetious for them to not just ignore it in the hope that it will go away? Which it sounds like some admins in the German Wikipedia did when a similar thing was passed. I'd think making sure there is participation on the part of the admins on their potential desysop process would matter more then their personal feelings of humilitation at said process. They will be feel humilitated anyway if they are that sensitive about it. So, why bend over backwards about it? More so because in no way whatsoever is the same consideration about the persons feelings made for people who are sent to ANI. What makes admins feelings special? --Adamant1 (talk) 01:27, 24 March 2021 (UTC)

134. Oppose While a desysoping policy is needed, I do not like the requirement that a desysop petition must be signed be at least three admins. I don't understand why its necessary to treat various classes of editors differently. Further, I'm a bit worried about what would happen if a desysop petition popular with regular users didn't get enough admin signatures; this feels like a good recipe for needless drama. Spirit of Eagle (talk) 04:34, 26 March 2021 (UTC)
135. Oppose — There should be a community desysop process. However, this would be overly complicated and have a little too many loopholes, per the opposes above. — The Most Comfortable Chair 05:30, 29 March 2021 (UTC)
136. Oppose per User:Chicdat's reasoning in § Oh, adminship, and because ArbCom is a thing that exists. TucanHolmes (talk) 20:08, 8 April 2021 (UTC)
137. Oppose - Arbcom appears to be handling these decently at the moment. and per many of the more-eloquent-than-I opposes above. - jc37 22:47, 8 April 2021 (UTC)
138. Oppose – The sentiments of Dennis Brown and others have swayed me into believing that ArbCom is currently able to process requests for desysop efficiently. They used to have a lot more on their plate insofar as cases are concerned; that is no longer the case. Kurtis ^(talk) 13:18, 9 April 2021 (UTC)

Neutral

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)

While turning inactive admins into active admins is ideal, sometime our magic wand fails. It is a mistake to think that an inactive admin retaining the tools is not a problem. It is a basic principle of computer security that you never give a permission to someone who never uses it. Let's say we drew lots and made, say, Nsk92 an admin but they never used the tools. Then someone compromised the account (Nsk92, I told you not to use '1234' as your password! Always use 'Swordfish'. They will never guess that one.) they could do a lot more harm than they could if Nsk92 was a normal user. --Guy Macon (talk) 05:30, 24 February 2021 (UTC)

Has this been a significant problem. It would be an argument for unbundling the admin toolset. Give admins the tools they need and use, remove the ones they don't need or use until they indicate a need and intent to use, then if they remain in good standing flip the bit for the tool while it remains useful. · · · Peter Southwood ^(talk): 04:49, 25 February 2021 (UTC)

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

   Moving to oppose - 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)

   Neutral (moved to oppose). 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)

   Neutral, for now. (moved to oppose) 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)

2. 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) Moving to hesitant support. Vanamonde (Talk) 16:29, 2 March 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)

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

   I'm not sure what a trial would tell us. If we have a trial, I would want tangible goals so we can measure success at the end of it rather than just having this same discussion again a year later. Without an idea of what the trial seeks to accomplish, I'll continue to let others decide the issue. — Wug·a·po·des​ 23:26, 3 March 2021 (UTC)

   I just noticed that Vanamonde93 moved to support, and since I cited their neutral !vote in my rationale I think I should explain why I now reach a different conclusion and continue to stand aside. When I worry about the lack of community agreement, it's not for lofty ideas about consensus or respecting minority opinions: it is practical. Our processes only work when we all agree they will benefit the encyclopedia in the long run (even if we disagree on the immediate value), but they fail when a significant portion of the community thinks a course will be actively harmful. This leads to active sabotage or failure through withheld labor. If a desysop procedure passes without resolving the fundamental community disagreement, I believe we are setting ourselves up for failure. Worse, if it did not succeed it will serve as evidence against any future proposal no matter how well conceived. I don't believe we need to get every detail right, but I do believe we need to get everyone on board.

   To give a personal example, in the city where I grew up we had a highway that ran through a park. The speed limit was 55 MPH and a pedestrian path was only feet away from the road. One day a driver lost focus for a second, veered off the highway, and killed a child in the park. None of us wanted to see this happen again. Of course, the solution is obvious: don't put a highway through a park. However that is not the solution our governor came up with: he lowered the speed limit to 35 MPH---a crawl on a major commute route for the second largest metro area in the state. Of course, many in the community did not agree with this solution, so they started speeding. As time goes on, fewer people remember the tragedy that caused the speed limit to be lowered in the first place, so fewer people feel an emotional need to obey it. But some people still do. The speed disparity between cars going 55 and cars going 35 increases the chances of vehicle collisions. The resources needed to ensure compliance take police from other areas where they are needed and drain the city of resources. People still go 55 MPH through the park. Did we succeed in making the city safer?

   Of course, this is an online encyclopedia, and this decision is not life-or-death (though with our spotty record of dealing with harassment, not trivial either). I won't oppose because in my eyes the benefits are better than the problems, but if the community cannot agree on that I worry supporting its adoption will actually be counter-productive. I would like a recall system, and I would be bound by this recall system, but I would rather abstain until the ideologues can come to an agreement on a course of action. — Wug·a·po·des​ 01:06, 4 March 2021 (UTC)

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

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

6. 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 change #3, and you might get a support from me. — Ched (talk) 19:31, 22 February 2021 (UTC) (edited after reading "The Earwig's" comment. — Ched (talk) 03:45, 25 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)

   The Earwig, Apologies for not getting back to this sooner. OK - I would change the wording to something like "The admin may transclude and if not done within 7 days then a crat can do it. One other item I noticed that I might make a small adjustment to is the number 2 item: "... endorse the request within 48 hours...". I'd probably change that to 72 hours to account for weekends. Another item that seems to be contentious for some users: the "at least 3 admins" ... I would like to see that kept. Not to say admins are any better than any other editor (obviously) - but more a "peers" thing where folks who have served in that position understand that particular position. Anyway - thank you for offering me a chance to voice my thoughts. Cheers and best. — Ched (talk) 03:42, 25 February 2021 (UTC)

7. 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)
8. 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)
9. 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)
10. Neutral - there are some valid concerns about this and I think that Rhododendrites's suggestion of running this through a trial period with a rule about how often this can be initiated by the same person. My concern is that the rules may make it easy for brigading, particularly when you have an admin who steps in with controversial topics. However we can't entirely accurately predict how this will play out so a trial period is necessary to look for any issues that pop up. I also think that any cases that pops up should be thoroughly discussed afterwards to determine if the system worked as it should, if it didn't, and what can or should be finetuned. I don't think that this should be permanently put into place without testing it out first. ReaderofthePack(formerly Tokyogirl79) (｡◕‿◕｡) 03:52, 25 February 2021 (UTC)
11. Conditional Neutral (a weird !vote, I concede). In effect, if this is closed as a trial with an automatic sunset (I'm open to any reasonable time/# of uses), then I am neutral, otherwise I should be counted as a firm oppose. The positives are clear. The negatives have been stated several times, and individuals say "we can improve as we go" and such, but none of them seem to say what we should do about anyone who gets caught in the gears in the process. Let's say we think an admin was somewhat (not egregiously) unfairly desysopped. Passing an RfA is harder than being deysopped, so we can't correct it that way. Maybe we get an improved method and that editor is just shit out of luck. I should note that the 60% to remove barrier seems fair. Nosebagbear (talk) 12:15, 25 February 2021 (UTC)
12. Neutral. I would like to support, because I am in favor of a community-based desysop process, distinct from ArbCom. However, I am concerned about the threshold in this proposal for retaining adminship. I would want it to be the same as for RfA, namely, consensus for the editor to be an admin (in practice, 65-75% support for adminship). But in the present proposal, the threshold is 60% for removal, meaning that retaining adminship only requires 40% support. Tony argues that "Our process typically requires consensus to sanction, not consensus to keep the status quo." But adminship is a privilege, not a right. Every admin was originally a regular user, so revoking adminship is restoring the status that they originally had. For that reason, I would prefer that a consensus be required to keep it, rather than to lose it. Tim Smith (talk) 04:53, 28 February 2021 (UTC)

    Neutral Has anybody considered the recall process as adopted on some other wikis? eg. User:ToBeFree/recall - I mean, German WP isn't exactly middle of nowhere and although I don't know if there are issues of abuse with that over there, (question which @ToBeFree: might answer), but that process seems less complicated/bureaucratic (by removing the WP:Dramaboard requirement) than the current proposal. Also, the requirement for a larger number of users seems to render that more robust than the current proposal. RandomCanadian (talk / contribs) 21:08, 1 March 2021 (UTC)

    After consideration, and with issues raised on the talk and by others, moving to oppose. RandomCanadian (talk / contribs) 03:13, 3 March 2021 (UTC)

    I like the process as it does lead to reasonable recalls in my opinion, and these recalls do lead to both reconfirmation, resignation and rejection, depending on whether the community still maintains its trust. Recent examples are de:Wikipedia:Adminkandidaturen/Björn_Hagemann_(Wieder-Wahl) (rejection), de:Special:Diff/207544035 (resignation after canvassed desysop vote renewals, diffs, block, result) and de:Wikipedia:Adminkandidaturen/LexICon_(2021) (reconfirmation). Statistics can be found at de:Wikipedia:Adminwiederwahl/Kurzstatistik. Pinging Hammersoft who probably disagrees about the process being like-able, for a different point of view. Note: Contrary to the current enwiki proposal, the dewiki approach is also used to deal with inactive administrators who make a few edits per year to retain the tools – that doesn't work over there. ~ ToBeFree (talk) 21:24, 1 March 2021 (UTC)

    As I recall, when de.wiki instituted their process, they lost 1/3rd of their admins in short order. We're almost at a tipping point already on this project, in terms of backlogs and our ability to maintain the project with the administrators we currently have. There are frequent discussions at WP:RFA about what to do about it, how to get more admins, etc. If we institute this procedure for de-adminship, we're doing the exact opposite. Worst case scenario is we're destroying the project. But, since nobody's bothered to do the homework that needs to underpin such a major shift in policy, we have no idea where this will take us. --Hammersoft (talk) 22:15, 1 March 2021 (UTC)

    (34+21)/314 ≈ 16% for a purely vote-based process (no "consensus" determination in dewiki's RfAs, 66% votes for keeping required) that allows desysopping without specifying any reason. The proposal has additional safeguards. ~ ToBeFree (talk) 22:48, 1 March 2021 (UTC)

13. Whatever. InedibleHulk (talk) 18:31, 7 March 2021 (UTC)

    The above comment should be stricken as it adds no value to this discussion. JayJay^{What did I do?} 02:05, 10 March 2021 (UTC)

    Neutral (moved to oppose)(Opposed earlier, reconsidered, moving back to oppose.) I wish I could support, but the opposes make outstanding points. I think that desysop should be separate from ArbCom, or at least be brought with a different (not lower, just more specific ) set of procedures that differs from an ordinary two-months-of-hell ArbCom case, but the proposal above is too easy and I agree with some of the opposes that it would just open the door to bullying and harassment of the best admins, the ones who make a hard calls and get stern with the IDONTGETIT crowd. Extended confirmed is far too easy a standard for a sock to reach, and it’s easy to round up 10 meatpuppets over on some of the anti-Wikipedia boards out there. Montanabw^(talk) 17:06, 10 March 2021 (UTC)

14. Neutral. I think the community needs a way to request desysopping, but I'm not sure the detail is right here. As an admin myself, I have come across a few other admins who have been problematic, either displaying an "I know best" attitude and not adhering to policies, abusing speedy deletion, or just being generally obnoxious and off-putting to other editors, but they are a minority. Whether this proposal would deal with those I'm not convinced, but trying something to see if it addresses the issue and tweaking it as we go along may be worth a try. --Michig (talk) 19:27, 10 March 2021 (UTC)
15. Not convinced enough to support, but don't oppose --DannyS712 (talk) 22:02, 29 March 2021 (UTC)
16. Moving to Neutral. I'm not convinced recall would have helped with either the RexxS or the Carlossuarez46 situations; until it's more clear which situations it will help with I'm no longer supporting this. Having hundreds of people vote about RexxS would have been more inflammatory, and letting ARBCOM handle it is more polite than a vote on an editor who appears to be retiring. User:力 (power~enwiki, π, ν) 01:50, 31 March 2021 (UTC)