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

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)[reply]

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)[reply]
    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)[reply]
  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)[reply]
  3. Support I think the endorsements requirement is particularly useful in preventing "grudge" filings. Schazjmd (talk) 20:57, 20 February 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
    Sdkb, Could you expand on what you mean by "grandfathered in"? -- RoySmith (talk) 17:53, 21 February 2021 (UTC)[reply]
    @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)[reply]
    Sdkb, That's what I figured. In other words, people like me? -- RoySmith (talk) 18:12, 21 February 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
  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).[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
  20. Support with the caveat that I expect there will be some changes after we see how this works in practice. This isn't free reign to motion to de-admin accounts, it's just a way for the community to deal with some discipline cases without going through ARBCOM proceedings. power~enwiki (π, ν) 00:51, 21 February 2021 (UTC)[reply]
  21. Support I think this is a good attempt at a desysop policy which has been to date something sorely absent. I feel the proposal has sufficient checks to ensure this proposal is not misused and support its implementation. Hopefully, this might act as an alternative to Arbcom and help the community to feel more empowered to deal with the rare case of admin power misuse.--Tom (LT) (talk) 01:52, 21 February 2021 (UTC)[reply]
  22. Strong support - This strikes me as an exceptionally reasonable and fair proposal, I really can't see any obvious flaws with it. It gives the community a realistic process to desysop someone for cause, in a way that is not too difficult, but it includes sufficient caveats and restrictions to prevent it from being weaponized disruptively or unfairly. We can play the "what if" game and never get anywhere, or we can implement a good proposal, probably as good as it's gonna get, with the understanding that if any flaws present themselves, the process can always be tweaked as needed. ~Swarm~ {sting} 01:57, 21 February 2021 (UTC)[reply]
  23. Is it perfect? No, but perfect/enemy of the good and all that. But variations of this proposal have been active for years on multiple large wikis and more or less it seems to have worked out okay for them. It is time we bring more accountability to enwiki administrators. --Rschen7754 03:49, 21 February 2021 (UTC)[reply]
  24. Support as others have said above, we can't let the perfect become the enemy of the good. We are long overdue for some form of community-based desysop procedure. The community is competent to bestow the tools and the community is likewise competent to take them away. LEPRICAVARK (talk) 03:58, 21 February 2021 (UTC)[reply]
  25. Support I don't know how this will work in practice, but that isn't a good enough reason to oppose. Hawkeye7 (discuss) 03:59, 21 February 2021 (UTC)[reply]
  26. Support. Tony has big ideas, and this is a good one. ArbCom need not be the alpha and omega for any and all sysop revocations. Not saying that it should otherwise relinquish its desysop role, but having another option that, it, as well, sets out appropriate safeguards — that's a good thing. I trust our admins, I trust our bureaucrats and I trust the community. This is progress. El_C 04:43, 21 February 2021 (UTC)[reply]
  27. Support. Overdue. It's nigh impossible to remove an abusive admin and this is a step in the right direction. -FASTILY 05:32, 21 February 2021 (UTC)[reply]
    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)[reply]
  28. Support This can only do good for the encyclopedia - Administrators should be extremely accountable for all actions. More to the point, the perception that administrators are more accountable to the outside world can only do the project some good. It makes people believe we are fairer and the chances of them getting "jumped on" by an admin will be reduced. Unfortunately, I can see there is significant opposition for the specific proposal rather than the general idea. Please reconsider, and trust yourself that the bigger picture of allowing us to keep admins in check is more important than the nuts and bolts - think of the greater good or the lesser evil, so to speak. Indeed, I would go as far as suggesting any !vote from an admin opposing this should carry less weight as they have a conflict of interest. Ritchie333 (talk) (cont) 10:23, 21 February 2021 (UTC)[reply]
  29. Support per nom. Maybe increase the 48hrs bit to 72hrs to take into account long weekends, bank holidays and the like. Lugnuts Fire Walk with Me 10:25, 21 February 2021 (UTC)[reply]
  30. Support. This is a good proposal, and though I am willing to negotiate on some details including numbers, these look reasonable to me in the first approximation. Yes, this procedure will definitely be used to harass admins, no doubt about this. But active admins are being subject to constant harassment anyway, with the community unwilling or not being able to do anything in 90% cases (the worst case which happened to me I had to report to police, and I had external sites specifically founded to spread deliberate lies about my personal life - I do not see how deadminship nomination would be any worse). To be honest, I do not foresee this procedure to be used often - to start with, we do not have so many AN(I) threads formally closed, even less closed with an explicit consensus that an admin was at fault, and in the borderline cases it is actually more difficult to get ANI consensus that to get the ArbCom to look at the case - but I think it is important to have this procedure.--Ymblanter (talk) 10:28, 21 February 2021 (UTC)[reply]
  31. Hello, I support. There is no article about myself in en.wp but there could possibly be an one one day (talk) 11:17, 21 February 2021 (UTC)[reply]
    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)[reply]
  32. Support. My main motivation for supporting is that we need some process in place. I acknowledge and even agree with some of the objections posted in the comments section. However, it's my belief that having a workable system in place will increase confidence in admin performance in the wider community. Tiderolls 13:53, 21 February 2021 (UTC)[reply]
  33. SupportThere has to be a better way of removing admins who have lost the trust of the community than full ArbCom cases, and this proposal has enough safeguards to prevent gaming or harassment. P-K3 (talk) 14:31, 21 February 2021 (UTC)[reply]
  34. Support the proposal as a whole. I am unable to support the three admin endorsement requirement however. I presume that the requirement's intent is to have at least three respected long term contributors which would very likely be included in a successful request. Great step in the right direction! -- Dolotta (talk) 14:38, 21 February 2021 (UTC)[reply]
  35. Support in principle, with the details to be worked out. Might be good to have a planned debriefing RfC after an incident to see if things worked as intended or needed to be tweaked. —valereee (talk) 15:57, 21 February 2021 (UTC)[reply]
  36. Support I concur precisely with Tide rolls' comments; happy days, LindsayHello 16:31, 21 February 2021 (UTC)[reply]
  37. Support I think the deadline for the 10 extended confirmed editor endorsement is a little bit short, per Lugnuts, but overall the proposed policy is quite a reform. Also, after it is implemented, I'm sure we can revise it as needed. P,TO 19104 (talk) (contribs) 17:20, 21 February 2021 (UTC)[reply]
  38. Support with the expectation that details may be altered, and with thanks to TB for coming up with this -- and a note to the opposers: "The perfect is the enemy of the good." Beyond My Ken (talk) 17:32, 21 February 2021 (UTC)[reply]
  39. Support per BMK; "the perfect is the enemy of the good", indeed. Like GiantSnowman mentions in the comment section, it seems a bit off to demand that the admin in question transclude their own request for desysop; seems like asking a user to build their own gallows. (I'm not really a fan of this kind of hyperbole, but it's the only metaphor that comes to mind.) TB's comment in response to that makes sense, though, so I feel like we should add some language in to formalize that they can ask a 'crat to do it for them if they wish. But regardless, I don't think that's a dealbreaker. Writ Keeper ⚇♔ 18:10, 21 February 2021 (UTC)[reply]

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)[reply]
  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)[reply]
    Feedback loop? · · · Peter Southwood (talk): 05:48, 21 February 2021 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
    I'm "leaning support", and will likely swap once the discussions below settle more. — xaosflux Talk 05:35, 21 February 2021 (UTC)[reply]
    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)[reply]
  4. Oppose per those above. Very likely supportive of the creation of such a process, but cannot endorse these specifics. — Godsy (TALKCONT) 05:10, 21 February 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
  10. Parking here as well. Some outstanding issues that concern me, particularly on how this process will act in relation to ArbCom and I share some of the concerns of some opposers above. But I hope to move to support with some clarifications/changes; I believe in the idea that the community can take back what it gives, and is entitled to decide itself who it wants mopping on its behalf. ProcrastinatingReader (talk) 10:10, 21 February 2021 (UTC)[reply]
  11. 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)[reply]
  12. Agree with many of the above. Insufficient protections against a howling mob.--Wehwalt (talk) 13:44, 21 February 2021 (UTC)[reply]
    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)[reply]
  13. 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)[reply]
  14. 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)[reply]
  15. 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)[reply]
  16. 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

