Wikipedia:Requests for comment/Desysop Policy (2021)

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

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

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

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

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

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

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

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

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

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

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Suggestions for future attempts at a community desysop

Even several opposers seemed to agree that Tony's proposal was well crafted. That it fell so far short of consensus suggests how difficult a task it may be to create a significantly more successful one. Especially as no-voters arrived from partly opposed perspectives: Some felt the proposal would make de-sysoping too hard, v some who felt the opposite. (or at least that it would have a net discouraging effect on Admins.) Yet with the benefit of hindsight, the following might help: 1) Have better (luckier) timing. Many feel that the current Arb system is working well. So before launching the next attempt, maybe wait until such a time when there's either more community discontent about Arbs making it too hard to bring a case against an Admin, or conversely that the Arbs are passing desysop remedies too easily. Then less might oppose with the 'solution in search of a problem / Arbcom is working fine' argument. 2) While ~20 opposed due to feeling the proposal would make it too hard to de-sysop, these were outnumbered about 4:1 by those concerned it would make de-sysopping too easy (or at least provide too little protection against admins being harassed by the process, even if such attempts were not likely to result in tool loss). So a process that is more difficult to trigger (though not necessarily more difficult to get the end result) may be more likely to get consensus. 3) If this can be done while retaining suitable safeguarding, make the next proposal simpler. 4) Maybe reduce the requirement for a 3 admin sign off. 5) Don't require the admin to transclude their own de-RfA (but retain some ability for them to control the timing, maybe give them a greater than 2 week window for this.) Over 10 voters expressed a preference for this, including some of the supporters and a neutral. 6) Possibly introduce as a trial, promising a revert to the status quo after 1 year unless a 2nd discussion green lights a continuation with a clear consensus. 7) Prior to the next proposal, maybe have a RfC to help fine tune it, perhaps as exemplified by Silktork in the "comments" section. 8) Read this whole discussion – there's about 50 suggestions for improvement I've not touched on above, but which might resonate more with current community thinking, whenever someone gets round to re-proposing.

Further analyses

Overall, an exceptionally high quality discussion, both in terms of collegiality and strength of argument. It's challenging case to sum up, as there were multiple partly incompatible and even incommensurable lines of argument, both for and against. This is WP:NOTAVOTE , yet I'll make use of numbers to indicate relative contribution towards consensus. Other than the simple 'totals' , all numbers given are subjective. For example, if you look closely, on some of the individual votes, it's not always easy to classify their rationale. Yet I hope the figures are of some help in summarising how many held the various widely shared views. Support vote break down. 168 votes in total. In contrast to the Opposes, very few supports had consistency issues with other support rationales. The clearest exception to this was Maile's vote which was conditional on upping the threshold to retain an admin from 40 > 60%. About 20 supporters expressed reservations. (This being a high subjective figure - some might say lower than 10 if they count only the stronger reservations. Or >50 if they count folk who made suggestions for modification to Tony's proposal, with only a faint hint of reservation.) Most support votes were essentially per Proposal, but quite a few advanced additional arguments. DGG & AKG made especially strong individual votes – not that I agreed with them, but as former Arbs, their position that the wider community is better placed to call the shots on desysops, had to carry extra weight. A few made the extra argument that the proposal would make new RfAs easier to pass. This was not rebutted, so slightly added to the support consensus. Richite333 made the argument that opposing admins might have their view discounted on COI grounds – I agreed with this, but only very slightly. Sam-2727 made a concise but effective argument rebutting the Oppose view that the proposal would lead to frivolous filings, which again slightly added extra weight to the support case. Several, most tellingly Swarm, pointed out the inconsistency in the oppose vote on the 'too easy / too hard' to desysop dimension. This reflected my own reading of the Oppose case, to the extent of making me discount it collectively by about 5% . This being by far the biggest weighting change – all the others points had at most a 1% influence. But it still only brought the weighted support % close to 60%. So far from the threshold for consensus, especially as on balance other factors pushed the weighted consensus partly back down in favour of oppose... Several made the 'perfect is the enemy of the good argument', and the allied case that we won't be able to properly assess the pros and cons of the Proposal until after its been tried. Though not fully refuted, several editors countered this idea, most especially by Dirk Beetstra. Several suggested that similar proposals had worked on other large wikis, along with the closely related view that data trumps speculation. However, in terms of providing specific and well presented data, none could compare with Hammersoft, so I considered this argument well rebutted. Oppose vote break down There were 138 oppose votes in total. About 80 could be classed as opposing largely out of the concern that the proposal made desysopping 'too easy' , or at least had too little protection against being used to harass admins. Comments by Beeblebrox and Sandstein were among the most persuasive in this regard. Conversely, there were about 20 Opposers who seemed to feel the proposal would make it too hard to desysop. Sandy Georgia and Joe Roe made especially strong arguments on these lines. And there was a handful of voters who (correctly in my view) pointed out that the proposal risked doing both. So when looked at closely, the Oppose case seemed less incoherent than it first appeared. A couple of voters made the case that the whole Proposal was based on a misconceoption - that Arbcom is already a community process. While this only seems true up to a point, it added slight extra weight. More common oppose rationales included that the proposal was too complex and that it was an unnecessary solution in search of a problem. Others felt it might create an unpleasant spectacle that could add to negatively and interpersonal strife. And then there were a few opposes simply due to not liking elements of the proposed process. Perhaps only a single vote could be slightly discounted for not being specific enough. Editors who especially added to the weight of the oppose case, without being easy to succinctly classify, include Hammersoft, Huggums537 & NSK92. While less cohesive than the support votes, I felt that the oppose votes were generally stronger on an aggregated individual bases. The neutral votes also added slightly to the Oppose case (But only very slightly – if you want your statement to effect consensus, you should make it either in the Oppose or Support section. In my view at least, crats almost never pay much attention to a neutral vote, even when it makes an exceptionally well argued point.) In terms of highlighting parts of Tony's proposal to tweak, the Neutral by RoySmith may be especially helpful. Reading the overall discussion outside the Voting blocks, the balance seemed to lean towards Oppose, especially in the 'Hammersoft' & 'Elephant' sections. (Though again, this only very marginally effected my reading of no consensus, unless Voters explicitly referred to the discussion section as part of their rationale.) A final factor that slightly favoured Oppose, was the fact that over the last few weeks, the trend had been towards Oppose, including several voters switching votes in that direction. All things considered, the Opposers did enough to quite easily block the formation of consensus. PS - As it may be useful for newer editors to see which arguments had the most sway on a closers view of consensus, I mentioned a few editors who seemed to make the very strongest arguments. Literally over 100 editors seemed to make particularly noteworthy contributions, so the list could have been a lot longer. Also, strongest doesn't mean best – some of the most insightful or eloquent contributions, e.g. from Barkeep or Chicdat, were maybe too nuanced to have the strongest contribution to consensus.

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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • People can already harass an administrator by filing arbitration requests. The committee declined about six case requests last year[1][2][3][4][5][6]. I don't think there will be more certified desysop requests than accepted admin conduct cases. AGK ■ 10:08, 24 February 2021 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• I think the community forums in point 1. would have to be ANI or AN (and nothing else) - i.e. major and highly visible forum. I think that you would also need to confirm that the ANI/AN discussion was closed by an admin (or even two admins), who concluded that there were problems - i.e. not an NAC (and probably not a single admin). Britishfinance (talk) 23:05, 20 February 2021 (UTC)
• Am I right in thinking that step 3 is in effect a "reverse RfA", needing 60% to oppose to desyop? That would make sense to me as a fair process. Britishfinance (talk) 23:08, 20 February 2021 (UTC)
  • Fair? I'm finding it strange that an editor who is not an admin must get 65–75% support in an RfA to pass, but once they've become a practising admin and the community can actually see how they use the tools, they will only ever need a support of 40% in order to keep them. – Uanfala (talk) 16:19, 23 February 2021 (UTC)
    • This idea about a "reverse RfA" is just a very crafty False equivalence, as well as a factual inaccuracy. A factually accurate equivalent comparison between an RfA, and an RfDA would compare the fact that it takes only 35% to 40% to deem an editor unworthy or unfit to hold the tools when they've done nothing wrong, likewise in an RfDA it should take a similar percentage or even less than that to deem an editor unfit or unworthy if they have been accused of doing something wrong or their trust in the community has come into question. Huggums537 (talk) 21:24, 26 February 2021 (UTC)
• Could ArbCom use this process? E.g. instead of starting off a 2-month ArbCom investigation, ArbCom could just !vote to send the admin in question direct to step 3. (above)? Ultimately, step 3. might turn out to be a better system for ADMINACCT cases (e.g. general conduct vs. technical breeches/tool misuse)? thanks. Britishfinance (talk) 23:13, 20 February 2021 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

I like Sandstein and I appreciate the role he plays here, and I absolutely don't want this to be construed as a personal attack against him, but he's known to be one of the most hardline, controversial admins on the project and he's had a ton of complaints and allegations of admin misconduct against him throughout the years. I'm one of the biggest advocates against the UNBLOCKABLE problem on this project, so I'm sympathetic to this argument, but even I can only take it with a grain of salt coming from Sandstein. I don't doubt that Sandstein would pass a desysop effort, but I also don't doubt that it's in his best interest not to have one. ~Swarm~ ^{sting} 01:22, 24 February 2021 (UTC)

Wow. OK, I am not an admin and have not the least inclination of ever trying to become one. I am still quite concern about the UNBLOCKABLES problem and I think it is likely that implementing this community desysop proposal will exacerbate this problem to some extent. Lets's assume that it was I and not Sandstein who made this argument to begin with. The point is, this objection is reasonable and rational, regardless of whom it is coming from. Nsk92 (talk) 01:54, 24 February 2021 (UTC)

If you're concerned about the UNBLOCKABLE problem you would support a reform to make abusive admins desysoppable via a community process. The opposition to this proposal is the epitome of unblockables resisting reforms to make the situation marginally better. This notion that giving the community an avenue to desysop abusive admins would make abusive admins more unblockable because it would force abusive admins to not be abusive is beyond me. The mental gymnastics are astounding. ~Swarm~ ^{sting} 10:06, 24 February 2021 (UTC)

Swarm, I am not following the logic of your argument, or is it intended as rhetoric? · · · Peter Southwood ^(talk): 06:07, 25 February 2021 (UTC)

Pray tell, Peter, which part are you not following? Everything I'm saying is incredibly straightforward. ~Swarm~ ^{sting} 08:19, 25 February 2021 (UTC)

Swarm, The paragraph directly above my comment. Are you suggesting that the opposition is coming mainly or exclusively from unblockables and their enablers, or that there are no reasonable concerns about the implementation and possible consequences of the proposal as it stands? My reading of the discussion suggests that there are several concerns, some reasonable, that have not been addressed to the satisfaction of a significant number of people. Claiming that this is not the case seems disingenuous. Suggesting that opposition puts one into the unblockables camp strikes me as mislabelling, which I would classify as rhetoric. Cheers, · · · Peter Southwood ^(talk): 15:01, 26 February 2021 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

  But that scenario will only occur if this imaginary user with an all-consuming grudge is some sort of Moriarty figure pulling the strings behind the scenes with tens or hundreds of somehow undetectable dummy accounts as they slowly drag their bewildered and helpless victim over the coals. It's not going to happen and legislating as if it is a likely state of affairs is a waste of time. Crispclear (talk) 01:55, 24 February 2021 (UTC)

  It doesn't assume that in the slightest, where did "tens or hundreds" come from? It feels like that was added just for rhetorical flourish and damn be to accuracy. My point is that of being dragged into the process as a negative. It would indeed take a huge amount for one rogue person to get someone desysopped just through their sock army, but I'm talking about just being wrenched through the endorsement process, which would require vastly less, and certainly less than we have seen by multiple sock masters in the past. Nosebagbear (talk) 11:22, 24 February 2021 (UTC)

  It would require a minimum of 10 undetected fake accounts to get a frivolous request certified (ok...9 plus the "master"), and then two accounts to counter every vote to not revoke. If the request was baseless then presumably the admin would have numerous supporters, so that easily gets into the "tens or hundreds". Presumably anybody who hates an admin so much that they are willing to risk their precious army of previously undetected fake accounts would not want to do so for a process that will merely lead their to enemy being endorsed and receiving the benefit of immunity through douple jeopardy. To be honest, if they are that good at faking genuine engagement across that many accounts then they'd probably have a few admin accounts too. Crispclear (talk) 12:38, 24 February 2021 (UTC)

  You keep jumping to the "two accounts to counter" - my point is the negative is reached as soon as you get past the 10-person stage, even if you ultimately are not desysopped, due to the sheer unpleasantness of that stage. I can't figure out why you keep covering that part when it wasn't part of my original reply. There also isn't any immunity of double jeopardy, except as socially agreed by individuals making up their own minds on the issue. Nosebagbear (talk) 16:57, 24 February 2021 (UTC)

  Because this scenario is even more unrealistic if you imagine that this evil genius will be content with merely having their complaint certified. Why risk nine or more of your meticulously mantained dummy accounts to get a complaint certified that will immediately be dismissed by everybody as baseless? Destruction will be the aim, not some storm-in-a-teacup unpleasantness that is over before it has begun and serves only to highlight the collusion between the certifying accounts. The process for dealing with genuine complaints may be damaging to the admin, but not that for frivilous actions. And the "double jeopardy" will be de facto - nobody is going to open a second request on the same actions. I just looked up "extended confirmed" users and they must have 500 edits, so just for confirmation there are going to have to be 5000 edits behind the certifying accounts (more than that really, as exactly 500 edits per account is going to be suspect, and one thing we know about this imaginary editor is that they are confident they don't do suspect). The more I see of the commitment of this imaginary enemy, the more I think that, if they ever did exist, certifying their complaint would be the least we could do to thank them for their contributions. Crispclear (talk) 09:38, 25 February 2021 (UTC)

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

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

• The point that most bothers me is that there seems to be only limited checks against an off-wiki co-ordinated attack on those admins who deal with paid content, or that protect against PoV-pushers. It's trivial to generate accounts that would qualify. Espresso Addict (talk) 23:53, 23 February 2021 (UTC)

• If I recall correctly, in a recent discussion, someone compiled the desysop policies from other language Wikipedias and I thought that was helpful for comparison. Could someone please repost that, if it exists? czar 04:38, 24 February 2021 (UTC)

  Wikipedia:Requests for comment/2019 community sentiment on binding desysop procedure § Descriptions of de-adminship systems on other projects czar 04:41, 24 February 2021 (UTC)

  Fascinating stuff. Thank you Czar. If other language wikis manage this sort of thing, I don't see why the English wiki can't. // Lollipoplollipoplollipop :: talk 15:51, 4 March 2021 (UTC)

• I think SD0001 and Gatoclass made a good point in the discussion of SD0001's statement. What would motivate the arbitration committee to accept a case to examine the behaviour of an administrator in a non-emergency situation? The arbitration committee serves as a last resort to deal with editor conduct, so in theory a community-initiated administrator review process ought to be attempted first. I suspect there would have to be highly irregular circumstances in that review process for the arbitration committee to subsequently accept a case and override the results of the first review process. isaacl (talk) 21:30, 24 February 2021 (UTC)

On hypotheticals

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yes, even accused admins have to take a number as soon as they're pinged to the noticeboard.

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

There have been various proposals for adding some structure to ANI. A few years ago I suggested clerks, based on their great assistance with arb com proceedings (and at SPI, It was rejected on the basis of not wanting to add another layer of bureaucracy. The alternative to human bureaucracy is what I will call the "bureaucracy of forms"--relying on templates and sectioning. It might work, but I dislike them personally so much that I rarely participate in processes that use them--and if I do, as at requested changes for coi, I comment free-form, ignoring the forms. But I think Atsme is right in saying that we need a much more rigorous definition of "involved".. Here too I made an earlier proposal, that nobody participate too often at ANI or similar proceedings regarding either the same topic or the same editor--once you've done so to any significant extent, such as sanctioning or closing, you've essentially formed a fixed view, even if you;re not aware of it. DGG ( talk ) 07:15, 24 February 2021 (UTC)

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

I haven't waded into all the background on this topic, but wouldn't it be easier to just impose a term limit for Admins and require a new RfA if they want to retain the tools? That would eliminate inactive or bad admins. If there's concern about grudge voting, the support percentage needed for incumbents to pass could be reduced. I assume this has been discussed and rejected for some reason, but I can't guess what the opposing argument was. Argento Surfer (talk) 14:01, 25 February 2021 (UTC)

@Argento Surfer: I'm assuming you mean an appointment length as opposed to a limit on the number of times one can serve; the biggest challenge with that is that we have 853 sysops - running that many full RfA's even on the first round would be a logistical barrier. — xaosflux ^Talk 14:26, 25 February 2021 (UTC)

Ah. Yeah, that makes sense. Thanks! Argento Surfer (talk) 14:57, 25 February 2021 (UTC)

@Xaosflux I think this is not nearly as scary of a problem as you make it seem. First a substantial number of those 1,111 sysops will simply not choose to run for confirmation. Second, even if we assume that all of those people will run, we can put them in tranches when setting up the initial term limits. We know RfA can handle hundreds of RfAs a year. So we divide up existing sysops in a way that all existing ones who've served more than the term over 3-5 years (I can't imagine a term being less than 5 years and I honestly expect it would end up closer to 10). If we decide we want to confirm admins this is a very solvable problem. I just don't think we've decided we want that. Best, Barkeep49 (talk) 15:57, 25 February 2021 (UTC)

@Barkeep49: there are certainly ways to do it, that was just a quick recap of one of the larger oppositions from the past. We could even do a round of simple "voting" like we do with steward confirmation globally (perhaps only making the full RfA process be needed for those that don't get a simple vote). — xaosflux ^Talk 16:07, 25 February 2021 (UTC)

Xaosflux, I agree with Barkeep49. there is an issue in that RFA peaked between 2005 and 2008, with ~1350 admins created in that period, compared with ~400 afterwards - so let's assume that whatever term length we come up with would include approximately 3/4 of the number of sysops outside. As Barkeep suggest, a significant portion will choose not to run for reconfirmation (say, up to 1/4 of the remaining) - We're looking at between 600 and 800 reconfirmations to manage. Spread the rest across 50 weeks, and you're only looking at 12-16 per week. Put it across 2 years, and you can half that.

What's more, I would expect a more lightweight confirmation system, rather than a full RfA (for example, focussing !votes on their behaviour as an admin and not wider ideological reasons) Worm^TT(talk) 16:13, 25 February 2021 (UTC)

I agree if there's a will, a way can be found. But I'm unclear if there is really a will for sufficient community members to provide a meaningful review of say 6-8 administrators a week for a hundred weeks consecutively, and then continuing at a pace of, say 3-4 a week if there's a 5-year term for admins. There also needs to be volunteers to manage the schedule to ensure that they occur at a suitable time: either to set it when the admin is available, or to confirm they don't mind having it at any time. (Some might want to vote in advance if they're going to be away; I suppose a voting page can be set up way ahead of time, with a scheduled time for close.) Of course, this may still be the best way forward to transition to having fixed terms. I think we need to calibrate expectations, however: for many admins, the review will be pro forma—though that'll likely be fine for the majority of admins. isaacl (talk) 16:46, 25 February 2021 (UTC)

Isaacl, I'm not too worried about the scheduling. If an admin knows they're going to be unavailable when theirs is due, they can just schedule the review early to reset the clock. Or, let their term expire, treat this like resigning not under a cloud, and run the review when they get back. -- RoySmith (talk) 17:43, 25 February 2021 (UTC)

I'm not worried about what will happen with an individual. There needs to be someone willing to keep track of the schedule for everyone, in order to spread out the initial reviews over two years, and to schedule the reviews each week after than, at a slower pace. To ensure a regular rate from then on, some admins will start with just two years between reviews, gradually increasing as time goes on. This is all absolutely doable, but some set of volunteers will have to do it, and that group will need sufficient active membership (with influx and outflux) to keep doing it indefinitely. English Wikipedia has long-standing ongoing programs for content-related matters, but I don't think there's anything at the same weekly scale for administrative tasks. isaacl (talk) 17:54, 25 February 2021 (UTC)

I love Wikipedia. Truly I do. I love a place where we can get bogged down in details about a hypothetical confirmation process in the middle of a discussion about a desysop process. Best, Barkeep49 (talk) 17:57, 25 February 2021 (UTC)

The specific details are not important and can obviously be changed. The key takeaway is that the process won't run itself, and so while the challenge may not be Mount Everest-scary, it's still a climb that has to be crested every week, indefinitely. That can sometimes be harder to sustain than a one-time push. isaacl (talk) 18:04, 25 February 2021 (UTC)

Isaacl, I'm sure somebody will write a bot to automate most of it. -- RoySmith (talk) 18:41, 25 February 2021 (UTC)

Certainly some of it can be automated; some of it needs interactions with admins and others and has to be done manually. Some tasks might not offer sufficient redundancy or flexibility if left solely to an automated process. Getting people to do things regularly on what would likely be at least a semi-weekly schedule is challenging. isaacl (talk) 18:53, 25 February 2021 (UTC)

Yes I intentionally used the word confirmation in my reply because I would fully expect that any system we have to be closely informed by the successful confirmation process stewards use rather than the RfA process we use for new admins (and which does have more parallels to the process used to select new stewards). Best, Barkeep49 (talk) 16:17, 25 February 2021 (UTC)

Process flowchart

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

I love this. Why not put it at the top. The text about it was very confusing to me. 🐔 Chicdat  ^{Bawk to me!} 11:36, 24 February 2021 (UTC)

A flow chart/picture speaks more than words. Thanks for this @Hammersoft:!Nalbarian (talk) 14:47, 24 February 2021 (UTC)

Thanks from me too. Nice work. --Tryptofish (talk) 21:04, 24 February 2021 (UTC)

Nice work. This does make it more clear. For something that was developed because "the ArbCom process is too difficult" this is pretty complicated. Beeblebrox (talk) 23:37, 24 February 2021 (UTC)

Well, it could have been laid out as essentially a straight vertical line—it just would have taken up more vertical space. I don't think it's complicated in the sense of having many different paths leading to different actions. It does (by deliberate design) have a lot of conditions that if not met will abort the process of initiating a discussion on removing administrative privileges or imposing other sanctions, and then the process to reach consensus in that discussion. isaacl (talk) 23:49, 24 February 2021 (UTC)

Thanks for creating this, but the fact that you did proves my point that is an extremely convoluted process. This is why I cannot support it.--Rusf10 (talk) 01:52, 26 February 2021 (UTC)

Rusf10, there are a great many steps in the arbitration process as well. It's just that the arbitration process rules evolved over time, rather than being developed all at once. AGK ■ 09:03, 26 February 2021 (UTC)

I agree. If we need a flow-chart, it's much too complicated for something as vital as keeping our admins in check. I'm still in support of the concept, but the specifics need adjustments before being ratified. Anarchyte (talk • work) 10:12, 28 February 2021 (UTC)

It is not 60%, it is 40%

This proposal's use of the 60% figure is cleverly misleading (even if not intentioned as such). Most users are familiar with the de-facto 70% threshold for RfAs and find the figure of 60% to be comfortingly close to that. The fallacy, which I suspect has eluded many, is that it is 60% votes for removal – and thus 40% votes for retention, which is a far cry from the 70% required for passing an RfA. Some users have suggested raising the bar to 65% (read 35%) which I find astonishing.

I think we should start talking in terms of the amount of support that an admin needs to have, because this is the way we've been used to thinking about it in RFAs. If the figure of the 40% had been used outright, this would have got lesser support than it has. – SD0001 (talk) 13:08, 26 February 2021 (UTC)

@SD0001: Huh... that's a bit weird. As one of the users who suggested raising the bar, I thought it was 60% votes for retention. I'll have to amend my comment. –MJL ‐Talk‐^☖ 18:16, 26 February 2021 (UTC)

So basically, an editor need overwhelming support to become an administrator, but only needs support from a minority to keep their administrator status. That's another problem with this proposal.--Rusf10 (talk) 01:05, 27 February 2021 (UTC)

We consider RfAs to be the community entrusting users with some extra tools, so it could make sense to compare "what percent of the community trusts you." Alternatively, we look for a consensus when changing the status quo, so it makes sense to consider a model of "consensus to make a change." If we want to alter or remove a policy, it'll require being north of 60% before it's clear do so. A sysop can retain their bit when nearly half of ArbCom has no faith in them. I think these are all flawed comparisons and analogies, but each has merit. I imagine it was mostly done for drawing a clear, simple line of demarcation. Besides, it's a novel proposal, so we might as well compare 40% for retention to the current 0%: nothing current is lost. ~ Amory (u • t • c) 01:13, 27 February 2021 (UTC)

That's an interesting phrase: "That's another problem with this proposal".

You are being asked to decide between two proposals:

1. 70% needed become an administrator, 40% needed to stay an administrator (this proposal passes).
2. 70% needed become an administrator, 0.001% needed to stay an administrator (this proposal fails).

And you only see a problem with the first of those two choices?

Note: I guesstimated that 0.001% by assuming that every person on Wikipedia except some of the arbcom members wants to get rid of the administrator. --Guy Macon (talk) 01:23, 27 February 2021 (UTC)

Well, the percentage factor needs to be fixed before this is passed. Unless we make it 60% or 70% to remain an admin in a de-sysop nomination, then the whole thing is toothless. We need to pass something that works, something that gets around the buddy system, where a given admin has enough friends among other admins that any de-sysop process is derailed by their friends. Otherwise, it just becomes a mockery to even start a de-sysop process.— Maile (talk) 01:30, 27 February 2021 (UTC)

This is what concerns me about this proposal. Any popular problematic admin could muster up 35-40% support. Under this proposal they wouldn’t be removed, but they might by ArbCom. If this proposal passes, it’s likely ArbCom wouldn’t touch the case anymore (“send it to the community”). If this happened, this proposal would be a serious net negative. ProcrastinatingReader (talk) 10:04, 27 February 2021 (UTC)

You are being asked to decide between two proposals... And you only see a problem with the first of those two choices? Yes, because only the first locks in a poor policy; a policy which is unlikely to be become a good policy through evolutionary change. The second leaves open the possibility of a good policy being proposed and accepted. It is not a single, binary decision, and I reject that dichotomy. We might as well compare 40% for retention to the current 0%: nothing current is lost. The potential for a good policy would be lost. - Ryk72 ^talk 01:56, 27 February 2021 (UTC)

So Guy is basically making the "its better than nothing" argument. Yes, the current process is not good and neither is this proposal. I'm not going to give support to something that because it may be slightly better than the status quo, put forth a better proposal and then I'll support it.--Rusf10 (talk) 01:34, 28 February 2021 (UTC)

Guy, your point is taken but in the interest of numeracy we should be realistic – I think 0.001% is probably incorrect. Most RfAs get only up to a couple hundred votes. There were 589 editors who commented at WP:FRAMBAN, which is probably a high water mark for anything admin-related. So let's use that to compute a percentage instead. Let's say several of 13 the currently active arbs recuse and use six voters for a conservative value. 6/589 is about 1%, not 0.001%. At worst you might have a fraction of the 144,229 active editors show up – let's say half for laughs, which is still 6/72,500 or around 0.01% so you are off by 10x at least. - Bri.public (talk) 20:02, 3 March 2021 (UTC)

(Smile) 67.43% of statistics on the Internet are made up on the spot. :)

As of Monday, 18 November 2024, 13:51 (UTC), The English Wikipedia has 48,281,942 registered users, 121,641 active editors, and 853 administrators. Together we have made 1,253,414,411 edits, created 61,860,690 pages of all kinds and created 6,912,473 articles.

So if I pretend that I bothered to calculate an actual number of as a percentage of a totally bogus number of users instead of just picking a number out of my hat, (smile) why not use registered users instead of active users? (Yes.I am being silly. And yes, "at lot fewer than 589" would be a far more useful number.) --Guy Macon (talk) 20:50, 3 March 2021 (UTC)

• I'd like to echo that I share the same thoughts about the False equivalency fallacy of the "reverse RfA" percentages, and I have commented my rationale about it here and here. Huggums537 (talk) 05:13, 27 February 2021 (UTC)

Not a false equivalency, an admin should have to retain the same broad community support he had to begin with. It's not like admins have terms that expire, they are give admin for life. The only way I would support such a high bar for removing an admin is if it was coupled with a proposal to give admins 2 (or possibly 4) year terms and make every single one of them go through a new RfA when their term expires. The community votes the admin "into office" and they should be able to vote them out.--Rusf10 (talk) 01:40, 28 February 2021 (UTC)

No such thing as maintaining the support you had to begin with when you have a life term. That's an absurd expectation, and unrealistic statement. An admin could lose the support they had only a year later for not really doing terrible things wrong when the community finds out they weren't as great as they thought they were, or they changed after they got the bit. A whole lot can change in a life term. The percentages are for sure a false equivalency, and saying an admin has to maintain his support can't be used as an excuse to change that. Huggums537 (talk) 03:13, 28 February 2021 (UTC)

The truth of the matter is that an admin doesn't need to maintain any support at all, they only need enough support to get the bit, and then they can be a jerk after that as long as they don't break any rules, but it doesn't matter because they have the bit for life unless they cross the wrong lines. Huggums537 (talk) 03:26, 28 February 2021 (UTC)

There's the problem right there, you find it acceptable for an admin to be a jerk. I don't. I believe admins need to be held to a higher standard. I don't accept poor performance for leadership. Apparently you do.--Rusf10 (talk) 06:32, 28 February 2021 (UTC)

You appear to have confused someone giving an accurate description of what exists with approval of same. I don't think you are being fair to Huggums537. --Guy Macon (talk) 08:37, 28 February 2021 (UTC)

Rusf10, Guy Macon is correct. I don't approve at all. Merely stating facts. I happen to know a few very good admins who would never be jerks, and I know a couple who are. I was only pointing out the same thing you were, that a lifetime appointment does present this problem, given that it allows them this choice. I also agree with you that a limited term would solve this since they would then be forced to keep their support for the next upcoming election. The only part where we disagree is the false equivalency on the percentages, and if you click on the links I posted above, you may find we agree there too. Huggums537 (talk) 10:46, 28 February 2021 (UTC)

41,43% — admin, who was topic-banned for speedy deletions and user bans by ArbCom, violated this prohibition and the admin flag was removed. With such a low criterion (40%), would he have to keep (obtain again) the flag? Why not give the flag to new members with a similar level of support?
We must not talk about the percentage for making a decision to remove the flag, no, we must talk about the level of trust in the administrator. ·Carn·!? 14:56, 14 April 2021 (UTC)

It's common (not illogical) to require a greater percentage / input to make a change. Including in Wikipedia And passing RFA and getting Desysopped are both changes. North8000 (talk) 17:55, 14 April 2021 (UTC)

"We can always change it later" is misleading

I think it has been brought up that many supporters of this proposal are admins, and it has been suggested that they have a personal stake in the outcome as a natural conflict of interest that might cause a majority of them to have a biased view towards any policies that would make it any easier to remove them from their position, regardless of whether it would be merited for other "bad" admins or not, especially if they had been influenced by fear-based arguments suggesting merited policies for "bad" admins would have detrimental and disastrous consequences for good ones. This is exactly what happened in the 2019 discussion. Because of this phenomenon, those who have supported this proposal will never allow any changes to occur very easily if this proposal passes. In other words, if this proposal turns out to be equally, or more difficult than ArbCom, as the opposers are telling you it will be, then don't expect any of these supporters who might be the biased ones to help you change it later. They won't. In fact, they'll oppose the changes later. So, if you've supported only because, "perfect is the enemy of good"; "it's not perfect", but "it's better than nothing", and you think, "we can always change it later", then you have deluded yourself into believing an ideaology that doesn't exist anywhere else other than the mind of someone who has been "Wikipedified". Huggums537 (talk) 05:56, 27 February 2021 (UTC)

I am probably totally spoiled by my education and job in natural sciences, but the argument of the type "admins do not want their flags removed, and this is why they have designed and mass-supported a proposal on removal of admin rights" does not make much sense to me. The only way I could make sens of it is if there is another proposal around which would make the process much easier, and admins do not want that proposal and this is why they came out with this one. Well, this theoretically could have happened, but in practice I do not see any proposal around which would make the removal of admin flag easy and has any chances to be supported by the community.--Ymblanter (talk) 08:01, 27 February 2021 (UTC)

What Ymblanter said; your argument appears to be "admins are trying to protect their status by supporting a proposal which makes it easier to strip them of their status", which makes no sense. In addition, I'm already suggested a mechanism (a hardcoded stick-or-twist expiry date for the process after which it needs to be formally readopted or rejected) as a way to prevent this becoming a part of the furniture if it does turn out to be somehow problematic; I'm sure there are other equally workable ways this could be done. ‑ Iridescent 09:13, 27 February 2021 (UTC)

There's ample history of industries proposing self-regulatory mechanisms to stave off external, usually government, regulation. The "stick-or-twist" isn't, in itself, a reason to support. - Ryk72 ^talk 09:59, 27 February 2021 (UTC)

Ymblanter and Iridescent, you have both misinterpreted my argument. A more accurate interpretation that would be closer to my argument is: admins do not want their flags removed, and this is why they have designed and mass-supported a proposal on removal of admin rights [that is harder than ArbCom], and admins are trying to protect their status by supporting a proposal which makes it easier [harder] to strip them of their status, respectively. Also, I do understand that Iridescent may be offering a workable solution as one of the non biased admins, but I think the biased ones wouldn't allow that either. Huggums537 (talk) 12:54, 27 February 2021 (UTC)

I just want to add that these interpretations (as well as the corrections) were not the focal point of my argument either. The focus of my argument is that the changes would be harder to make later, not easier. The fact that admins want to protect their status is really incidental. Huggums537 (talk) 13:09, 27 February 2021 (UTC)

This proposal is not a replacement for ArbCom desysops though, but rather another, community-based method. — J947 ‡ ^{message ⁓ edits} 18:48, 1 March 2021 (UTC)

This assumes that Arbcom won't start sending some percentage of desysop cases to the community, as they regularly do now with non-admin cases. --Guy Macon (talk) 20:54, 3 March 2021 (UTC)

We want a community desysop process, but if this isn't it - what is?

It is clear we want a community desysop process. It is equally clear that this proposed procedure is not the one we want. People are opposing with regret because they want a procedure, but see too many flaws in this. People are supporting reluctantly/in principle because despite the flaws, they'd rather have something than nothing, and many are expecting or hoping that the necessary changes will occur as part of the normal wiki process. I have supported because it is too easy to derail significant proposals like this, and it is important that we have a community desysop process so the community can feel more in control than they are at the moment. But while I have supported, to be honest there isn't much (anything?) that I like about the proposed idea. I don't like the way that a desysop has to be set up (via ANI) nor the way it is concluded (a focus on stoning the admin, and asking for quite a high percentage of stone throwing to desysop), and the middle section is also a little convoluted. Looking at comments, It seems a significant number of people share the same concerns. Can we use this opportunity to generate some community ideas on how we'd like a community desysop process to proceed, and then vote on the best of them? I'm increasingly uncomfortable supporting this proposal, but I do want to see a community desysop process happen.

The first aspect is the starting process. Tony's proposal is that a desysop process must start at ANI, and that to take the matter further a user must meet certain criteria. A number of people have issues with this idea for varying reasons - including that not all concerns regarding an admin may start at ANI (some users, for example, are concerned about Long-term nearly-inactive administrators), that it is dependant on an admin closing an ANI discussion with a statement that the admin under question acted "inappropriately", and that the user criteria limits those who are able to raise the issue. We do have WP:ADMINACCT, which allows "editors" to raise a concern with an admin: "Subject only to the bounds of civility, avoiding personal attacks, and reasonable good faith, editors are free to question or to criticize administrator actions." And that, surely, is also the first stage in any concern: raising the issue directly with the admin in question. It is only when the response is felt to be inappropriate or inadequate that it should be taken further. So, my suggestion is that, per WP:ADMINACCT, any editor may raise a concern with an admin, and if the response is inappropriate/inadequate, and the editor's concerns are clearly relevant to WP:ADMINCOND, they may request a desysop/reconfirmation RfA. A new noticeboard would need to be set up for making such requests. Appropriate responses an admin could make to the editor raising a concern would be: 1) Respond with a reasonable explanation 2) Acknowledge the concern and commit to addressing the issue going forward 3) Acknowledge the concern and voluntarily set up a reconfirmation process 4) Acknowledge the concern and resign permanently (under a cloud). Inappropriate responses would be 1) Ignore the concern (continuing to edit without responding within a reasonable timeframe) 2) Dismiss the concern, either bluntly or politely 3) Provide an inappropriate, inaccurate, or inadequate explanation 4) Commit to addressing the issue, but then failing to do so 5) Threaten or intimidate the editor.

To prevent disgruntled or mischievous users from making repeated desysop requests of either the same admin or different admins, any editor who makes three declined requests should be forbidden from making any more.

A specific page should be set up for making desysop requests. As per Tony's suggestion, this should be assessed and closed by a 'Crat. A link should be made to where the editor raised the issue with the admin. If the concern is regarding a long term inactive admin, then an email should be sent to the admin, and a reasonable time given to allow a response. Some people are concerned, though, of a simple knee jerk reaction being hastened to a full desyop session by allowing 10 users within 48 hours to agree; also, that it needs three admins. I'm not clear on what the alternative should be. In my experience most proposals tend to get support quickly and early, and it takes a while for the oppositions to start building. Some community input on what form the desysop request should take, would be useful. There should be a consensus, and there should be a time limit, but what minimum consensus and time is acceptable and appropriate? Does there have to be a certain number of admins agreeing? Is the admin requirement needed if a 'Crat is going to close anyway? If we keep Tony's 10 users, and use that as a minimum qualification, but allow the 'Crat to assess the consensus (so, for example, if 10 users agree, but 20 don't agree, then there is no consensus). And if we extend the time to allow for opposition (if appropriate) to the desysop to look over the concerns and put forward reasonable reasons why a desysop RfA should not happen. Because of weekends, etc, a minimum of four days could be allowed.

Now, the actual desysop vote/discussion. A number of people are unhappy with the proposed idea. We are already familiar with reconfirmation RfAs. The most notable being Fram's in 2019. It is a procedure that works. It is the procedure that most of those who are open to recall have selected for themselves. My suggestion would be that we use the existing RfA process as the means to decide if the community still retains confidence in the user to have the sysop tools. Consensus is assessed in the same way it is now. This allows the community to ask questions, and make a more detailed and sophisticated assessment than simply focusing on perhaps one incident. It also gets away from the negativity of voting to desysop (which some people may be uncomfortable with, and so may avoid voting) - instead asking the community if they have confidence in the user to be an admin. Other suggestions are welcome.

These are my suggestions for how the desysop procedure should work. Others should feel free to add their own so we can get a clear sense of what it is the community really want, and then move forward with that. SilkTork (talk) 13:36, 27 February 2021 (UTC)

Over 200 people have participated in this RfC. What's below is intended to be a straw poll exercise, correct? Best, Barkeep49 (talk) 14:41, 27 February 2021 (UTC)

If part of the rationale of starting this new discussion mid-RfC is that some editors who opposed did so "reluctantly", then one has to consider how many of those were actually reluctant, and how many were trying to be polite, or otherwise using the term for various rhetorical purposes. And the assumption that we already know that this proposal is not what the community wants is absolutely inappropriate. There's a reason that consensus is determined after a discussion is closed, and that the close is made by someone uninvolved. I know that SilkTork means well by this, but I think that it's highly problematic. --Tryptofish (talk) 21:07, 27 February 2021 (UTC)

My intention was to build on the momentum of this proposal and work out the aspects that are troubling people and invite more (not less) community involvement. I think we have a chance to get a community desysop process (CDP), but, curiously, one in which the community are not involved in the construction. What I think is clear is that the community want to have a CDP. What is also clear is that there are concerns with some, many, or all aspects of this proposal. So, while we are here, what I felt might be helpful is for the community to work out what would be a good proposal. What aspects could people agree on. Essentially, there are two approaches we can take here. The first is that we reject or accept the proposal as it stands. We can reject a CDP, even though we want one, because there are some aspects of it that we don't like. Or can accept a CDP that we think is problematic, just because we want such a procedure. The second approach is that we accept that we want a CDP, and as a community we actually work out the details and reach a consensus. In the first procedure we either get another attempt at a CDP turned down, or we get it accepted but with aspects that we find problematic. Some of those voting to accept appear quite happy with the proposal as it, some just want a CDP, and are not fussed with details; others, such as myself, are accepting - aware of the problems - but with a belief that we will iron out the wrinkles as we go along. As we always do. In the second we attempt to iron out the wrinkles before the CDP is launched. I was unclear from the moment I read the proposal as to which way I would vote. I am in favour of a CDP, but I have concerns about this one. I decided to support, not because I particularly like this scheme, but because we have been talking about having a CDP for so long but each proposal gets stalled, and I felt it was important to get one off the ground. But as more and more concerns were raised I started to feel uneasy. Does this proposal really address some of the issues that people have with admins, concerns that are not being met with either ArbCom, or our existing ways of dealing with problematic admins, particularly those who became admins a long time ago, are mostly inactive, but may at any moment step in and make an inappropriate admin action? I don't think it does. I'm reading the concerns, and I'm at the point where I feel that our current system, not quite adequate as it is, is better than this proposal. So better to keep what we have than to add in more problems. Though we can make this proposal work, if we fine tune it. Essentially there are three aspects: How to start a CDP, how to run it to ensure it is fair to the admin and to the community, and how to close it. My quick assessment of this page is that the concerns rest mainly on how the CDP starts and finishes in this proposal. If we all work together to address those concerns now, then we are more likely (rather than less) to get not just a CDP, but the CDP we want.

I'm sorry I've not been clearer with setting this up - I did it rather quickly yesterday before I went out. In retrospect it would have been better to get a few people to look at it before publishing it. SilkTork (talk) 12:18, 28 February 2021 (UTC)

As I said, I know you meant well, but I still think that this is a discussion for after the present RfC closes, whatever way it might close. --Tryptofish (talk) 19:42, 28 February 2021 (UTC)

To prevent disgruntled or mischievous users from making repeated desysop requests of either the same admin or different admins, any editor who makes three declined requests should be forbidden from making any more.

I don't think there should be such a hard limit. I think either an cooldown period or just the ability to give a restriction to it would work better Asartea ^{Talk | Contribs} 15:51, 12 March 2021 (UTC)

Editor should first raise concern with admin per WP:ADMINACCT

To initiate a desysop procedure a registered editor should first raise their concern with the admin per WP:ADMINACCT. Only if the response is inappropriate (examples include, but are not limited to: 1) Ignoring the concern (continuing to edit without responding within a reasonable timeframe) 2) Dismissing the concern, either bluntly or politely 3) Providing an inappropriate, inaccurate, or inadequate explanation 4) Committing to addressing the issue, but then failing to do so 5) Threatening or intimidating the editor) should the editor then initiate the procedure.

Support

1. Support. SilkTork (talk) 13:36, 27 February 2021 (UTC)
2. Support We do need something. Agree with first step. Huggums537 (talk) 13:51, 27 February 2021 (UTC)
3. Support You should always be able to discuss something with an admin. Failure to follow up on that is the root of the majority of administrator issues. Ritchie333 ^{(talk) (cont)} 18:26, 27 February 2021 (UTC)
4. Support. To tack onto what Ritchie said, you should try to work out most issues with any user before turning to the community for help. -- Calidum 19:56, 27 February 2021 (UTC)
5. Support per Richie — Ched (talk) 08:35, 6 March 2021 (UTC)

Oppose

1. Oppose I suppose this in principle, but as written it's a no. "Editors should first raise concerns with the admin" is fine. But plenty of concerns are dismiss-able, and what's 'inadequate' is in the eye of the beholder. Simplify to "Editors should first raise concerns with the admin", and I'm onboard. The point is for the discussion to happen and situations to de-escalate, or ambiguities resolved. And I'd also want to be clear that raising concerns can be done in many places, with various levels of formality. Headbomb {t · c · p · b} 20:50, 27 February 2021 (UTC)
2. Oppose. On further read, I think this goes too far. While a user should first contact an admin in most instances to discuss an issue, I think the restrictions are too much. -- Calidum 20:57, 27 February 2021 (UTC)
3. Oppose. An unnecessary step in a process that is already far too difficult. Coretheapple (talk) 16:04, 28 February 2021 (UTC)
4. Oppose " Dismissing the concern, either bluntly or politely" can well be the appropriate admin response to quite a few potential accusations from an individual. For example, If someone complains about a specific AfD close, sometimes the appropriate thing to do is to explain; sometimes the appropriate thing is tell them to go to Deletion Review. There are even some concerns, such as baseless complaints of prejudice, for which ignoring the request is appropriate. DGG ( talk ) 22:26, 1 March 2021 (UTC)
5. Oppose Headbomb and DGG raise some points that I feel must be addressed with the OP/supporters. 🐔 Chicdat  ^{Bawk to me!} 11:31, 5 March 2021 (UTC)
6. Oppose I am fully 100% on board with talking with the admin and sorting things out beforehand. That's dispute resolution 101 and should absolutely be a prerequisite if any community desysop guidelines go into effect as most issues get resolved by discussion. The part I'm not on board with is what both Headbomb and DGG have mentioned: oftentimes, dismissing or ignoring complains is oftentimes the right thing to do procedurally. If the above goes into effect, it could be abused by less knowledgeable users or bad faith editors who feel slighted because an admin correctly dismissed a claim they felt was legitimate. Discussion should be a requirement first (as with any conflict) but the above rules feel too strict. Jns4eva (talk) 20:14, 5 March 2021 (UTC)
7. Oppose. At least if anything like Tony Ballioni's proposal underpins this, there will have been specific event precipitating this that will on its face have already been resolved at AN/ANI/wherever. The issue is that the admin's behaviour, around this issue or a pattern including this issue, is felt by someone to be such the community has lost confidence in the admin. There is little to be gained here by forcing a "tell *me* what you're going to do otherwise I'll start a petition to -sysop" interaction. If someone feels the trust is gone, they start the process. If they're wrong, that start expires harmlessly with limited support. Martinp (talk) 20:53, 6 March 2021 (UTC)
8. Oppose It's a good idea to talk first, but this isn't quite the way I like it, now that I think about it. Who gets to decide what is "inappropriate", the editor or the admin? Huggums537 (talk) 08:04, 11 March 2021 (UTC)

Neutral

1. First of all, I have severe reservations about the way that this straw-poll-or-whatever-it-is is being started mid-RfC, and I do not want the closer of this RfC to interpret any comments that I make down here as indicating diminished support for the actual proposal being considered here. I also very much agree with the general principal that one should normally begin by discussing the concerns directly with the admin, unless there are other considerations that would get in the way. But as written, I cannot see this wording as an adequate addendum to the main proposal, because it's too restrictive. --Tryptofish (talk) 21:12, 27 February 2021 (UTC)

Comment

See, my impression was is that any kind of desysopping process that allows one editor on their own accord to start the process was a non-starter because of the "bad faith editors and POV-pushers will abuse it as an intimidation tactic" issue. I figure this is why Tony set the "must have an ANI thread" requirement, so that folks need to get some support from others before they can start the process. Jo-Jo Eumerus (talk) 13:46, 27 February 2021 (UTC)

"Must have ANI thread" is not necessarily bad; "Must have ANI thread with closure that the admin acted inappropriately" is terrible. - Ryk72 ^talk 13:50, 27 February 2021 (UTC)

The problem then would be "ANI thread closed with no finding of wrongdoing by the admin" cases. Jo-Jo Eumerus (talk) 16:41, 27 February 2021 (UTC)

Agree with Jo-Jo. The ANI thread idea is horrible all the way. Huggums537 (talk) 17:16, 27 February 2021 (UTC)

I'm not certain that this would not be filtered out at either the "10 endorsements" stage or the final vote stage. - Ryk72 ^talk 23:58, 27 February 2021 (UTC)

A successful intimidation effort does not require the process at the end to yield a desysop - people still get upset at perceived unfair treatment even if it's swiftly reversed. There is a reason we have policies like WP:INVOLVED even though an abusive block is usually quickly lifted. Jo-Jo Eumerus (talk) 10:04, 28 February 2021 (UTC)