Neutral

  1. Neutral This is obviously a "removal for cause"-type proposal and I don't think the current processes are unable to quickly or effectively address admins who are intentionally performing actions against the community interest. It is the admins who inadvertently or unintentionally perform such actions, or who perform no actions, that are a bigger issue. We have policies and procedures to address misbehavior but we have none to address the continuing retention of the tools by admins that do not perform admin tasks. The admins who obtained the bit in the early 2000's when admins status was subject to very little examination and have managed just enough to retain the status are retaining their hats not because they want to improve the project (they manifestly are not doing so). The misbehaving admin can be addressed through ANI, ArbCom, T&S (and possibly other processes I forget) so this proposal would be a fourth such process. There are no processes for the other category. We should address the lacuna in process before adding another to a current set of processes. Eggishorn (talk) (contrib) 22:31, 20 February 2021 (UTC)[reply]
    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)[reply]
  2. Neutral I would support this but i think the minimum support threshold should be changed from 60% supporting removal to 65% and requests for desysop between 65 and 75% support should be subject to the discretion of bureaucrats to make it aligned with how RfA's work 🌸 1.Ayana 🌸 (talk) 22:53, 20 February 2021 (UTC)[reply]
    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)[reply]
  3. 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)[reply]
  4. 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)[reply]
  5. Neutral. I know Tony will be disappointed at me not supporting. Like Dennis above, I launched a similar proposal just under a decade ago. There is still some work to do, and an alternative to Arbcom is sorely needed, but this isn't it. I have made a longer explanation in the comments section. I hope I will not have wasted anyone's time by asking them to read it. Kudpung กุดผึ้ง (talk) 07:23, 21 February 2021 (UTC)[reply]
  6. Neutral, for now. I feel that in this case the worry about "what ifs" is warranted and one needs to think through the possible consequences of implementing this proposal more carefully. I would also still like to hear a stronger justification for why the proposal it is needed in the first place. A generalized sentiment that admins should be more accountable is, IMO, insufficienent as a justification here. The process described in the proposal is pretty brutal and arduous. The process may be necessary and I could support it, but I'd like to hear a more convincing explanation for why it is necessary (e.g. that the current arbcom desysop process is seriously deficient and fails to remove many admins who should be removed). In geneneral I can see less brutal and confrontational ways of increasing admin accountability, such as instituting admin term limits, with a mandatory reconfirmation RfA at the end of the term for those wishing to retain the sysop bit. Somebody in the support column mentioned that the lack of a community desysop process makes people more reluctant to support RfA candidates. A much much much bigger problem at RfA now is the lack of RfA candidates and the difficulty in recruiting them. As stressful and unpleasant as RfAs can be now, these desysop RfAs will be 100 times more contentious. It is likely that the prospect of potentially facing such a gory public spectacle will make the job of recruiting RfA candidates even harder. I am also concerned about the interactions of the proposed process with the existing ArbCom desysop process. It is naive to assume that the ArbCom desysop process will simply continue on its merry way, completely unaffected. It may well happen that the ArbCom will become much more reluctant to accept desysop cases, preferring/waiting for the community desysop to take place. ArbCom often looks to the community for guidance on important policy issues. IMO, a successful version of this proposal needs to explicitly state something to the effect that the two procesess are strictly independent and complementary, and, moreover, that, in the opinion of the community, the ArbCom should never consider the lack of a prior community desysop attempt as a reason to decline a desysop request. It is a more complicated question as to what is supposed to happen if a commputity desysop RfA fails and then a desysop case is filed at ArbCom. Nsk92 (talk) 11:53, 21 February 2021 (UTC)[reply]

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)[reply]

I meant to add that myself. Added. TonyBallioni (talk) 21:01, 20 February 2021 (UTC)[reply]
Thanks. ϢereSpielChequers 11:41, 21 February 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • "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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
[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)[reply]
Category