Any editor submitting three declined desysop requests is forbidden from submitting any future requests

Support

1. Support. SilkTork (talk) 13:36, 27 February 2021 (UTC)
2. Support. If we're going to be serious about building a mechanism to automatically start a desysop process there's no problem with locking out an editor who has made *THREE* failed requests. Protonk (talk) 18:15, 27 February 2021 (UTC)

   So, then an editor who repeatedly gets denied for improperly formatting or some other technical reasons is now suddenly completely locked out under the guise of preventing malicious requests even though they may have a valid one? Huggums537 (talk) 18:27, 27 February 2021 (UTC)

Oppose

1. Oppose disenfranchising editors for being wrong. Clearly malicious requests can be addressed through other means. - Ryk72 ^talk 13:53, 27 February 2021 (UTC)
2. Oppose I think it should say 3 decline requests against the same admin, not 3 decline requests in general. [Moving to neutral]. Huggums537 (talk) 13:57, 27 February 2021 (UTC) Switch back to oppose. Have to agree with Ryk72. Other means can address malicious requests that won't completely deprive editors of being able to make valid requests when needed. Huggums537 (talk) 15:14, 27 February 2021 (UTC)
3. Per Ryk. Let the community deal with this if needed. -- Calidum 20:05, 27 February 2021 (UTC)
4. Oppose as written. Making frivolous requests should see the person blocked and banned for WP:DE. Simply being in a minority shouldn't result in the removal of privileges. Getting 'crats involved in recall moderation and empowering them to dismiss such requests should be enough. Headbomb {t · c · p · b} 20:54, 27 February 2021 (UTC)
5. Oppose as written. Maybe three failed requests about a single admin or something like that. --Tryptofish (talk) 21:14, 27 February 2021 (UTC)
6. Oppose for the same reason that we don't have a policy saying editors are banned from filing AfDs if their last n AfDs closed as keep. Disruptive behavior should be dealt with, but not using purely numerical checks. — The Earwig (talk) 03:54, 28 February 2021 (UTC)
7. per Headbomb. WP:DE will cover this. -- CptViraj (talk) 04:50, 28 February 2021 (UTC)
8. Oppose. Frivolous requests are already covered by policy as disruptive, as noted above. Coretheapple (talk) 16:06, 28 February 2021 (UTC)
9. Oppose There is a point at which repeated requests would be disruptive, but sometimes it could be one abusive or frivolous request; and sometimes , in addressing chronic problems, repeated failure to obtain actual desysop but which nevertheless change the direction of behavior, can be highly productive. DGG ( talk ) 22:31, 1 March 2021 (UTC)
10. Oppose this particular criterion, but there should be some sort of "immunity" once an admin has been through this process and kept the bit. Added a proposal below. Stifle (talk) 11:07, 2 March 2021 (UTC)
11. Oppose Unlikely to occur often, arbitrarily punitive, and I think it's better to resolve rules abuse with other methods, rather than overly complicate this proposal (which will be complicated and litigated a lot as is, if it is every used). —Wingedserif (talk) 15:45, 2 March 2021 (UTC)
12. Oppose per Headbomb, Coretheapple and DGG. A limit of nominations about a single editor in a given period of time would be propotionate, but it would occur so infrequently as to be pointless and the chances of it not being disruptive editing of some sort are so slim that it would be redundant. Thryduulf (talk) 16:39, 2 March 2021 (UTC)
13. Oppose because this is CREEPy. 🐔 Chicdat  ^{Bawk to me!} 11:25, 5 March 2021 (UTC)
14. Oppose. The existing toolkit on disruptive behavior is sufficient. Martinp (talk) 20:55, 6 March 2021 (UTC)

Neutral

1. Neutral I will move my position to "support" if SilkTork will modify it to say 3 declined requests against the same admin, rather than 3 declined requests in general. Huggums537 (talk) 14:07, 27 February 2021 (UTC) [Moving back to oppose. Final answer.] Huggums537 (talk) 17:58, 27 February 2021 (UTC)
2. I don't think I'd make this mandatory, but if somebody keeps filing rejected desysop requests, they can be sanctioned (via a topic ban or block) using the usual procedures. Ritchie333 ^{(talk) (cont)} 18:45, 27 February 2021 (UTC)
3. I would support if there was a time frame here - something like: Any editor submitting three declined desysop requests withing a year is forbidden from submitting any future further requests for a year. — Ched (talk) 08:28, 6 March 2021 (UTC) Also support the sanction option that Ritchie mentions. — Ched (talk) 08:33, 6 March 2021 (UTC)

Comment

@SilkTork: To clarify, is this a request which fails to get to a vote, or a request which fails to desysop? - Ryk72 ^talk 14:05, 27 February 2021 (UTC)

I was looking to prevent malicious requests. So the intention was for requests which don't get forwarded to a desysop RfA. I share some of the concerns expressed so far. SilkTorkAway (talk) 14:17, 27 February 2021 (UTC)

A "Request Desysop/Reconfirmation" page should be set up under the authority of 'Crats

Having raised their concern with the admin, and not receiving an appropriate response within a reasonable time, an editor may post their desysop request to a special "Request Desysop/Reconfirmation" page that can only be closed by a 'Crat.

Support

1. Support. SilkTork (talk) 13:36, 27 February 2021 (UTC)
2. Support Sounds like a good idea. Huggums537 (talk) 13:59, 27 February 2021 (UTC)
3. Support Absolutely. This should not be done unless crats are involved. Headbomb {t · c · p · b} 20:55, 27 February 2021 (UTC)
4. Support Sounds reasonable. Sysops as well as editors should first be given the possibility of clarify the issue between/for themselves.Paradise Chronicle (talk) 01:09, 28 February 2021 (UTC)
5. Support this seems to have more possibility of passing than the main one. 🐔 Chicdat  ^{Bawk to me!} 11:32, 5 March 2021 (UTC)

Oppose

1. We have a bad habit of saying "let the Crats deal with it" without asking the Crats, who were not selected to do this task. This is a mistake I've made in the past as well, but have learned from. In the past, Crats have been very, very reluctant to have their role expanded, understandably, from one of reading consensus and applying policy in non-controversial situations, to doing other things that are more controversial, or wrapped in controversy, like desysoping. Bots and reading consensus at RFA is their primary remit (along with flipping bits when consensus and/or authority is crystal clear), which is very different than proposed here. Dennis Brown - 2¢ 17:25, 5 March 2021 (UTC)
2. Oppose. In the original proposal, crats are the ones who check whether the conditions to force a "recall discussion"/de-RFA/whatever are satisfied. While not exactly in crats' current remit, it's a reasonable stretch: they impartially judge consensus to +sysop, so it's reasonable they're trusted to say "look, agreed community conditions are met that it should be checked if you still retain community trust". However, part of what I like about Tony's proposal is that ill-concieved (whether frivolous or merely misreading the situation) attempts to start a desysop discussion just wither away with minimum drama. Making the whole thing a Process under the Aegis of the Crats is making it a big deal, one of several rounds of trial by fire. I think this proposal, in a well intentioned attempt to shield admins from inappropriate "recall petitions", actually makes them a bigger deal. Martinp (talk) 21:06, 6 March 2021 (UTC)

Neutral

1. It's not clear to me how this differs from the main proposal. --Tryptofish (talk) 21:16, 27 February 2021 (UTC)

   It's the same I think. Just making it explicit as Tony's proposal doesn't set out where the request should take place. SilkTorkAway (talk) 22:27, 27 February 2021 (UTC)

A request can only proceed to a "Desysop/Reconfirmation RfA" after at least ten users have voted and at least four days have passed

When a Crat assesses the consensus to move the matter forward to a "Desysop/Reconfirmation RfA" they must be sure that at least ten users have voted, at least four days have passed, and that there is a clear consensus to take the matter forward.

Support

1. Support. SilkTork (talk) 13:36, 27 February 2021 (UTC)
2. Weak Support I think a minimum of seven days is much better. Huggums537 (talk) 14:01, 27 February 2021 (UTC)
3. Support. With the caveat that there should be no requirement for any of the endorsers to be admins. -- Calidum 20:03, 27 February 2021 (UTC)
4. Support If Calidum's concerns are followed, then strong support. 🐔 Chicdat  ^{Bawk to me!} 11:35, 5 March 2021 (UTC)

Oppose

1. Again, this is trying to force Crats into a role that I'm not sure they want to accept, and they didn't agree to take on. Dennis Brown - 2¢ 17:26, 5 March 2021 (UTC)
2. Oppose. This and the previous proposal try to turn this "is there enough concern to have a de-RFA discussion" stagegate into a consensus-reading exercise brokered by crats, turning it into 2 stages that are essentially the same, just differ in scale. The true community discussion, seeking consensus whether there is continued trust in this admin holding the bit, should happen once. Whether to move the matter forward should just be a check whether there is any groundswell of concern. Just like political recall petitions focus on sufficiently many valid signatures demanding a recall, not an attempt to gauge whether the supporters or opposers have more support. I could see a role for crats to exclude obviously biased/vindictive/uninvolved petitioners, to wait at least x days, or whatever, but not to do a "de-RFA lite" to decide whether to proceed to "de-RFA-for-real". As a separate point, I disagree with Calidum and Chicdat regarding removing a requirement for admin endorsers. I actually think it's very prudent to require a couple admins to also express concern, since they are more likely to be familiar with the stresses of adminship. If not even 3 admins think there is a cause for concern, then the only route to de-admin can continue to be ArbCom. Martinp (talk) 21:19, 6 March 2021 (UTC)

Neutral

1. Again, I'm finding it hard to pinpoint how this differs from the main proposal. --Tryptofish (talk) 21:18, 27 February 2021 (UTC)

Hi, this is about details of the main proposal so everyone can see how we like them. 🐔 Chicdat  ^{Bawk to me!} 11:35, 5 March 2021 (UTC)

A request can be closed by a Crat at any time if it appears inappropriate or unlikely to succeed

A request can be closed by a Crat at any time if it appears inappropriate (such as the admin wasn't contacted, or gave an appropriate response) or it appears after a reasonable amount of time to clearly be unlikely to succeed (such as 50 users in 48 hours rejecting the request, and only the one editor supporting it).

Support

1. Support. SilkTork (talk) 13:36, 27 February 2021 (UTC)
2. Weak Support (move to oppose) I was going to oppose this at first because it seemed to be able to take the desysop out of the hands of the community, and potentially place it in the hands of a "bad" admin's 'Crat buddy, but the way it is worded seems like it might allow the community to prevent that from happening. Huggums537 (talk) 14:01, 27 February 2021 (UTC) [Move to oppose in this]. Huggums537 (talk) 17:44, 27 February 2021 (UTC)
3. Weak support. I've already written above that I oppose the whole part of insisting the admin be specifically contacted prior to the de-RFA "petiton", and also that I oppose this preliminary stage being a consensus-seeking exercise. So I disagree with both of the "such as" phrases in this proposal. But I do support allowing Crats to close the request/petition if it is clearly inappropriate or unlikely to succeed, under our principles of SNOW. That being said, I also agree with Tryptofish below that misguided or disruptive requests/petitions are pretty harmless, since they will just wither away, so this is more in the spirit of cleanup than anything else. Martinp (talk) 21:25, 6 March 2021 (UTC)

Oppose

1. Oppose The more I think about it, the more I dislike the possibility that a "bad" admin could have a 'Crat buddy who could take the decision away from the community. Huggums537 (talk) 17:51, 27 February 2021 (UTC)

   I suspect if that happened, the 'crat in question would have their head on a plate and given a mighty kicking. Here is an example of the community getting quite upset at a 'crat appearing to go above their station. Ritchie333 ^{(talk) (cont)} 18:57, 27 February 2021 (UTC)

   Well, let us hope so then. In the meantime, my position remains opposed. Huggums537 (talk) 23:22, 27 February 2021 (UTC)

2. The endorsement period should be enough of a safeguard against this issue. -- Calidum 20:04, 27 February 2021 (UTC)
3. I'm not strongly opposed to this, but once it becomes clear that there will probably be a consensus against desysopping, it's not going to be too stressful to just let the process play itself out. --Tryptofish (talk) 21:20, 27 February 2021 (UTC)
4. Oppose too much potential for abuse. Coretheapple (talk) 16:07, 28 February 2021 (UTC)
5. Oppose What if the admin in question is also a 'crat? 🐔 Chicdat  ^{Bawk to me!} 11:37, 5 March 2021 (UTC)
6. Again, I haven't seen anyone ask the Crats what they think of this new responsibility, which is wildly outside their normal remit. You are asking them to be judges and to "Dismiss with prejudice" a case against an admin, which they aren't likely to do since it would be controversial and Crats generally only do uncontroversial things, so the rule becomes moot. Dennis Brown - 2¢ 12:16, 7 March 2021 (UTC)

Use "Reconfirmation" RfA

To assess community confidence in the user to remain as an admin, we use the existing RfA process with the same criteria as existing RfAs.

Support

1. Support. SilkTork (talk) 13:36, 27 February 2021 (UTC)
2. Support as an acceptable option. Would accept a "pass" mark as low as 50%+1. - Ryk72 ^talk 14:00, 27 February 2021 (UTC)
3. Support I suggest questions should relate to events a Sysop was active and/or on general WP:policy/guidelinesParadise Chronicle (talk) 18:50, 27 February 2021 (UTC)
4. Support Admins have too much power. ArbCom has too much power. Wikipedia feels to me like an oligarchy. 🐔 Chicdat  ^{Bawk to me!} 11:24, 5 March 2021 (UTC)

Oppose

1. Strong Oppose A community vote about the wrongdoing of an admin, and an RfA are two fundamentally different things. In an RfA, all of the good things about an editor are reviewed to see if they are fit, and qualify for the tools. In a discussion about wrongdoing, suspect actions are coming under scrutiny. Votes are very likely to go in two polar opposite directions depending on which discussion you enter into. We should not be giving admins who have come under scrutiny for losing community trust the benefit of having an RfA "popularity" discussion that would be more appropriately conducted in a discussion about wrongdoing. Huggums537 (talk) 15:01, 27 February 2021 (UTC) I just want to add that this kind of process would be very much the same thing like taking evidence of a problematic editor to ANI, and just allowing them to make their unblock request right there before they've even been blocked, rather than letting the discussion run. Huggums537 (talk) 19:08, 27 February 2021 (UTC)
2. I strongly oppose using this system in place of the percentage thresholds and approach of the main proposal of this RfC. And if the intention here is to require a new RfA in place of the main proposal, then how does one decide that a reconfirmation is going to be required? And once someone is desysopped, a new RfA is already self-evident as the way to get the tools back again. --Tryptofish (talk) 21:25, 27 February 2021 (UTC)
3. . The purpose is different: in a RfA, we're guessing about suitability; in a discussion about desysop, there are usually specific issues, and the format of our current RfA would very probably lead to argumentation which would increase the conflict. Indeed, many potentially good admins already decline to apply because of the nature of our RfAs--conducting them in circumstances like these would be many times worse. DGG ( talk ) 22:35, 1 March 2021 (UTC)
4. Strong oppose. Existing admins can easily fall below 75% support. IMO the purpose of requiring supermajority support for RfA is not just to ensure strong consensus for promotion, but also to ensure that the decision is not easily reversed by a trivial issue a few months later. I think 50% is a good threshold for retaining adminship (not 40% as proposed by OP, or 75% as proposed here). -- King of ♥ ♦ ♣ ♠ 17:56, 2 March 2021 (UTC)
5. Oppose. Recentism/availability heuristics will mean that decisions will be tainted by what has recently happened. Stifle (talk) 10:08, 3 March 2021 (UTC)
6. Oppose as per DGG. No need to rehash his comments. Dennis Brown - 2¢ 17:28, 5 March 2021 (UTC)
7. Strong oppose, I think. I interpret this that admins dragged through this process need to reach a consensus to *keep* the bit, with some debate whether it should be the "supermajority" needed for a new +sysop, or some slight leeway as has historically been given for highly-irregular reconfirmation RfAs. I feel pretty strongly that instead we should require consensus to *remove* the bit.

In fact, as I read this further, I'm realizing there is a very important fundamental difference between Tony's proposal and SilkTork's. In Tony's proposal, there's a "recall petition" with some conditions to make sure enough active community members are concerned, and then a "de-RFA" (at RFA) to seek consensus to -sysop. In SilkTork's, the "recall petition" stage is already a crat-brokered discussion where a "mini-consensus" is needed to proceed to the next stage of -sysop, which is then a reconfirmation RFA needing consensus to keep the bit. I think this is much more prone to abuse and much more stressful, and will end up -sysoping many more admins. The participants in the 1st stage get to say, "we're not really desysoping, we're just saying it should be thought about" and then the 2nd stage will invariably end up saying "well, there was a consensus that X should maybe lose the bit, so it's tautologically clear we don't have supermajority trust in X". If this is right, then I strongly prefer Tony's proposals to SilkTork's. Martinp (talk) 21:38, 6 March 2021 (UTC)

Neutral

1. This proposal requires fleshing out before I can favor or oppose. Coretheapple (talk) 16:10, 28 February 2021 (UTC)
2. Ditto. Is this the same proposal as TonyBallioni's but with no special requirements beyond the need for an AN(I) consensus? Jo-Jo Eumerus (talk) 10:51, 3 March 2021 (UTC)

Comment

1. While it should be a vote of some sort, this is too vague for me to comment further. -- Calidum 20:01, 27 February 2021 (UTC)
2. I agree that the proposer should flesh it out. How does this begin? Someone starts an RfA by saying "I think this admin should be desysoped as they are no good for the following reasons?" And then it goes to a vote? Maybe it becomes known as an "RfD" (Request to Desysop}? That is straightforward, I will say. Coretheapple (talk) 16:12, 28 February 2021 (UTC)
3. I was under the impression that the original proposal intended to use reconfirmation RfAs. Anarchyte (talk • work) 07:15, 1 March 2021 (UTC)

Repeated requests

To avoid vexatious requests, an admin subject to a desysop request that failed may not be subject to a further desysop request:

• for any reason within 1 month after a request fails due to lack of endorsements
• for any reason within 3 months after a request fails due to a lack of consensus at the one-week RFDA
• at any future time based on the AN thread(s) cited at the time of the first-mentioned request.

Support

1. As author. Stifle (talk) 09:39, 2 March 2021 (UTC)

Oppose

1. Oppose Consensus can change. 🐔 Chicdat  ^{Bawk to me!} 11:39, 5 March 2021 (UTC)

Comment

To ensure an admin gets some respite after a failed request and that once a particular piece of conduct has been cited it cannot be used again. Stifle (talk) 09:39, 2 March 2021 (UTC)

The Elephant In The Room

Basic Truth #1:
For many years, every time there has been a discussion about how one should gain and lose the sysop bit, there has been an overwhelming consensus -- often above 70% -- that the current system is badly broken and needs to be fixed.

Basic Truth #2:
For many years, the finest minds on Wikipedia have proposed a wide variety of solutions to the above problem, every one of which fails to achieve consensus. Many don't hit 10%. A few do somewhat better, but never enough to pass.

Every time I see a new proposal, I wonder if this will finally be the one that breaks the pattern. Every time I end up disappointed. Nonetheless, hope springs eternal. --Guy Macon (talk) 15:02, 27 February 2021 (UTC)

Congrats for hitting just what we've all been thinking for 20 years! 🐔 Chicdat  ^{Bawk to me!} 11:46, 5 March 2021 (UTC)

*bing* full marks to Guy for hitting the nail squarely on the head. Ritchie333 ^{(talk) (cont)} 18:30, 27 February 2021 (UTC)

Exactly! Thanks Guy Macon for saying this! --Tryptofish (talk) 21:26, 27 February 2021 (UTC)

What's "badly broken" about the current system? Maybe the first step is getting a consensus on what the problem(s) is/are. Then you have a foundation on which to have discussions about proposals to address the problems and how they are intended to fix them. – wbm1058 (talk) 23:16, 27 February 2021 (UTC)

(edit conflict) Note that I said that there is an overwhelming consensus that the current system is badly broken and needs to be fixed. Take your own poll if you doubt this. I did not imply that there was a consensus an how it is broken. That's part of the problem. When the finest minds on Wikipedia proposed a wide variety of solutions, many of them started by attempting to get a consensus on what the problems are. So that isn't the magic bullet either. Very seldom do I see any proposed solution that has not been tried and failed multiple times.

Pretty much every time I have expressed the above "two basic truths" opinion in the past multiple readers end up saying to themselves "That's easy to fix. All you have to do is X!". But they never quite manage to get the consensus needed to get the community to try X. One can only hope that finally, this conversation is the one the succeeds in making a change. Just because all previous efforts have failed, that doesn't prove that all future efforts will. --Guy Macon (talk) 00:48, 28 February 2021 (UTC)

I have long argued for precisely that. But, there's been little work towards that end. It's easy to come up with processes for de-adminship. Lots and lots and lots of well meaning editors have done exactly that. This is yet another one. Unfortunately, depending on the experience of the closer of this RfC, this stands a chance of being accepted as policy, without any work being done beforehand. We might as well build the Empire State Building first and then be completely random about what foundation we put it upon. Who cares if it falls over? Who cares if it destroys lots of buildings around it? It's better than nothing! <Sigh> --Hammersoft (talk) 00:41, 28 February 2021 (UTC)

Good point. Of all the solutions I have seen proposed, very few have bothered to even search and see if a previous proposed solution was similar. My own "That's easy to fix. All you have to do is X!" theory that won't work is to start by spending the huge amount of time needed to document all or most of the previous efforts to define the problem and efforts to fix the problem in one place. Needless to say, the words "I have long argued for..." are an example of Basic Truth #2 above. :) --Guy Macon (talk) 00:57, 28 February 2021 (UTC)

It occurs to me that most policy-related issues that come before the community do not combine (a) the construction of a multi-step, brand-new process with (b) something that feels high-stakes because it involves removing a privilege previously conferred. There are proposed policy changes that deal with things people feel strongly about, but they typically do not require the creation of a new process. I think it may be baked into the basic idea of a new, community-based desysop procedure that, no matter how it may be constructed, it will present an unusually large target for people to find something, somewhere within the proposal, that they disagree with. --Tryptofish (talk) 19:55, 28 February 2021 (UTC)

Alternate elephant in the room

I consider that the real "elephant in the room" is that, instead of fixing RfA, we instead try to create umpteen processes for deaminship instead. --Jules (Mrjulesd) 12:24, 3 March 2021 (UTC)

• agreed. - Nabla (talk) 20:00, 3 March 2021 (UTC)
• Exactly. I would add Basic Truth #3 to the mix here: that there IS no "overwhelming consensus" -- obviously -- that it is usually easy to get a majority to back an abstract We Should Change The System! protest vote (see real world politics for many sad and sorry examples), and that quite a few people who vote for "Throw da bums out!!" in the abstract balk when it comes to facing up to concrete choices. (This is why, rather cannily, the brick throwers usually cast their protest proposals in as vague a set of terms as they can, so they can thereafter claim an "overwhelming consensus" around What The People Want.) Ravenswing 13:08, 5 March 2021 (UTC)
  • I disagree. There is a very real difference between "no consensus that there is a problem" and "overwhelming consensus that there is a problem, no consensus on a solution." You appear to be saying that the latter consensus cannot possibly exist. --Guy Macon (talk) 13:59, 5 March 2021 (UTC)
    • I think this RfC fails to demonstrate that there is "overwhelming consensus that there is a problem". But you could also say that, until a satisfactory process is found, any "overwhelming consensus that there is a problem" is moot, because what if a satisfactory non-committee process doesn't exist? --Jules (Mrjulesd) 15:09, 5 March 2021 (UTC)
      • This proposal has roughly 60 percent support. On top of that, many of those in the oppose and neutral columns, such as myself, have acknowledged there is in fact a problem but believe this is an imperfect solution (for whatever reason). That's a pretty strong consensus. -- Calidum 16:16, 5 March 2021 (UTC)
        • As I said above, every time I see a new proposal, I wonder if this will finally be the one that breaks the pattern. Every time I end up disappointed. Nonetheless, hope springs eternal. Will this proposal be the one that breaks the pattern? Could be. Even long standing patterns such as "No snow in Malibu, California" sometimes get broken[8] Or maybe not.[9] --Guy Macon (talk) 16:57, 5 March 2021 (UTC)
        • As always, it's believe a supposed problem exists, believe a supposed solution exists, but become disappointed when the supposed solution is inferior. Wash and repeat. --Jules (Mrjulesd) 18:57, 6 March 2021 (UTC)
          • Difficulty in solving a problem does not equate to the non-existence of a solution – nor to the non-existence of the problem. --Tryptofish (talk) 19:10, 6 March 2021 (UTC)
            • But what problem? Can you really demonstrate that a problem exists? As far as I'm aware Arbcom does a reasonable job, or at least a better one than the "evil step-child of RfA" is likely to muster. --Jules (Mrjulesd) 21:57, 6 March 2021 (UTC)
              • First of all, I agree with you that ArbCom currently does a pretty good job as is. But elsewhere on this page you will see discussion in which a member of ArbCom points out that there are some things that ArbCom might want to have the community more involved in. It strikes me as a little glib to dismiss the hard work of so many members of the community, trying to figure out workable improvements, as "wash and repeat". --Tryptofish (talk) 23:43, 6 March 2021 (UTC)
                • Why am I so dismissive? Firstly because we should be fixing RfA instead. Secondly, because inferior parallel processes are never helpful. Thirdly, because perennial proposals are usually wrong and a waste of time, and this is no exception. Fourthly, because I don't want admins go through evil processes. Jules (Mrjulesd) 08:52, 7 March 2021 (UTC)
                  • I don't have a problem with the substance of your views about desysopping, but I'm just very, very tired of the culture of editors being dismissive of other editors' sincere concerns. You can express the views you have without being disrespectful. --Tryptofish (talk) 23:47, 7 March 2021 (UTC)

It's still debatable whether or not the Committee 'does a good job' - there is no arbitration, unless of course the current case is going to finally break the pattern and at least examine the veracity of the claims and the behaviour of the plaintiffs before pronouncing their verdict and imposing the heaviest sentence they can, because they can. Otherwise, IMO all Arbcom really does (those who are left after the recusals and those who are conveniently on a Wikibreak) is read the consensus of all the involved, non-involved, and wannabe WikiCops (the regulars' at the noticeboards) and gives the frenzied mob what they want to hear. Sometimes it seems as if the decorum of the participants is no better than that of the peanut gallery at ANI and is equally blockable or desyopable. Arbcom cases are lopsided anyway because it's all about prosecution and 'evidence' and little or no defence is permitted. Not many alternative solutions the community can come up with will be more equitable, or effective, as the case may be, and cases are so rare a trial would need to last for 5 years in order to be a reasonable sample. Kudpung กุดผึ้ง (talk) 09:54, 7 March 2021 (UTC)

When you applied for an Arbcom. seat in 2019, presumably you must have considered it a role worthy of your time & effort. You had no designs on the reform of Arbcom. You subsequently had your Admin. privileges removed by the same committee of which you might have been a member. Do sarcastic comments about AC members ‘’conveniently on a Wikibreak’’, ‘’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’’, etc. not simply indicate rejection bitterness? Persistently repeating tired tropes; ‘’frenzied mobs, the peanut gallery, wannabe WikiCops’’ relating to the wider community, is also unhelpful. If you have evidence, please produce it rather than making broad based unsubstantiated attacks. Leaky caldron (talk) 12:41, 8 March 2021 (UTC)

• Yeah, sorry to the commenters above, but 58% in favor (which is where the proposal now stands) is a majority. It's certainly not a "consensus," let alone an overwhelming one. No one would dare to change a policy or a guideline with such a margin, no AfD would pass with one, no action at ANI would pass with so small a margin, and a RfA with so small a level of support would fail ... presuming the candidate didn't just call the whole thing off early on the (accurate) premise that a candidacy with as many as 40% in opposition was doomed. Ravenswing 19:16, 7 March 2021 (UTC)
  • The reality is there is no percentage. There's someone above who indicated there's 60% support and that this means there is strong consensus. This is patently false. You don't evaluate consensus by counting votes. It is clear from the oppose and support votes that there is very strong disagreement about this proposal. Many of the support and oppose votes are equivocal at best, and describe things wanted in the proposal that aren't in the proposal. I am deeply concerned this proposal is going to be closed by an inexperienced or not very well experienced closer. This will generate an enormous amount of controversy surrounding this proposal if the closer decrees it as successful. Even a very experienced closer is likely to achieve the same result. No discussion about this proposal regarding its closure occurred before it was launched. Now we're left in this conundrum of how to go about closing it. It is fraught with difficulty. This was wholly predictable because the pre-homework that needed to be done to lay out the foundations of this proposal was not done. We're talking about a fundamental shift in the operation of the project that could cause a catastrophic destruction of the admin corps. This should never have moved forward in its current form, and now we're left with this badly divided mess. Some enterprising and well-meaning closer will attempt to close, not realizing the tsunami they are unleashing. But, I guess if you throw enough spaghetti against the wall something will eventually stick, and to hell with the consequences. I have real doubts any closer is going to read through the more than 100 printed pages worth of commentary on this proposal. --Hammersoft (talk) 19:53, 7 March 2021 (UTC)
    • Since you’re (mis)quoting me, I feel I should reiterate that I did not say there was a strong consensus for this community desysop procedure. I said there is a strong consensus that a community desysop procedure is needed given that even some of those opposed or neutral to this proposal have said so. And just a friendly word of advice, lose the hyperbole. It does your cause no good. -- Calidum 20:10, 7 March 2021 (UTC)
      • Consider that your words can be read from multiple perspectives and that text based communications have their limitations. I wasn't attacking you, and would prefer you didn't take negative where negative wasn't intended, and that you did return that perceived negativity towards me. I also made no exaggeration of any kind. I speak what is the truth from my perspective. --Hammersoft (talk) 03:21, 8 March 2021 (UTC)

Might I gently point out that some of you have hijacked this section and are no longer talking about the topic at the top? Might I suggest that you create a new thread and move whatever the heck the above is there so the rest of us can discuss Basic Truth #1 and Basic Truth #2 in peace? --Guy Macon (talk) 15:39, 8 March 2021 (UTC)

But what if we disagree with your "basic truths"? This is a comments section after all. My "basic" truth is that we would be better off fixing RfA. --Jules (Mrjulesd) 15:59, 8 March 2021 (UTC)

If you want to disagree with my "basic truths" this is the correct section. If you want to talk about other things with comments like "culture of editors being dismissive of other editors' sincere concerns", "consider that your words can be read from multiple perspectives" and "arbcom cases are lopsided anyway because it's all about prosecution and 'evidence' and little or no defence is permitted" -- and yes, even "My 'basic' truth is that we would be better off fixing RfA" -- that's fine, but please do it in your own section rather than hijacking this thread with material that has nothing to do with my argument. --Guy Macon (talk) 00:56, 10 March 2021 (UTC)

This is silly since it never hijacked your thread, it was quite separate. But very well I have created a new thread instead. --Jules (Mrjulesd) 01:02, 10 March 2021 (UTC)

Trial period

I wonder how many people in the oppose or neutral camps would be willing to support a fixed-length trial period (say, 12 months), after which we would return to the status quo ante pending positive consensus to adopt the procedure indefinitely.

As lots of people have noted (here, and every time, as well as at every proposed change to RfA) there's an awful lot of "something must be done!! ... but ehhh not this particular thing." That attitude is part of the premise for a proposal like this, and so any such proposal should have a trial period. There are a lot of unknowns and a lot of valid concerns. My hope is that people would be willing to be optimistic, with the assurance that it has an end date if it doesn't work.

So are there enough people who would be willing to say "it's not exactly what I want, but it's better than nothing so worth trying for a year" and switch their !vote? — Rhododendrites ^talk \\ 21:59, 27 February 2021 (UTC)

• For my part, no. I will not support a process that has potentially massive repercussions without there being a careful development process that includes situational examination and determination of problem analysis. The German Wikipedia suffered massive attrition to their admin corps when they implemented their process. That was an unintended consequence. I think we will see the same sort of massive attrition with this process, in that a great many administrators won't even bother to defend themselves once this reaches the fifth diamond on the process flowchart. This is, I think, largely due to the fact of the almost completely absent protections built in to this system, and the reality that there is no built in ability for an administrator to defend themselves at any step of this process. It's a bad process from start to finish. Giving it a trial run could have dramatically negative effects on the project. --Hammersoft (talk) 22:51, 27 February 2021 (UTC)

  The main proposal has far too many issues that make me want to stay firmly opposed, but the one suggested by SilkTork seems much more workable. I have some hope for it. Huggums537 (talk) 22:58, 27 February 2021 (UTC)

  Adding that if I did not stay firmly opposed, then I would for sure require a trial period, but I do stay firmly opposed to the proposal. Huggums537 (talk) 07:51, 2 March 2021 (UTC)

  There are already quite a few supports that have stated in them that they'd want a trial. It's not clear in many cases whether those are viewed as conditional or not, some are clearly such. I've actually gone for being neutral if a trial, oppose if not. I think some more would move if clearly needing future reapproval, but I'm not sure how many Nosebagbear (talk) 02:38, 28 February 2021 (UTC)

  I think even those like myself who basically approve it are so uncertain about the optimal details that it would be foolhardy to adopt a major change like this without a trial. Hammersmith, whatever parameters we use, I do not think there will be massive requests, and we can't know what precautious we need and what special cases we must provide for without a test period. If we try to get everything right in a complicated process before we start, we will never start. DGG ( talk ) 12:12, 28 February 2021 (UTC)

• I would not support even with a trial period because I think, as the proposal is framed, there is no chance of a desysopping ever being enacted, no matter how long a trial period offered. We have here a proposal for desysopping that will not likely ever result in a desysopping, because the conditions are such that they are not likely to ever be met, but is likely to increase the very problems that exist now at ANI ... abusive admins will rush to close to protect other abusive admins so that the conditions can never be met, and boomerangs will increase to shut down anyone who complains. That system is already viewable as a trial. SandyGeorgia (Talk) 12:35, 28 February 2021 (UTC)

I agree with what SandyGeorgia says above. I could support a trial period if I thought that the proposal had some realistic chance of working but that's not the case here. Moreover, as SandyGeorgia notes, the proposal will make things much worse at ANI. The admins are already reluctant to criticize each other in AN and ANI threads. They will only close ranks further if this proposal is enacted, even on a trial basis, and if they know that closing an ANI thread with a formal finding against another admin constitutes a prerequisite for a desysop. Closing any ANI thread involving an admin will become much harder, and the cliquish and partisan behavior there will increase dramatically. Threads will be closed, re-opened and then reclosed again. It is likely that just about every close of such a thread, whether it goes for or against a particular admin, will be contested. ANI is already disfunctional as it is, and we don't need wrecking it further for a year for the sake of testing an unrealistic proposal. Nsk92 (talk) 13:11, 28 February 2021 (UTC)

• My concerns square on how this relates to the ArbCom procedure. Those would not go away, even in a 1yr trial, in the proposal as currently written. So it's a no from me too. I also agree on SG's points. ProcrastinatingReader (talk) 13:52, 28 February 2021 (UTC)

• How does this relate to ArbCom, by the way? I hope this proposal is not taking desysops out of their remit, because we will then effectively end up with no means to desysop. This proposal is so skewed towards giving more power to admins to protect other admins, that it leaves no chance for the broader community to deal with abuse of tools, so we will still hopefully have recourse with ArbCom. SandyGeorgia (Talk) 15:13, 28 February 2021 (UTC)

  Asked relatively early, answered relatively early. No modification of ArbCom procedures. ~ ToBeFree (talk) 23:50, 1 March 2021 (UTC)

  I do think since the arbitration committee is tasked with being a last resort for conduct issues, there will be a tendency to demur from accepting non-emergency case requests until the community review is completed, and I imagine any subsequent case resolution would defer to the community's judgement, absent any significant irregularity. isaacl (talk) 00:26, 2 March 2021 (UTC)

  @SandyGeorgia: Sorry, didn't see this due to lack of ping. My concern is if this passes, ArbCom will be even more reluctant to take issues of admin conduct, instead choosing to say it should be passed off to the community. And this process is no replacement for ArbCom. For two reasons at least, the first that community structures do not do well dealing with some issues, one of those likely being admin issues with active admins (not including old-age admins who are intermittently active). The second being that this proposal only requires 40% support to retain adminship. I'm pretty sure this - a move to this method rather than ArbCom - is intentional of the proposal. Even if the ArbCom process sticks, this seems a bit like possible double jeopardy which would be deeply unpleasant for both the admin and relatively disruptive on the community's time, as well. These parts, and other concerns in how this proposal interacts with the ArbCom method, need to be further thought out before a proposal, even a trial, passes. ProcrastinatingReader (talk) 00:26, 8 March 2021 (UTC)

No, once it's in there would be no turning around. Stifle (talk) 09:40, 2 March 2021 (UTC)

• I believe this a good idea, Wikipedia should be open to experimenting with policies. It would also help with other projects, where to honest proceduralism is on its way to killing projects in other languages. Kranke133 (talk) 10:29, 7 March 2021 (UTC)

Give AN/ANI discussions power to ask an Admin to commit to a reconfirmation RfA

What I would Support is if an AN/ANI discussion about an administrator closes with a consensus that the administrator needs to re-apply for a re-confirmation RfA, and if the AN/ANI close is endorsed by a crat/crat-chat to represent actual consensus, then the administrator, without having to resign/relinquish his/her tools, will apply for a reconfirmation RfA or approach ArbCom for resolution if they feel there are issues with the AN/ANI discussion that the community was not/could not be privy to. Lourdes 14:51, 28 February 2021 (UTC)

If a "bad" admin has gained enough consensus that the community feels they've done enough wrong that they're deserving of needing an RfA, then why should we waste our time with them? Just take the tools away and let them do their own RfA. Aren't they allowed to reapply for RfA anyway? Let them do it on their own time. Bad behaviour should not be rewarded with an immediate opportunity for a "redo" or "tryover". Regular editors can get blocked for a very long time for not acting right, and admins should not be immune from consequences either. In the long run, it weeds out the bad elements, and keeps the good headed on the right path. Huggums537 (talk) 15:31, 28 February 2021 (UTC)

• Since November 2018, the community has possessed a fairly robust technical means to enact a social consensus that an administrator should be prevented from further administrative activity (optionally pending reconfirmation), so this is already possible under existing structures with the only difference being it requires administrators (not bureaucrats) to endorse the consensus, as the enforcement is not within the permitted activities of bureaucrats and would require application of the Banning or Blocking policies.

  A community discussion where consensus is established that "an administrator should not edit further while holding administrative privileges absent a renewed indication of community confidence" (e.g. reconfirmation RfA) can be enacted by an administrator via social or technical restrictions (permitting the affected user to edit WP:BN, WP:RFA, WP:RFAR or their talk page, only). In this context, an administrator would still have the option to petition the committee if there were procedural concerns about the discussion, while those who refused to submit for reconfirmation within a grace period or voluntarily resign following the consensus being enacted could be procedurally blocked. The community decision could then being formalized by simple motion allowing bureaucrats to perform the removal of administrative privileges.

  The issue is that AN or ANI aren't really structured to hold a conversation like this, and determining consensus from a sprawling 1 mb+ AN thread will be very difficult. That's probably why most desysop proposals attempt to provide some structures and barriers to entry, and also why most of them end up looking like "a reverse RFA". ← This modified version of EVula proposal was never put forward due to convincing arguments that the committee is already an effective community desysop mechanism with pre-existing structures and staff to moderate heat to light volume along with the concern that it would lead to a decline, rather than an increase in administrators and administrative activity. YMMV.

  Tl;dr: This is already possible: if consensus is established that an administrator should submit to reconfirmation, that user can restricted accordingly if they do not adhere to consensus within an acceptable timeframe. –xeno^talk 17:10, 28 February 2021 (UTC)

  That the technical ability to do this doesn't mean the social will exists to actually proceed in that manner (accordingly, I've never seen an AN/ANI consensus limiting an admin from using their tools before, does one exist? I discussed this very concept with El C before and he said it would be voluntary for an admin to adhere to unless ArbCom endorsed it. See here). ProcrastinatingReader (talk) 17:21, 28 February 2021 (UTC)

  Yeah, I think the far more likely course is that an arbitration case request will be filed and accepted by the arbitration committee. (Although community sentiment may have changed, past consensus was that only the arbitration committee has the scope to enforce a ban on using administrative tools.) isaacl (talk) 17:36, 28 February 2021 (UTC)

  I'm not sure if ever been done just so, but there are likely WP:RFC/Us that led administrators to step down under compelling community pressure, and administrators have been blocked and socially restricted before. Someone (Iridescent?) might be able to sketch the history of administrators being blocked (and whether any led to voluntary resignation or reconfirmations), but the block policy has been used to prevent unacceptable administrative activity in the past. –xeno^talk 17:44, 28 February 2021 (UTC)

  There may well have been others, but the only occasions I can think of in which an admin voluntarily submitted to reconfirmation on the basis that their judgement had been called into question are the handful listed at Wikipedia:Standing reconfirmations. The most recent of those was Wikipedia:Requests for adminship/Herostratus 2 more than a decade ago (the more recent one was from someone who'd promised to only serve a five year 'term' and to re-run if he wanted to keep it after that, rather than a reconfirmation-for-cause). With the exception of Everyking—eventually resysopped on the fifth attempt after four unsuccessful reconfirmations, and even that was a bloodbath (and again, more than a decade ago), I'm unaware of any occasion in the modern era (i.e., when admins weren't just Jimmy Wales's buddies) of someone losing the bit for cause and subsequently regaining it other than socks like Law or Pastor Theo in which the candidate ran as a new user and the former desysopped account wasn't disclosed. For all practical purposes, desysopping acts as a permanent bar to an editor ever becoming an admin again. ‑ Iridescent 17:59, 28 February 2021 (UTC)

  For all practical purposes, desysopping acts as a permanent bar to an editor ever becoming an admin again should be rammed home to all new admins from day 1. It is something they should consider in every decision, action and comment they make. Whether it is a one-off breach of trust or chronic behaviour patterns exhibited over many years, the door to desysoping is now clearly open via Arbcom who have essentially recognised that the existing Admin managed boards will only very rarely deal effectively with one of their own group. Turning to the quoted comment, it is a bald statement of fact - not one I think intended to garner sympathy, one way or the other. Leaky caldron (talk) 13:06, 1 March 2021 (UTC)

  @Leaky caldron: it is incorrect to say that For all practical purposes, desysopping acts as a permanent bar to an editor ever becoming an admin again because there is simply no evidence to back this up. Over 50 editors have been desysopped by arbcom since 2004, 12 were resysopped by the committee (most recent 2009). Of the remainder only 10 have stood for RFA, 5 were successful, 5 were unsuccessful. Only 3 former arbitrators have stood for RFA since 2015, none since 2019. Of those 3, one failed because the issues that they were desysopped for were still ongoing, one failed because of new issues that would have rendered a first RFA unsuccessful and one failed immediately after the desysopping so there was no opportunity for editors to tell whether the issues had ceased or not. For your assertion to be true, there would need to be multiple editors who have done all of:

  1. Been desysopped for cause
  2. Continued (or resumed) editing
  3. Acted to resolve the issues that resulted in them being desysopped
  4. Not engaged in any other behaviour that would also have resulted in a desysop or failed first RFA
  5. Stood for re-RFA
  6. Failed at that re-RFA

  The most recent examples I can find of an editor doing steps 1-5 are Everyking (RFA) and MZMcBride (RFA), both in 2009 and both of whom were successful. As far as I can tell, it has been over 10 years since anyone who has addressed the reasons why they were desysopped has even stood for RFA (Hawkeye7 (RFA) in 2019 failed on point 4, but the RFA has no clear consensus on whether they had actually addressed the reason for the deysopping or not). It is therefore impossible to say whether desysopping is or is not a permanent bar. See User:Thryduulf/What happened after a desysop for most of the stats and links. Thryduulf (talk) 12:36, 9 March 2021 (UTC)

  Please don't fact bomb me, @Thryduulf:. I was "quoting" from the post immediately prior to mine by Iridescent. Leaky caldron (talk) 12:50, 9 March 2021 (UTC)

  @Iridescent: I think the Q is more if the community, which can place bans on the editing activity of any editor, can also place bans on the use of administrative tools of an admin? e.g. is "Iridescent is prohibited from using their sysop tools" or "Iridescent is prohibited from blocking editors" a valid and enforceable consensus at AN? I mean yes, consensus can do whatever it wants (ie, if someone can take an action and nobody will have their head for it, I guess that's valid), but the idea is more has something of the sort happened within, say, the last 5 years? (if not, then for all practical purposes I presume this is not valid?) ProcrastinatingReader (talk) 14:03, 1 March 2021 (UTC)

  ProcrastinatingReader None that fresh, the examples are from 2006 to 2009. Admins blocking each other for long-running issues didn't go well back then, so it's probably why it's a thing we don't really do much, preferring to refer to arbcom... Anything more complicated than a L1 or L2 cannot really be handled at AN/ANI. –xeno^talk 03:33, 4 March 2021 (UTC)

  I agree with xeno's statement. I want to add that sometimes iterating on a broken process is better than trying to create one from scratch. We don't use bans like this, but there's nothing that says we can't. If the community doesn't trust an admin to use the tools, we have every right to say that. If they use the tools despite that distrust, we have every right to impose a social restriction (ban) on using the tools. If they violate that ban, we have every right to block them for it. The benefit of using our existing ban and block policies, is that we have more fine grained control to handle edge cases. Bans can be indefinite, sure, but they can also be time limited. We can ban tool use for particular time periods or in particular areas. Like TBANs, we can target areas where behavior is problematic without losing the good contributions they make elsewhere. We don't even need to say "don't use your tools in area X", a regular TBAN would stop that without even needing to radically change our typical standard procedures. The problem we've seen with arbcom desysoppings is that they have a single hammer. Even here, we only get a single option to deal with a problem. It's desysop or nothing. The reality we have faced is that situations are complex and a one-size-fits-all approach leads to disproportionate responses similar to mandatory minimum sentences. Maybe the answer is to just start treating admins like normal editors by placing sanctions on them like we do to those without +sysop. — Wug·a·po·des​ 23:54, 3 March 2021 (UTC)

• What a convoluted system. Sheesh! I don't think I have much else to add to these discussions. From the looks of it, the whole thing seems like it's gonna be a wash anyway, just like past discussions. It looks like the "Guy" (no pun intended) who posted this section knew what he was saying. However, the idea did occur to me that giving AN/I the power to enforce admin RfA reconfirmations could be a viable alternative to limited terms of appointment, which I know is contradictory to me earlier statement, but after mulling it over, I think it would be easier to instate some kind of reconfirmation RfA process for only wrongdoers than it would be to seek all admins having terms of service that expire or have to be renewed. Huggums537 (talk) 20:19, 28 February 2021 (UTC)
• I feel I can support something like this. I believe there needs to be a balance between the expectation of the community to hold administrators accountable and recognizing that administrators are often thrust into making difficult decisions that are or can be controversial. I do think that this proposal could allow for those boards to express displeasure about certain administrative actions while also providing their ability to say that certain conduct requires the community to weigh in to see if the administrator should retain the tools. --Enos733 (talk) 05:48, 1 March 2021 (UTC)
• xeno, with due respect to what you have written, there is currently no AN/ANI discussion that can ask an Admin to submit to a re-RfA or to stop using their tools. So I am unsure from where you have interpreted this. Unlike what you have said, this does not exist – it will be great if it does, and enshrined in policy. Lourdes 06:36, 1 March 2021 (UTC)

  Lourdes: I was thinking about a hypothetical discussion where it is established that the continued activity of an administrator is deemed by strong community consensus to be disruptive (i.e. due to failure to observe WP:ADMINCOND or WP:ADMINACCT), so much so that the administrator should be prevented from further activity. In this context, that administrator could be blocked for disruption (this has happened before), with the unblock conditions set by the community as "resign or reconfirm" - though I don’t think this has ever happened, and isaacl above has suggested there is previous community discussion that precludes this type of thing (and also pointed out that if there is such an obvious consensus in this direction, the committee route should work just fine - which I agree with, especially in recent years). So the belief that the community ex arbcom has no way at all to compel a disruptive administrator to stop activity is not accurate; it’s there, and since November 2018, effective. You are right in that the community has been unable to generally agree on the terms of the discussion, and no firm agreements to that end have been reached. I still don’t see this route as prohibited by policy, further reading notwithstanding. In the hypothetical situation where community consensus exists that an administrator should not continue, and for whatever reason, arbcom is not effective, the community can act. The reason non-AC CDA proposals always fail is not because the community doesn’t have the power, it is the lack of agreement on how to convene the discussion in a way that doesn’t cause more problems than it solves. –xeno^talk 15:59, 1 March 2021 (UTC)

• Thanks xeno. Your reasoning is absolutely different from what this discussion is about. Removal of tools may be required/implemented for many reasons, even for a degree of tendentious editing. But you are talking about disruptive administrators, which is a completely different and much narrower universe than removal of tools/re-RfA. Sorry but your reasoning is off-tangent. Thanks, Lourdes 06:53, 2 March 2021 (UTC)

• A persistent "degree of tendentious editing" from an admin is disruption. I don’t think we necessarily disagree, you are asking for the community to have the power, I’m suggesting that the community has the power (the necessarily technical tools; the community could agree that "this is a thing we do now", similar to how the community agreed to expand the acceptable uses of ECP); the lack of agreement on a resilient process is the blocker. I suppose the distinction doesn’t matter in a practical sense. –xeno^talk 14:48, 2 March 2021 (UTC)

• ANI has become mildly notorious for being dysfunctional and lots of people avoid it. I suspect an RfA candidate who has spent a lot of time there might get opposed on that basis alone. It's particularly bad at dealing with behavioural problems involving established editors, which is what would be involved in a desysop discussion. It's probably the worst place to hold those discussions. AN is better but not by much. Hut 8.5 08:44, 1 March 2021 (UTC)

  OTOH, if any 'normal editor' has to be subject to the 'injustices' of ANI, is there any reason an admin shouldn't be subject to the same processes, regardless of how good or bad they are? I mean, believing otherwise seems to be akin to saying admins are superusers. This seems to get even more icky when you think about now unbundled tools. A template-editor can be flogged at ANI for their use of TPE, but an admin cannot be flogged for the exact same action because their TPE is bundled into their admin kit? [replace TPE with rollback, page moving, or something similar for the same effects] ProcrastinatingReader (talk) 14:10, 1 March 2021 (UTC)

  Well said PR. Lourdes 06:53, 2 March 2021 (UTC)

  You can flog admins at ANI now if you must. This proposal gives a lot of power to the user closing the AN/ANI thread. You'd need to have a specific consensus which asks for the admin tools to be removed and reconfirmed, which would generally require consistent disruptive behaviour. SportingFlyer T·C 15:12, 2 March 2021 (UTC)

  Ignore that. I re-read the original proposal, which would require a consensus. SportingFlyer T·C 15:13, 2 March 2021 (UTC)

@Lourdes:, I don't see how you can oppose a proposal that would require 60% of participants to support a de-sysop as "opposite our WP:CONSENSUS policy", and yet support having roughly the same number of participants trigger a discussion requiring only 30% of participants to support a de-sysop. The requirement that an AN/ANI consensus has found that an admin acted inappropriately in the RFC proposal is functionally equivalent to your trigger here; we can't have a situation where 90% of editors think an admin is behaving fine but an RFC is triggered under the proposal. power~enwiki (π, ν) 21:31, 2 March 2021 (UTC)

To expand on this, the RFC proposal is:

1. An AN/ANI discussion finds consensus an admin has acted inappropriately.
2. A motion is made to initiate a de-sysop vote.
3. The motion must obtain sufficient second.
4. The motion is discussed for a week, if 40% or more of the community support the admin remaining an admin, they will remain an admin.

Your proposal (the L proposal) as I understand it is:

1. An AN/ANI discussion finds consensus an admin has acted inappropriately (or possibly can request a de-sysop for no reason at all) and requests a re-RFA.
2. No additional motion or second is necessary.
3. The motion is discussed for a week, if 65% or more of the community support the admin remaining an admin, they will remain an admin.

If you support the L proposal, how can you oppose the RFC proposal for being "opposite our WP:CONSENSUS policy"? How do additional hurdles in the RFC proposal make it easier for there to be a "public lynch mobbing and appeal for a desysop review request"? power~enwiki (π, ν) 22:35, 2 March 2021 (UTC)

Hi power-enwiki. Your above description is mistaken in two areas.

To expand on this, the RFC proposal is:

1. An AN/ANI discussion is given the power to conclude that an admin should go for a reconfirmation reverse RfA – not based on consensus, but based on a specific number of editors and administrators agreeing, ignoring the editors and administrators who may disagree, whatever the number of the disagreeing lot may be.

My proposal is:

1. An AN/ANI discussion finds consensus an admin should go for a reconfirmation RfA, based on consensus closure and the closure being deemed appropriate by a crat.

Thanks, Lourdes 03:42, 3 March 2021 (UTC)

I only see one disagreement, but there is a disagreement. The RFC says that after a finding of malpractice, a motion to de-sysop is in order, while you require a consensus to make a motion to de-sysop. I disagree. Once there is agreement that an admin is behaving badly, I feel a motion to de-sysop should not require consensus to start; the motion itself will require consensus to actually de-sysop an editor. If you require a consensus to start a motion to de-sysop, you are holding a vote twice; this will only increase the power of various cabals at ANI. power~enwiki (π, ν) 03:48, 3 March 2021 (UTC)

• For clarity's sake I should note I oppose the alternative plan proposed above - it would again be easy to trigger a fullblown RfC, but I also feel that any admin that is taking actions that trigger significant controversy or unhappiness is going to struggle to meet the percentages seen in a standard RfA. Nosebagbear (talk) 11:26, 3 March 2021 (UTC)

  Is there any evidence for this? Consider the case of El C, for example, who has sanctioned many regular editors and even some admins as probably the most active AE admin. I do not think El C would fall under 75% if he ran a reconfirmation RfA, certainly not below 65%. Ironically, from observing some past talk interactions, it seems El C still retains the respect of some editors he sanctions (not exactly sure what his secret is). I have a feeling that these 'admins engaging in controversial actions' you refer to are people doing so in an incompetent manner. ProcrastinatingReader (talk) 12:12, 3 March 2021 (UTC)

  ProcrastinatingReader, you're making me El_C 14:07, 3 March 2021 (UTC)

  Nosebagbear you have a point. We could consider a reverse-RfA in such a case. Lourdes 14:15, 3 March 2021 (UTC)

  We know admins who do really difficult unpopular things (sometimes so unpopular that they can cause an RfC that hundreds participate in) can still retain the trust of at least 60% of the community. How? Because Arbitrators routinely get re-elected with at least 60% support. Now there does seem to be a cap, at least at ArbCom, but some of that cap also appears to be a function of it being zero sum (i.e. only so many Arbs get elected) where as at a confirmation situation there would be no such pressure. Best, Barkeep49 (talk) 03:38, 4 March 2021 (UTC)

  @Barkeep49: It's important to note the difference in structure between ArbCom elections and RfA. ArbCom elections employ a secret ballot where no one can see how others are voting or their reasons for doing so. Additionally, the ArbCom elections of recent years have been well-publicized using a mass user talk page message to every eligible voter that has edited in the last year. On the other hand, RfA voting is public, and the discussions are generally attended by a small subset of the ArbCom-voting community that takes active interest in the project's governance. These distinctions have important consequences, the most important of which is the "pile on" effect. At RfA, it is not unusual for an outspoken voice in the community to cast an early oppose vote, which leads to a "pile on" of further oppose votes that simply cite the first oppose. This effect is tempered at ArbCom elections because of the secret ballot—some editors do publicize their opinions in voter guides and other discussion pages, but these don't seem to have nearly the same influence as the open and unstructured format of an RfA (I'm recalling your essay at User:Barkeep49/ACE#Candidate guides). Additionally, the mass message at ArbCom allows for a greater diversity of opinion than RfA allows, which reduces the likelihood than an isolated controversy or a vocal minority can sway the outcome. The result is that in my opinion it would be more difficult (albeit not impossible—see Floquenbeam 2) for a controversial administrator to pass a reconfirmation RfA than it would be to get elected to ArbCom. Mz7 (talk) 07:32, 4 March 2021 (UTC)

  Beyond that, ARBCOM is, in theory, a competition of the best and most trusted - even if some take controversial actions. Being in that category should not be necessary for a controversial admin to avoid desysopping - even an average controversial admin should be able to survive it without difficulty, and I don't think that would hold up - especially factoring in what will be a major recency bias. Nosebagbear (talk) 12:00, 4 March 2021 (UTC)

  Nosebagbear, What do you mean by "recency bias"? -- RoySmith (talk) 12:56, 4 March 2021 (UTC)

  People inherently focus on the most recent events and place more attention to it. In a normal RfA, the candidate chooses when to run, so this falls in their favour (or, at a minimum, neutrally, if they run when suits time-wise). Arbs can't choose when to run, but do know when it's coming and can avoid anything too problematic in the imminent run-up/during the election. In a desysop process, it will naturally come about because something negative has occurred - recency bias means that additional focus will be put on the recent events, requiring a very large weighting of "general positive performance" to outweigh it. The US army supposedly has the phrase "all the 'atta boys are outweighed by one 'oh shit'". In this sense, the circumstances are significantly more stacked against than, say, the arbs in an ARBCOM election. Nosebagbear (talk) 13:59, 4 March 2021 (UTC)

  I am still not convinced with the view that at least 65% of the community cannot think rationally and assess a reconfirmation RfA admin on their overall merits. And I still see no evidence here of proof to the contrary, so this all seems very presumptive. And in general, I don't think an admin without the support of the community should be admining anyway. ProcrastinatingReader (talk) 14:15, 4 March 2021 (UTC)

  It's not a "x huge proportion will not do a logical assessment" issue, it's "x appreciable proportion will not do a 100% logical assessment". In an event where a significant but insufficient minority reasonably chose to desysop, this group could easily put the count over a high/low (depending on POV) threshold. While the Wikipedia article on recency bias is not great, there's huge amounts of academic literature on the subject available in a quick search, unless we genuinely believe that Wikipedia editors, as a class, are functionally immune to it. Nosebagbear (talk) 15:28, 4 March 2021 (UTC)

  You're correct that the pool of voters for ArbCom is much larger than a typical RfA. And I intentionally did not bring up the Floq RfA because it's anecdote not data (even though it supports my contention). However, I think most people have suggested that anonymous voting will make it easier for people to oppose because there is no fear of retaliation so I do not agree with your analysis that this contributes to a higher support %. And I would suggest that NBB's "all the 'atta boys are outweighed by one 'oh shit'" is no more stacked against administrators than Arbs. Arbs have 1 or 2 year terms. I really doubt that editors upset by controversial decisions would forget it in that period of time. 60% retained support is already 5% below the cut-off for the discretionary range for crats at a typical RfA thus allowing plenty of wiggle room for a revenge based voter or two to be washed out. Best, Barkeep49 (talk) 16:48, 4 March 2021 (UTC)

An alternative approach, where ArbCom initiates the process

KevinL, at around oppose #102, makes an argument that I have found very interesting and worth further consideration: [10]. He says in part that he prefers ArbCom to deal with actual admin misconduct, but would be interested in whether the community could deal with loss of community trust in an admin over time. I've been thinking a lot about that over the past few days, and I also see the issue as being broadly relevant to an ArbCom case that is going on simultaneously with this RfC.

I have an idea that I'm going to spitball here. I'm making no assumption about whether or not the proposal in this RfC is going to pass:

• If the proposal here passes, then an idea like the one I'm describing here could be evaluated as a proposed amendment to the policy later on.
• If the proposal here does not pass, then the idea here could be a separate proposal sometime in the future.

This would be a process in which the community participates, but it would not exactly be a community desysop process. It would be initiated by ArbCom, not by members of the community. It seems to me that many of the editors who oppose community-based processes but who support ArbCom's role might, perhaps, want to support an idea like this.

1. The only way the procedure could be initiated would be by a decision by ArbCom, according to their own procedures. They could initiate it either by motion, or by a remedy in the final decision of a case.
2. ArbCom would initiate it when they have determined that an administrator may perhaps have lost the trust of the community, but where ArbCom has also determined that they are not, themselves, going to desysop the administrator for the kinds of reasons that ArbCom has traditionally cited (specific violations of administrator policy, etc.). ArbCom would continue to be free to act on desysops as ArbCom has traditionally done; there would be no requirement or expectation that they refrain from making desysop decisions themselves. But if ArbCom does elect to use this procedure in a particular case, then the administrator remains an administrator in good standing during the procedure.
3. Within an amount of time set by ArbCom after ArbCom posts its decision at the Arbitration Noticeboard, the Arbitration Clerks will be responsible for setting up and transcluding the community discussion page. If the administrator being reviewed requests more time, the time may be extended at the discretion of ArbCom.
4. The discussion page will resemble pages for WP:RfA, and will be transcluded similarly. The Clerks will post notices of the discussion at the same places that RfAs are publicized (WP:CENT, watchlist notices, etc.), and at the user talk page of the administrator.
5. In place of the nomination used for RfAs, there will be a statement by ArbCom. In place of the nomination acceptance by RfA candidates, the administrator may make a statement. This statement will be omitted if the administrator chooses not to participate. Analogous with RfAs, there will be questions to the administrator from the community.
6. Instead of sections for "Support", "Oppose", and "Neutral", the sections will be "Retain as administrator", "Remove (desysop)", and "Neutral".
7. The discussion will remain open for seven days.
8. The discussion will be closed by Bureaucrats. They will consider the numbered comments according to "Remove" divided by "Retain + Remove", with a sufficiently high value of this ratio needed to reach consensus for desysopping. There will be a discretionary range, as with RfAs. (The actual numerical guidelines for this will be determined later, during a community RfC, if this idea becomes a formal proposal.) In the event of a consensus to desysop, the Bureaucrats will enact the decision.

I think there's a lot to the idea that admins must have the trust of the community – but that the community, not ArbCom, is who should evaluate "trust". ArbCom is elected by the community, but to some extent they have to guess whether or not the community still trusts a particular admin. This is different from ArbCom desysopping an admin, and the admin reapplying via a new RfA. Here, the admin would not have been desysopped by ArbCom, so the rationale that one should oppose the RfA because ArbCom already decided it once would not apply. And for editors who are uncomfortable with the community being able to desysop someone, this would be something that requires ArbCom to initiate it. (For editors who hate ArbCom and hate admins, I'm afraid I can't help you there.) --Tryptofish (talk) 21:05, 5 March 2021 (UTC)

In the Russian Wikipedia, an ArbCom can force the admin to stand a reconfirmation RfA (I believe I was an arb when this practice started, but I might be also wrong as it was more than 10 years ago). The motivation is that it is sometimes difficult to determine whether the admin still has the community trust. In most cases this RfA is preceded by a notification, with a number of users (50 or so) are required tro sign up, then the RfA starts. There were about a dozen cases in total, with a few who passed the RfA, a few who have not, and a bunch who refused to run an RfA.--Ymblanter (talk) 22:30, 5 March 2021 (UTC)

@Ymblanter: What you describe is basically like the German WP recall process, except that it needs to go through ArbCom first, right? I wouldn't have too much objections to that, but of course that would need to be a different RfC RandomCanadian (talk / contribs) 22:36, 5 March 2021 (UTC)

We had (and I think they still have) just the same RfC as usual, with questions and the same support threshold.--Ymblanter (talk) 22:58, 5 March 2021 (UTC)

I'm afraid I don't agree with Kevin's separation of "loss of community trust" and "specific identifiable acts of administrative misconduct". In my view, the community only loses trust in an administrator because of specific identifiable acts of administrative misconduct. In other words, there needs to be evidence that an existing administrator is a net negative to the project, not just a "general feeling" or a personal disagreement or grudge. If a community process results in desysopping an administrator without providing specific evidence of misconduct, then I would see that as an unfortunate failure of the process—we would have wrongly desysopped an administrator. The status quo protects against this risk by demanding high-quality evidence and strong arguments rooted in our policies and guidelines. Mz7 (talk) 22:41, 5 March 2021 (UTC)

@Mz7: (also ping Tryptofish) I can kind of see what you're talking about, but I think some of these are things that ArbCom is institutionally in a much better position to address than others. For example, lack of competence (e.g. a legacy admin who gets involved in the project after a long period of near-absence who is in over their head) will eventually be addressed by ArbCom if it is bad enough – but something has to go pretty wrong first. If the community instead determined through supermajority consensus that that admin (who might have engaged in a series of minor missteps far short of ArbCom normally, or otherwise clearly no longer retains a community mandate to be a sysop) no longer retains its confidence, that would be a good outcome. Best, KevinL (aka L235 · t · c) 08:41, 6 March 2021 (UTC)

@L235: You said in your oppose comment that you have been thinking about a possible procedure, and would provide more details if editors ask. So I'd like to ask: are there ways in which you would prefer to do things differently than what I describe here? Also, since DGG said below that he believes that this would cause ArbCom to become less involved in desysoppings, what is your take on that? Thanks. --Tryptofish (talk) 16:10, 6 March 2021 (UTC)

I would actually be pretty happy with the process as proposed in this RfC, except that we should drop the AN/ANI thread requirement and note that generally requests for desysopping on the basis of abuse etc. should generally go to ArbCom. I think the requirements set forth in point 2 sufficiently protect admins from retaliatory, frivolous, or abusive filings. Best, KevinL (aka L235 · t · c) 23:28, 7 March 2021 (UTC)

I disagree that we need specific identifiable acts of misconduct. I think this summarizes it best: "A motion of no confidence ... is a statement or vote about whether a person in a position of responsibility ... is no longer deemed fit to hold that position, perhaps because they are inadequate in some aspect, are failing to carry out obligations, or are making decisions that other members feel as being detrimental." We have three layers there: 1) there is a certain level of WP:COMPETENCE required to be an admin and one's level of competence can change over time, especially as policies and procedures change or as admins change themselves; 2) many admins fail to carry out their obligations by being long-term nearly-inactive administrators who game the system to maintain the mop, evading the one method to remove their tools while at the same time doing little to nothing in terms of sysop work; 3) this is where the uncivil and problematic behaviors would fall. All three are items that can erode the community's trust, and all three have been issues at one point or another. Nihlus 22:56, 5 March 2021 (UTC)

My response would be that (1) and (3) are examples of issues where you should be required to find specific identifiable instances in order to justify your desysop case. An administrator that is truly incompetent or exhibits a pattern of incivility is engaging in misconduct that you should be able to build an evidence-based case around. (2) is definitely the trickier one, and I will concede that the status quo may be insufficient in this area. I am skeptical, however, that either TonyBallioni or Tryptofish's proposals would actually address that issue. Instead, it'd require tightening our admin inactivity process (we've done so incrementally over the past few years, e.g. requiring a new RfA after 5 years of no admin actions, but I suspect you're probably right that it's not enough). Mz7 (talk) 23:28, 5 March 2021 (UTC)

I should have worded it better and said that I disagree with always needing specific identifiable acts. While it makes sense for (1) and (3), it doesn't for (2), so such a limitation would be detrimental to the purpose of a community initiated desysop process. Nihlus 00:00, 6 March 2021 (UTC)

• One thing this would do, is make it much easier for the arbs. If they gave the community all hard decisions on desysop, nobody would be able to blame them for the results. This is basically turning arb com from a final appeal board, into a preliminary screening board. DGG ( talk ) 22:44, 5 March 2021 (UTC)

Regarding what Ymblanter and RandomCanadian said, there could be an advantage to having a discussion that isn't exactly a reconfirmation RfA in that it could be more focused than that. In other words, the administrator (or a nominator) would set up a reconfirmation using the standard RfA format, whereas this could be something formatted around a statement by ArbCom and a response from the admin. I think Mz7 is correct that there isn't a bright line that separates specific misconduct from loss of trust, but I don't necessarily see that as a problem. I see it as tied in with DGG's observation. If ArbCom just punts on this and falls back to what DGG calls a preliminary screening board, then there probably should not be a procedure like this one, and the status quo would be better. But I would hope that ArbCom would not do that, and that there would be rapid community pushback if they did. My intention here is that ArbCom would keep on doing what they do, not turn into a bunch of buck-passers. They would only use this procedure sometimes. And it wouldn't be evidence-free, in the way that Mz7 envisions as a failure of process. If the threshold for consensus is set properly, it would be difficult to get to desysop just on hunches without evidence. There would be evidence, but the evidence would be less-than-black-and-white by ArbCom standards. ArbCom has (arguably!) made some recent desysops, and desysops followed by unsuccessful new RfAs, based on the premise that only they can desysop – which (arguably!) could mean that they would have felt less obligated to pull the plug if they had another option. This would give them the option of turning it over to the community, but they would also retain the option of acting on their own. In addition to what Nihlus said, please see the comments following KevinL's oppose for other conceptions of loss of confidence. And yes, inactivity is another relevant issue, although I hadn't thought about it when I wrote the opening post here. --Tryptofish (talk) 23:55, 5 March 2021 (UTC)

Agree with this general sentiment. Re. "Inactivity" - yes, that is certainly something where better than what we have can be done; and Tobias mentions that on dewiki the scope of recalls includes admins who are pretty much inactive but log on once in a while to "game the system" (the bigger question, besides the potential security risks of mostly inactive admin accounts, is whether such users might have lost touch with the current community - of course that might require something that treats each case individually, but we probably don't want a full fledged RfA for each of these again [although that would increase the activity at RfA, which is these days often notoriously silent]). RandomCanadian (talk / contribs) 00:29, 6 March 2021 (UTC)

I oppose. For the not very experienced year I have been on Wikipedia, I have long thought that ArbCom has too much power. In fact, I felt that Wikipedia was feudalism: ArbCom at the top of the triangle, then administrators, then non-admins with myriad special user rights, then regular users (like me). The things that ArbCom can do now include: Imposing editing restrictions on editors without any discussion, imposing blocks on editors without any discussion, imposing bans on editors without any discussion, and removing user rights from editors without any discussion. I'm all for anything that gives the community roles in Wikipedia: this DRfA proposal is among them. 🐔 Chicdat  ^{Bawk to me!} 13:14, 6 March 2021 (UTC)

Not trying to pick on your personally, Chicdat, but this to me seems like very far from how things actually work around here. ArbCom does very few things without long-winded discussion. And community consensus both sets policy as well as resolves (reasonable) editing disputes. Actually, after about 15 not-very-active-years here, I'd turn your triangle upside down. At the top are regular editors, who basically can run around doing anything they want. They might get reverted, challenged/disagreed with (as I am disagreeing with you), in the extreme warned or blocked for a short while. But it really takes a strong pig-headedness (not necessarily a bad thing!) to get truly sanctioned; most poor behaviour goes unpunished, just wastes the community's time. The community appoints admins, who have a much harder time at the middle of the triangle. They may have some special tools in their toolkit, but their behaviour in using them is perpetually under the microscope and editors routinely complain about them (sometimes those complaints are valid), and they're expected to be friendly and polite and accountable for their actions--something an individual editor, bizarrely, really is not! Finally, at the bottom of the triangle are ArbCom, who get the thankless task of trying to resolve conflicts the community can't solve. Their main tool is mind-numbing deliberation and pomposity, though exceptionally they can vote someone off the island or impose circuit-breakers on their behaviour. However, they are almost perpetually being criticized from all sides for doing too little and too much, and then are actually supposed stand for re-election. So of everyone, they're actually the most under the gun and operate with the least amount of impunity. The above is all slightly tongue in cheek and overstated, but I do think your read of the dynamics is far from accurate. Martinp (talk) 21:59, 6 March 2021 (UTC)

I never thought of it like that before. I'll try to think about Wikipedia more like that. 🐔 Chicdat  ^{Bawk to me!} 11:08, 7 March 2021 (UTC)

• I think letting arbcom refer certain cases to the community could be an interesting idea. I would not want it as a replacement for a community initiated process, however. -- Calidum 16:35, 6 March 2021 (UTC)
• I cannot imagine just how brutal it would be to have this as a final remedy - the poor soul would have had a month (at least) of ARBCOM stuff, and then have a hostile RfA on top. I have to worry how much it would spike loss of editors (both keeping or losing the bit) Nosebagbear (talk) 11:27, 7 March 2021 (UTC)
  • (edit conflict) Your points are well-taken. It seems to me that an idea like this would only be successful to the extent that ArbCom uses it properly. If, as DGG suggested, they just punt most cases to the community, that would be something highly undesirable. But if they were to use this process very selectively, then it really should not be something that disheartens most admins, nor most editors generally. It would not be something that most admins would ever face. And I think that there is at least some case to be made that it might be better to go through all of this and come out with a reaffirmation of community support, than to be desysopped by ArbCom because ArbCom regards themselves as the only entity that is permitted to evaluate community trust. --Tryptofish (talk) 23:42, 7 March 2021 (UTC)

    Looking over the last 3 years (2018-2020) I would expect in about half the cases where there was administrative misconduct considered (and desysop was considered) that the committee would have chosen this process rather than making the decision themselves (including in 1 of those 9 not to desysop). Is that the right amount or too much? Best, Barkeep49 (talk) 00:59, 8 March 2021 (UTC)

    Yes, that's the question. Offhand, I don't know the answer, but it's very much worth analyzing. I think it depends a lot on the specifics of each of those cases: how probable it would have been in each case that the community would have decided differently than ArbCom ended up deciding, how beneficial or not-beneficial each one of those differences would have been, and in each case how much would it have genuinely improved how ArbCom handled the case. But the very fact that ArbCom would likely have wanted to make use of this process a significant number of times is, in itself, very significant, as it goes a long way towards answering the question of whether or not there might be a need for this process. In other words, it becomes pretty hard to argue convincingly that we don't need this because ArbCom can do it by themselves, if ArbCom members say that they would prefer to have this option. The remaining question, then, becomes whether or not having such a process would actually be beneficial to the community as a whole. --Tryptofish (talk) 20:23, 8 March 2021 (UTC)

    Well the reason I pose the question is because I think it instructive to say "Would ArbCom have done this other process?" and in the cases where the answer is yes "Do I think that would have been the right decision?" Some of that second question is harder to answer because we don't know what the community would decide in this scenario but we can all imagine. Would that have led to "better" outcomes? I have had people make the argument to me that the answer to that question is no. Best, Barkeep49 (talk) 22:23, 8 March 2021 (UTC)

    We agree. It might be awkward to compile the actual data, case-by-case, but that would probably be the best way to examine it. --Tryptofish (talk) 23:41, 8 March 2021 (UTC)

• Yeah, no. ArbCom should make a decision or they shouldn't. As long as they leave the possibility of re-RfA open immediately, there isn't much of a difference, except the admin keeping the bit over the course of the discussion, which... yeah, it's probably insignificant. The issues that Nosebagbear are far worse than any benefit here. Elli (talk | contribs) 23:35, 7 March 2021 (UTC)
  • I think the point here would be to let ArbCom say "we're not saying you should be desysopped". An ArbCom desysopping makes a re-RfA, especially a re-RfA soon after desysopping, very difficult, because only about 30% of the community needs to agree with ArbCom for the admin to not get their bit back. Instead, this process would make ArbCom neutral on the ultimate question of whether the admin should keep the bit; ArbCom simply says that the question should be asked (at RfA). Best, KevinL (aka L235 · t · c) 00:37, 8 March 2021 (UTC)
• Way, way back, and I mean 2005 now, while desysoppings had happened very seldomly and the process hadn't been hammered out yet, there was an arbitration case where the ArbCom deferred the decision to desysop to the community via an RFA. It did not go well. The community consensus turned rapidly to the idea that if ArbCom thinks a desysop is warranted they should go ahead and do it. There was no need to add insult to injury by putting the defending admin through a hostile RFA process. While this was long ago, I think the objection to this way of handling matters still stands. Sjakkalle (Check!) 15:18, 10 March 2021 (UTC)

People. We ALREADY HAVE a perfectly good process. You all just need to implement it.

First of all I didn't read much of this, ANI whatever, this procedure and that procedure, somebody initiates, somebody doesn't, so forth. Forget that. It's as hard to get stuff like this passed as it is to repeal the 2nd Amendment, Right now its 159-115, 58% in favor.

Simply cogitate on the following four points:

1. There already exists a procedure for community reconfirmation and it's right here: Wikipedia:Administrators open to recall/Sample process. It's been used. It's been used, and it works fine. OK? It works fine.
2. That's a really really important point, so I'm going to repeat it: procedure exists, been used, works fine. Read it.
3. It is true that, de facto, only admins who have voluntarily placed themselves in Category:Wikipedia administrators open to recall are subject to community reconfirmation. And most haven't.
4. Well that's easy. Just stop voting for candidates who refuse to agree to be subject to recall. OK? It's not hard. Just stop doing it. Simple: Ask the candidate "Will you agree to be subject to reconfirmation, by placing yourself in Category:Wikipedia administrators open to recall?" Anything but a firm clear "Yes", you vote Oppose. You don't even have to read any more of the RfA. No clear firm "Yes", no Support, period.

And it's an entirely legit Oppose on the merits. It's just simply too risky to give editors a job for life. Failure to give a firm clear "Yes" to that question is saying "I want this job for life (providing any transgressions I commit are not Arbcom-level egregious), and if it turns out that I get all full of myself or whatever and you're sorry you elected me, you can go pound sand". If that doesn't merit an Oppose vote what does.

Compacts are great! Stop farting around and make one.

All you need is a compact of enough people to do this. You don't need a lot of people -- 20 or 30 maybe.

You don't even need a formal agreement. You don't need to write down a list of members anywhere (mabye you should, but maybe you could catch a lot of flak too). All you need is enough people reading this page right now to say to themselves "Yeah, that sounds good, let's do that, I'm in" and recruit others. That's it! No study committes, no Mensheviks vs Cadets vs Left SRs and all that.

Stop wasting your time with all this other stuff. Form a compact., highkey or lowkey. It's entirely legit to do so. I'm in. Be like me. (I'm not a leader type so don't look to me for that, tho.)

I know a bit about this, because I've done it. I was an admin. I put myself in Category:Wikipedia administrators open to recall. I was taken up on it! I was made to go through a reconfirmation RfA. I lost. I'm no longer an admin. And I shouldn't be (well I don't think so, but the community did, and that is what matters). It worked fine. So let's just keep doing it. No new rules required!

The rest is just noise, but there're more details, I'll talk about them below. Read or not as you wish.

Noise

But what about current admins?

Yup, using thie existing method means that all the existing admins are grandfathered in. Oh well. Over time it'll take effect, and anyway politically that's probably a very good thing -- maybe necessary, as hopefull admin corps won't be that upset, because it doesn't affect them personally -- grandfathered! (You still might get "Deciding with others in advance how you're all going to vote on an RfA is prima facie conspiracy to disrupt the project, you're in trouble". But maybe not, because grandfather. Grandfather is your friend. And I mean after all anything that you try to do that affects the existing admin corps -- well, good luck with that. I'm not saying its impossible, but it's a lot more heavy lifting. The threat of professional extinction will focus people's minds.

But... can a "compact" like this really work, practically?

Yes. Somebody runs for admin, but won't agree to be subject to reconfirmation... Say you've got 100 voters. Say 30 in the compact, 5 opposed for other reasons. That's 65-35 support... 65%. It's not enough for the editor to get the bit. Really, once this gets rolling I can't see hordes of editors being of the mind "Support. She won't agree to be subject to reconfirmation and wants a job for life, but I like her anyway and hey I'm a risk-taker". Maybe. Only one way to find out.

FWIW I get the word "compact" from National Popular Vote Interstate Compact, an interesting project. Our "compact" isn't the same, but sorta-kinda. The National Popular Vote Interstate Compact doesn't give a shit what states who don't want to join think. Similarly, I'm sure that a lot of people here are of the mind "Ugh, that is a terrible idea, one-issue voting". Speaking for myself anyway, that's their prerogative to think that, but I don't care. And in fact there're probably enough people of that mind such that of course you're not going to get any formal written procedure accepted. So let's skin the cat another way. We don't need a plurality. All we need is 20-30 people who think it's a good idea. It doesn't matter how many don't. I'm in, so already it's down to 19-29 people...

Pilot case details

Pilot case is here: Wikipedia:Requests for adminship/Herostratus 2. The only real problem was that the Bureacrats won't close a reconfirmation RfD. I believe that's because only Stewards, not Bureacrats, can remove the sysop bit. It's dereliction that they won't (of course they can, I'll skip the details; they just won't, so far.) So we need to figure that out; in this case I did an ad-hoc thing that worked. But it won't work for almost anyone else. Most RfA's aren't numerically close so any rando person can close. I don't know... somebody write an essay outlining a good procedure for selecting a closer, and link to it from Wikipedia:Administrators open to recall/Sample process, or something.

So a couple things about that pilot case: the ArbCom would probably not have taken a case, and if they had would probably not have desysopped. Because 1) there wasn't an ongoing unresolved dispute, and 2) the particulars of the precise case weren't very strong, and 3) the case was really about general deportment with not really any particular bad pattern of actions sufficient to get the ArbCom worked up, probably.

Thus: if the reconfirmation RfA path hadn't been open to the community, I would probably still be an admin operating in an environment where (apparently) I should't be, and how is that a good thing. So I mean this is an excellent example of why we want and need reconfirmation RfA.

But... what about the spectre of politics?

Politics is not a spectre. It's how things get done. If you don't like politics, you don't like people. So, the pilot case was initiated for political reasons! Doesn't matter. An editor had written an article for, uh, the least wiki-notable person I have ever seen an article for, obviously for a couple hundred dollars or whatever, and wanted to keep the money, and was trying to stop me from trying to delete it or at least punish me, and got the reconfirmation effort going for that reason (but I mean I did give him the opening). I get that people worry about this happening, and it is a legit worry, but look: who cares what the motivation was? 147 people voted in that RfA and they got to get rid of an admin that a lot of them didn't want, so how is that bad? I was an admin for like 5 years, and 48 people figured that that wasn't working for the project. There's no planet on which a person with those numbers should be an admin, so how did this "political" motivatation lead to a bad end. Politics is not Chthulu.

No system is ever going to be perfect. If some political foes get you into a reconfirmation RfA that's very annoying, but if you've got the truth on your side you'll pass. RfA works, and has for 15 years.

But... the barrier to a reconfirmation RfA is too low

Yeah maybe. It's easy to fix. So, Wikipedia:Administrators open to recall/Sample process -- which is the default process unless an admin specifices otherwise when giving his firm clear "Yes" in his initial RfA -- requires the signature of six editors with over 500 edits and one month of tenure, to initiate a reconfirmation RfA. Works for me, but maybe that's too easy. Maybe it's too hard. There's only one way to find out, but note:

An individual candidate, when giving her firm clear "Yes" to the question "Will you agree to be subject to reconfirmation, by placing yourself in Category:Wikipedia administrators open to recall?", can specify a different critiera. She can say "Yes, but it has to be ten editors". She can say "Yes but the editors need to have 2,000 edits and one year of service". She can say "Yes, but at least two of the editors have to be admins", or "Yes but it has to be six editors net at the end of a seven-day period, with each editor who doesn't want the reconfirmation RfA cancelling one who does" or "Yes but really four editors is enough" or specifiy any number of complicated changes for their particular case, or whatever.

This is fine. Maybe six is too few, so rather than trying to change the default rule (not possible), let the candidate make a realtime correction that they think is reasonable. You're not going to change the written rule, so let the body of candidates organically and individually decide what level of requirement they think they can get away with.

Then, it's up to us, the "compact" people, to individually decide how to take to this. You can be like "Support, asking for ten signatures [or whatever they did] is reasonable" or like "Oppose, asking for ten signatures [or whatever they did] makes for too high a barrier". If the candidate is being reasonable, she'll probably satisfy most of us "compact" people, if she's not then not. It's not anything to worry about now.

And by the way the Question has to include the addendum "And if you forget, you don't mind if I do it, right?"

But... won't there be a an awful lot of RfA all of a sudden?

Probably! So? Our RfAs right now seem to running at the rate of zero, one, or two going at once. Back in the day we'd have a half-dozen or more going at once. It was fine. The project went along just fine.

And you know what? My guess is A lot of the RfA will be new people requesting the bit. And succeeding. Because voters will be of the mind "Well, marginal... but we need admins, he might grow into, and if not we can always ask for reconfirmation". Consequently, more editors will ask for the bit, because the de facto standard will be lower, and they might not be as shy about asking. I don't know if this will happen, and I don't know if it'll be a good thing. Probably. But there's only one way to find out.

If somebody tries to nominate 20 admins for reconfirmation or nominates somebody right after they passed one, that's just trolling. People can do that now, nominate 1000 articles at AfD or whatever, and we deal with that. Just send them to WP:ANI and get them topic blocked. Also the "compact" can simply ignore these nonsense nominations, don't ask the Question and just Support the person. I intend to. They're not real RFA and to do otherwise is feeding trolls.

But what if we "find out" it's not a good thing, and it all blows up and there're significant unforeseen consequences?

Well that's easy. Just stop demanding that admin candidates agree to be open to reconfirmation. Let the "compact" fall apart and die out. Remember, relatively few admins will be affected: only those between the beginning of the "compact", and the clear indication that it's not working. You can also delete Wikipedia:Administrators open to recall and Category:Wikipedia administrators open to recall. If it's clearly and obviously a screwup, you all shouldn't have any trouble doing that. If you can't, that's probably natures way of telling you that it's only your opinion that it's clearly and obviously a screwup.

But what if it's not possible to pull this off, politically? What if say the Admin Corps does decide it's disruptive and starts blocking us?

Well that would suck. But I mean, do we want to live forever? Are we mice or humans? We can't stop that from happening... there is no do, only try or try not. I'm for try.

See? The magic was within yourselves, all along. Good luck, and fear no darkness. Herostratus (talk) 01:22, 11 March 2021 (UTC)

...@Herostratus: a couple of areas not covered within the text of your covering answers (which I like, btw). 1) Admins can't be bound to permanently retain either a specific recall policy or to have one at all. I just created my recall conditions, but if I ever went in heavily to, say, I'd probably change the terms to raise the requirements. I might even remove them. Admins could well do this without acting in bad faith, so long as they weren't clearly doing it to pass RfA and then shift. In your penultimate point, you don't cover what happens to the unfortunate test subjects. Passing RfAs is much harder than failing a recall, so even if a majority decide the unforeseen consequences are too bad, that doesn't avoid the major negative consequences to your test cases. Nosebagbear (talk) 02:00, 11 March 2021 (UTC)

Alright. You say you like it, so join the compact! Only in your own mind is fine. Now we only need 28 more!

Yes, right, you do hear that -- that admins who work in fraught areas and make hard decisions are going to make so many enemies that they become vulnerable. Nobody really knows if this is true, but I would not take counsel of my fears, as it seem to me that such an admin would acquire many admirers also -- and more at an RfA, where people not familiar with that admin are exposed to her work. After all some RfA candidates now have pissed off people who deserved it, and they get in.

I just don't see... if an admin gets like 40 oppose votes in RfA... I mean if you have that many enemies, isn't something wrong? And if it's really a case of a bunch of bad actors ganging up on a good admin, isn't that going to be apparent and backfire?

As to enforcement... if an admin agrees to be subject to reconfirmation using whatever criteria they wanted (should be written down somewhere for convenience, but you can always go look at the RfA), and reneges? Is that what you're asking? Well OK then the community has a number of escalating steps we can take:

1. Drag the guy to WP:ANI. Tell the Admin Corps in effect "This lying POS is going back on her word. You can't desysop her, but you can ban her. Police yourselves, and do it." Maybe they will, or maybe they'll be derelict in their duty and won't. Can't make them.
2. So if that doesn't work, drag the guy to ArbCom with the same request. Maybe they'll desysop her, or maybe they'll be derelict in their duty and won't. Can't make them.
3. If that doesn't work, you could try going to the Stewards. Show them what happened and ask them to pull the guy's bit. I don't know how the Stewards work but I'm pretty sure this won't work. But you could ask.
4. If that doesn't work, I guess you could take send her to Coventry and also make her famous. Regular public shaming can make a person's life here unpleasant. But you won't be able to do it if the Admin Corps backs her up (they'll go after you for harassment).
5. If the Admin Corps does back her up, them maybe you're missing something and you're in the wrong. That, or the Admin Corps is poltroons. If the Admin Corps is poltroons, you could just sigh, mutter something about nothing straight ever being made from the crooked timber of mankind, and go back to writing articles. Or if the whole thing grates too much, then I suppose you could get a new hobby. Model trains are fun. Herostratus (talk) 02:54, 11 March 2021 (UTC)

What you propose is not just targeted harassment, it is endured harassment with the clearly stated purpose to turn the user's life to hell. This is not compatible with the terms of use.--Ymblanter (talk) 08:25, 11 March 2021 (UTC)

Strongest possible agree with Ymblanter here. If this 'pact' happens, you'll be lucky to just get badgered to hell. "Don't disrupt the encyclopedia to make a point", etc etc. Vaticidalprophet (talk) 02:03, 12 March 2021 (UTC)

So we should hypothetically reject otherwise perfectly good candidates for RfA (where we already have so few candidates) to make a point? That's a bit WP:POINTY, and it certainly won't help with the already existing laundry list requirements of some editors... RandomCanadian (talk / contribs) 03:04, 11 March 2021 (UTC)

(edit conflict)Of course we should, and there's nothing hypothetical about it. Unless you like taking risks. I mean if you're a hiring manager, and the candidate looks like a really excellent fit, you're ready to go with him, and he's like "One more thing, would you sign this contract saying that the job's for life, absent some really egregious behavior that gets me hauled before the division Vice-President?", wouldn't that kind of kill your enthusiasm?

This should have been done from the start. It should have been a required question from the start. It's just common good practice. Got overlooked, but it's time to stop overlooking it.

But you be you, and that's fine. There's really no need to comment here -- this is not that kind of thread. We're looking for 30 28 or so good humans and true. Editors who're not on board, OK. Herostratus (talk) 03:19, 11 March 2021 (UTC)

There's already desysopping for inactivity (which we could make more stringent to avoid the potential gaming); and there's little evidence that ArbCom isn't able to handle the current situation; let alone consensus to implement something like this. RandomCanadian (talk / contribs) 03:22, 11 March 2021 (UTC)

Who said anything about consensus? This isn't one of those kinds of proposals.

I don't know what the ArbCom will do, and that makes two of us. But I mean, ultimately the Wikipedia runs on norms and ethics and good faith. If an administrator is like "Yeah I agreed to be available for recall, which is how I got elected, but I was lying, and screw you"... well they're shameless, is all, and they've disgraced themselves in front of everybody, and themselves too. There shouldn't be any need for enforcement: they just go to the Stewards, point to the failed RfA, and have them pull your bit. I did. Who wouldn't? If the person won't do that... there're things you can do, let's assume that's never going to happen and not go there yet. Herostratus (talk) 04:08, 11 March 2021 (UTC)

The recall question should be the standard RFA Q4. Levivich ^harass/_hound 03:12, 11 March 2021 (UTC)

Welcome aboard User:Levivich! We're down to 27. Herostratus (talk) 03:20, 11 March 2021 (UTC)

Many administrators have good reasons why they aren't open to recall. For instance, if I ran for adminship, I would not be open to recall, to prevent abuse by users who, for instance, hold grudges from that article I deleted that they created. And if I required admin endorsers, then there could be an admin who I had a dispute with at WP:ANI who voted to desysop me. You see, even if that article I deleted was deleted for a good reason. If I decided to work in editing restrictions or content disputes, there could be a huge coalition of users who wanted me desysoped. All they are waiting for is some excuse for desysoping me when I block one of them for edit warring. All of these meatpuppets, to come to their comrade's rescue, start a recall discussion. The editors with sense vote no, but they are outnumbered, and I am inevitably desysoped. See the danger of being open to recall? 🐔 Chicdat  ^{Bawk to me!} 12:46, 11 March 2021 (UTC)

The danger you describe is not real, proven by the fact that over 100 admins are already recallable and we haven't even had someone start a recall process in a decade. If this hypothetical danger of retribution were real, it would have happened at least once by now. Levivich ^harass/_hound 15:19, 21 March 2021 (UTC)

The problem here is that this suffers from the same issues as the subject of this RfC: work in a controversial area and you rack up some people hating you fast enough, and you just need one negatively closed thread and BAM, you're up for recall. Anything, really anything, below 3 rather significant loss-of-faith cases need to be done by ArbCom (however much I despise that system), not in any form by the community. If there is anything of a significant, repeating pattern then there is case for desysop. This really needs to be protected by a '(at least) three strikes' type of system (which neither this, nor the original RfC question above have) if the community itself has to do it. Otherwise you will see a breakdown of the whole admin corps to a level that not enough admins will be available to maintain Wikipedia (and the admins that are left over will have to take over the controversial stuff and hence follow suit of the first rather fast as well, or admins that refuse to do controversial stuff so they run less risk and just do the standard). --Dirk Beetstra ^{T C} 05:53, 11 March 2021 (UTC)

OK, well, to drive my point home that this is not kind of thread, I'll be rude (for effect, nothing personal): OK, noted. You're not on board. Next. We're not looking for consensus here. You can't stop this because it's not that kind of typical Wikipedia argle-bargle. You can't "vote against" people individually refusing to accept new admins on a perfectly reasonable basis or require anyone to get a "consensus" to do so.

We're not arguing. We're just recruiting. 28 to go.

But to argue on the merits for the fencesitters: I don't buy it. I don't. First of all, it's not going to happen, I don't think. Don't be afraid of the community, don't take counsel of fears. If it doesn't work, it'll basically auto-correct itself. Whether constantly bringing up this dubious point is, consciously or unconsciously self-serving... I don't know. Probably, from what I know of people. It's just bogeyman talk.

Second of all: I don't care what areas you work in -- if you've been an admin for a couple-few years, and you have a reconfirmation RfA, and 120 people vote, and 35 say "Well, thank you for service, but this just isn't working for the organization", I mean, you're doing something wrong. You need to find a way to not have like 35 people go over the totality of your record and say "Nah, didn't work". If you can't... should you keep adminning? Not in my book.

And if you can't stand the heat stay out of the kitchen. There's plenty of admin work that we need done where you don't supposedly end up being the innocent victim of a whole bunch of people being inexplicably mad at you. If working in politically fraught areas is not a strength point for you, leave it to others. I'm confident we'll manage.

And good grief, you're not going to decimated the Admin Corps because existing admins are grandfathered out unless they want in. We're raising up like what, 20 admins a year? It's trivial. Too trivial in fact, but at least it's a start. Herostratus (talk) 13:28, 11 March 2021 (UTC)

Herostratus, there are good points in that, but if you enforce this you run a ReRFA every so many months whenever you upset some people. I am not against either of above system and this, but with a quench on it, the ‘3 strikes’. As I say above, we make mistakes (self-trout on special:nuke, I had half of Wikipedia piling on on my talkpage and ANI). If I now do the same there is cause for worry, I don’t learn. 3 times with 3 different ones, fine, I am doing something wrong. But we need a threshold first, and let ArbCom for now handle the ‘first strike cases’.

Just thinking out loud: first mistake - ReRFA, you pass; second mistake - ReRFA, you pass but just, ... that is a lot of stress for nothing. Try with a bit of threshold first, then losen. Dirk Beetstra ^{T C} 15:46, 11 March 2021 (UTC)

(edit conflict)Yes, right, right. Fair points. OK... let's think about how this would work out...

First, I don't believe it's going to happen. If you -- scratch the "you"; if you're an admin now you're OK, grandpa -- if the admin is not making a mistake, people aren't going to pile on them. If they did make a mistake, yes maybe enough people will be mad at them to force a reconfirmation (and remember, there is a seven day period for people to cool down and withdraw their signatures, and for other people (including that admin) to make arguments about how the admin should be not be required to reconfirm -- maybe pursuade some people to not sign, or withdraw their signatures if they have.)

But maybe I'm wrong. Well.. if the admin is required to go thru an undeserved reconfirmation RfA, that will suck for them. However, I don't believe that very many of the people who are mad at the admin will actually vote against them, if their record is OK.. If they do anyway its a jerk move, and they're being jerks. I don't think that the community has that many jerks. If you do, are you sure you're not being a sourpuss from too much time dealing with contumacious reprobates? Go do some easier (but still necessary!) work for a while. People here are great, actually!

I mean, I recently got in a rough-and-tumble with an admin, and he was way wrong. And he was being kind of full of himself and sort of pulling rank about it. But, apparently he's a well-respected admin of long standing, so I mean, it's fine. He's not perfect. Maybe he was having a bad day. Maybe he got his back up -- people do. Supposing he was in Category:Wikipedia administrators open to recall (maybe he is). I'm not going to try to recall him, and if I did no way I'd get five other people on board. And if I did, he'd pass his reconfirmation with flying colors (although yes, he would have to go thru the annoyance). Now... if he'd blocked me out of spite, that's different. That'd be egregious abuse to a concerning degree and maybe we should check to see if that's been a pattern. A reconfirmation RfA would do that... for this guy I probably wouldn't have gotten five other signatures anyway tho. So... I'm not seeing a big problem here.

And trolls trying to make drama? they'll be handled. They are elsewhere. It'll be fine.

Extended detail on how trolls aren't anything to worry about (OK to skip)

So... if trolls try to abuse the system -- well, there aren't any safeguards written down to prevent people being trolls: say, nominating an admin for reconfirmation RfA one after the other as soon as they pass (and the troll would need a tag-team of five confederates, mind you). But there aren't safeguards written down for a lot of trollish behavior, and we manage.

For instance, as far as I know, there's nothing written down that says you can't keep nominating an article for AfD over and over as soon at passes one. But nobody does. Because what happens if someone does that? The second AfD is a near-unanimous Keep, maybe speedy, and the troll gets yelled at and if they have a pattern of that they quickly get topic-banned, or maybe right off. So it's really rare. Same thing here. I'm not likely to vote Oppose against someone who just passed a reconfirmation RfA, and very few people would. Even if the admin is like "I just passed a reconfirmation, and now I'm being dragged to another one, and I'm done with that and I'm not going to agree to be subject to confirmation anymore", I'd maybe be sympathetic and consider voting Support in that case I guess and so would most of the compact I think.

And I mean... someone could do a MfD on the RfA, and suspend the RfA while that's in progress (there are ways to do that easily) -- in fact, this is precisely what happened in the pilot case, if I remember right. The pilot case easily passed the MfD because it wasn't trollery. If it had been it wouldn't have. The community is not morons. Relax. Or I mean someone could just delete the RfA page on grounds of trollery (using the unwritten rule WP:No. Just... no.) and if basically nobody objects, you're good.

And I mean we've discovered a nest of malcontent trolls (the troll and his five confederates). They're surely topic banned at least, and problem solved.

Don't worry about it too much. There are plenty of safeguards against trollery and assholery. The community works. The river will find the right path.

Remember, this is going to happen provided enough people are nodding their heads right now, or will. There's nothing anybody can do about it. This is not a proposal. Three strikes or four balls and the ArbCom this or that and what have you... This thread is not one of those threads, let's get our heads around that.

And one more thing. Remember, I went through this. In my opinion, it was bullshit. I didn't deserve to lose the bit. But or course I'm going to think that, and who cares what I think. It is what the community thinks that matters. Even if they're "wrong" on the merits, it's what matters. That's how we are supposed to roll, should role, and must roll. If you're going to be a big shot around here you had better believe in the community. I did and do, and so can you. If you don't... that's not a good look, for someone wanting to be a big shot. Herostratus (talk) 17:40, 11 March 2021 (UTC)

• If I weren't such a nice person, I'd say the following, but of course I would never say something like that. People. We ALREADY HAVE a discussion on a proposal here. You could try reading it. (First of all, I didn't read all of the stuff about being open to recall. But recall is not a standard process. An admin can say they are open to recall, but construct it in such a way that it is toothless. And even at its best, recall isn't a deliberative process that brings in a large cross-section of the community.) --Tryptofish (talk) 16:55, 11 March 2021 (UTC)

No we shouldn't try reading it. I looked at the numbers. You're running 58% percent in favor. Nobody's going to close the RfC like this as "accepted" with those numbers, and with 285 voters so far, you're not going to be able to move that percentage up much. The proposal is not going to be accepted, and that's all I need to know. We're moving on from that, here.

And if the proposal is accepted, well God bless you, and you're good to go. You can ignore all this if like. But it's not going to be, so let's move on.

So on the other... an admin can't construct anything to make anything toothless, no. We're not morons here. Somebody trying to be disingenuous... that's not going to fly. If someone is like "Sure I'm open to reconfirmation, but I'm not going to with the standard offer; I'm going to require 35 signatures." That's patently toothless, and everybody in the compact is going to take that as tantamount to "No". If they try to get fancy with complicated requirements to try to pull the wool over our eyes, that's going to be to be taken as a "No". If the requirements are reasonable, that's different, that's fine and no problem. The compact is going to be mostly good, smart people, just as most of the editors here are.

If the person is just lying and, if sent to reconfirmation, goes like "Well, I changed my mind, and go pound sand"... yes, that's a problem. I'm kind of assuming that most admins aren't blackguards, but if one is, I did outline some steps to take. They might not work. But if an admin is so determined to hang on to her bit that she'll burn the world... well, at least we'll know she's a blackguard, and bring it up every time she tries to pull something. I really don't think she'll be having fun anymore, so... Herostratus (talk) 18:15, 11 March 2021 (UTC)

"No we shouldn't try reading it." Let's make that the new slogan for Wikipedia! (Much better than "The Free Encyclopedia".) --Tryptofish (talk) 18:33, 11 March 2021 (UTC)

Lol. You should take a look at the Russian Wikipedia. It reads you. But I mean, I'm just doing time management. Herostratus (talk) 00:47, 12 March 2021 (UTC)

• Herostratus, I looked at the !numbers as well. But I don't believe in the drastically enforced changes. I agree, you may be right, but just in case you are not I am afraid that this is going to go dramatical. Losing 30% of our admins is not going to go right (what if it is 50%). Our refill rate is not going to compensate that. I hate losing those 30% and having to say to 25% of that (or 40 if it turns out 50%) 'sorry, it was an experiment, too bad, your bit is gone, others will take over at some point'. Being an admin is not a big deal, but we need them nonetheless. I am all for the '3 strikes' and then figuring out it only rips out 1%, and thén saying 'OK, lets try to strikes' and then ripping 15% out, instead of not knowing what we do and ripping out 50% and then not knowing what will happens next ('oh, maybe if we made it 2 strikes ...'). There is stuff that IS detrimental (copyvio, spam, bad socks, ...), do we really want to risk that? I know 'slechte heelmeesters maken stinkende wonden' (sorry for the Dutch, try google translate), but 'lets cut of his head, lets see if that cures the pain in his finger' is not cutting the deal either ... Dirk Beetstra ^{T C} 19:34, 11 March 2021 (UTC)

• Point 4 isn't what I was expecting. I was expecting you to say "let's just require all admins to be open to recall". If we decide as a community that we'd like to demand a certain level of accountability from admins, we should demand that from everyone, not form a pact that'd try to force the hand of only future candidates (it's the grandfathered admins who are the larger problem anyways, imo). {{u|Sdkb}} ^talk 21:14, 11 March 2021 (UTC)

Well yes, but: politics is the art of the possible. Taking the current Admin Corps off the table removes, hopefully, a huge stumbling block to getting something going. And yes it will take a few years to have a lot of bite (altho it could possibly come in handy in individual instances within a year), but I mean the years are going to pass anyway, so might as well get started. Discussion is great, but at the end of the day this isn't the senior common room at All Souls, it's the bloody coal face. Let's dig.

And I mean there isn't any way to apply anything worthwhile to the current Admin Corps even if we wanted to. I doubt it's politically possible. (Maybe I'm wrong, and by all means keep trying and godspeed. But I'm not wrong.) And even if we could, I suppose it is possible that anything affecting the entire Admin Corps at once would be overly disruptive the the Admin Corps (I doubt it, because even new candidates who've had no chance to make an admin record are typically accepted 103-3 or something. But you never know. So I mean doing this will bring in a gradual rollout). Herostratus (talk) 00:47, 12 March 2021 (UTC)

So you're saying we should use this for future admins (which likely are much more selectively chosen than before, because laundry list RfAs) but not for some older admins, whom supposedly some people have a problem with for xyz reason. Seems like a real winner move: solving a supposed problem by applying the solution to the non-problem... Your whole post reads like there's a WP:CABAL of the "Admin Corps": again, to repeat the point: adminship shouldn't be a big deal - it's just a few tools to make life easier for others. As for politics: if we could get rid of that here and just worry about writing a friggin encyclopedia that'd be a great improvement; and it's not like there's nothing to do... RandomCanadian (talk / contribs) 00:59, 12 March 2021 (UTC)

OK. No need to get agitated. "As for politics: if we could get rid of that..." well now that's always the tricky part isn't it. "As for gravity: if we could get rid of that..."

I don't have an opinion on whether there's some way to include current admins in some system or whether that's even a good idea. Why have an opinion on something that's not going to happen.

If you or anybody can make it happen, great! (I guess.) Nothing we're doing in this thread impacts that at all. But absent that, do you just want whine about who's a winner and who isn't. If you're not on board with the compact, fine, thanks for sharing, I guess.

Well, the ArbCom does get rid of a couple of bad admins a year I guess. And there's general attrition. At time passes a growing percentage of admins will be subject to reconfirmation. I personally come across bad admins very rarely, but if they're out there that sucks. But nothing we're doing with the compact is going to make that any worse I guess, so what's the problem?

One more thing on the subject of politics. People, stop saying "recall". Use "reconfirmation". That casts it in a positive light. Propaganda 101. And we hope that the admin will be reconfirmed! That's a win. The person was selected to be admin, and now he's been checked out and reselected! Something for him to be proud of! But some will have to be informed that we think their strengths and value lie in other areas. Herostratus (talk) 04:56, 12 March 2021 (UTC)

People, stop saying "recall". Use "reconfirmation". That casts it in a positive light. Propaganda 101. You think it works when you say that's what you're doing? (Every terrible admin I've run into got the bit when I was in grade school or younger; well aside from everything else about this proposal, it punishes the innocent and frees the guilty.) Vaticidalprophet (talk) 05:42, 12 March 2021 (UTC)

Whatever happens, you'll want to have stuff along these lines made and ready to go. Herostratus (talk) 05:27, 12 March 2021 (UTC)

This admin has been reconfirmed and is proud of it!

This former admin is proud to have put the will of the many above the will of the few, or the one.

Saying adminship is not a big deal is a fallacy. If it was truly not a big deal we wouldn't need to try to reform the process every fifteen minutes. Anarchyte (talk • work) 06:57, 13 March 2021 (UTC)

• That idea is actually dangerous if you look at how it would actually work.

If you can convince a fraction of RfA !voters that is large enough to block otherwise-unopposed candidates, you can probably craft a proposal that would pass. So in reality, what you hope for is an RfA with something like ~55% full support, ~30% "no content creation or whatever" opposes, and ~15% "would support but the candidate is not open to recall" !votes. At that point, either enough in the "recall needed" side fold and support anyway (or the closing 'crat ignores those !votes), in which case the whole thing is toothless; or you become an earth-scorching mob, killing a good candidacy to make a point about the process.

I would be tempted to join, really: the Cause is Just or something. But next, there will be a faction that decides that only native English speakers or certified linguists should get the bit (because adminship requires an exquisite command of language subtelties). Or only those with >500 AfDs participations because they might close some (even if the candidate indicates no interest in doing so, what if they change their mind in ten years?). Or anything really - as long as you can express the idea without getting blocked and you get enough blind supporters, you are golden.

If making a point by sacrificing the candidate becomes acceptable practice at RfAs, I doubt the environment would improve. This means importing the workings of political parties into Wikipedia processes (you may debate internally at your leisure, but in public you defend the party line tooth and nail even against your own opinion), which does not foster good arguments. A good deal of RfA comments are stupid, sure, but I am confident that they are individually stupid, and having to type your own stupid comment puts an upper bound on how stupid it can be. Tigraan^{Click here to contact me} 13:11, 15 March 2021 (UTC)

@Herostratus: I will join your compact. Is there a sign-up list? Tim Smith (talk) 04:57, 21 March 2021 (UTC)

Oh, adminship

Adminship is one of the most disappointing areas on Wikipedia. When Jimbo Wales first created adminship, it was given to people with barely 1,000 edits. A lot of those editors hardly even edited. But they didn't show off their role. Unless you had serious issues, adminship's requirements were as subtle as that of our modern extended confirmed: it was basically, "A user appears on Wikipedia in 2004 and makes a few edits. The 47th edit is to ask for adminship. It is granted, after small numbers of support !votes saying 'Adminship is no big deal.' The user is granted the tools. They forget about Wikipedia. They remain an admin for seven years, not making a single edit, when they are desysoped for inactivity." We didn't even need desysoping back then, because no one thought that adminship was a big deal. Then, slowly but surely, the number of new admins started to decline. By 2010, users were getting enamored in "RfA reform." The perennial proposal of community desysoping, WP:Requests for de-adminship, etc. began. All these things continued until 2013. By then, upwards of 100 editors were !voting in RfAs. The traditional "Support - no big deal" so often seen on 2003 – 2010 RfAs was becoming rarer and rarer. Fewer editors were thinking of adminship as "no big deal", being dwarfed by the editors who suddenly required: "10,000 edits! 5 FAs! 20 GAs! 500 AIV reports! 500 RfPP reports! 10 user rights! 10 years!" Before, most users' criteria were "at least one non-stub", which would give WP:SNOW candidates like Prahlad balaji "automatic" adminship, but criteria got bigger and bigger. Our doomed number of active admins got lower and lower. The old 2000s admins, one by one, began to retire. In the one year (only!) I've been on Wikipedia, I've seen many a 10 or 15 year editor, often an admin, leave, saying something like "Wikipedia has changed so much. It has become too hostile for me." Before that moment, that admin could be, say, responsible for 36% of all AfC reviewing, and the 5000-draft backlog only developed afterwards. Wikipedia's admins are leaving, and, instead of making RfA easier, we propose all sorts of "adminship term length" and "community-based desysop" to make it EASIER for those admins' removal. These poor users are now saying, "Wikipedia is too hostile for me" when we are making things worse. Adminship should be "no big deal" again. But it's very hard if every few hours we're yelling, "Why not make a recall process for admins? We hold a reconfirmation RfA every three weeks for each admin." This would put so much stress on these poor admins that they would all resign. Sometimes the admin is behaving badly, like in the case of Bbb23, but that is the only case I can think of. Any thoughts? 🐔 Chicdat  ^{Bawk to me!} 12:58, 14 March 2021 (UTC)

Adminship was a "no big deal" deal when Wikipedia was much smaller and simpler as a project but it was experiencing a steady influx of new regular editors. Now things are completely different. Adminship as a job has become much more complicated, involved and often unpleasant because Wikipedia has become much more complex. At the same time the incoming supply of new regular editors has stagnated. The only realistic way to make adminship be "no big deal" again is to dramatically change the nature of the job, most likely through unbundling the tools and introducing various new limited user rights. Nsk92 (talk) 11:40, 15 March 2021 (UTC)

Precisely because the admin flag is not a big deal, there is no need to make a drama out of the fact that someone's flag will be removed. What Wikipedia really needs is some sort of easy group decision-making process that doesn't put extra weight on admins — that's why people burn out and leave. ·Carn·!? 14:35, 14 April 2021 (UTC)

I agree completely (although it could do with c/e). The problem is that RfA is broken, and no consensus to fix it. And proposals like this, should it pass, will give prospective RfA candidates one more reason not to bother. Jules (Mrjulesd) 14:54, 14 March 2021 (UTC)

I think the adage "Be careful what you ask for. You just might get it!" applies. Apparently some people think we can do without a large swath of our admin corps and keep this project going. We can't. What's depressing is this RfC will most likely be closed by someone without sufficient experience and without the requisite consensus evaluation skills. There's 124 130 printed pages to this RfC now. I dare say few, if any, will read it in full to even begin assessing consensus properly. Thus, some well-meaning, but woefully unprepared closer will close this as pass, and there goes a large swath of our admin corps. --Hammersoft (talk) 00:38, 15 March 2021 (UTC)

I'm somewhat unfamiliar with the standards for deciding consensus, but with 125 separate individuals (many with long experience) voting against it, it doesn't strike me as an obvious "there is consensus" result. There is a majority (164:125), but we're not counting !votes. Would that narrow a margin really be considered consensus? Tarl N. (discuss) 01:10, 15 March 2021 (UTC)

Other than pique, what would be the reason for the large swathe leaving? - Ryk72 ^talk 01:18, 15 March 2021 (UTC)

• When the German wikipedia launched their community desysop system, they promptly lost something like 1/3rd of their admin corps. But (not aimed at you), who cares? We need something, so we might as well do this, right? Consequences be damned. <sigh> --Hammersoft (talk) 01:29, 15 March 2021 (UTC)

  Hammersoft, I'm curious, what happened to the 1/3? Were there tons of desysops, or did admins just resign in protest, or something else? -- RoySmith (talk) 01:33, 15 March 2021 (UTC)

  • It's been some years, but as I recall when faced with a reconfirmation request, much as like here, many refused to go through it. RfA is hellish to many as it is. To be forced to go through it when you know there is blood in the water (not just hope there isn't) is too much for many people. We are all volunteers here. To willingly put yourself into such a situation is not acceptable to many people. So, the short of it is if you get one thread at WP:AN/I that results even moderately against you, you're basically screwed. It's not worth it to many people. --Hammersoft (talk) 01:39, 15 March 2021 (UTC)

    So what if 1/3 of the German admins left? I'm not that familiar with the German Wikipedia, but from what I do know it's still around and chugging along perfectly fine without them. Anyway, a decision for how people should be held accountable for their actions should not be determined by fear of said people taking their toys and going home. Being an admin is a privilege's and it should be treated like one. If that means more accountability is needed then the current system, fine. That's the cost of having the privilege. If an admin isn't willing to go through a reconfirmation process because they think it's to arduous or whatever, or if they take issue with having to follow basic standards of behavior, then clearly they don't see their privileged position as one and shouldn't have it. --Adamant1 (talk) 02:24, 15 March 2021 (UTC)

• Define "chugging along perfectly fine". Let me give you a counter example; Commons. Commons has a serious lack of administrators. There are deletion discussions there that are 10 months old and haven't been closed. 10 months. Is Commons still operating? Sure. But, it's capability to stay on top of backlogs is gone. That project will collapse in the years ahead because control of incoming files will fall apart. We are unequivocally headed in the same direction, as this rather painfully shows. The German wikipedia has lost 42.9% of its administrator corps from it's peak in 2009. We've lost 23.6% of our admin corps since our peak in 2010. Administrators are already held accountable for their actions. ArbCom has shown a willingness to take on administrator conduct cases at the slightest whiff of impropriety, making this process meaningless. Three administrators were forcibly removed by ArbCom in 2020, and another four in 2019. I don't know any administrator that has issue with following basic standards of conduct. This reconfirmation process enables bad actors to game the system. Allowing reconfirmations to proceed with so little protections pretty much guarantees that administrators will have to face a reconfirmation RfA with the flimsiest of reasons. There's no evidence gathering, no opportunity for rebuttal, no declarations of scope, no control over how much antagonists can write. In effect, it's a free-for-all lynching. I doubt there's many administrators who would want to face that. Being an admin doesn't really grant extra privileges on the project. It gives you some tools to do volunteer work on behalf of the community. Acting with those tools carries significant responsibility. Trying to defend such usage in the face of a process that has little protections and no opportunity for evidence gathering is pointless. --Hammersoft (talk) 02:53, 15 March 2021 (UTC)

• @Hammersoft: Try Wiktionary. The article "Fine-looking" has been sitting there for 17 months. There is consensus to delete, but there is not a single admin that has the time to close the request. Wiktionary and Commons? Wikipedia is already like them in some regards. Take, Articles for Creation. Its backlog has 5,100 submissions going back 5 months. I used to clear the 4 month category every day, but it included impatient editors who pressured me to accept the drafts, so I stopped reviewing. And that's an example of a backlog that isn't even restricted to admins. Some backlogs can be terrible for the users affected. Unblock requests, say. If it's backlogged, then it's super easy to clear it. All you say is, "Procedural decline only. This unblock request has been open for over two weeks but has not been answered. If you substantially reword your request...." when you could say, "Sorry, the unblock request category was backlogged, so I'm sorry I got to you so late. Now... [accepts or declines]" We need more admins. This does the opposite. I strike my !vote. I !vote oppose. 🐔 Chicdat  ^{Bawk to me!} 10:19, 15 March 2021 (UTC)
• Here's something ridiculous: Yesterday I was browsing a 2010 RfA and found that some users !voted like this, "Oppose - we have too many admins." I wish we were in those days, where the problem was that the admins didn't have anything to do, since the backlogs were cleared so quickly. 🐔 Chicdat  ^{Bawk to me!} 10:19, 15 March 2021 (UTC)

• Both Commons and Wikipedia should do more on the back end to recruit administrators. Like you say, they are already going down with both projects though and they still will decline on Wikipedia if this implemented or not, but that doesn't mean standards of behavior and things related to accountability should not evolve or be updated in the meantime. The same could also go for the decline in editors over the years, but that doesn't mean standards or processes of accountability for users should be relaxed or gotten rid of just to gain more editors. There's better ways to recruit people. I don't know any admin that has a problem following basic standards of behavior either. My point was purely related to the possibility of admin deciding to desyop themselves because they don't want to be re-confirmed. The only reason they wouldn't want to go through the process again, aside from it just being a hassle, is so their past behavior isn't brought up. In the meantime, there's zero evidence that passing this RfC will allow "gaming the system." Even admins support it. Framing the community based process this would allow for as a "free-for-all lynching" is rather hyperbolic. I've been through some pretty BS ANI processes myself and I wouldn't even go that far. Again though, being an admin is a privilege and it's one granted by the community. So there's zero reason it shouldn't also be taken away by the community. Clearly that's not how ArbCom works. It isn't a community based solution and clearly it isn't working on it's own or there wouldn't be a need for this RfC in the first place. Nor would this keep coming up. It doesn't matter what the admins want to face or not, it matters what the best way to deal with bad behavior is and clearly this is a needed solution to the problem. Is it the "best" solution? No. It's a better one then what there currently is though. --Adamant1 (talk) 03:12, 15 March 2021 (UTC)

  Adamant1, how is ArbCom not a community based solution? It, obviously, has quite some support if we have significant numbers of people volunteering to be on the committee, and significant numbers of people voting to elect their preferred candidates. We choose to have an ArbCom.

  I agree that we can come up with a community-based decision (as opposed to a community-based-committee-based-decision), what I am afraid of are too-lax selection criteria of who stands for reconfirmation, making 1/3 of the people decide that they do not want to do it anymore and resign pre-emptively (we are then at a total loss of 50% of the admins since 2010), then losing another 1/3 who go through the process (or who see others go and decide to go). And then? The process was wrong, sorry, thank you? Do we want to run the risk that we can't handle deletion discussions, spamming, BLP violations, etc. etc. anymore?

  Yes, we should do more to attract more admins, but this process will first make people more reluctant to become one, and since we have no significant upgoing trend in getting more admins now (we are not doing anything on the back end to recruit administrators) and run the risk that this is going to cost us a massive number of admins (even if here the same happens as at de.wikipedia, and we lose 1/3 then by the end of 2021 we have lost almost 50% of the admins since the peak in 2010).

  This starts to feel a bit like Darwin awards meets the empty-toilet-roll-"Never start a project unless all resources are available"-meme. Dirk Beetstra ^{T C} 06:26, 15 March 2021 (UTC)

  • ArbCom is a way less community based process then ANI. They aren't even comparable in the level of participation or people who browse one versus the other. ArbCom by it's nature isn't as exclusive as ANI is. There's also nothing in this RfC from what I can tell that would completely take ArbCom out of the process. They would still usable in instances where they need to be. This just makes them not the automatic go to for admin dispute resolution. On the selection process might be too-lax thing, it might be. It might not be though, and at least it can be adjusted after a trial period. That's how things work. Nothing is perfect. Especially on first tries. That doesn't mean they aren't worth doing though. Same goes for your whole "we are going to lose 1/3 of the admins if we implement this." There's zero evidence that will happen and even if it does there are better ways to get more admins, who will be fine with re-confirmation. I especially disagree with your "massive" judgement about how many admins will be lost when plenty of admins have given their approval for this. I didn't do an exact count, but it seems like at this point more are for then against it. Most of the people who are against it agree that ArbCom isn't the best way to do things and that at least something should be done to. So, what's the alternative? On Wikipedia not being able to handle deletion discussions Etc. Etc. Again, that's just more crystal ball fear mongering and its not what happened with the German Wikipedia even after they lost 1/3 of their admins. Again though, the way to make sure that doesn't happen is to recruit more admins who are willing to abide by modern standards and processes. Not just keep around the ones who aren't. --Adamant1 (talk) 09:24, 15 March 2021 (UTC)

    Then the community either figures out a new RfA process that resembles the criteria from 'the good old days' / one that can output admins at a significantly higher output than the current one, or it puts up with those backlogs. Suspect folks would figure something out rather than see WP:AN get spammed with even more backlog notices than it already does. ProcrastinatingReader (talk) 11:28, 15 March 2021 (UTC)

ArbCom cases are effectively a supervote at the end of the day. Us editors are allowed to leave our opinions but that doesn't mean the committee has to take them into account when they vote accept/decline, and I think that's what angers most of the people in the support column. By making de-adminship go through the community without excessive restrictions it gives the impression that we might actually have a say past the initial RfA. I'm not saying this proposal is flawless (my support is tentative), but it's better than sitting around and twiddling our thumbs for another twelve months as we wonder why everyone complains about the adminship process. I think it's inevitable that some admins do decide, if this passes, that it's too bureaucratic and would rather resign their rights than go through the torture of another RfA, but it should hopefully open up other avenues of expanding the admin pool. The most immediate aspect that might change could be the stringent admin criteria that some serial opposers use. If everyone becomes capable of starting de-adminship requests instead of being shoehorned into having one shot to prevent an RfA from passing, then maybe they'll be more lenient and being granted the role will slowly develop back to not being too big a deal. Anarchyte (talk • work) 11:40, 15 March 2021 (UTC)

• I dunno why it took until Anarchyte's last sentence above to say it in this section, but IMO that is the main argument for the proposal: making it easier to desysop lessens the deal that adminship has become, so that RfA becomes easier to pass. There are cogent counterarguments to make ("adminship would still be a big deal", "it would guarantee an immediate hit at admin numbers for a speculative long-term benefit", etc.) but "tougher life as admin = fewer admins" is not one of them. Tigraan^{Click here to contact me} 12:29, 15 March 2021 (UTC)

The irony is this proposal gives the community less power. It requires under 40% in favour of keeping to pass, and although it's not explicitly said many editors probably expect desysops go via this process, not ArbCom. People will likely oppose raising the threshold to 60%, and ArbCom will probably decline cases on the basis of "use the community process / community DR not exhausted" (and when it is they'll probably say "community voted to retain, ArbCom shouldn't overrule the community", or at least many statements will likely urge them to vote that way). A 40% threshold is so poor only the most unpopular admins would actually fail to achieve that support. Indeed, if User:Thryduulf/What happened after a desysop is anything to go by, those 3 desysops with above 40% but under 65% support in re-RfA would not have happened under this proposal (for better or worse). This proposal pretty much makes popular admins undesysoppable, imo. ProcrastinatingReader (talk) 12:41, 15 March 2021 (UTC)

The idea that passing this proposal means it will be easier to pass RfA, and thus we'll get more administrators is unfounded speculation. As a reference point with actual data: On the German Wikipedia, they instituted their de-adminship in late 2009. Since then, the number of successful RfAs has on average continued to decline, as the chart I am including here shows. Coming up with real data to support solution finding is critical in any problem solving matrix. Plenty of people have their pet theories on what is wrong with RfA, and why we must or must not have de-adminship outside of ArbCom. Acting without real data is simply guessing. --Hammersoft (talk) 15:51, 15 March 2021 (UTC)

That kind of data is very helpful, thanks. Does that decline result from fewer RfAs being attempted, or from fewer of the attempted RfAs being successful? --Tryptofish (talk) 16:51, 15 March 2021 (UTC)

• I don't know, though it's a worthy question. I was only attempting to gather data to support or refute the presumption that a de-adminship process would result in increased numbers of successful RfAs. On the German Wikipedia, it didn't. --Hammersoft (talk) 17:05, 15 March 2021 (UTC)

Looking at the chart it appears that the Germany Wikipedia did not lose admins at any different rate after the policy was passed then before. So apparently it had zero effect on the rate of decline and the opinion that it did is basically just fear mongering. Which is what my supposition was. If anything it looks like the number of admins that were being lost over time decreased after it's passage. Although obviously the number of admins hasn't increased since then, but it wasn't increasing anyway. So, clearly they are separate issues that should be dealt with as such. In the meantime though, there's clearly zero correlation between the passage of things like this and losing admins. --Adamant1 (talk) 00:56, 16 March 2021 (UTC)

• No Adamant1, it is not fear mongering. The data displayed is for new RfAs, not administrators being recalled/reconfirmed. This dataset can not show or disprove a correlation, nor should any attempt to do so be done with it. It's simply not relevant. --Hammersoft (talk) 01:10, 16 March 2021 (UTC)

  How many admins were desysopped on the German Wikipedia via the community process, and for what reasons, does anyone know? ProcrastinatingReader (talk) 01:20, 16 March 2021 (UTC)

  • I don't know, and it's harder to derive that data from what I've been able to drum up. I recall the issue about them losing a ton of administrators after it was implemented, but this was 10+ years ago. I can't remember where that conversation took place. The data is complicated by changing definitions of voluntary, reconfirmed, etc. It looks like ~57% of involuntary re-elections were successful (82 of 143). But, this figure does not include the administrators who refused to go through the re-election process. That's where there was a sizeable drop off of administrators. I wish I could find the article that discussed this. Maybe somebody else can. I'll keep digging. --Hammersoft (talk) 02:19, 16 March 2021 (UTC)
  • Ah HA! I found it! Check out Wikipedia:Administrators/RfC for binding administrator recall#Statistics from German Wikipedia. Short of it; when faced with a recall election, 37% of administrators retired or refused to respond. Extrapolating from that data, using that in 2009, the German Wikipedia had ~325 administrators: In 2009, 67 reconfirmations were run. 12 were re-elected, 34 not re-elected, and 21 chose to retire. So, 18% of the 67 were re-elected. The rest failed or retired. 67 of 325 faced reconfirmation, or 20.6%. We currently have 1,109 administrators. If the same rates happened here, we would see 228 administrators face reconfirmation in the first year of implementation. Of those, 41 would be successful. We would lose 187 administrators, or ~16.8% of our administrators. If we look at this from the active administrators perspective; we currently have 498 active administrators ([11]). From this body, we would lose 84 active administrators. This would be the biggest hit to our administrator pool since 2011 (Wikipedia:Desysoppings_by_month). The ones who lost their bit from a reconfirmation, fine. Perhaps they would deserve it. But, there would be ~71 administrators who would simply walk away rather than deal with a reconfirmation. --Hammersoft (talk) 02:50, 16 March 2021 (UTC)

The administrators that failed re-confirmation aside, 21 of them choosing to retire (of which I'm sure more then a few would have failed re-confirmation if they had of gone through with it) out of 325 isn't 1/3 of the administrators. Nor is it that big of a deal in the grand scheme of things. Unless your going to tell me the English Wikipedia community can't come up with 10 or 15 new administrators to mostly make up for the drop. If it can't, then the platform has much larger problems then what this RfC would cause, if it causes any in the first place. So, I stand by the whole "We can't do this because we will lose administrators" being mostly fear mongering comment. BTW, I'm not including the ones the German Wikipedia lost because of failing the re-confirmation process. Since I'm sure some of them deserved to be desysoped and I don't feel like getting into a discussion of how many did or didn't. --Adamant1 (talk) 04:08, 16 March 2021 (UTC)

Adamant1, I remain, now having seen those statistics again, you can first put a hurdle before it and erode it if it is too restrictive, or you can gamble and loose many of them (as the current proposal stands).

You evade the ‘but they deserve it’, but it raises a question: how many of the reelected ones are WP:UNBLOCKABLES? Dirk Beetstra ^{T C} 04:35, 16 March 2021 (UTC)

Or you can gamble (but not really)and not loose many of them, because ultimately one data point from a completely different Wiki with it's own problems isn't definitive enough evidence to say there will be big enough drop for it to grind the project to a halt. Which was the original presumption about it. Not just that some admins will leave because they don't want to be re-confirmed, but that it will be enough to ultimately destroy the project or otherwise make it unmanageable. Which is mainly where the fear mongering comes in. Anyway, I have read through most of the discussion here and I haven't seen a single admin commit to desysoping themselves if they have to be re-confirmed. Out of the admins who have "voted" so far that I've seen none of them have said anything remotely along those lines. We could always do a side RfC straw poll asking how many admins are commit to desysoping themselves if this is passed, but then I wouldn't call that definitive and we shouldn't be held hostage by a super vote of retaliatory admins either. --Adamant1 (talk) 05:01, 16 March 2021 (UTC)

• I believe you are choosing what you want to see. The figures show 97 out of 325 being removed from adminship. That's ~30%. Ok, it's not 33%, so you're technically correct, it's not 1/3rd. I see losing 84 active administrators as a catastrophic impact on the project. You don't. Several examples of projects that are failing for lack of administrators have been noted. You don't see this as a problem. I do. Quite a number of things on this project are already badly backlogged. You don't see this as a problem. I do. And since you asked; if I had to go through a reconfirmation, I would resign rather than run the process. That's not retaliatory, though I imagine you'll interpret it that way. I'm a volunteer here. I'm not going to submit myself to a public flogging so I can have the ability to delete something. It's not that interesting. I also volunteer at a food bank. If I had to endure a public flogging to volunteer there, I wouldn't do it. I'd find some other place to volunteer. At this point, we're talking past each other. You're convinced this will work and I'm convinced it won't. I dare say your view of it isn't convincing me of the veracity of your opinion, nor mine yours. We're done. Thanks, and good luck. --Hammersoft (talk) 06:09, 16 March 2021 (UTC)

At least far as the discussion that I've been involved with you, your main talking point has been about admins who will potentially desysop themselves because of this if it's passed, not just "losing admins", and I've been pretty clear that I am only talking about that and not the ones who will leave the project due to not being re-confirmed. I never denied that it could be 30% of the admins lost total, but I don't care what the percentage of admins are lost if they deserve it. Your argument seems to be that you would be fine with keeping 30% of the admins no matter how they have behaved or what the opinion of is of the community, simply because the project needs admins. Which is inherently faulty logic and just allows for inappropriate behavior. Personally, and I say this as someone who has been admin of other sites before, I don't see anything wrong with dropping people that should be dropped. The fact that you consider any kind of public scrutiny of an admins behavior beyond the few people who decide outcomes in ArbCom as a public flogging or think that admins should somehow be above such things while general editors shouldn't (at the same time your saying admins aren't "privileged" at all) is exactly why we are "talking past each other." I'm making a evidence based, rational, fair argument for why this should be passed. Whereas all your doing is appealing to emotion and trying to scuttle things "because German Wikipedia." I'm not here to convince people like you. I could really care less what your opinion is, because it's not based in reality and is completely non-nonsensical. Which is exactly why you never directly refuted anything I said or bothered to pose a rational alternative to this besides the status quo. You don't have one that isn't doing the same old same old and lamenting nostalgically about the good old days of adminship. So, clearly there's nothing to discuss. Also, I'm pretty sure the place you volunteer at reviews your performance once in a while. If your not willing to have the same thing done here, good riddance IMO. Your exactly the kind of person I'm saying this project shouldn't be held hostage by. Adamant1 (talk) 07:37, 16 March 2021 (UTC)

That might be a bit extreme. Admins that will fail reconfirmation fall into three buckets. "Rotten apples" who stand through the whole process and fail (or who resign a bit before it becomes abundantly clear that they will fail). "Divas" who would be reconfirmed if they stick to the end, but quit early in the process because they think it is beneath them. And "humans" who quit at some point when they would rather have their adminship removed than go through a stressful RfA-like process.

I agree rotten apples should be kicked out, whether that is 1% or 50% of the active admins. Divas are suspicious temperament-wise but some might be decent admins on the average; however, I speculate that divas are not a significant fraction of the admin corps, from the absence of any comment above along the lines of "If this passes do not expect me to go through it". Losing the humans is a negative, but there is the question of how many there are again (they all went through RfA-hell at some point, and from what I see admins who stick around tend to get rougher with age rather than mellower). Tigraan^{Click here to contact me} 15:38, 22 March 2021 (UTC)

When the German wikipedia launched their community desysop system, they promptly lost something like 1/3rd of their admin corps – this appears to be incorrect, Hammersoft, as I had already calculated at Special:Diff/1009704874/1009708189 on March 1.
The figures show 97 out of 325 being removed from adminship. I assume that "97" is "44+33+20" from Wikipedia:Administrators/RfC_for_binding_administrator_recall#Statistics_from_German_Wikipedia. However, this is "From 2009 to February 2015" and thus probably not "out of 325". This statistic is broken by the number of successful RfAs from 2009 to February 2015, as a part of the "97" has likely been elected after the introduction of the process and may even include the same person multiple times. A table of all RfAs, successful or not, can be found at de:Wikipedia:Adminkandidaturen/Statistik. All of these statistics are of dubious usefulness to evaluate the enwiki proposal, as the dewiki procedure is also used to deal with inactive administrators who never did anything wrong.

A graph of dewiki's admin count over time can be found at [12]. I can't see the supposed "catastrophic impact" that is supposed to have happened in or shortly after 2009. It isn't in the graph. Also, dewiki doesn't seem to have been irreparably broken, looking at it today, and considering that the (fine, working) desysop process is still in place. ~ ToBeFree (talk) 18:45, 28 March 2021 (UTC)

Regarding "If we look at this from the active administrators perspective; we currently have 498 active administrators (...). From this body, we would lose 84 active administrators." – no, this is not correct either. It incorrectly assumes that there is no correlation between inactivity and recalls, which is incorrect both for the dewiki situation and the enwiki proposal. This is a misinterpretation of a dewiki statistic, incorrect application of the statistic to enwiki, followed by another logical fallacy. Three errors in a row; meaningless result. ~ ToBeFree (talk) 19:34, 28 March 2021 (UTC)

• • • Fair enough for your opinion. Respectfully, I disagree with your conclusions. --Hammersoft (talk) 02:09, 29 March 2021 (UTC)

@Hammersoft: "Opinions" aside, how come the rate of successful RfAs goes down at the exact same rate after the policy is passed on the Germany Wikipedia then it did before the policy? if the policy made any difference you'd think the rate of RfAs that succeeded would have changed, but it clearly didn't. While that means it didn't make RfAs easier, it didn't make them harder either. Which is my main issue with your assertions about it. The policy had zero effect and your treating the zero effect like it was a negative one when it wasn't. IMO if something has zero effect, the clearly something else needs to change upstream of these kinds of policies. That doesn't mean we should throw the baby out with bath water though. Since the purpose of this policy is to hold the current admins more easily accountable to the community. Not recruit more admins. For whatever reason, you and the other people who share your "opinions" about it are convoluting the two though. --Adamant1 (talk) 03:11, 29 March 2021 (UTC)

• All I know is I've been an admin for 9 1/2 years, and if all the people who lose their shit over the status of administrators ever had free access to the mythical "might" we possess they'd demand a refund. This isn't like Earthsea, where upon a successful RfA a witch takes away your childhood name and you have to find your way naked to a mage who will give you a new name imbued with magic power. Seriously, you'd think this was access to the nuclear football or something; just consider how many electrons you're willing to murder in cold blood to accomplish your goal, and how many you're actually saving in the end, then figure out whether it's honestly worth it. Now back to the actual volunteer work of being an administrator. The Blade of the Northern Lights (話して下さい) 01:13, 7 April 2021 (UTC)

  Re: your edit summary ("Do people here really get what admins do?"): One of the things admins do is decide who can't edit. Another thing admins do is decide what can't be edited. When some admins do these things in a way that people don't like, people want to be able to take those admins' privileges away. Some people think the process for doing that shouldn't be limited to arbcom. That they think so doesn't mean they don't get what admins do, or don't appreciate it. Levivich ^harass/_hound 03:44, 7 April 2021 (UTC)

  Goodness gracious. "When some admins do these things in a way that people don't like, people want to be able to take those admins' privileges away."Doesn't matter that the admin acted within the rules and in the best interests of wiki. If they upset someone who doesn't like the way the admin acted, that someone wants the right to sack the admin. I don't think you really mean that. Moriori (talk) 04:00, 7 April 2021 (UTC)

  So if you can't remove an admin because, say, a hundred veteran admins and a thousand veteran users don't want them to be an admin any more, but you require them to also break some sort of "an admin can never do this and stay an admin" rule, then you need a group of experienced editors chosen by the community for their ability to determine whether an admin has or has not broken those rules. In other words, Arbcom. There has to be a point where if you have pissed enough people off with the way you use the tools we take the tools away from you. The only question is how high we should set the bar. --Guy Macon (talk) 04:41, 7 April 2021 (UTC)

  Group(s) of experienced editors are definitely an improvement on the self-selected hoi polloi of WP:AN(I). But it doesn't necessarily need to be ArbCom. - Ryk72 ^talk 05:30, 7 April 2021 (UTC)

Aren't admins who ultimately close and decide the outcomes of complaints at WP:AN(I) (especially WP:AN) anyway? So how is that a "self-selected hoi polloi" outside of random people giving their (usually ignored along with the ANI complaint itself) opinions and exactly what is the issue with "people saying things" to admins (or about them)? Especially since the standard doesn't apply to anyone else and there's an extremely small chance of anything coming of an ANI complaint for an admin the way this proposal is anyway. Except maybe a lot of hot air blowing when someone files an ANI complaint. Which, IMO, would still be better then how things are now. A good percentage of the people who are against this seem to want it both ways where there's nothing special about being an admin, but then expect them to be treated in a special way by them not having to go through the normal processes, putting special care into not hurting their feelings, and by not complaining about their behavior or talking about them. --Adamant1 (talk) 05:37, 7 April 2021 (UTC)

If this was a reply to my previous comment, as the indenting would suggest, then unfortunately, I wasn't able to parse it completely. It may be admins that make a significant proportion of the closures at WP:AN(I); but those closures should reflect the consensus of the discussion, and therefore, are at least in part dependent on the opinions presented in the discussion; particularly so when a particular sanction is put to a !vote. I don't agree that opinions are generally ignored; nor that they are generally from random people - which is where the issue of self-selection comes in. An issue with consensus decision making in self-selected groups is that it can be brigaded into taking an action; or brigaded into inaction. I have no issue with people saying things to (or about) admins, and have been strongly critical of a number of administrator decisions (both individual & in aggregate) throughout my time here. I agree that there's an extremely small chance of anything coming of an ANI complaint for an admin the way this proposal is anyway and see this as a critical failing of the proposal. I am not a member of the set of people described in the last sentence. - Ryk72 ^talk 01:48, 9 April 2021 (UTC)

• • @The Blade of the Northern Lights: If we're in the realm of fantasy, I doubt the wizard Yevaud is too concerned with the janitors of the Encyclopedia Foundation. In the realm of reality, my question is to @Guy Macon: - would this process have been better than what just happened for either RexxS or Carlossuarez46? User:力 (power~enwiki, π, ν) 18:06, 8 April 2021 (UTC)
    • Unknown. I cannot evaluate a process that has not been defined, and if what I wrote at Wikipedia:Requests for comment/Desysop Policy (2021)#The Elephant In The Room is correct, it is impossible at this time or any time soon to define a community desysop policy. We have not agreed upon (or really discussed, not that discussing such details isn't a colossal waste of time) such basic questions a "can Arbcom overrule the community?", "can the community overrule Arbcom?", "can the W?F overrule both and get away with it without the board once again overruling the W?F?" --Guy Macon (talk) 19:09, 8 April 2021 (UTC)
    • My main point is that, given how utterly mundane the overwhelming number of actual tasks a Wikipedia administrator carries out, I don't get that people freak out over it to such a degree; I jest not when I say most people who experience it for free would still want a refund. Who are these heretofore nameless administrators who are burning shit to the ground yet aren't in front of ArbCom? I specifically did not vote because I don't know what the right answer is, but I do know that ArbCom will desysop people for cause and that I don't see many rejected cases on the matter. The Blade of the Northern Lights (話して下さい) 04:18, 9 April 2021 (UTC)

Who says the only standard for when an admin should be desysoped or disciplined is if they are "burning shit to the ground"? There's plenty of more subtle and corrosive ways that admins can behave, that wouldn't necessarily warrant or be worth taking them to Arbcom over and "burning shit to the ground" but can still warrant a complaint somewhere. Which I assume would mean reporting them to ANI(AN) and we can't currently do with any kind of usefulness. For instance, something like a temporary block of an admins privileges or a communal slap on the wrist would be perfectly reasonable ways to put an admins more low level bad behavior in check if need be, but no one is going to go to through a 2 month Arbcom process just to do either. Ultimately, this shouldn't be an all or nothing thing. Where the only thing is a complete block of admin privileges through Arbcom due to "burning shit to the ground", or everything else being acceptable ways to behave and no way of dealing with admins outside of Arbcom. -Adamant1 (talk) 00:29, 11 April 2021 (UTC)

And where does this proposal contain any of the remedies you suggest? What you're describing sounds like an entirely different process, one which wouldn't either be affirmed or rejected in this RfC. And it must be said, whether or not ArbCom is the ideal solution here, in their latest actions they've proven that under at least some circumstances they'll act without a drawn out 2 month case. The Blade of the Northern Lights (話して下さい) 05:17, 11 April 2021 (UTC)

Two things

1. This proposal is to make it so someone can use "normal means" to request an admin be desysoped for bad behavior. I would assume that any outcome of the request other then them being desysoped would be a slap on the wrist. Be it an actual one, or one that's just an outcome of the public scrutiny of their bad behavior. In all three cases, it would serve to decrease said bad behavior and I see no evidence to prove otherwise. Light is the best bleach or whatever

The current way of only being able to bring up issues with admins on their talk page or through ArbCom does nothing to tamper down badly behaved admins. In my experience they just act dismissive about complaints because they know the only option is ArbCom. Which most people won't go through, especially for lower level stuff. Again, I see no evidence otherwise.

Feel free to point out an ANI (AN) complaint over an admin where they were disciplined, took responsibility for bad behavior, there was otherwise consequences to an admin for anything. Let alone where any of that happened just through a discussion on their talk page. Even if you can, I have about 100 counter examples (which can't be said for "normal" users BTW). The point is though, just because this won't result in an admin being desysoped all (or most) of the time, doesn't mean it won't have benefit or improve the generelly high level of toxicity on this platform. Some of which undeniably comes from admins.

2. Just because ArbCom doesn't go through a 2 months process under "some circumstances" doesn't mean they are a completely effective way to deal with admins, that there aren't things that could be better dealt with outside of ArbCom's involvement, or that isn't within their peerview to deal with in the first place.

Also, a lot of people don't know what ArbCom is in the first place, let alone how to report an admin to them. Plus, most people don't want to report an admin to ArbCom either. But they do know what ANI (AN) is, how to use it, and would be more then willing to report an admin to ANI(AN) if they had the option to. I've been in the situation myself where I would have reported an admin to ANI if it would have resulted in anything, but I didn't think the issue was worth taking them to ArbCom over (and I just didn't want to deal with the ArbCom process). I've gotten more then one message by other people who have been in the same situation. So, there's clearly a need for an option outside of ArbCom to deal with admins and they aren't completely effective. Adamant1 (talk) 02:00, 12 April 2021 (UTC)