Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The policy section of the village pump is used to discuss already proposed policies and guidelines and to discuss changes to existing policies and guidelines.

• If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
• If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
• If you want to ask what the policy is on something, try the Help desk or the Teahouse.
• This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.
• If you want to propose a new or amended speedy deletion criterion, use Wikipedia talk:Criteria for speedy deletion.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181

RfC on a procedural community desysop

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.

---

Although rare, there are situations where the community has consensus that an administrator should be blocked indefinitely, or at least for a significant period. In those circumstances, this proposal suggests that administrators who have been blocked for more than 28 days do not hold the trust of the community and therefore the sysop userright should be removed procedurally alongside inactivity desysops. Worm^TT(talk) 14:05, 17 April 2023 (UTC)

Proposal: Procedural community desysop

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.

---

The following section should be added to WP:Administrators

Procedural removal

On the first day of the month, any administrator who is blocked and has been blocked for more than 28 days will have their administrator user-right procedurally removed (alongside inactivity removals). Administrators who have their sysop user right removed in this manner are not eligible to simply request return at the bureaucrats' noticeboard, but may appeal the removal to the Arbitration Committee. The administrator may regain their administrative permissions through a successful request for adminship.

Survey (Proposal: Procedural community desysop)

• Support as proposer. Recent events have brought home to me that we are still lacking in ways to handle poor behaviour by administrators. I believe that as a community, we have consensus that an indefinitely / long term blocked administrator does not hold the trust of the community. However, in those situations, the only place to remove the toolkit is Arbcom (or waiting 12 months). I see no reason why such a removal shouldn't happen more quickly, and no reason that Arbcom needs to be involved if it does.
  Instead, I'm suggesting that we have a 1 month period, which allows for cooling off, then removal as part of the next automatic removals, no request necessary, no fuss, no mess. Worm^TT(talk) 14:05, 17 April 2023 (UTC)
• Support I'm speaking as an admin here. If my conduct as an editor warranted any sort of long term block of a month or so, I should not be trusted with the admin tools any longer. RickinBaltimore (talk) 14:15, 17 April 2023 (UTC)

  The reasoning here sounds straightforward to me. It seems rather easy to become an Admin these days, based on some of the pro/con discussion I have seen this year regarding length and depth of candidate editing experience. So, I can certainly understand some people getting carried away and behaving "poorly". Martindo (talk) 06:48, 26 April 2023 (UTC)

• Oppose Pointless. A blocked admin can't (since 2018) unblock themselves, and if they're blocked indefinitely, they'll just be auto-de-adminned when the time comes around. I find it difficult to think of a situation where this process would be useful. --Jayron32 14:17, 17 April 2023 (UTC)

  Actually, editing their own talk page would be enough to forestall the annual edit requirement. Courcelles (talk) 13:33, 18 April 2023 (UTC)

• Support with revisions to clarify "blocked". In exceptional circumstances we might pblock a sysop from a small number of pages but still want them to continue as a sysop -- I feel that "blocked" in this case should mean "blocked from the entire mainspace".—S Marshall T/C 14:20, 17 April 2023 (UTC)

  I'm having a hard time picturing under what circumstances we might want to pblock somebody yet still trust them enough to hold a mop. -- RoySmith (talk) 14:33, 17 April 2023 (UTC)

  People could want to have a pblock? —Kusma (talk) 17:06, 17 April 2023 (UTC)

  The community has rejected the idea of an admin being desysoped due to a partial ban. Don't see why a single page block should be any stronger in this context. Animal lover |666| 20:05, 17 April 2023 (UTC)

  Only sitewide block should be considered for the removal of administrators. Thingofme (talk) 14:09, 18 April 2023 (UTC)

• Weak support. The choice to only desysop on the first of the month concerns me as it could lead to some controversial situations; an admin blocked for 50 days on the 5th of March will remain an admin, while an admin blocked for 30 days on the 2nd of March will not. I find it hard to justify this, as for blocks of under two months whether an admin remains an admin becomes random chance. However, this isn't enough for me to oppose this proposal as I believe it is important to have a process to address situations where admins have so clearly lost the trust of the community. BilledMammal (talk) 14:21, 17 April 2023 (UTC)

  It appears to me from Worm That Turned's vote that it would happen during the normal automatic removals, I'm assuming that means the others happen on the first of the month, so no need to create extra work. But you have a good sentiment Happy Editing--IAmChaos 16:44, 17 April 2023 (UTC)

  That was my guess. Can someone confirm it would actually work the same way via software? Martindo (talk) 06:44, 26 April 2023 (UTC)

• Support in principle but Oppose in its current form. I don't get why this needs to be tied to a specific day on the calendar. But more than that, it allows for stealth desysops. Let's say I block bradv. He's been inactive for 9 months, so he's not going to notice. If nobody else happens to notice, come June 1st, he'll get desysopped. I assume that's not your intent, but as written, it's what would happen. This could be fixed by adding a requirement that in addition to blocking brad, I would have to post a notice to WP:AN to start the clock ticking. Then it essentially becomes WP:PROD for admins. -- RoySmith (talk) 14:32, 17 April 2023 (UTC)

  OK, it's been demonstrated to me that blocks do show up on watchlists, and I'm sure every admin's talk page is watchlisted by lots of people, so that satisfies my concern about stealth blocks. I still don't get why this needs to be tied to a specific day on the calendar (and if it must be, at least make it the ides) but that's not enough to me to oppose. -- RoySmith (talk) 15:07, 17 April 2023 (UTC)

  Interestingly, I did consider putting together a proposal about blocking administrators as part of this, which included a notice to AN. But I didn't feel it was necessary. That said, I really don't like the idea that administrators get an automatic AN review if blocked, creating a "class structure" - we already have supermario issues, which is something I'm trying to address.

  If you are concerned about blocking inactive admins, well, yes, it's possible, but most admins userpage's are watchlisted by multiple people - a stealth block would be noticed. Even if it wasn't, this is something that the appeals process would be quick to fix. Worm^TT(talk) 14:46, 17 April 2023 (UTC)

  Does watching somebody's user page generate a watchlist notice? Normally, a block is accompanied by a talk page notice, but it doesn't have to be. Could you please block User:RoySmith-testing without any explicit notice? I'm watching their user page. Let's see if I get a notice. -- RoySmith (talk) 14:53, 17 April 2023 (UTC)

  It does show up on watchlists. To show this, I have just pblocked your test account for 3 hours. Best, Barkeep49 (talk) 14:57, 17 April 2023 (UTC)

  Yeah, I got:

  × Block log 14:57:29 Barkeep49 talk contribs block changed block settings for RoySmith-testing talk contribs blocking the page User:RoySmith/Three best sources with an expiration time of 2023-04-17T17:56:33 (autoblock disabled) ‎(requested for testing purposes by User:RoySmith) (unblock | change block)

  I'm actually kind of surprised about that, but, OK. -- RoySmith (talk) 15:02, 17 April 2023 (UTC)

• Oppose in this form. (a) it isn't clear that 28 days is enough for a good-faith unblock request in complicated cases and we shouldn't let stalling an unblock turn into a desysop (b) why not just escalate to ArbCom after the 28 days? (c) would any block trigger this? —Kusma (talk) 14:38, 17 April 2023 (UTC)

  I also note that no discussion is required, meaning that the mechanism is - in theory - not implementing a "community desysop" but a "single admin PROD-like desysop". I know that this will likely play out differently in practice, but there should be safeguards against the proposed mechanism. —Kusma (talk) 15:09, 17 April 2023 (UTC)

• Support If editor has been blocked for more than a month, especially if that block gets confirmed by the community which I suspect it would in a majority of these cases, they shouldn't be an admin anymore. This is true even if the block is for less than an indef or a year, to address Jayron's question about why not wait for the current inactivity to desysop. I see this as an important way for the community to take some control over the deysop practice, something I have long favored. The presence of this in policy would be an important way of combatting the super mario effect as there is now some incentive for an admin to block, as they would anyone else, an admin who has breached policy rather than just go "well it's for arbcom to sort out". As to the idea that it takes someone longer than 28 days to formulate an appeal, they can still appeal the decision: by re-running for RfA. If the community wants to be able to handle some desysops on its own, and it's my fervernt hope that it does, then we need to stop letting the perfect be the enemy of the good and support reasonable proposals like this as first steps towards building community capacity around merit based desysops and showing concerned editors that the community can handle these issues, not just arbcom. Best, Barkeep49 (talk) 14:55, 17 April 2023 (UTC)
• Support - I'm not quite sure why it's necessary to wait for 28 days. If we're going to go in this direction, then it seems to me that a CBAN of an admin should carry with it an automatic immediate desysop, which, after all, can always be undone if necessary - but, that being said, this proposal is certainly better than the situation we have now, where there's absolutely no way for the community to desysop an admin (despite the fact that it's the community which creates the admin in the first place, via RfA). Beyond My Ken (talk) 15:06, 17 April 2023 (UTC)

• Remove support in favor of Tony Ballioni's proposal below. Beyond My Ken (talk) 09:11, 20 April 2023 (UTC)

• In the proposal, admins can desysop other admins. There is no community element. —Kusma (talk) 15:18, 17 April 2023 (UTC)

  I don't agree. A block of an admin would be reviewed by the community. It wouldn't happen based on a single admin's view - or rather, it wouldn't stick for over a month based on a single admins view. Worm^TT(talk) 15:20, 17 April 2023 (UTC)

  Only admins can initiate the desysop review by blocking. The community can't initiate this. —Kusma (talk) 15:53, 17 April 2023 (UTC)

  Admins are part of the community - what's more, if you have a consensus of non-admins at say, WP:AN, we can be confident that an admin would implement it. The only way this works is with consensus, and with our current practises. Worm^TT(talk) 15:56, 17 April 2023 (UTC)

  I am rather uncomfortable with how many implicit assumptions about the functioning of the community and the current practises are part of this proposal. —Kusma (talk) 16:42, 17 April 2023 (UTC)

  +1 - it seems unclear to me why a community desysop process does not actually require the community to weigh in, and only assumes that it will. Galobtter (talk) 19:03, 17 April 2023 (UTC)

• Oppose If we wish to devise a procedure for community-instituted de-sysop, we should devise a procedure for community-instituted de-sysop (with appropriate safeguards). The proposed process will only mean that editors will be encouraged to !vote at for a month or longer block at WP:AN when they believe that the admin should be de-sysoped (irrespective of whether they believe that a block itself is necessary) since that is the only procedural loophole they have been granted to achieve the desired end. Why introduce such a de-sysoping through wink-and-a-nod process? Abecedare (talk) 15:08, 17 April 2023 (UTC)

  All editors have safeguards if they are wrongly blocked or they wrongly lose a permission. I do not believe administrators should get extra safeguards and I do not believe that someone who has had conduct worth a 28+ day block fulfills the administrator conduct policy and thus should not be an admin. Best, Barkeep49 (talk) 15:12, 17 April 2023 (UTC)

  Sorry, if I was not clear enough. My argument is not that admins with long blocks should not be desysoped (frankly, I can't imagine a scenario, except for self-requested blocks, when they shouldn't be) or that admins need extra-safeguards from being blocked (they don't!). My objection is that a >28-day block should not be a necessary intermediate step for a community-instituted desysop. If the community wishes to desyspo an admin they should !vote for it explicitly rather than be forced/encouraged to !vote for a > 28-day block with the understanding that such a block would eventually lead to the desired end, i.e., a desysop. (I think I may be repeating myself, so if you or anyone wishes to discuss this separately we can do so at my talk-page w/o taking too much space here.) Abecedare (talk) 15:31, 17 April 2023 (UTC)

  @Abecedare I would absolutely support a direct community desysop proposal, but as yet, we have not found one that can gain consensus (even though mor than one have had majority support). I am not sure that opposing something you agree with because you see a potential something tangentially better is a good idea though. Is that not the definition of perfection getting in the way of good? Worm^TT(talk) 15:52, 17 April 2023 (UTC)

• Support I'm an admin. I got blocked. A lot of people asked me to appeal, so I did, apologising for bad conduct (I was going through a horrible time in my personal life, leading me to lash out completely unnecessarily in complete violation of WP:ADMINCOND) and I was unblocked, easily within a week. If you can't successfully file an appeal within 28 days, you probably shouldn't be an admin. Ritchie333 ^{(talk) (cont)} 15:23, 17 April 2023 (UTC)
• Support I had a completely different comment, but Ritchie333 edit conflicted me and changed my mind. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:28, 17 April 2023 (UTC)

  I did also misunderstand on first reading, thinking that having a block imposed of 28 days or more triggered the desysop, rather than still being blocked after 28 days. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:32, 17 April 2023 (UTC)

• Support. Although I think this proposal does not go far enough. In practice this sounds similar to a community admin de-sysop process in two steps (Admins getting blocked - 28 day period for the procedural desysop) and I would like more discussion on a robust system based around considering it as a single process (but presumably higher thresholds to implement). That discussion does not have to be now or on this survey, but I think more community power to desysop admins is a good thing. Soni (talk) 15:31, 17 April 2023 (UTC)
• Oppose. If a desysop is needed, do it via ArbCom. That's what it's there for. Seraphimblade ^{Talk to me} 15:34, 17 April 2023 (UTC)
• Comment Also @Worm That Turned: maybe this should be listed on WP:CENT or similar. Soni (talk) 15:33, 17 April 2023 (UTC)

  It's already been on CENT :). Best, Barkeep49 (talk) 15:44, 17 April 2023 (UTC)

  Ah, I see how I missed it. I forgot links are marked as "read" on my browser if I follow it from anywhere, not just from CENT specifically. Thanks for clarifying. Soni (talk) 15:50, 17 April 2023 (UTC)

• Support per Ritchie333. I agree that it's a fair assumption that if an admin stays blocked for 4 weeks then they don't have the community's trust. —pythoncoder (talk | contribs) 15:57, 17 April 2023 (UTC)
• Oppose. This proposal reminds me of the one linking desysops with community restrictions, which resulted in a clear consensus against.
  Despite the supporters' best intentions, this worsens the "unblockable" and "Super Mario" effects, given that the proposed policy increases the consequences of blocking an administrator and further discourages it. If the proposal prevents even one administrator from being blocked when they should be, then it is not worth it: administrators must be held accountable for their actions. We elect the Arbitration Committee so that it can handle requests for removal of administrative tools. That grave responsibility should not be borne by a single editor.
  When Special:Block is opened, one needs to be convinced that imminent or continuing damage and disruption to Wikipedia will be prevented. That is the main concern. That decision-making process, which is already clouded by the fact that a user with social capital is being blocked, should not be impaired by secondary questions over whether an administrator is fit to continue holding that access.
  Administrators must be held accountable. But this is not the answer. Sdrqaz (talk) 16:18, 17 April 2023 (UTC)

Not sure I agree with you on the top line but I really appreciate your well reasoned and concise argument. I think its so important that people look beyond just the question in front of us and try to fit the current proposal into the big picture. Horse Eye's Back (talk) 16:43, 17 April 2023 (UTC)

• (edit conflict) Oppose This proposal allows admins to near-unilaterally desysop another one, unless a review of the block is brought up at AN/I which won't always happen even if a block is controversial. It also makes blocks of an admin greater than 28 days unnecessarily more contentious. I am willing to support a method for the community to desysop an admin, but it should unconditionally require community discussion. Snowmanonahoe (talk) 16:21, 17 April 2023 (UTC)

  Any admin who is blocked is able to make an unblock request and ask for a community review. I think 28 days is plenty long enough for them to do that. Boing! said Zebedee (talk) 16:31, 17 April 2023 (UTC)

  Currently, a blocked admin would be subject to a standard block review. With this proposal, they will be subject to a community desysop review, a very different beast for which there is no precedent. It is quite a new ability for any single admin to initiate a community desysop review. —Kusma (talk) 16:47, 17 April 2023 (UTC)

• Question - Does anyone have a number for how many times an admin has been blocked >28 days and arbcom hasn't quickly and easily stepped in to remove permissions? Seems like a reasonable proposal, but has it ever been needed? — Rhododendrites ^talk \\ 16:23, 17 April 2023 (UTC)

  This feels a bit like a chicken and the egg. Recently, for instance, Athaenara could have been desysopped under this proposal rather than the arbcom motion which happened. One virtue of this proposal, which I didn't mention above, is that I think it would save some time and community drama - even an ArbCom case request is high on both. Barkeep49 (talk) 16:44, 17 April 2023 (UTC)

  I reviewed the list of current admins; the only one who this would have affected would be Smartse, who was blocked for 78 days per their own request to enforce a wikibreak. BilledMammal (talk) 18:23, 17 April 2023 (UTC)

  @BilledMammal: Not true. Per my research using a PHP script making API queries, Randykitty self-blocked in 2018 for 85.3 days (relevant contribution history). That's the longest block tor a current administrator, assuming my algorithm is correct. – wbm1058 (talk) 20:12, 7 May 2023 (UTC)

  ...and Spartaz was blocked for 79 days in 2018 as well, per their request. – wbm1058 (talk) 21:22, 7 May 2023 (UTC)

  That was before my RfA. SmartSE (talk) 18:31, 17 April 2023 (UTC)

  But raises the question of whether it's sensible to de-sysop for requesting a wikibreak. Imagine someone on a military deployment: "Thank you for requesting that your account be blocked while you know you won't be able to use it. By the way, we're going to de-sysop you." Thank you for your service, indeed. WhatamIdoing (talk) 21:06, 17 April 2023 (UTC)

  I'm unsure as to whether to support the proposal as a whole, but it would need an exemption for an admin in good standing who requested to be blocked. Certes (talk) 10:01, 25 April 2023 (UTC)

  ...especially as an adept wikilawyer would sidestep this measure by resigning their adminship before requesting a block, then re-request sysop when they return. Certes (talk) 10:07, 25 April 2023 (UTC)

  Part of me wants to support this as a sorta-kinda community desysop process. Rather than "should this person be desysopped" it's "should this person be blocked for exactly 29 days? wink wink what I mean?" My concerns are (a) that the illusion of a community desysop process will lead arbcom to defer to the community for some cases, when it seems like arbcom is doing alright with the extreme cases already (such as those requiring a long block); (b) I'm not sure why it would reduce drama. Anytime someone with a lot of experience gets blocked for one day (nevermind a month or more), it leads to a ton of drama. It's the block more than the desysop, right?; (c) Isn't this easy enough to handle on a case-by-case basis? A desysop can be carried out by arbcom motion, and that should be relatively straightforward in the case of someone blocked for a month. On the other hand, requiring an action by arbcom means there's room for judgment to handle exceptional cases like a requested block. Not sure. — Rhododendrites ^talk \\ 12:51, 19 April 2023 (UTC)

• Support. If an admin is indef/long-term blocked and has been so for more than 28 days, I don't think it could be read in any other way than they've lost the trust of the community. An ArbCom request in such a case would be little more than a rubber stamp (as I can't see ArbCom reversing such a strong community action), so this would really just save time and effort for the same ultimate result. Boing! said Zebedee (talk) 16:26, 17 April 2023 (UTC)

  @Boing! said Zebedee Or maybe they just needed a break or they rage quit? I'm not meaning to call you out on those (nor do I need to know the details), but we should consider if those events should have resulted in the loss of your mop. -- RoySmith (talk) 14:53, 19 April 2023 (UTC)

  Voluntary relinquishment due to taking a break or leaving Wikipedia would still allow for requesting privileges to be re-granted without a request for administrative privileges, within the bounds of the activity requirements. isaacl (talk) 15:39, 19 April 2023 (UTC)

• Support. The community appoints admins. If it can be trusted to do that, it can be trusted to remove them. The proposed conditions under which this would occur seem entirely reasonable. AndyTheGrump (talk) 16:50, 17 April 2023 (UTC)

  The community has been doing an absolutely terrible job at appointing admins (extremely conservative and unforgiving of small mistakes). —Kusma (talk) 16:58, 17 April 2023 (UTC)

  I think that's true, yes. But I wonder if it's another side of the same thing - if theres no community way to get rid of an admin, does it make people at RfA a lot more cautious and demanding? (I really don't know, just pondering out loud.) Boing! said Zebedee (talk) 18:20, 17 April 2023 (UTC)

  We've had years of people clamouring against "admins for life" and we have recently made it harder to retain admin status, offending a few low-activity oldtimer admins. It doesn't seem to have made people less cautious. I don't think admin-PROD is going to make any difference to RfA either. —Kusma (talk) 20:34, 17 April 2023 (UTC)

  Hmm, yes, I think you're probably right - maybe the creeping intolerance at RfA simply goes hand in hand with general rule creep across the project. Boing! said Zebedee (talk) 07:09, 18 April 2023 (UTC)

• Support If an admin needs to b e blocked, and the block sticks, they are obviously unfit to be an admin. We don't need a month-long committee case to make decisions this obvious. Beeblebrox (talk) 17:00, 17 April 2023 (UTC)
• Support - this accounts for appeals happening and so on, so is fine. For the sake of clarity, this can be taken to oppose any alternate standard that might be picked out from this discussion (obviously I'll amend if I see a good one, just to avoid missing a discussion). Nosebagbear (talk) 17:01, 17 April 2023 (UTC) Since we have broken out new ideas as they arise, !vote adjusted to just this one. Nosebagbear (talk) 14:58, 24 April 2023 (UTC)
• Hesitant support. I have several concerns here. First, that this will raise the stakes for blocking an admin, which is already hard enough: but we don't do it very often, so perhaps it's not a concern. Second, per Abecedare above, that we're not going far enough; but I don't want to let the perfect be the enemy of the good either. Finally I'm concerned that the ARBCOM appeal clause defangs this proposal. If the intention is that a full ARBCOM case should not be necessary step to a desysop, we're making it to easy for this to end up in ARBCOM's lap anyway. I suppose the burden is shifted from the community to the admin, so perhaps it's a shift for the better; but I'm unconvinced this is going to be a big change in that respect. Ultimately, though, yes, an admin blocked for more than 28 days should likely be desysopped. So I land here. Vanamonde (Talk) 17:35, 17 April 2023 (UTC)
• Support - (another admin here). I think Wugapodes and Beeblebrox have explained why. - Donald Albury 17:46, 17 April 2023 (UTC)
• Support. I'm a bit worried that this will incentivize admins/the community to make blocks that wouldn't otherwise need to be made, but I also strongly agree with what Ritchie333 is implying below: that holding out for the perfect proposal means we end up stuck with an even less desirable status quo. I believe this proposal will remove admins who need to be removed and will not remove admins who don't need to be removed, all while furthering admin accountability to the community, which is important to me. That means it's likely to be on net an improvement, and I support things that are improvements even if my ideal desysop proposal might read differently. And if this system doesn't work, I have no doubt that the community will be capable of revising or repealing it. Extraordinary Writ (talk) 17:52, 17 April 2023 (UTC)
• Support per nom. This doesn't seem likely to solve much since I can't imagine very many admins are blocked for a month, return to editing, and don't resign the tools. But as a few of the supporters have alluded to, even a miniscule tightening of the rules for administrators who have clearly lost community trust (and anyone remotely high-profile here who is blocked for a month has very clearly lost the community's trust) is a net-positive. Even if its only real effect is to show that we can agree on something. Ajpolino (talk) 18:14, 17 April 2023 (UTC)
• Oppose Is this really a "community" desysop process? That is, if most of the power is with admins, can it even really be called a community process? The proposal ostensibly starts with a case where "the community has consensus that an administrator should be blocked indefinitely, or at least for a significant period". But the actual proposal doesn't require any sort of community consensus that the admin be blocked. Yes, any block that's in anyway not obvious will almost certainly go to the community within 28 days, but it still gives the power to admins to start the desysop process. I also note that WP:CTOP blocks can be unilaterally imposed and require a "clear consensus" to lift, so we could have a situation where 60% of the community disagrees with a block but that still results in a desysop. Imagine also being the closer of such a discussion and having the almost unilateral power to decide if someone gets desysopped. Yes, there's the safeguard of "may appeal the removal to the Arbitration Committee" but in a proposal meant to save time I only see more drama and time being wasted in any controversial case.
  I also think this makes blocking admins worse, both in them not being blocked and in them being unnecessarily blocked. As Sdrqaz eloquently explains, this makes blocking admins more troublesome. But I also think this could result in admins being unnecessarily blocked just so they can be desysopped. Someone brought up Wikipedia:Arbitration/Requests/Case/Neelix as one case where this could be useful. But I note that Neelix was never blocked for more than a few days until well after the case, and I don't think a block should have been imposed just to cause a desysop - often times, a community restriction is all that is actually needed. I think there's a case of Goodhart's law here - I'm not and I don't think anyone is disputing that an admin blocked for more than 28 days is unfit to be an admin, but I think using that as a the only measure will cause more problems than it will solve.
  To be honest, I'm not convinced there's any particular need this is addressing. ArbCom has only seemed more and more willing to de-sysop over the past few years (and I've generally seen this as a good thing). The main argument seems to be that this will save a full case in obvious cases, but ArbCom literally just de-sysopped by motion without requiring a case (after a lot of hemming and hawing to be fair). And that was in a case where the community even rejected an indefinite block, so less obvious than any case this proposal addresses. I honestly think all we need is ArbCom being more willing to desysop by motion in obvious cases and the community supporting that. Galobtter (talk) 19:00, 17 April 2023 (UTC)
• Support because it's something. Moneytrees🏝️(Talk) 19:46, 17 April 2023 (UTC)
• WeakSupportOppose "Support" reasons are those given by the nom and because it's something. "Weak" Oppose because this we need stronger more routine community reviews rather than focusing on desysop, and this one is for even rarer cases when they blew it as an editor rather than aqs an admin. We need to strengthen WP:Administrative action review and take the "poison pills" out of it. And add to it more admin conduct issues. And the most common results would be mere findings and guidance and maybe a few trouts. North8000 (talk) 20:18, 17 April 2023 (UTC)

"Safe" but so specialized/ unlikely to get used that it's not worth the diversion and complexity of creating. North8000 (talk) 20:41, 18 April 2023 (UTC)

• Oppose Why can't we just keep it simple and have a community desysop process based on an up-and-down majority vote like Commons? -- King of ♥ ♦ ♣ ♠ 20:36, 17 April 2023 (UTC)

  Because people keep opposing to the specific proposal rather than the general concept, so it never gets consensus. Ritchie333 ^{(talk) (cont)} 20:59, 17 April 2023 (UTC)

  The next admin block/unblock will be a de facto desysop discussion, and we have no rules at all how to deal with these, so we'll just make the rules up as we go along on ANI. That is a terrible way to make sound policies. —Kusma (talk) 21:08, 17 April 2023 (UTC)

• Support. I disagree with Sdrqaz that this will make the WP:SUPERMARIO effect worse. To the contrary, I believe it will help by linking the "normal" way of dealing with conduct issues (blocks) with the loss of tools. Otherwise, this is a sensible, if imperfect, proposal. I think Tamzin's concern can and should be easily solved by specifying the block must be non-voluntary. And I would rather have a clause delaying the removal of the bit if there is an appeal ongoing: there shouldn't be a race-against-the-clock to form consensus within the next 24 hours at AN before a new RfA is required to regain the mop. I also think it would be cleaner to simply specify that losing the tools in this way counts as losing them under a cloud, instead of separately explaining how one can regain the tools after losing them in this way. But perfect cannot be the enemy of progress. HouseBlaster^talk 21:45, 17 April 2023 (UTC)

  Just after I hit publish, I realized the significance of something WTT said above: "(or waiting 12 months)". One off-the-rails admin can already issue a block that will eventually result in the removal of the bit. Heck, anyone can hop over to ANI and seek consensus for an indef ban, which would result in them losing the tools after a year. All this proposal does is lower the amount of time it takes before the tools are removed. Do you think someone who is blocked for more than 28 days but less than a year deserves access to the tools? I don't think so. HouseBlaster^talk 21:54, 17 April 2023 (UTC)

• Support Without reservations. This has been desperately needed for 20 years. The process itself can be amended later if needed but we need SOMETHING here. The idea the community can elect admins but never remove them without appealing to ArbCom is backwards and always has been. - Who is John Galt? ✉ 21:47, 17 April 2023 (UTC)
• Oppose - I support the idea of a process for community desysop. But this isn't it. First, 28 days is way too short a time period. This should be a year at least, and only in the case of a ban. Second, as we have shown through adding things like partial blocks, what an editor does in one place may not disqualify them from being able to positively help out in other ways. And so, just being blocked for reason A, should necessarily mean that the admin tools should be removed. Due to the idea of escalation blocks, should someone who receives a 30-day block suddenly lost the tools? Also, there's a difference between a block and a ban - and this is intentional. So no, we should not be removing tools merely due to an arbitrary time period of a block. To be clear, I think I might have supported this if the time period was "a year and a day", and if it was a "community ban", not merely a block. - jc37 22:42, 17 April 2023 (UTC)

  @Jc37 If an admin doesn't edit for a year, say, because they're blocked - they already have their admin rights removed. But I can guarantee, that there would be community uproar and an arbcom case before that happened. This simply gives a procedural option, shortening the time period, meaning that Arbcom need not be involved. Worm^TT(talk) 07:35, 18 April 2023 (UTC)

  @WTT - 28 days is way too short. It needs to be at least longer than the 6 months of the Wikipedia:Standard offer. To do otherwise is just inherently wrong. And, in practice (based upon actual requests I've seen), longer than a year is what's more likely, if the community is willing. Hence my "a year and a day". If you think there would be an uproar and this needs encoding, then let's please have that discussion. And what everone's been saying here about a single admin essentially making this happen - that really just sounds like a bad idea. And setting aside the act itself, I think adding this to the mix will rachet up the drama. That's a time sink that we can avoid, I think, by making this a community ban rather than merely a block. - jc37 07:48, 18 April 2023 (UTC)

  @Jc37, I understand where you're coming from, as I say, we already remove for inactivity after a year, block or ban. So, in my eyes, your suggestion is moving further away from the goal of a community desysop without Arbcom. Why is (at least) 28 days too short? It allows for absence, cooling off, negotiation, self imposed / community imposed sanctions or any other dispute resolution. A month is considered a reasonable period for discussion at almost every venue I can think of. Worm^TT(talk) 07:59, 18 April 2023 (UTC)

  If that's all true, why then do we wait 6 months for the Standard offer? I think that community has already set the absolute minimum length of time there, and really, even there, it suggests longer. What does it say about us if we say: "It's been 30 days - you've done your time and now are unblocked, but we don't trust you any more." ? Useight (below) was very right that this just screams punitive. Where's the fire? - jc37 08:11, 18 April 2023 (UTC)

• Support per Ritchie333 and Beeblebrox. I have nothing to add to their words. LEPRICAVARK (talk) 22:48, 17 April 2023 (UTC)
• Support per Ritchie333 and Beeblebrox. In the extremely unlikely event that someone was blocked for >28 days, and was not unblocked before that period elapsed, but did still have the trust of the community then they could demonstrate this trust to arbcom who would grant the appeal and/or they would easily pass a new RFA. Thryduulf (talk) 23:05, 17 April 2023 (UTC)

  I think that's a bit of circular reasoning. That could be said of anyone for any reason. For example: "If they have the community's trust then they would easily pass a new RFA, so we should have daily RfAs for admins."... - jc37 23:20, 17 April 2023 (UTC)

  Well daily is hyperbole, but I fully support having reconfirmation RFAs when someone figures out how to get community consensus for a scalable process. Thryduulf (talk) 00:01, 18 April 2023 (UTC)

• Support with caveats. An admin who has been blocked in good faith for more than 28 days should just not be an admin. If they haven't been able to appeal their block in that time, then they don't have the support of the community, and they should be demopped until they can demonstrate support in a reconfirmation RFA. What we're proposing here is a desysop related to clear misconduct; WP:CLOUD should apply. These shouldn't be procedural with the right to regain the tools upon request, like inactivity desysops are. If I block someone and take away their pagemover userright for out-of-process moves, they don't just get it back when the block expires, they have to make a new WP:PERM request and demonstrate suitability all over again. There's no way admins should be held to a lesser standard than that. Ivanvector (^Talk/_Edits) 23:30, 17 April 2023 (UTC)
  • Ivanvector, the proposal already covers this with Administrators who have their sysop user-right removed in this manner are not eligible to simply request return at bureaucrat's noticeboard, right? Or is there something else you'd prefer? Extraordinary Writ (talk) 23:35, 17 April 2023 (UTC)

    Thank you, I misread. Comment revised. Ivanvector (^Talk/_Edits) 15:24, 18 April 2023 (UTC)

• Oppose just because I think this is going to end in wheel wars. I would support automatic removal of sysop on a successful community ban that was widely participated in, however. It should also be made clear that ArbCom is still an option to result in a desysop. --Rschen7754 00:49, 18 April 2023 (UTC)

  I'm not surprised to see an editor, like yourself, who was around for the wild west days bring this up but it strikes me as not part of our current culture. The last time we had a true wheel war was Fred Bauder, no? I feel WHEEL is properly understood to be a brightline desysop offense these days and so admins just don't do it. In this situation the third mover would be someone reinstating a block so losing your admin bits to try to make sure someone else loses theirs would be a choice. Best, Barkeep49 (talk) 02:49, 18 April 2023 (UTC)

  I don't remember if WP:FRAM came before or after Fred Bauder but there were minimal penalties for that scenario. Rschen7754 03:02, 18 April 2023 (UTC)

  We have strong procedures for wheel wars and actually, we haven't seen them in years. Maybe the odd Wheel skirmish, but nothing of the like from Wikipedia's early days. Yes, this proposal risks pushing those procedures, but I think that's worth it. Worm^TT(talk) 07:32, 18 April 2023 (UTC)

• Oppose While it might seem intuitive to say that an admin blocked for a month shouldn't be an admin, a block can be instituted by any admin or cabal of admins and I don't agree their decision should overturn the results of an RfA. I don't have that much faith in the sort of admins we have on this website. Chris Troutman (talk) 03:13, 18 April 2023 (UTC)
• Oppose. The purpose of a block is to prevent damage or disruption to Wikipedia. Assuming the block was done properly, then the block is performing that function (that is to say, the user is blocked and therefore cannot damage/disrupt Wikipedia). Having the block do something more is not within the intended scope of a block. I would go so far as to say that this proposal would make 28-day blocks punitive instead of (or in addition to) being preventative. It's unclear to me how removing the bit prevents something that the block doesn't. Useight (talk) 03:46, 18 April 2023 (UTC)

  "Preventative, not punitive" is a very, very good point. - jc37 06:10, 18 April 2023 (UTC)

• Support per Ritchie333 and Beeblebrox.Pharaoh of the Wizards (talk) 05:41, 18 April 2023 (UTC)
• Oppose I support a community-based desysop procedure, but only one that has a clearly defined and equally community-based resysop procedure. The proposal as written tries to address potential objections around resysop by splitting the baby and having ArbCom oversee an undefined appeals procedure.
  Ultimately it comes down to this: if this is procedural and linked to inactivity desysops as the proposal is hinting at, then an individual should be able to request it back at BN. If it is actually a community-based disciplinary procedure, +sysop should only be able to be restored via RfA, not by ArbCom.
  Worm, I'm assuming you wrote this proposal as something that would address potential objections and could pass (i.e. the objection that there's no procedural protection, so leaving the option of an appeal on one hand, and then the objection that if it is procedural it can just be re-requested on the other.) The problem is that the resysop provisions try to have it both ways, and the real crux of any desysop proposal is the resysop provisions (removing the flags are easy; the question is who can get them back.)
  I would support some version of this with resysop provisions that are clearly defined and aren't ambiguous and subject to a relatively opaque ArbCom appeal process - whether that be requiring RfA, or allowing restoration at BN. But the current language will cause drama when someone is desysoped after 28 days, is unblocked on day 29, and then goes to ARCA or even emails the mailing list. If this is going to be community based, resysop must be community based too. TonyBallioni (talk) 06:00, 18 April 2023 (UTC)

  I accept that the Arbcom appeal process is opaque, and you are right, I put it in to address potential concerns. The point of the committee is to deliberate, and I'm sure the group could make a decision on whether the procedural removal should have happened - which will go back to whether the block was valid in the first place. I'd also welcome expansion of that clause to whatever the community wished (from ability to raise a full case to only appeal in absolute obvious circumstances, eg bad block that somehow stuck) - or indeed the complete removal of the clause. I am against allowing restoration at BN, but RfA being the only option here would be fine by me. Worm^TT(talk) 07:30, 18 April 2023 (UTC)

• Oppose. Blocks are a technical measure to prevent imminent or likely damage to Wikipedia. This proposal would turn them into a proxy for a high-stakes disciplinary process. That is not the purpose of the block feature. It is ArbCom's job to desysop users, and in the rare cases in which the community keeps an admin blocked for more than a month I find it difficult to imagine that ArbCom would not take up an appropriate motion, as they recently did in the Dbachmann case. Sandstein 11:32, 18 April 2023 (UTC)
• Support per Worm That Turned and Ritchie333. ✠ SunDawn ✠ (contact) 11:39, 18 April 2023 (UTC)
• Support I originally thought I would oppose this, but ultimately an action serious enough to warrant a 4 week block is one that would have led me to oppose at an RFA, and by extension should be enough to indicate that the user shouldn't be an admin. I understand that mistakes happen, but at this length it isn't a minor infraction or one-off issue, and there's been time for appeals and considerations. So yes, I'm ok with this, and oddly enough I'm more ok with this than some of the issues that I've seen result in a desysop via Arbcom. That said, if it is easier to remove admin rights I wish it was also easier to grant them, but perhaps one needs to be modified to fix the other. - Bilby (talk) 11:45, 18 April 2023 (UTC)
• Support. Seems uncontroversial and logical, per "an admin blocked for that long should not be an admin". --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 12:10, 18 April 2023 (UTC)
• Support with perhaps an exception that a self-imposed block should not trigger the desysop. But if an admin is blocked for cause and can't find an unblock from any other admin in a month, that's prima facie evidence of having lost the community's trust. Courcelles (talk) 13:37, 18 April 2023 (UTC)
• Support - First choice as compared to the alternate proposal below. There's nothing I can really add that hasn't already been said. Other than Fnord. --⛵ WaltClipper -(talk) 15:49, 18 April 2023 (UTC)
• Weak Oppose per Jayron32. This seems more like a solution in search of a problem than an actual need. If someone can show me a need, i.e. where an admin really needed to be de-sysopped and existing procedure failed to do it, I could be convinced to support. Dave (talk) 16:38, 18 April 2023 (UTC)
• Support This proposal won't really solve the problem of unaccountable admins or the need for a community desysop procedure, and will in practice probably never be used. But it's something, and really, it should work this way regardless. Writ Keeper ⚇♔ 17:34, 18 April 2023 (UTC)
• Support per above. If an editor with admin rights gets blocked for a month, they're clearly not fit to be an admin -FASTILY 19:55, 18 April 2023 (UTC)
• Oppose This is prescribing punishment without due process, and would incentivize wheel warring. We need to come up with more than just the outcome. We need a set, agreed upon way of removing adminship in the first place. Just because someone has been in jail for a month does not make them guilty. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:30, 18 April 2023 (UTC)
• Oppose mainly per Sandstein. This proposal is outside the traditional use of the block tools. It seems like a method for reducing Arb's workload, which isn't really that high anyway. I think if you are going to desysop someone, some kind of process needs to take place. Since desysopping via Arb really isn't that difficult, it needs to stay there. Arb has virtually unlimited tools, from full cases, suspend and desysop, hear and keep the bit, admonish, or sanction. Arb has shown they can do it in less than 28 days. Pushing it off onto the blocking admin and a calendar seems to be a cheap substitute for fair process, and frankly, seems a bit lazy. Dennis Brown - 2¢ 20:35, 18 April 2023 (UTC)
• Oppose. Upon reading the proposal my inital reaction was to support, but then I read the opposes here and changed my mind. The main argument that convinced me was Useight's point about WP:BLOCKNOTPUNITIVE. This seems like it would expand the block function into something punitive. I do think admins should be held to a higher standard than the average user, but I don't think an expansion of the block is the proper way to bring that about. Patr2016 (talk) 21:23, 18 April 2023 (UTC)
• Support. An admin who is successfully blocked for an extended period almost certainly does not have the trust of the community that is supposed to be the basis for adminship. Contra the "blocks should not be punitive" argument, as User:HouseBlaster points out above, a long enough block could already result in a desysop for inactivity. This is exposing the same result in a shorter timeframe, which is justified for the reason I stated initially. --RL0919 (talk) 06:03, 19 April 2023 (UTC)

  The words "could" and "same" are doing a lot of heavy lifting in that sentence. I have quickly sketched out this process and the inactivity process (apologies if I missed some details) here. There is a scenario in which the result is the same (defined as an administrator being desysopped and requiring a new RFA to get the bit back), but not necessarily (hence the "could"), but it would essentially have to be a two-year block with talkpage access revoked in order to force the same result as this 28-day proposal could do. To be clear, I'm not arguing the merits of this proposal here (as I already have done above), nor the merits of the inactivity policy, as that is not relevant here. I'm asserting that insinuating that this proposal is more or less the same as the inactivity policy applying to a blocked admin, only shorter, is a disingenuous argument. Useight (talk) 15:41, 19 April 2023 (UTC)

• Oppose as unnecessary and potentially harmful as a strict policy. Long-term or indefinite blocks of admins are fortunately very rare. The situations where they do happen, and the proposed policy would apply, are already drama-filled, and it is precisely for that reason that it is helpful to have someone like Arbcom reflect on whether continued admin permissions are warranted. I see lots of potential for additional drama from a policy like this one (e.g. keeping a user blocked past the time a block is needed to prevent disruption so that deadminning is triggered). I would support the community validating to Arbcom that admins engaging in behaviour that gets and keeps them blocked long-term is conduct unbecoming and grounds for desysopping, but given this is a rare occurrence I think the additional step of Arbcom weighing the desysop is beneficial and hardly a horrible additional workload. Bottom line: the *behaviour* that leads to a long-term block of an admin is likely grounds for desysopping, but that should be through normal channels for a conduct-related desysop (Arbcom) rather than "procedural". Martinp (talk) 17:41, 19 April 2023 (UTC)

  Added an alternative proposal relying on WP:LEVEL2 below. Martinp (talk) 18:12, 19 April 2023 (UTC)

• Oppose in it's current form. This seems overly bureaucratic, and makes no mention of specifically being blocked for misconduct as opposed to something like a self-block to enforce a wikibreak or a circumstance where an appeal is ongoing (controversial ones can last longer than 28 days). I'll review the alternates below, but in general I'm opposed to this sort of "automatic" process for anything but housekeeping. The Wordsmith^{Talk to me} 18:26, 19 April 2023 (UTC)
• Support - if blocked for that amount of time, indeed a desysopping is in order. Atsme 💬 📧 02:44, 20 April 2023 (UTC)
• Oppose this specific policy implementation but not the general idea of such a process. Andre🚐 02:47, 20 April 2023 (UTC)
• Support per Barkeep, Beeblebrox, et al. firefly ( t · c ) 08:27, 20 April 2023 (UTC)
• Support - Recent months have highlighted again the need for some kind of community desysop procedure; while this proposal would not work for all situations, it is an improvement on the current situation. Fundamentally, an admin who has been and remains blocked for 28+ days is not a suitable person to be an admin. The worries about rogue blocks leading to desysops without community input do not worry me - I cannot imagine that one admin blocking another, especially for 28 days, would not makes its way to ANI almost immediately. I would be very happy to add a condition that if the community later overturns the block (as a bad block, rather than a "you've apologised and learned your lesson"), then admin rights can be restored. Equally, I would be happy to put in a hold condition that would pause the process if there is an active, ongoing review of the block. And waiving the procedure for non-bad behaviour blocks (self-requested, for example) would be fine too. WJ94 (talk) 09:19, 20 April 2023 (UTC)
• Oppose as a solution looking for a problem. Stifle (talk) 10:14, 20 April 2023 (UTC)
• Oppose a rare occurrence like this can be handle by ArbCom. Such a rule would encourage gaming the system (get a long block on an admin you don’t like to end them for good). Jehochman ^Talk 12:19, 20 April 2023 (UTC)
• Oppose this is an overly baroque procedure. I'm supporting the alternate proposal instead. Jahaza (talk) 16:54, 20 April 2023 (UTC)
• Support in cases where someone is blocked for that long they should almost certainly be desysopped. Any block like this would be subject to lots of community review anyway and I highly doubt it would be used just to desysop someone. Hut 8.5 18:20, 20 April 2023 (UTC)
• Oppose as needless bureaucratic bullsnot to control the flow of power. Rules, restrictions, and more rules on top of more restrictions... This whole site creeps me the bleep out! Huggums537 (talk) 05:32, 21 April 2023 (UTC)
• Oppose as pointless - blocking an admin for this period of time happens very rarely, and the one time it did happen (Athaenara) it wouldn't have helped as Arbcom was already pursuing a desysop long before it would have triggered. * Pppery * _{it has begun...} 21:20, 21 April 2023 (UTC)
• Weak oppose as I really like the sentiment of the proposal, but I think it would have the opposite of the intended effect. I'm really not worried about wheel warring or covert blocking, since any block of an admin is inevitably going to garner a lot of scrutiny. What I do worry about though is the impact this has on blocking admins. Either the potential desysop consequence is a factor in blocking a sysop, in which case the wonderfully uncontroversial question "have they done something desysoppable" would be introduced to the decision making process behind the block (and you can imagine how many admins want to make unilateral decisions on that). Or, the desysop sanction is not a factor, in which case a) said sanction is punitive, not preventative, and b) any admin that feels compelled to block another admin is opened up to immense drama and inevitable speculation over their motives. The drama that would likely come with a blocked sysop today is already big, and I don't think raising the stakes and adding a timer and an ultimatum on whether to unblock would be an improvement. Giraffer ^{(talk·contribs)} 14:30, 22 April 2023 (UTC)
• Oppose There's too many potential negatives to this, and the reality is the number of cases it could possibly address are vanishingly small, if they exist at all. I don't see a need for more instruction creep to deal with a non-existent problem. --Hammersoft (talk) 17:01, 23 April 2023 (UTC)
• Weak support My first thought was 'oh, what if it was a bad block?' and some protection needs to exist for that. Also, my second thought was 'let's just block someone for 28 days and there they go, desysopped!' with the intention being the secondary and not the primary...'oh look, 28 days? Desysop!!'. Nonetheless, I hope common sense will be applied to this proposal, as it will make desysopping quicker in some cases when it needs to be. Obviously, an indef block of an admin means goodbye admin rights. That's pretty clear cut. talk to !dave 12:54, 24 April 2023 (UTC)
• Weak Oppose - kill the "On the first day of the month" part, if this is going to happen it shouldn't be pegged to a specific day of the month, should just be rolling like everything else in the admin policy. (Now, if it in practice happens a bit late sometimes - no big deal, but if the processor is late and the block has already lapsed then it shouldn't be done either....). In short, this sets up yet another pile of bad timing issues that like to find their way in to the admin policy, cause headaches, and need to eventually be repaired. Try again, — xaosflux ^Talk 22:54, 24 April 2023 (UTC)
• Oppose mainly per TonyBallioni's lengthy oppose and Stifle's pithy one.--Bbb23 (talk) 23:12, 24 April 2023 (UTC)
• Support this with reasonable exceptions as needed, and also support TonyBallioni's proposal. – John M Wolfson (talk • contribs) 23:30, 24 April 2023 (UTC)
• Oppose - Can't see how this is needed or useful. Paul August ☎ 23:34, 24 April 2023 (UTC)
• Support - very reasonable.--Dl.thinker (talk) 23:47, 24 April 2023 (UTC)
• Oppose per Stifle who beat me to it. This is a solution in search of a problem. I have confidence that if an admin has been blocked for good cause that the matter will be handled by ARBCOM where they would also have at least an opportunity to present their side rather than being automatically punished in contravention of the community's blocking policy. See also WP:CREEP. -Ad Orientem (talk) 00:58, 25 April 2023 (UTC)
• Oppose grave punishment done mechanically without deliberation. Lokys dar Vienas (talk) 04:06, 25 April 2023 (UTC)
• Oppose Per Seraphimblade. A month gives plenty of time for Arbcom to sort things out, and if they can't handle desyops in that time, why do we have an Arbcom again? Jclemens (talk) 04:14, 25 April 2023 (UTC)
• Oppose both per WP:BLOCKNOTPUNITIVE and per CaptainEek's "just because someone's been in jail for a month doesn't mean they're guilty" argument. I'd support a separate community desysop procedure, but would not support automatically tying it to a block. Loki (talk) 23:53, 24 April 2023 (UTC)
• Oppose Classic solution in search of a problem. What problem are we trying to solve here? How many times has an administrator been legitimately blocked for 1+ months and didn't subsequently lose the tools? More needs to be done to better define the problem to be solved by this proposed policy change, so that we can gauge whether this is the best solution to that problem. As it stands, the proposed solution is somewhat bizarre, e.g. having it tied to the first day of the month. —⁠ScottyWong⁠— 04:50, 25 April 2023 (UTC)
• Oppose; the ArbCom exists to deal with these matters. The proposal as written fails to exclude no-cause self-blocks and self-requested blocks. The proposed process could easily be gamed. Sending desysop proposals though the ArbCom avoids gaming and less-than-desirable behavior like pile-ons and partisan !votes at dramah boards. See also WP:CREEP. Baffle☿gab 05:46, 25 April 2023 (UTC)
• Oppose; sounds good on paper, but it just means that admins are able to desysop each other, and given ArbCom exists to deal with these sorts of matters, why don’t we just leave desysops to them. Zippybonzo | Talk (he|him) 06:16, 25 April 2023 (UTC)
• Oppose: I've worked at CAT:RFU and introduced a category for idle unblock requests because of the overwhelming amount of unblock requests in the queue that needed some kind of sorting. Even with these, currently 31, idle unblock requests taken out of the main category, there remain 96 open unblock requests as of now. A noticeable amount of these won't reach a decision within the next 28 days, so I'm not sure which allegedly reasonable source that number of days comes from. I'm unhappy with the assumption that an admin's unblock request will surely be handled quicker than the others, skipping the queue as an implicit necessity codified into the desysop procedure. ~ ToBeFree (talk) 06:51, 25 April 2023 (UTC)
• Oppose we already elect Arbcom to desysop admins when necessary. Re this specific proposal, the only admin who would have been caught by this in recent years was someone requesting a block to enforce a wikibreak. I don't think that we should discourage such wikibreaks in this way, or more likely create huge ANI debates about the blocking of admins who could be more quickly, fairly and less dramatically reviewed and if necessarily desysoped by Arbcom. I'm also concerned that this raises the stakes when blocking admins, especially thirty day blocks in the last couple of days of the month. I think that if anything we should try to reduce the stakes re the blocking of admins, an admin should be blocked in a situation where a non admin would be blocked. ϢereSpielChequers 06:57, 25 April 2023 (UTC)
• Oppose. A solution in search of a problem. There is absolutely no evidence that we have a significant number of admins who get blocked for an extended period of time without being desysopped by Arbcom. Moreover, as noted above, this proposal, if implemented, would significantly raise the stakes for blocking an admin. That would increase the amount of drama and gamesmanship surrounding such blocks and likely make such blocks more difficult to impose in practice. Nsk92 (talk) 08:23, 25 April 2023 (UTC)
• Oppose Reading through all the arguements above, Sandstein's was the most persusaive. The Squirrel Conspiracy (talk) 09:56, 25 April 2023 (UTC)
• Support We say that being an administrator is "no big deal," but as soon as a proposal comes up to remove administrators, it suddenly is a very big deal and administrators circle the wagons. This is a very reasonable idea. Figureofnine (talk • contribs) 12:11, 25 April 2023 (UTC)
• Oppose per Sdrqaz and The Wordsmith. OhanaUnited^{Talk page} 13:19, 25 April 2023 (UTC)
• Oppose, at least in current form. I think there's an unacceptable level of arbitrariness in this design. First, based on the votes, I now understand that "has been blocked for 28 days" refers to the the number of days the admin has been blocked as of the first of the month, not the total length of the block, as the buffer is meant to ensure an appeal is possible. But—and I concede it's possible I'm missing something big about how block timing works—doesn't that create chaos? Consider a user blocked for 1 month (or, hey, 30 days) at any point between April 3–29. By the first of the month, that user will not have been blocked for 28 days. Even if the user is blocked for 5 weeks on April 10th, they will not be subject to this sanction. But a user blocked for 1 month on, say October 2nd will have privileges stripped, because, by November 1, the user will have been blocked for 28 days.--Jerome Frank Disciple (talk) 13:55, 25 April 2023 (UTC)
• Support per Ritchie333. Inevitably, this procedure will have growing pains and problems. However, refinement requires testing and this is a very reasonable proposal. ~ Pbritti (talk) 17:49, 25 April 2023 (UTC)
• Oppose. This is a solution looking for a problem. If an administrator truly needs to be blocked longer than a couple days, I would expect an WP:ARC request to be filed well before the 28-day period is up. Recent examples have demonstrated that ArbCom is perfectly capable of expeditiously desysopping administrators in less than 28 days where necessary. For example, see
  1. Special:PermanentLink/1149026678#Dbachmann, in which ArbCom summarily desysopped an administrator (who was not blocked) after only 8 days of discussion, and
  2. Special:PermanentLink/1116499056#Athaenara, in which ArbCom summarily desysopped a blocked administrator after only 34 hours (see [1] for the desysop motion)
• Essentially, with the threshold set at 28 days, this will result in no tangible change to the current process, which is already quite efficient. Mz7 (talk) 21:22, 25 April 2023 (UTC)
• Support Though i don't care for the bureaucratic portion of it ~ on the first, twentyeight days... ~ which seem somewhat open to misinterpretation or abuse, it is a positive step towards a proper community de-admin process, and very clearly any admin who's been blocked for that long has lost the trust of enough of us that they shouldn't be adminning any longer. Happy days, ~ Lindsay^Hello 21:43, 25 April 2023 (UTC)
• Support- if an admin is blocked for that long, it means they must have done something very wrong. Admins who get such a long block should not be admins after all as they have broken Wikipedia policies to a serious extent. 747pilot (talk) 01:39, 26 April 2023 (UTC)
• Support This seems like a reasonable policy. Martindo (talk) 06:59, 26 April 2023 (UTC)
• Oppose Is there a problem with the current desysop procedure? Arbcom seems to desysop problematic administrators just fine. Lightoil (talk) 08:34, 26 April 2023 (UTC)
• Conditionally support if this can only occur where there are no ongoing appeal actions. Peacemaker67 (click to talk to me) 09:07, 26 April 2023 (UTC)
• Support as a stopgap between leaving problematic admins with the tools and having to wait months for ArbCom to handle the matter. Anarchyte (talk) 12:40, 26 April 2023 (UTC)
• Oppose The fact that an editor is blocked, does not automatically mean that he is not fit to be an admin. Sometimes it does, sometimes it doesn't. Therefore, this must be decided on a case-to-case basis, without any fixed procedures. Debresser (talk) 12:58, 26 April 2023 (UTC)
• Support Perhaps it's pointless, but I have a really hard time seeing how it could be a net negative. ᴢxᴄᴠʙɴᴍ (ᴛ) 13:45, 26 April 2023 (UTC)
• Oppose as written. Firstly, per Jayron32, there seems to be no actual problem that this would address. Secondly, the block tool is preventative and used to prevent ongoing disruption. This is mostly unrelated to reasons why an admin should be deadminned, and would muddy the waters — Martin (MSGJ · talk) 13:47, 26 April 2023 (UTC)
• Support – I note that some opposing arguments state that blocking doesn't automatically mean that removing the bit is necessary. I concede that point, but I also note the length of block required for this to become relevant. ANYONE who has been blocked for 28 consecutive days has shown to this community that their trustworthiness is questionable at best. While beyond the scope of this RfC, I would also support that, in addition to Administrators, all extended permissions – viz. CheckUser, Oversight, Bureaucrat, and anything granted at WP:PERM – should be automatically rescinded if that user has been blocked for 28 consecutive days. I've seen rather egregious conduct be met with blocks of only a few days, so for a 28-day block to be levied then someone really WP:DONTGETIT. — Jkudlick ⚓ (talk) 20:52, 26 April 2023 (UTC)
• Oppose I appreciate the intention in the proposal but I'm concerned with the aspect for creating higher level drama among individuals rather than solving an apparent, existing structural problem. Regards, --Goldsztajn (talk) 23:32, 26 April 2023 (UTC)
• Oppose. The intent is good, but the procedure is poor. It creates unnecessary tensions among administrators and we have a regular procedure for desysopping via Arbcom which should be respected. In addition, 28 days may just be too short a period to appeal. --TadejM ^{my talk} 16:10, 27 April 2023 (UTC)
• Support. Just about any proposal that makes it easier to get admin tools out of the hands of those who abuse them gets my support. The scenarios suggested in the oppose !votes where this causes problems are largely implausible. —swpb^{T • beyond • mutual} 17:47, 27 April 2023 (UTC)
• Weak support. I am not sure how often administrators block each other. If an administrator gets blocked, it should be serious enough to not only warrant a block but to warrant removal of administrator privileges. Samuel R Jenkins (talk) 04:32, 28 April 2023 (UTC) Blocked sock. NmWTfs85lXusaybq (talk) 03:43, 1 May 2023 (UTC)
• Oppose I agree that the community needs a de-sysop procedure, but this is not it. This could make block of less than 50 days become somewhat of a Russian Roulette for whether they stay an admin. Furthermore, this is hardly a "community procedure" since only other admins can block admins. We need a system, but not this one. QuicoleJR (talk) 16:19, 28 April 2023 (UTC)
• Support per Beeblebrox and Ritchie. Admins must have the confidence of the community, so it makes sense for their bit to be subject to community consensus, rather than needing to rely on ArbCom. Also agree with others that the risk of stealth desysops is very low; and anyway, that would itself be an ADMINCOND issue. DFlhb (talk) 19:24, 28 April 2023 (UTC)
• Support if nothing else. I think this is a poor solution, but any form of community desysop is better than nothing... CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:17, 28 April 2023 (UTC)
• Oppose per QuicoleJR. And WP:CREEP. This adds more procedural layers, while lacking clarity for implementation E.g., the faulty 1st of the month element. Something much simpler might find consensus. Pechmerle (talk) 05:53, 29 April 2023 (UTC)
• Weak support I have concerns around mobbing but also if someone has that kind of ban they shouldn't be an admin UNLESS there is some sort of reasonable reason. Dr vulpes ^{(💬 • 📝)} 06:03, 29 April 2023 (UTC)
• Weak oppose. It just seems like a lot of clean up when they should've had their admin rights removed as part of the block. I do agree with the proposal but not the process. Any admin who's worthy of a block should be desysopped automatically, and if they want their rights back, a community review should be conducted. Callmemirela 🍁 ^talk 14:48, 29 April 2023 (UTC)
• Oppose Too many weird edge cases in this proposal, as already well described by others. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Oppose too much of a catch all such as admins blocked for a wiki break. Also desysops should not be automatic in my view, each one needs proper consideration, Atlantic306 (talk) 20:03, 29 April 2023 (UTC)
• Support – This is a "Like, duh!" proposal, so of course it's opposed. Welcome to Wikipedia. --IJBall (contribs • talk) 00:16, 30 April 2023 (UTC)
• Support. It seems like a waste of ArbCom's time when there is a snowball's chance in hell that a blocked editor deserves to be an administrator.  — Freoh 12:11, 30 April 2023 (UTC)
• Weak Oppose In theory this could be good (say, someone gets radicalized into being a QAnoner or Anti Vaxxer on YouTube and that becomes their new activist cause for the site). However, I worry ArbCom in the end will value civility over all else and this will heighten demographic disparities in administrators. People of color, women, and queer people are more likely to be seen as incivil and I can easily conceptualize perma-bans from administration resulting in an even higher proportion of straight white men determining who is write or wrong at ArbCom, which already has documented troubles with arbitrating contentious topics related to race, gender, and sexuality.Computer-ergonomics (he/him; talk; please ping me in replies ) 12:56, 30 April 2023 (UTC)
• Oppose Needlessly bureaucratic and WP:CREEPy. Some1 (talk) 14:03, 30 April 2023 (UTC)
• Support, but what is who is blocked and has been blocked for more than 28 days? What happens if your block lasted more than 28 days but expired on say 5th of the month? Then you escape removal in the current cycle because it is not yet 28+ days, but in the next cycle, you won't fulfil is blocked requirement and won't be removed despite being blocked for 28+ days. I think is blocked is unnecessary. If you were blocked for 28+ between previous and current cycle, you should be desysoped. AhmadLX-(Wikiposta) 16:38, 30 April 2023 (UTC)
• Oppose. The proposal is plausible enough on its face. But having read through all of the arguments above, nobody seems able to articulate an actually-existing problem that this would solve. Further, quite a few people have noted problems that this proposal would be likely to create. This is a narrow enough circumstance that the impacts would be limited, but given the risk of harm to the project and the lack of any clear benefit, it seems best to leave this sort of rare edge case to be handled on a case-by-case basis. -- Visviva (talk) 23:57, 2 May 2023 (UTC)
• Oppose for basically the same reasons as Visviva.-- Aervanath (talk) 10:05, 3 May 2023 (UTC)
• Support: Not the first time Tony's comments have been the pivot upon which consensus might swing, but while I don't really disagree with his statements (and also note Galobtter's fair points about "not community"), I still basically take the Moneytrees approach here: it's barely anything so at least it's something. If it were to go, I'd prefer clarity that it's considering full blocks not partial blocks. ~ Amory (u • t • c) 12:26, 3 May 2023 (UTC)
• Oppose - This seems to create more problems than it solves. If the problem is untrustworthy admins, then giving admins the power to effectively de-sysop each other by imposing 28 day blocks seems to exacerbate the problem. Admittedly there could be a review, but I am not sure how well that would work. Rlendog (talk) 14:20, 3 May 2023 (UTC)
• Support but enforcement should consist of removing admin rights on day 28. Aasim - Herrscher of Wikis ❄️ 15:08, 3 May 2023 (UTC)
• How often does this happen? Guy (help! - typo?) 17:11, 3 May 2023 (UTC)
• Weak oppose. Add me into the column of respondents who think we are long overdue to establish some sort of broad community based desysop process, but who view this particular proposed solution to be far too awkward, unnesesarily indirect, and likely to prove prone to numerous problematic knock-on effects, several (but probably not all) of which have been identified above. Personally, I would advocate that we simply create a process for a discussion and direct community !vote (presumably to be typically conducted at ANI like msot CBANS), with an atypical requirement that there be a certain advisory threshold for minimum number of participants and minimum proportion of support perspectives, so that any communty desysop has some degree of rough parity with the volume of community will expressed through RfA itself. I don't really see the need for a more complicated process or more involved criteria than that: so long as there is a relatively high burden of required support baked into the policy language that describes this process, the community should be able to handle these exceptional cases through the same open-discourse and proposed sanctions methodologies with which it handles any other claims of serious misconduct. SnowRise ^{let's rap} 02:04, 4 May 2023 (UTC)
• Oppose. Solution in search of a problem that also has the potential to create new problems. The minimal benefit does not outweigh the risks. T. Canens (talk) 03:50, 4 May 2023 (UTC)
• Weak support - I'm fine with the principle but share the concerns of User:BilledMammal and User:Xaosflux about limiting implementation to the first day of the month. My preference would be not to specify that in the policy. Procedurally that could mean automatic implementation on the first day of each month, but that bureaucrats could also desysop blocked admins meeting the criteria manually at any time. The scenario User:BilledMammal outlined indicates why limiting implementation to one day a month is a bad idea. WaggersTALK 07:29, 4 May 2023 (UTC)
• Support – in general I support making it easier to revoke adminship. That brings us closer to the ideal of adminship being WP:NOBIGDEAL, which will hopefully make it easier to increase the number of new admins. —Mx. Granger (talk · contribs) 13:18, 4 May 2023 (UTC)
• Support, although I don't really see this as a community desysop procedure in the sense of "something done by the community", I don't see how an admin subject to a long block, not overturned, for a month can be considered to hold the confidence of the community. In any case, as the proposal currently stands, there are sufficent avenues of appeal. Alpha3031 (t • c) 11:13, 6 May 2023 (UTC)
• Oppose Needs to be after any length block (subject to any appeals over the block). Only in death does duty end (talk) 11:37, 10 May 2023 (UTC)
• Support – any admin blocked for that long should not be an admin. Ritchie's point an appealing is also particularly convincing. Aza24 (talk) 05:37, 11 May 2023 (UTC)
• Oppose per Tony. "Community desysop" should−explicitly and without exception−require community consensus. —Rutebega (talk) 19:44, 11 May 2023 (UTC)
• Support, though not an admin, my beliefs are the same as RickinBaltimore. InvadingInvader (userpage, talk) 04:15, 12 May 2023 (UTC)
• Weak oppose – no need for a procedural desysop here, in my opinion. Editing your own talk page while blocked should not count as an edit for postponing the year-long desysop, however. Skarmory (talk • contribs) 23:56, 12 May 2023 (UTC)
• Weak oppose mostly because this feels like instruction creep. It sounds like this might unintentially apply to self-blocked admins taking a break and would only truly apply to a few people (per BilledMammal conversation). Darkfrog24 (talk) 01:17, 13 May 2023 (UTC)

Discussion (Proposal: Procedural community desysop)

The concern I have with Arbcom is that it is such a long-drawn out process, that it burns out the people who are participants in a admin conduct related case, that they'd rather quit Wikipedia than stick it out. So we not only lose an admin, we lose an editor. Kudpung and RexxS are the most obvious cases I could think of, and it's just possible, perhaps, that a 48 hour civility block on either could have stopped them from quitting, addressed the complainants' concerns somewhat (for example, it's not a WP:SUPERMARIO if they get blocked, and a block removes immediate disruption and defuses situations in a way a long Arbcom case can't) and allowed them to hold on to their admin bit. Ritchie333 ^{(talk) (cont)} 15:52, 17 April 2023 (UTC)

"Administrators must be held accountable. But this is not the answer." This is pretty much why we don't have enough accountability, because too many people oppose the specific proposal over supporting the general concept. So nothing ever happens. Ritchie333 ^{(talk) (cont)} 16:31, 17 April 2023 (UTC)

(Since I'm being quoted) Ritchie, this isn't an enemy-of-the-good situation for me. If I thought the proposal would have a neutral effect, or a tiny positive one, or maybe even a negligible negative one, I wouldn't have opposed. My issue with the proposal is that it makes things worse, and that we are choosing to do something because it is something rather than because it's a positive change. As I explain above, I believe that it worsens accountability. Sdrqaz (talk) 02:02, 18 April 2023 (UTC)

I somewhat like this idea, but don't think I can support without a distinction between "for-cause" blocks and other ones. While it's rare for an admin to be blocked at length as a not-for-cause matter, I recall someone self-blocking a few years ago due to a family emergency, although I can't recall who at the moment. I would suggest adding for misconduct after the words who is blocked; I think it will be pretty straightforward for the bureaucrats to sort out the difference between "admin X is indeffed for repeated copyright violations" and "admin Y is indeffed with summary 'requested some time away from Wikipedia'". I also would rather this say something to the effect of and has no pending on-wiki appeals, although I tend to agree with Ritchie that after 28 to 59 days, things have probably shaken out. -- Tamzin^{[cetacean needed]} (she|they|xe) 16:32, 17 April 2023 (UTC)

For self-requested blocks, I think it would reasonable to relinquish administrative privileges at the same time. As a voluntary removal of permissions, the editor would be able to request to have them returned without having to go through a request for administrative privileges discussion. isaacl (talk) 18:26, 17 April 2023 (UTC)

One general issue is that our desysopping methods are already working better than our sysopping methods, so making additional desysopping methods (with no evidence that the current ones are insufficient) looks to me like working on the wrong problem. —Kusma (talk) 16:56, 17 April 2023 (UTC)

I choose to take that remark as a compliment. However, I don't think it is as much a matter of being insufficient as it is being unnecessary. Again and again when wayward admins are brought before the committee, they simply shut down and refuse to present a defense. So, the committee has been doing things like opening cases but suspending them for a few months, with the admin in question being temporarily desysopped unless and until they indicate a desire to open the case. To date, no admin has chosen the option of a full case when presented with such a choice. So, those admins do get removed, after 3-6 months, providing somebody remembers to actually close the case when it is supposed to close, which failed to happen at least twice in the last few years. This is simpler, faster, and presents pretty much the same choice to the admin: show up and present a cogent defense, or don't and let your admin tools go. Beeblebrox (talk) 17:08, 17 April 2023 (UTC)

I would note that as of this edit, among current or past arbs 5 support and 1 opposes. It's possible that "our desysopping methods are already working better than our sysopping methods" can be true but more because our sysopping methods are so broke that the desysopping looks good by comparison. Best, Barkeep49 (talk) 18:14, 17 April 2023 (UTC)

Recent for-cause desysops were handled quickly and with a comparably low amount of noise. I expect that there will be more noise under the proposed system, just less paperwork for ArbCom. —Kusma (talk) 18:52, 17 April 2023 (UTC)

I don't know. I feel like all of the recent admin arb cases, minus Jimmy's, had lots of community noise before and after it reached the case request stage. Best, Barkeep49 (talk) 20:02, 17 April 2023 (UTC)

In the Athaenara case, probably the desysop under this proposal would have gone through, but the block/unblock chaos might have been worse with blocks automatically meaning desysops. In the Geschichte case, if the community had had the tool of desysop-via-60-day block, it is anyone's guess how the epic ANI discussion would have played out, but I do think we'd have had more noise. —Kusma (talk) 21:21, 17 April 2023 (UTC)

"A blocked admin can't (since 2018) unblock themselves, and if they're blocked indefinitely, they'll just be auto-de-adminned when the time comes around." They are still able to edit their talk page and file an unblock request. This'll probably result in an ANI thread like this: "Hi, I just blocked admin X for edit warring and personal attacks, they're not admitting fault and threatening to block the other party in the dispute, can we review the block?" Or even, "Hi, I've indeffed Jimbo Wales as they've just blocked 3 arbs indefinitely; it clearly looks like their account is compromised". It'll get a response. If they're not prepared to file an unblock request, either they've got ANI flu and given up, or they think blocking is for the "little people" and not them, in which case they shouldn't be an admin. Ritchie333 ^{(talk) (cont)} 17:45, 17 April 2023 (UTC)

• Question: So, I have been doing some thinking on this beyond my initial oppose vote. What I want to know is what existing ongoing problem is this supposed to solve? Which is to say, what are some examples of blocked admins who got to keep their tools after being unblocked, and for which this process would have taken the tools away? It feels like a solution in search of a problem, at this point. I mean, unless someone can actually point to this being a problem (and I don't mean "one isolated case", I mean "an ongoing issue that keeps biting us in the ass"), then I really fail to see why we're going through the trouble to create a new policy. Can anyone in support of the policy provide evidence that this is a problem that needs new policy to fix? Examples, evidence, etc? --Jayron32 17:40, 17 April 2023 (UTC)

  The principal problem, as Beeblebrox said, it is it stops putting an unnecessary workload on Arbcom. It's a bit of an old example, but Wikipedia:Arbitration/Requests/Case/Neelix comes to mind. After the mass-creation of puerile redirects were discovered, he could have been blocked (to prevent any more being created) until the community could work out what to do. The community could have decided to site ban Neelix. But he was an admin, so Arbcom had to get involved, wasting everyone's time as I think there was near unanimity that Neelix should have been sanctioned. Ritchie333 ^{(talk) (cont)} 17:49, 17 April 2023 (UTC)

  You've asserted that it is "unnecessary workload". If your only example is a singular 8-year-old arbcom case, that's pretty flimsy in terms of necessitating a new policy. I think ArbCom can handle one such case every decade or so. Doesn't seem to me like "unnecessary workload". I ask again, what is the evidence this is needed? --Jayron32 17:53, 17 April 2023 (UTC)

  Also, I note that your best example was an ArbCom case that was resolved in 3 days. Replacing a process that takes 3 days with one that takes 28 days is somehow more efficient? --Jayron32 17:55, 17 April 2023 (UTC)

  It was the first example I could think of, and one of the most memorable, but by no means the only one. For example, Carlossuarez46 could have been blocked for personal attacks, or Athaenara could have just been indeffed for hate speech and left as is. Also, it might be worth comparing the 3 days with the amount of text that was generated, and from how many users - also, it's worth remembering that it only took 3 days because Neelix resigned his tools with a pledge he would not get them back with a new RfA. Ritchie333 ^{(talk) (cont)} 17:59, 17 April 2023 (UTC)

  Again, hardly a major issue. The memorable cases are memorable because they are so rare. We don't need to write new policy for cases spaced out over several years. You claim to be saving ArbCom work; have they asked the community for this help? Also, people are free to contribute to discussions as they see fit. I could equally claim that the amount of text this discussion has generated is out-of-proportion for the magnitude of the problem it proports to solve, which makes it worse than the problem it is trying to solve. I'm just saying that if you want more support for a proposed overhaul of policy, you've not shown how it is needed. A few isolated, weird cases have been shown. We don't have an epidemic of blocked-but-still-can-use-their-tools admins now, do we? If this were happening 3 times every 8 weeks or even 8 months, I'd think we have a problem. 3 times in 8 years seems hardly worth creating a policy over. --Jayron32 18:14, 17 April 2023 (UTC)

  If in practice the community has considered being blocked incompatible with having administrative privileges, then codifying this shifts discussion from the majority of cases where this view is held to those where exceptional circumstances may alter the community's opinion. This should be a net reduction in discussion (of course provided the initial inference on the community's view on blocked admins is true, which this RfC seeks to establish). isaacl (talk) 18:07, 17 April 2023 (UTC)

  How often are admins blocked? There's no need to create a policy to deal with a rare event. --Jayron32 18:14, 17 April 2023 (UTC)

  Sure, I often agree with that view. We'll see if the community thinks it's a net positive to explicitly state the incompatibility versus handling it each time it comes up. isaacl (talk) 18:41, 17 April 2023 (UTC)

  It's rather hard to query, because the database doesn't give an easy way to check whether user X was an admin at time Y, but for a mostly-complete set, combine quarry:history/65830/669690/650357 for current admins who've been blocked (mostly accidents/testing, with false positives for users like me who were blocked pre-adminship), the "Blocked or locked" sections of WP:FORCAUSE, Wikipedia:Former administrators/reason/resigned for past admins who are currently blocked (with false positives for post-desysop blocks), and Wikipedia:Former administrators/reason/compromised and "compromise" entries in WP:RESYSOPS (where I think everyone is or was once blocked); these miss most cases of blocked-then-deysopped-then-unblocked (but there's only one of those every few years) and blocked-then-unblocked-then-desysopped (but those are likewise mostly accidents/testing, with unrelated desysops). To my knowledge, prior to Athaenara, the last admin to be indeffed for cause as a regular admin action (i.e. not CUblock/ArbComBlock) and then get desysopped was Craigy144 in 2010—copyvio block, desysopped as unresponsive to ArbCom. There's several more recent blocks-then-desysops for compromise, with or without later unblock and/or resysop. -- Tamzin^{[cetacean needed]} (she|they|xe) 19:01, 17 April 2023 (UTC)

  @Tamzin: Fred Bauder was indeffed as a normal admin action by FPAS in 2018 for edit-warring and subsequent wheel warring. Maxim then removed the sysop flag as a unilateral emergency 'crat action (for violating WP:NEVERUNBLOCK/WP:WHEEL) shortly thereafter.

  There's a couple other indeffs done as normal admin actions that post date that of Craigy144 though none of them ended up lasting all that long, and thus were not the proximal cause of ARBCOM action, although in some of those cases they were part of the pattern that resulted in a later ARC and subsequent desysop. 74.73.224.126 (talk) 00:59, 9 May 2023 (UTC)

  @Jayron32:, you are right. This would probably apply about once every 5 years and won't affect Arbcom workload. But it's safe. Sort of like saying that if it it's found that somebody can't do basic addition (2 + 2 = ?) that we take away their math teaching position. North8000 (talk) 20:27, 17 April 2023 (UTC)

  @Jayron32, @North8000: The question is whether blocks of admins will remain rare if they have the option of turning into "community" desysops. —Kusma (talk) 10:33, 18 April 2023 (UTC)

  @Kusma: Good question. My guess is that that wouldn't happen. Basically a complex effort of a group of people mis-using the system to "get" an admin. But maybe a reason to avoid enacting something like this that really isn't going to serve a purpose. North8000 (talk) 13:39, 18 April 2023 (UTC)

  The Neelix case took four days. Guy (help! - typo?) 17:17, 3 May 2023 (UTC)

Regarding the concern that the proposal allows a single admin to block another, triggering a community discussion that may lead to the removal of administrative privileges: note unilateral blocks can only be enacted for edits related to contentious topics, enforcing specific arbitration remedies that authorize blocks, or for flagrant policy violations. An appeal of a block not meeting these conditions should be upheld, and the community can then decide if any further discussion of the situation is warranted. In essence, the same discussions that would occur today would still occur under the proposed change, with an added implication that being blocked is incompatible with holding administrative privileges. isaacl (talk) 17:50, 17 April 2023 (UTC)

It might be a good idea to have someone set up a bot to notify WP:AN whenever an administrator is blocked. Obviously it's pretty unlikely that such a block would slip under the radar for 28+ days, but if that notification would help reässure anyone that this proposal wouldn't be desysopping people under cover of darkness, it'd be a positive. Extraordinary Writ (talk) 18:08, 17 April 2023 (UTC)

Note the actual removal of privileges would not happen in the dark, and any unwarranted stealth blocks is going to be noticed when the list of blocked admins is prepared. So while it may be a good idea to have a bot update a page with a query of the list of blocked admins that can be transcluded elsewhere (or some other implementation), I don't think it's critical for this proposal. isaacl (talk) 18:38, 17 April 2023 (UTC)

This proposal does not require the community to weigh in in any way - it does not require the block to be reviewed or upheld. This is for obvious reasons: blocking an admin should in theory not be any different than a non-admin. But it at the same time relies implicitly on, and quoting the proposer himself, the assumption that "A block of an admin would be reviewed by the community". So I think it threads the needle of not explicitly making blocking admins different but in practice requiring community review of every long block of an admin (with the caveat that this will probably happen regardless of this proposal). In short, I'm not sure a proposal that explicitly required community review of the block would pass, but this proposal is functionally that. Galobtter (talk) 19:42, 17 April 2023 (UTC)

If blocking an admin results in de-adminship, then we will stop even pretending to treat blocks of admins the same as blocks of non-admins. WhatamIdoing (talk) 21:09, 17 April 2023 (UTC)

@WhatamIdoing FWIW, from a technical standpoint it effectively does.

While blocked the only logged action a blocked admin can perform is to block the admin that blocked them. SQL^{Query Me!} 23:10, 17 April 2023 (UTC)

Adding: Apparently you can't see deleted revs but can still see private abusefilter hits while blocked. SQL^{Query Me!} 23:18, 17 April 2023 (UTC)

But that "de-adminship" is automatically temporary. If you were blocked, you would still be an admin when the block expired. This is not what's proposed here. This proposal says: If you can get an admin blocked on January 3rd, for any reason, and it's not lifted before February 1st, then that admin will be permanently de-sysopped, even if the block is set to expire on February 2nd. WhatamIdoing (talk) 00:46, 18 April 2023 (UTC)

I am not sure if this has been considered. But since I found a discussion on desysopping, I bring it on. In the past I have observed two desysops not so much related with their sysop activity but with their views. I'd support a process where a sysop can be desysopped for their actions not so much for their views (they expressed some years ago). To desysop one for a few phrases in a little venue, when they had a tenure for several years...Have you considered to bring the desysop process before the community like the RfA?Paradise Chronicle (talk) 10:22, 25 April 2023 (UTC)

Clarification sought, in three scenarios:

• Admin A is blocked for 50 days on 10 July. On 1 August they haven't been blocked for 30 days yet so retain the mop. On 1 September they're no longer blocked, so retain the mop. Correct? That would seem to go against the proponents who argue that a 30-day block is a bad enough sign that the comunity no longer trusts A.
• Admin B is blocked for 40 days on 2 October. Drama ensues and a friendly (to B, anyway) Admin C unblocks Admin B in good faith, as C feels the block was inappropriate. A scant 23 minutes later after some testy posts at AN/I, Admin D reinstates the block, which holds. On 1 November, the review shows that B was not blocked 30 days and so retains the mop.
• Admin F is blocked for 30 days on 1 May. On 1 June, F is no longer blocked and so retains the mop. (The obvious "lucky timing" case.)

Is this the correct understanding of the proposal as written? — JohnFromPinckney (talk / edits) 21:24, 19 April 2023 (UTC)

Tweak based on comments made: "On the first day of the month, any administrator who is blocked and has been blocked [for cause] for more than 28 days [in the preceding two months] will have their administrator user-right procedurally removed (alongside inactivity removals)." SilkTork (talk) 08:39, 25 April 2023 (UTC)

SilkTork, do you mean to propose (as I think you might) ...for a total of more than 28 days...? That is, it could have been three separate blocks, yes? — JohnFromPinckney (talk / edits) 09:21, 25 April 2023 (UTC)

The convenience of routine software "housekeeping" functions does make this proposal seem awkward to implement. I suggest a shorter time limit, say 17 days of *consecutive* block, regardless of what happens between day 17 and the start of the subsequent month. I recommend 17 because it includes 3 full weekends, allowing for variations in time zone. Martindo (talk) 07:03, 26 April 2023 (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.

Alternate proposal (Procedural community desysop)

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.

---

Let's simplify this, and align it with current policy and process.

If an editor is banned by the community (not merely blocked), their granted permissions - including but not limited to admin tools - are removed. And even if the editor successfully appeals the ban and returns to editing, they will need to re-apply through the typical processes (such as WP:RFA) to regain any removed granted permissions.

(This is for an indefinite, full ban only, not a limited, topical, or partial one.)

In the rare instance where the ban is reversed due to a mistake by the community (but not merely due to a successful appeal of the ban), then said removals are reversed as well. - jc37 08:28, 18 April 2023 (UTC)

Survey (alternate community desysop proposal)

• Support I see no reason that this is mutually exclusive from the other proposal, but I do support this. If a site ban passes on an admin, they should no longer be an admin. Worm^TT(talk) 08:40, 18 April 2023 (UTC)
• Support I support this. It is reasonable and a step even further in the right direction, with respect to having community say in desysops without forcing Arbcom involvement. I would like to also see non-ban related proposals for desysops, but those can wait for a more future time Soni (talk) 08:43, 18 April 2023 (UTC)
• Support, that is fine (assuming ban means "site ban" and doesn't include any interaction bans). This would have worked in the Athaenara situation and would not have been discussed in the Geschichte case. —Kusma (talk) 09:28, 18 April 2023 (UTC)
• Support as above Ritchie333 ^{(talk) (cont)} 10:21, 18 April 2023 (UTC)
• Support per WTT. Thryduulf (talk) 10:35, 18 April 2023 (UTC)
• Support Seems much more reasonable than the first proposal. If someone has lost the community trust to the point where a community discussion has led to a community ban, that should implicitly imply that such a person has lost enough trust to lose the tools. The first proposal leaves too much on a single, possibly time-limited block, it puts too much in the hands of a single individual. --Jayron32 11:42, 18 April 2023 (UTC)
• Support - this is probably the only community decision which is so extreme that it would never occur unless the community has lost trust completely. Users may demand a temporary block or a partial ban to an admin who ruled against them on some issue, but not a permanent site ban; a small number of highly vindictive users may demand that, but the community won't support it. Animal lover |666| 12:48, 18 April 2023 (UTC)
• "Their granted permissions - including but not limited to admin tools" - this will overturn the consensus determined in Wikipedia:Requests for comment/User rights of (site) banned users. Also, for the proposal itself: (1) I am personally against it citing WP:CREEP and current ArbCom is sufficient to handle such cases; (2) I suggest we should explicit mention that such actions may still be appealed to ArbCom.--GZWDer (talk) 13:43, 18 April 2023 (UTC)

  My understanding is that ultimately (after community paths have been trod) any community action may be appealed to arbcom. So that would presumably include this. - jc37 14:08, 18 April 2023 (UTC)

  I never really agreed with that in the first place anyway. --Rschen7754 23:25, 18 April 2023 (UTC)

  Consensus can change; no state of consensus is permanent, and no discussion can bind any future state of the community at Wikipedia from discussing an idea and reaching a new consensus. It is a good data point to know what the existing consensus is on a topic when discussing it, but that existing consensus only lasts until it isn't consensus anymore. This very discussion is the way we are change that consensus. --Jayron32 14:42, 19 April 2023 (UTC)

• Weak support - I think the wording here will still favor de-sysop requests being taken to ArbCom rather than a community de-sysop process, for the reason that a site ban would be considered an action with greater scope and severity than a de-sysop. I don't think this is a sufficient remedy, but it's better than nothing. --⛵ WaltClipper -(talk) 14:07, 18 April 2023 (UTC)
• Support introducing this consensus-oriented method of removing bits. As worded, this proposal would allow for the community to de-crat, de-CU, and de-OS; I believe that these are features of this proposal, not bugs. I would also suggest that whenever a unban discussion takes place, people should be advised to make it clear if they are supporting an unban as "User:Example should not have been banned in the first place" (in which case the tools should be restored) or as "no longer required to prevent disruption" (in which case they should not). I would also like it if we specified that any CBAN discussion that results in the bit being removed should be closed by a 'crat. That is, it should function like RfA closure does: anyone can WP:SNOW/WP:NOTNOW close, but only a 'crat can close as successful. (For the avoidance of doubt, I am not advocating that we institute 'crat chats or a "discretionary range" for CBAN discussions.) HouseBlaster^talk 15:08, 18 April 2023 (UTC)
• Support as duh. If an admin is site banned by the community, then obviously they lose their rights. Sending it to ArbCom would be, in my opinion, a waste of time as ArbCom would pretty much rubberstamp the desysop. RickinBaltimore (talk) 16:01, 18 April 2023 (UTC)
• Support. I don't see this as mutually exclusive with the above, and I don't see it being used often, but I agree with the principle. Vanamonde (Talk) 16:10, 18 April 2023 (UTC)
• Support, in addition to the original proposal above. Boing! said Zebedee (talk) 16:27, 18 April 2023 (UTC)
• Support I opposed the original proposal but this is of course very reasonable and something I think we can all get behind. I think the amount of instances covered by the original proposal but not by this proposal is vanishingly few. (As a minor and moot point, I'm not sure if we can technically de-CU or de-OS a user, since WP:ARBPOL gives those duties to ARBCOM, but of course ArbCom will remove the permissions from a site-banned user.) Galobtter (talk) 17:33, 18 April 2023 (UTC)
• Support This proposal won't really solve the problem of unaccountable admins or the need for a community desysop procedure, and will in practice probably never be used. But it's something, and really, it should work this way regardless.— Preceding unsigned comment added by Writ Keeper (talk • contribs) 17:35, 18 April 2023 (UTC)
• Support, noting that in the Athaenara case several arbs implied they would do this anyways if it came to it. It's a little odd how this interacts with non-admin-tier rights, but at the same time not really an issue, since most of those can all be restored at any admin's discretion; the exceptions are EFM and EFH, but that's probably a good thing. I know I'd have no problem giving rollback back to a recently-unbanned user if the ban didn't involve rollback abuse or edit-warring, for instance. As to desysopping and decratting, I agree with HouseBlaster that this should follow the default rule that a discussion should only be closed by someone with the tools to enact it (or in the case of decratting, the authority to request a steward enact it). With de-CU and de-OS, a 'crat could close as "banned and referred to ArbCom regarding CU and OS" and start a pro forma case request. Like Galobtter, I very much doubt any committee will hesitate to remove rights in that situation. -- Tamzin^{[cetacean needed]} (she|they|xe) 18:05, 18 April 2023 (UTC)
• Support regardless of whether the original proposal passes. Of course, 99% of admins who do something even remotely sitebannable are going to be desysopped by the Committee (whether by level 1, level 2, or motion) well before the ban discussion is closed, and I hope arbitrators continue doing that without feeling that they need to defer to the community: the last thing I want to do is slow down the desysop process in straightforward and/or urgent cases. But in general I think the proposal does move us (very marginally) in the right direction toward additional admin accountability to the community, so I'm happy to support. Extraordinary Writ (talk) 18:33, 18 April 2023 (UTC)
• Support regardless of whether the original proposal passes; makes sense. Editors holding rights are expected to hold the trust of the community; if the editor is banned it is very clear that they have lost that trust. BilledMammal (talk) 19:58, 18 April 2023 (UTC)
• Support Not much more to add. Admins and 'Crats must retain the community's trust --Enos733 (talk) 20:06, 18 April 2023 (UTC)
• Oppose per my above oppose. I don't see what problem this fixes. What terrible thing happened that this will prevent? Lowering the workload for Arb? I don't see the workload as a problem. Dennis Brown - 2¢ 20:37, 18 April 2023 (UTC)

  What terrible result will come from this passing? As far as I can tell, this should have nearly 0 effect in a century of Wikipedia but that nil effect would be good. Animal lover |666| 12:10, 19 April 2023 (UTC)

• Support. It hopefully won't be needed often, but this does look like a process that the community can handle without needing an Arbcom case. - Donald Albury 20:40, 18 April 2023 (UTC)
• Support It takes an awful lot of misbehavior to earn a site ban, & most admins are very visible folk. Further, some of admins gained the bit back when standards weren't as high, & even if this never implemented, it'll serve as a sword of Damocles to check admins from being too enthusiastic with the bit. -- llywrch (talk) 21:10, 18 April 2023 (UTC)
• Weak oppose It's like saying that a person who can't do basic addition isn't allowed to teach math in a university. No argument with that, but it's something that will never get used and so not worth messing with. North8000 (talk) 21:17, 18 April 2023 (UTC)

  And, BTW this is a better proposal than the initial one. North8000 (talk) 17:29, 19 April 2023 (UTC)

• Support even if seldom used, this will be a start for community based decisions. Graeme Bartlett (talk) 23:19, 18 April 2023 (UTC)
• Support contains the spirit of the original proposal without the drama-adding elements. --Rschen7754 23:24, 18 April 2023 (UTC)
• Support as a minimum. AndyTheGrump (talk) 23:56, 18 April 2023 (UTC)
• Support for the same reasons I !voted support above. -FASTILY 02:09, 19 April 2023 (UTC)
• Support simple and straightforward. Legoktm (talk) 03:57, 19 April 2023 (UTC)
• Support in addition to supporting the original proposal above. An admin who draws a CBAN is even more obviously not trusted by the community. --RL0919 (talk) 06:08, 19 April 2023 (UTC)
• Support, as a CBAN is a clear indication of the loss of the community's trust. ScottishFinnishRadish (talk) 13:57, 19 April 2023 (UTC)
• Support per WTT. Ajpolino (talk) 14:59, 19 April 2023 (UTC)
• Oppose - this isn't a logical extension of the original proposal, which was to procedurally remove the tools from admins blocked for a significant term, considering that blocks are to prevent editing disruption. There's generally no consensus that blocks can be used to respond to administrative misconduct, that's why we have WP:LEVEL1. Any admin who blocks another admin because of an administrative action is likely to be the first mover in a wheel war, and we should not introduce ambiguity to that policy. An administrator who is banned by the community is likely to be blocked anyway, and would have their permissions removed after 28 days if the above proposal passes or after a year under current policy; I don't see why this is necessary. However, the extension is a backdoor to create a community desysop process by which the only way for the community to remove admin rights is to ban the admin, even if their edit history is spotless. That's too heavy-handed, and it's absolutely going to be abused by bad actors to intimidate or eliminate administrators that get in the way of their tendentious agendas. It's a step too far, especially considering it's a first step. Ivanvector (^Talk/_Edits) 16:14, 19 April 2023 (UTC)

  In what circumstances do you envision a community consensus to ban an admin "if their edit history is spotless"? --RL0919 (talk) 20:10, 19 April 2023 (UTC)

• Support as a start. If you mess us enough to get yourself community banned, then you're clearly not suitable to hold advanced user rights. SkyWarrior 17:50, 19 April 2023 (UTC)
• Weak oppose based on the current wording. I think this is a solid idea, but I'd like to see it clarified that if an appeal finds that the original close was improper (incorrect reading of consensus, involved admin, wheel warring, things of that nature) rather than an appeal determining that the ban was valid but should now be lifted, then permissions should be restored. The Wordsmith^{Talk to me} 18:25, 19 April 2023 (UTC) Switching to Support as I had missed part of the proposal. It seems like a good idea and a fairly obvious change to be made. The Wordsmith^{Talk to me} 20:38, 19 April 2023 (UTC)

  That should be inherent in the last line of the proposal. Reversal due to "Community mistake". There are many ways in which mistakes could be made in a discussion. From the proposing, through to the closure. I don't think we could list them all. But should it be determined that the ban was done in error, then the granted tools should be restored. Essentially undoing a "miscarriage of justice". - jc37 19:28, 19 April 2023 (UTC)

  Somehow my eyes managed to skip over that entire line, I do see now that my issue is already addressed. I'll update my statement accordingly. The Wordsmith^{Talk to me} 20:37, 19 April 2023 (UTC)

• Support other have already said everything I could say. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:30, 19 April 2023 (UTC)
• Support this is better than nothing, but it is vastly inferior to the original proposal. The bar for admin accountability on this site is still way too high. LEPRICAVARK (talk) 01:56, 20 April 2023 (UTC)
• Support per my comments above. TonyBallioni (talk) 02:05, 20 April 2023 (UTC)
• Support Andre🚐 02:49, 20 April 2023 (UTC)
• Oppose. I do not see the practical need for this instruction creep (WP:CREEP). Community bans of admins are hopefully very rare (has there ever been a case?), and there is no reason to believe that ArbCom would not promptly desysop an admin who has been properly banned by the community (if only because they can no longer legitimately use their tools). The problem with this proposal is that it would incentivize people to use ban discussions as a proxy for a desysop by community consensus, which so far the community has declined to institute for what I think are good reasons. Sandstein 07:20, 20 April 2023 (UTC)
• Support I think usage othis will be incredibly rare but it's conceptually sound. Best, Barkeep49 (talk) 07:52, 20 April 2023 (UTC)
• Suppport noting that this doesn't conflict with the primary proposal here so, despite the title, it's not in any meaningful sense an "alternative". I'm supporting it as a complementary idea.—S Marshall T/C 08:01, 20 April 2023 (UTC)
• Support in parallel to the primary proposal. As WTT said, If a site ban passes on an admin, they should no longer be an admin. firefly ( t · c ) 08:25, 20 April 2023 (UTC)
• Support in addition to the proposal below. Beyond My Ken (talk) 09:11, 20 April 2023 (UTC)
• Support - Seems straightforward that if a user does not have the trust of the community to edit Wikipedia, they don't have the requisite trust to be an admin. Compatible with WTT's proposal above. WJ94 (talk) 09:21, 20 April 2023 (UTC)
• Oppose, solution looking for a problem. Stifle (talk) 10:12, 20 April 2023 (UTC)
  • To add to this comment, this solution would be a witch-hunters' paradise. It takes a week, and a massive stressful process, to grant adminship. Removing adminship based on a pile-on on ANI is a desperately bad idea. There's a reason WP:QKP was killed off. Stifle (talk) 08:36, 12 May 2023 (UTC)
• Oppose a rare occurrence like this can be handle by ArbCom. Such a rule would encourage even more gaming of the system (campaign for a long block on an admin you don’t like to end them for good). Jehochman ^Talk 12:18, 20 April 2023 (UTC)

  Hi Jehochman. The survey about long blocks is before this one. This one concerns site bans. - jc37 13:07, 20 April 2023 (UTC)

  Same logic, different terminology. (I did copy and paste.) This proposal is even more unnecessary because it addresses an extremely rare situation. If an administrator gets sitebanned, ArbCom should definitely be looking into it to understand what happened (compromised account, etc.). Jehochman ^Talk 19:22, 20 April 2023 (UTC)

• Support per WTT Pharaoh of the Wizards (talk) 16:35, 20 April 2023 (UTC)
• Support a bit narrow but I don't see any problems with this —pythoncoder (talk | contribs) 18:09, 20 April 2023 (UTC)
• Support This sounds good too. - Who is John Galt? ✉ 21:33, 20 April 2023 (UTC)
• Support, but I can't believe this is even a question. You mean to tell me that a banning doesn't mean you lose your privileges? Ok, so if I get banned you are telling me I still get to keep my autoconfirmed, rollbacker, and pending changes reviewer status rights, or is it only admins that get to keep tools? That is ridiculous. Huggums537 (talk) 05:46, 21 April 2023 (UTC)
• Weak oppose as pointless instruction creep, per Dennis Brown, Jehochman, Sandstein. If an admin gets cbanned, I would imagine they would be pretty uncontroversially and with minimum additional drama be de-adminned by Arbcom using their Level II procedures. This situation is fortunately sufficiently rare that we don't need additional policy to sidestap that existing solution. I'm opposing this variant only weakly, as opposed to original proposal, since by applying simply to cbans and not imposing arbitrary timelines, the instruction creep is more manageable. But it's still unnecessary. Martinp (talk) 15:05, 21 April 2023 (UTC)
• Oppose as pointless - it appears this situation has never happened in recent history. * Pppery * _{it has begun...} 21:18, 21 April 2023 (UTC)
• Support as codifying what should be common sense. Giraffer ^{(talk·contribs)} 14:34, 22 April 2023 (UTC)
• Support, provided that an amendment is made to indicate that it must be an indefinite site ban, so that we don't see silly things like a five-minute site ban being proposed as a "backdoor desysop". Seraphimblade ^{Talk to me} 15:44, 22 April 2023 (UTC)

  Done - I already noted it did not include limited bans, but added the clarification anyway. - jc37 16:29, 22 April 2023 (UTC)

  Although of course tomorrow the community could invent a fixed-duration site ban, with the historical concept of a site ban, it's always indefinite. Editors are site banned when they are no longer welcome to be participate at all in the English Wikipedia community. It's not a situation that times out without an appeal. isaacl (talk) 04:03, 23 April 2023 (UTC)

• Support While I acknowledge that the cases where this could apply are likely small which gives me reason to oppose, I think this is the best possible way to handle community based desysop proposals. We've been trying to untie this gordian knot for almost 20 years without success. It's been clear for a long time now that we need such a process. I can see how this process could have problems; a single administrator closing the discussion to CBAN? Hmm. Gang mentality polluting the results? Hmm. Sockpuppeters coming out of the woodwork after their favorite target? Hmm. I think the process can weather that. I would like to see one caveat applied though; CBAN "discussion must be kept open for 72 hours except in cases where there is limited opposition and the outcome is obvious after 24 hours". The 24 hour statement shouldn't apply in this case, instead requiring 72 hours. --Hammersoft (talk) 17:23, 23 April 2023 (UTC)
• Weak support I don't think this is needed, as it is rare and there are existing venues to deal with this situation, but it may avoid needless redundant paperwork. — xaosflux ^Talk 23:00, 24 April 2023 (UTC)
• Support - a natural, I'd say merely technical extension of ban. Lokys dar Vienas (talk) 03:56, 25 April 2023 (UTC)
• Support in that it's 1) a higher threshold, 2) consistent across permissions, such that, if I remember correctly, it would have been useful--even if just as a principle--in some of the old bot operator/automated editing conduct issues. Jclemens (talk) 04:25, 25 April 2023 (UTC)
• Support, as reaching a consensus for an indefinite siteban is a clear, existing way for the community to express a complete loss of trust. ~ ToBeFree (talk) 07:22, 25 April 2023 (UTC)
• Oppose. Unnecessary, a solution in search of a problem. Nsk92 (talk) 11:47, 25 April 2023 (UTC)
• Support This formalises what should be obvious. talk to !dave 12:15, 25 April 2023 (UTC)
• Support.--Jerome Frank Disciple (talk) 13:57, 25 April 2023 (UTC)
• Oppose as an absurd weakening of the original proposal. Figureofnine (talk • contribs) 14:49, 25 April 2023 (UTC)

  These proposal are not exclusive. — xaosflux ^Talk 12:45, 27 April 2023 (UTC)

• Support: a plainly fine proposal; far better than nothing. ~ Pbritti (talk) 19:39, 25 April 2023 (UTC)
• Neutral. I'm not substantively opposed to this proposal as I believe it reflects common sense: obviously a site-banned administrator has lost the confidence of the community and should be desysopped. However, like the original proposal, I see this as a bit of a solution looking for a problem, and I do not foresee that it will produce any tangible improvement to current process. We site-ban administrators exceedingly rarely—the threshold for a desysop is much lower than the threshold for a site-ban. If an administrator is under discussion for a site-ban, I would expect that a request at WP:ARC will have already been filed in parallel, and as I mentioned earlier, recent examples have shown that ArbCom is perfectly capable of expeditiously desysopping administrators where necessary. Mz7 (talk) 21:44, 25 April 2023 (UTC)

  Just wanted to add a bit to this to explain why I am "neutral" on this alternative proposal and "oppose" on the main proposal. I am more sympathetic to this alternative proposal because a site ban is a higher bar to clear than a block. A site ban requires clear community consensus at an administrative noticeboard, whereas a block can be imposed unilaterally. The consensus for a site ban can become clear pretty efficiently: I've seen cases at WP:AN where we've site-banned editors within a day or two (although because of the invention of WP:3X, site ban discussions are quite rare nowadays). This is in contrast to the required 28-day window from the main proposal.

  If we pass this alternative proposal, I can see cases where if an administrator does something so egregious that they need to be blocked indefinitely, the community would then have two avenues to desysop the admin: (1) start a site-ban discussion, or (2) request a desysop at WP:ARC. The reason I am "neutral" and not "support" is because I believe the existing process of requesting the desysop at WP:ARC already works as efficiently as a site-ban discussion (and may even be preferable because ArbCom is generally more evidence-focused and deliberative than the free-for-all style of WP:AN). Also, I am worried that this will lead to situations where we go for a site-ban on a blocked administrator where a simple indefinite block would have sufficed, just so that we can desysop them (a block can be overturned unilaterally whereas a ban requires community consensus to overturn). Mz7 (talk) 21:12, 27 April 2023 (UTC)

• Oppose as unnecessary any C-banned admin would almost certainly be desysoped by Arbcom. Lightoil (talk) 08:39, 26 April 2023 (UTC)
• Support Seems like a great idea to me. -- Grapefanatic (talk) 14:45, 26 April 2023 (UTC)
• Oppose at the moment any admin who was community banned would likely be desysopped by motion from arbcom. So if this went through there would either be no meaningful change, or we'd have a bunch of attempts to ban particular admins, with some people supporting the ban as the most effective way to desysop that admin, and others saying that they hope arbcom does a desysop but they don't think a ban is merited. If there is any scope for a community desysop it is to deal with people who arbcom would not desysop, but where the people who elect arbcom want to be harsher than arbcom. That group won't overlap with the people who merit a ban. ϢereSpielChequers 14:58, 26 April 2023 (UTC)
• Oppose; redundant proposal as the ArbCom can order an emergency desysop if needed. I agree site-banned users should not hold advanced rights but this proposal could be gamed, would create much dramah and become unworkable. Baffle☿gab 21:01, 26 April 2023 (UTC)
• Oppose per WP:CREEP. Still a solution in search of a problem. Passing more rules just for the sake of passing more rules is something I typically associate with politicians and (some) civil servants who need to justify their paycheck. -Ad Orientem (talk) 21:04, 26 April 2023 (UTC)
• Support in combination with the primary proposal. Long blocks and bans should mean de-sysoping, and a successful ban appeal should not mean an automatic restoration of the bit. Way too much abuse of the tools goes on, and anything that curbs that would have to have some pretty enormous downsides to lose my support. —swpb^{T • beyond • mutual} 17:50, 27 April 2023 (UTC)
• Support per Worm. ~ 🦝 Shushugah (he/him • talk) 22:57, 27 April 2023 (UTC)
• Support a reasonable thing that sould happen. I don't see the need for arbcom to pro forma vote to desysop someone here. --In actu (Guerillero) ^{Parlez Moi} 07:51, 28 April 2023 (UTC)
• Support as better than nothing, even if it's only used rarely. Hard to think of any case where an admin is banned, yet still trusted enough to keep the tools. DFlhb (talk) 16:47, 28 April 2023 (UTC)
• Strong support. I don't see a world where a user who is so distrusted to be banned is trusted to be an admin... CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:22, 28 April 2023 (UTC)
• Support Being allowed to resume editing is a different kettle of fish to having one's advanced privileges restored. MrsSnoozyTurtle 05:01, 29 April 2023 (UTC)
• Neutral Makes sense, but it seems unlikely that existing processes (i.e. an ArbCom motion) wouldn't already handle this. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Strong support per my comment in the original proposal. Removing admin rights should be done automatically when such user is blocked or banned. RFA is the venue to regain their rights. Callmemirela 🍁 18:03, 29 April 2023 (UTC)
• Support as superior to the original proposal. If an admin is site-banned by the community, then their privileges should be immediately revoked, full stop. I don't see a reason why this should need to be sent to ArbCom.-- Aervanath (talk) 10:09, 3 May 2023 (UTC)
• Basically in agreement with the above supports: sure, not mutually exclusive. I'd go much, much farther, but as above, at least it's something. ~ Amory (u • t • c) 12:27, 3 May 2023 (UTC)
• Support – seems like common sense, and in general I support making it easier to revoke adminship, as I explained above. —Mx. Granger (talk · contribs) 13:20, 4 May 2023 (UTC)
• Support at the same level as the original proposal. Aasim - Herrscher of Wikis ❄️ 16:16, 4 May 2023 (UTC)
• Support Thought this was done as a matter of course already; ArbCom shouldn't be in charge of literally everything. – John M Wolfson (talk • contribs) 01:37, 6 May 2023 (UTC)
• Support. Side note, while I do think both of these proposals essentially codify something that would almost certainly happen anyway through existing processes (Level II), and if we could only have one procedure I would probably prefer one that's separate from any blocks or bans, but we can have more than one and I doubt we'd get to the point of it becoming CREEP unless we somehow decided to start adding new "things that gets admins' bits removed by the community" to the list every week or two. Alpha3031 (t • c) 11:13, 6 May 2023 (UTC)
• Oppose Needs to be any ban (including topic). Only in death does duty end (talk) 11:38, 10 May 2023 (UTC)
• Support it's somewhat incredible this wasn't adopted in some form about 15 years ago. —Rutebega (talk) 19:56, 11 May 2023 (UTC)

Discussion (alternate community desysop proposal)

There's a couple suggestions above that the discussion should be closed by a crat. Since the desysopping would be a consequence of the ban by policy but not explicitly part of it, I don't think this needs to be the case. I feel like this is a case where the admin closing could simply leave a note at WP:BN, as is done with ArbCom desysops. Galobtter (talk) 18:21, 18 April 2023 (UTC)

I agree. Closure by an uninvolved admin is fine. Thryduulf (talk) 11:56, 19 April 2023 (UTC)

If this were likely to be relevant soon for a specific admin, it may have required a bureaucrat; however, since this is clearly not the case, admin closure should sefice. Animal lover |666| 13:54, 19 April 2023 (UTC)

I am somewhat concerned that this might end up (to a greater degree than the slow 28 day process) be used in some cases to force a desysop through banning someone, when their actions would not otherwise have led to a CBAN. I'm not sure whether mitigation with stressed clarity that a !vote seemingly acting to ban only as a means to desysop. Nosebagbear (talk) 20:43, 19 April 2023 (UTC)

I hope the community isn't so cruel as to site ban just to cause a desysop, but I agree there is a perverse incentive here - but I feel like that equally applies to the original proposal. Galobtter (talk) 02:52, 20 April 2023 (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.

Alternate proposal (Arbcom Level II desysop of long-term blocked admins)

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.

---

Let's address the issue without gameable instruction creep and with minimum changes to existing policies for what are very rare cases. Arbcom can already desysop an admin under WP:LEVEL2 if "(a) the account's behavior is inconsistent with the level of trust required for its associated advanced permissions, and (b) no satisfactory explanation is forthcoming." Doing so doesn't take the weeks or months of an active or suspended arbcom case, just a vote by Arbcom. Therefore, if there is any ambiguity, let's just resolve the situation by affirming the statement in the next paragraph. Then in the rare cases an admin ends up in this situation, sua sponte or on request any arbitrator can propose a Level II desysopping and the Committee can effect it by voting. They will presumably do this with a minimum of fuss, but with a bit of consideration/deliberation as to whether there are any exceptional circumstances, and whether sufficient time has passed for it to become clear that the user in question will remain blocked for some time.

Statement: The community affirms that engaging in behaviour that leads to an admin becoming and remaining long-term blocked (or banned), for cause, is generally inconsistent with the level of trust required for retaining administrator permissions. Arbcom is empowered (alternative: directed?) to act per its existing policies (currently WP:LEVEL2) to deal with such situations.

Editing since forgot to sign: Martinp (talk) 18:10, 19 April 2023 (UTC)

Survey (alternate proposal for Arbcom Level II desysop of long-term blocked admins)

• Oppose For pure WP:BURO reasons. I do not see anything this proposal does that Arbcom does not already do, via their string of measures. A "please do this" from the community to Arbcom isn't enough. And the biggest draw of the other proposals for me was simply "Having more community measures to desysop" instead of putting even more things strictly at Arbcom alone.

In fact, I cannot imagine a single scenario where Arbcom would block or ban someone without de-adminning, making this even more of a rules creep. At least the others were explicitly "community decision" instead Soni (talk) 02:42, 20 April 2023 (UTC)

• Support in the event no other proposals here gain consensus (in which case I oppose this as redundant). ArbCom issues "community reminders" all the time; why can't we do the same to ArbCom? HouseBlaster^talk 03:01, 20 April 2023 (UTC)
• Oppose, instruction creep. ArbCom is elected and can be trusted to make this (rather obvious) determination on a case-by-case basis. Sandstein 07:22, 20 April 2023 (UTC)
• Oppose because this is not a process that offers the community any role in desysopping.—S Marshall T/C 07:59, 20 April 2023 (UTC)
• Oppose I don't see what the purpose of this is. Beyond My Ken (talk) 09:11, 20 April 2023 (UTC)
• (edit conflict) Oppose. This is not the way to amend arbitration policy, and will be wholly redundant to either of the first two proposals here. Thryduulf (talk) 09:11, 20 April 2023 (UTC)
• Oppose. This just seems like adding a bit more bureaucratic waffle, without achieving anything concrete. Boing! said Zebedee (talk) 10:03, 20 April 2023 (UTC)
• Oppose Doesn't ArbCom already have the power to desysop people? Why are we just reconfirming what they already do? --Jayron32 12:03, 20 April 2023 (UTC)
• Oppose because this isn't a proposal to change anything of substance. AndyTheGrump (talk) 12:06, 20 April 2023 (UTC)
• Neutral: I agree with the statement above but it is already the case the ArbCom removes admin rights from banned users. The statement is not a proposal for a community-based desysop process. Baffle☿gab 21:09, 26 April 2023 (UTC)
• Oppose per most of the above and WP:CREEP. Still a solution in search of a problem. -Ad Orientem (talk) 21:13, 26 April 2023 (UTC)
• Oppose. Is this not exactly what ArbCom already does? CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:31, 28 April 2023 (UTC)
• Support-ish This doesn't really do anything other than restating the obvious: someone long-term blocked or banned probably has lost the trust of the community, and WP:LEVEL2 exists allowing ArbCom to remove the bit if they want. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Oppose The more I read these proposals the more I see unintended outcomes and I'm beginning to wonder if I misunderstand the true purpose behind additional, unnecessary rules. Chris Troutman (talk) 18:37, 29 April 2023 (UTC)
• Oppose Does not address the actual problem. Only in death does duty end (talk) 11:39, 10 May 2023 (UTC)

Discussion (alternate proposal Arbcom Level II desysop of long-term blocked admins)

Since my proposal is garnering quite a lot of opposition, let me explain my thinking. In my view, yes this changes very little. I view it as uncontroversial that in many (most?) circumstances, being blocked long-term for cause is clearly incompatible with the level of trust needed to continue holding adminship. So I would like to think that if some admin ends up in that circumstance, Arbcom could just de-admin them for conduct unbecoming. However, there is significant functionary (including Arb) support for the present "community procedural de-admin" proposal, with specific bright line criteria. This support presents as the alternative being avoided a "long, drawn out arbitration case". So I'm proposing to explicitly just say, "yeah, Arbcom, go ahead and pull the bit using L2 without too much fuss where warranted" as a less bureaucratic solution to a rare problem then a convoluted "community procedural" process, one where we're needing to wordsmith ahead of time exactly what the block age and duration should be, what kind of block counts, etc. Basically, I feel we actually don't need more rules to solve a rare problem. However, since Arbcom members seem (implicitly) unsure if they have the authority to desysop someone just because the community has decided to block them for a long time, reassure them that they already do. Martinp (talk) 19:38, 20 April 2023 (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.

Alternate proposal: the community supports development of a de-sysop process

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.

---

Let's stop beating around the bush and just propose this:

The community supports the development of a community based process for removing administrator rights for cause outside of the current arbitration committee procedures. If this proposal closes with consensus, the community directs that a binding RfC be opened within 30 days where community members may submit proposals to determine the process.

Survey (Alternate proposal: the community supports development of a de-sysop process)

• Support determines the actual consensus on the principle of the matter, and establishes a procedure to determine how to implement the consensus on the principle if it exists. Much better than picking around the edges. If there is a community consensus on the principle, let us establish that and then determine what the method of implementing it should be. TonyBallioni (talk) 02:10, 20 April 2023 (UTC)
• Support I've long assumed this first part describes the community's desire (though I suppose we'll see here). It's the second part, actually finding details of such a process, that folks seem to struggle with. But another RfC is certainly worth a try. Ajpolino (talk) 02:27, 20 April 2023 (UTC)
• Support This is most in line with what I would like to see. I worry that this structure guarantees another no consensus (being too similar to the last N failed RFA reforms, and apparently the other DESYSOP proposals). But I would like community desysop to happen, and supporting this is more preferable than standing in the way. Soni (talk) 02:46, 20 April 2023 (UTC)
• Support. I think where the earlier proposals fail is in trying to make this work within the existing block framework, when what is actually required is a concrete mechanism by which sysops who have lost the confidence and trust of the community can be de-sysoped. Patr2016 (talk) 02:57, 20 April 2023 (UTC)
• Support I guess, but I am not very optimistic that it will end in a real process. --Rschen7754 03:11, 20 April 2023 (UTC)
  • Oppose just because the "waste of time" argument is too strong. Maybe in another year. --Rschen7754 04:24, 26 April 2023 (UTC)
• Support. I agree with the principle, and while I reserve the right to say "I told you so" when the RfC ends up with too many proposals, too few participants, and no consensus, I agree with Soni that supporting this is more preferable than standing in the way. An oppose !vote certainly wouldn't make community desysop more likely to happen. Extraordinary Writ (talk) 06:23, 20 April 2023 (UTC)
• Support. I don't expect this to work but it is worth trying. BilledMammal (talk) 06:57, 20 April 2023 (UTC)
• Oppose. I frankly don't see the practical need for yet another drama-laden process. From what I can tell, the ArbCom process works rather well, as in the recent Dbachmann case. If and when we have a specific case where ArbCom declines to desysop a person who's obviously unfit for the job, then we can and should have this discussion. Sandstein 07:24, 20 April 2023 (UTC)
• Theoretical support, actual oppose. I support community desysop but for the reasons I mention here I find this proposal to get there not to be fully thought out or practical. Barkeep49 (talk) 07:42, 20 April 2023 (UTC)
• Oppose. This seeks to replace the practical, workable ideas already on the table with no tangible offer at all.—S Marshall T/C 07:57, 20 April 2023 (UTC)
• Oppose Per Barkeep and S Marshall. I support in theory, but not in practise. We have a couple of small step solutions here that are thought out. Scrapping the work above and hoping that a binding RfC which has failed twice in recent years is not a solution. Worm^TT(talk) 08:09, 20 April 2023 (UTC)
• Oppose per Barkeep et al. This is a fine idea in theory, but I fear it won't actually result in any real change. IMHO - best to take iterative steps toward a solution than start a(nother) large discussion. firefly ( t · c ) 08:22, 20 April 2023 (UTC)
• Weak support, this is much better than the original proposal where we would just make up the rules as we go along the next time an admin is blocked. I do think we can usually leave things to ArbCom, though; a slow and deliberative process is likely better than things like Wikipedia:Requests for comment/Kelly Martin/original. —Kusma (talk) 08:42, 20 April 2023 (UTC)
• Support - OMG, this is so freaking overdue, yes, yes, yes. Beyond My Ken (talk) 09:02, 20 April 2023 (UTC)
• Oppose at the moment. If either of the first two proposals on this page get consensus this will be redundant to them, if they don't then I can't see the point in spending more time developing a more complicated and drama-laden version of the same thing. Also per WTT et al. Thryduulf (talk) 09:16, 20 April 2023 (UTC)

  I mostly support because I hope the new process will be less drama-laden than turning every discussion about the block of an admin into a desysop discussion happening in an undefined location (the user's talk page? ANI?) under undefined rules. —Kusma (talk) 09:33, 20 April 2023 (UTC)

• Oppose, essentially per Barkeep49, S Marshall, Worm That Turned, though support in principle for a future time and place. Every proposal for a fully worked-out community desysop has failed. Part of the problem is that all sorts of alternative proposals come up, and we get lots of partial support for them. But with everyone tugging in a different way, nothing gets done. Every single time - absolutely nothing. So, while we have a couple of clear and simple proposals going here, please let's not derail things yet again. I say let's see how the simple proposals here work out, and then revisit a full community desysop proposal at a future time. Ideally, I'd like us to have a full community desysop. But if we try it here and now, I think it's almost certain that the only achievement will, yet again, be nothing at all. We've tried running too many times. We need to walk first, one step at a time. Boing! said Zebedee (talk) 10:07, 20 April 2023 (UTC)
• Oppose - it's not like it's been eons since the last time we went through this. So oppose per Worm et al. Also, functionally all RfCs are intended to be binding, so not sure what that was intended to add. Nosebagbear (talk) 10:13, 20 April 2023 (UTC)
• Support, though I am not sure we will end up with anything, like the last trillion times. Stifle (talk) 10:16, 20 April 2023 (UTC)
• Support, but I will not be volunteering to run it. :D Valereee (talk) 11:05, 20 April 2023 (UTC)
• Oppose, am swayed by Barkeep49, S Marshall, Worm That Turned and Boing! said Zebedee. Hiding T 11:23, 20 April 2023 (UTC)
• Support - a simple statement with the backing of consensus, affirming at a high level that the community desires a community desysop process. We always start with a proposal, then figure out what problems it solves, then ask if we actually want to solve those problems. Of course they fail, we're doing it entirely backwards. We need a discussion or process to flesh out what the problems are that the community wants to solve, and really only then can we constructively discuss how to solve them. But the first step of all is to determine whether or not the community actually wants such a process at all. I mean, I think it's pretty clear from the years and years of discussions and proposals, but I don't think we've ever really formally asked. Ivanvector (^Talk/_Edits) 11:53, 20 April 2023 (UTC)
• Oppose perversely because it's to easy to oppose. Making a swiping change that gets a majority agreement is extremely hard, because different groups will oppose different parts. Maybe if the community was split into two simple groups (as some editors appear to beleive it is) then it would be possible to get a 51% majority victory. But realistically getting a majority of editors to agree on such a big change is like herding cats. Incremental changes like those already suggested are much more likely to succeed. The recent inactivity requirements are a good example. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:58, 20 April 2023 (UTC)
• Oppose as pointless. The community has the power already to start such an RFC. No need to re-affirm what we could already do. If an editor or group of editors wishes to workshop an idea that might have a chance of gaining widespread consensus, they can just do so. They don't need a special RFC to empower them to do so. The barrier is not that proposals aren't made; the barrier is that no such proposal has gained consensus. --Jayron32 12:05, 20 April 2023 (UTC)
• Support I sympathize with those who object that this will preempt the proposals above, but realistically the only proposal above likely to pass is the one about desysopping a sitebanned admin, and that's honestly a pretty redundant proposal since a desysop in that case would be inevitable anyway. LEPRICAVARK (talk) 13:50, 20 April 2023 (UTC)
• Oppose in this context, where it is presented an alternative to the more specific process changes that are already under discussion. --RL0919 (talk) 15:40, 20 April 2023 (UTC)
• Hesitant conditional support. Contra several respected colleagues above, I don't see why this would derail the above proposals, which I also support: but for the sake of clarity, my support is conditional to this proposal not overturning consensus on the previous two. As to the rest, I'm hesitant about the "binding" bit; I don't want us to end up stuck with a bad proposal because nothing better reached consensus in a binding RfC; but I suppose I trust that our general opposition to change that is not fully thought through will handle that. Vanamonde (Talk) 16:26, 20 April 2023 (UTC)
• Oppose this is somewhat pointless, since there is nothing stopping anybody from starting an RfC or making a proposal on the subject anyway. Unless it's supposed to mean that we have to establish a community desysop process and the RfC is just to establish what it will look like, but I don't think that's a good idea. While community desysop is a good idea in theory a lot of the proposals end up being rather susceptible to lynch mobs and will probably make things worse. Hut 8.5 18:35, 20 April 2023 (UTC)
• Support Yes, this would also work. - Who is John Galt? ✉ 21:35, 20 April 2023 (UTC)
• Oppose. The lack of consensus in previous discussions about this, combined with flare-ups in drama in some high profile admin misconduct cases, lead me to believe it is best to leave desysopping for cause to Arbcom. That's a process that we've shown works reasonably well in cases of egregious misconduct. I would be much more inclined to support term limits on all admins in some way (e.g. reconfirmations after x years), with some sort of protection against grudge-bearing etc., since that would work better against the (perceived) issue of out-of-touch admins throwing their weight around on the boundaries of what they can get away with. Martinp (talk) 12:17, 21 April 2023 (UTC)
• Oppose per Sandstein and Boing!. I'm not sure what problem we are really solving and it seems unlikely that another RfC would actually lead to anything useful. Galobtter (talk) 21:53, 24 April 2023 (UTC)
• Support Fuck it, I think such a process is inevitable, and "something is better than nothing" here (even with the risk of action bias). – John M Wolfson (talk • contribs) 23:28, 24 April 2023 (UTC)
• Oppose: I'm fine with "the development of a community based process for removing administrator rights for cause outside of the current arbitration committee procedures", but the RfC the proposal asks for is happening here already. I'd especially not want one to be held if one of the above proposals already passes. ~ ToBeFree (talk) 07:31, 25 April 2023 (UTC)
• Support in principle, pending enough detail to make a more informed comment. Certes (talk) 10:16, 25 April 2023 (UTC)
• Oppose That's right, I would like this process to open another process to gain another process. Process? talk to !dave 12:17, 25 April 2023 (UTC)
• Weak support It would be better to focus the effort on giving more routine review and feedback such as tuning up and taking the poison pills out of WP:Administrative action review. Arbcom can handle the rarer severe desysop cases. But I 'spose it would be good to have some community route in place. And also to methodically decide on and float optimum proposal in order to resolve this question. North8000 (talk) 12:43, 25 April 2023 (UTC)
• Support I don't see why this has to be an alternative, but yes it is a good idea. I can't think of a reasonable reason to oppose this, as clearly there needs to be an easier way to put the brakes on misbehaving and unfit administrators. Figureofnine (talk • contribs) 15:55, 25 April 2023 (UTC)
• Oppose. My view is that the current process works sufficiently well. In other words, there is no need to develop "a community based process for removing administrator rights for cause outside of the current arbitration committee procedures". The proposal is not clear in describing what ways the current process is deficient, other than merely saying we want an alternative. Mz7 (talk) 21:33, 25 April 2023 (UTC)
• Oppose. As others have noted, it's not clear that there is any actual pressing problem (or any consensus that there is a problem) that we need to find a solution to. People should certainly continue to feel free to propose any bright new ideas that they have, but if there isn't a consensus for any of these proposals it's hard to see the point of an additional binding RfC. We'd just be progressing from one round of policy churn to another. -- Visviva (talk) 22:13, 25 April 2023 (UTC)
• Oppose. Please god no, no more RfC-trainwrecks. – Joe (talk) 04:19, 26 April 2023 (UTC)
• Oppose Our current process of removal of administrative tools works just fine. Lightoil (talk) 08:42, 26 April 2023 (UTC)
• Oppose per most of the above and WP:CREEP. Still a solution in search of a problem. -Ad Orientem (talk) 21:11, 26 April 2023 (UTC)
• Oppose, as unnecessary, a solution in search of a problem. There is precisely zero evidence that the current arbcom desysop for cause process is insufficient and somehow fails to remove admins who should be removed because of abuse/misuse of admin tools. I would support some version of term limits for admins, requiring a reconfirmation RfA to retain the tools, but that's very different from a community desysop for cause. Nsk92 (talk) 23:02, 26 April 2023 (UTC)
• Support, iff it includes Extraordinary Writ's option. Make it binding that the most supported option gets a six-month trial. Otherwise, this proposal is just the status quo, per Jayron32. DFlhb (talk) 16:41, 28 April 2023 (UTC)
• Strong support. Desysops should need not be taken all the way up to ArbCom. Even if the 2nd RfC doesn't develop consensus, change should still hopefully come per WP:BARTENDER. I support EW's option, but that should be discussed in the 2nd RfC. CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:56, 28 April 2023 (UTC)
• Oppose You don't need an RFC about having an RFC. If you have a proposal that you think might actually get support, just propose it. If you want to workshop it first with like-minded people (good idea), go ahead and do it. The problem in the past is that no one has been able to come up with something that actually gets consensus, not lack of will to talk about it. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Weak oppose as it's unclear as to what process the proposal is referring. Does it involve the community as a whole or established users? Furthermore, what "cause" would require for the community's input to desysop an admin? I feel desysop as part of a block then reaching to RFA to restore rights is the right process. I find this proposal unclear and vague, so I oppose for now as per Anomie above. Callmemirela 🍁 18:11, 29 April 2023 (UTC)
• Strong support - This is a proposal I can get around. I'm an advocate for a community-based desysop process without the explicit need for arbcom and this is a great start to initiate such a policy. The community should absolutely have a say and an opinion on site administrators who get to stay or go. — That Coptic Guy^{ping me!} (talk) (contribs) 20:44, 29 April 2023 (UTC)
• Oppose I have limited confidence, that an abstract RfC will actually lead to a clear outcome. I would rather ratify specific/limited recall processes, regardless of whether they're a step in the right direction or not, and shift the goal post to improving those policies instead of...inevitably...waiting for another perfect RfC proposal to come along. This is our chance and we should seize it. ~ 🦝 Shushugah (he/him • talk) 22:53, 27 April 2023 (UTC)
• Support failing the other two proposals above, this sounds like a good idea. Aasim - Herrscher of Wikis ❄️ 16:17, 4 May 2023 (UTC)
• Very strong support. I don't mean to sound hyperbolic, but I'm genuinely a little mystified by the number of "solution in search of a problem" takes on this rather non-specific proposal. Without question, the occasional need to take the mop back from a community member entrusted with it is an unfortunate but unavoidable concern, so the "problem" is very much concrete, and the specifics of how this process is handled have significant impacts. The only question, therefore, is whether we want this task to be the exclusive purview of ArbCom, and whether such an arrangement is the most rational and efficient state of affairs.
  As to the first part of that question, I've always gotten the impression that the community was widely supportive of a parallel process, but the more principle point is that I think it just makes good sense. I see no inherent problem with ArbCom continuing to do much of the heavy lifting in this regard, but I see no compelling reason why the community at large, with it's broader and more generalized mandate, should not have a detailed and agreed-upon process for quickly arresting problematic actors who managed to squeek their way into advanced tools, or were simply granted them in a more anarchic phase of the project's history.
  These may be relatively rare scenarios, but the damage that can be done to community cohesion and morale when the wrong personality is capable of abusing advanced permissions is significant, and in brightline cases, a laborious ArbCom brouhaha should not be the only option. Being entrusted with the bit should make a community member more inherently open to scrutiny, not for some reason suddenly unanswerable to the mere plebs who are also the sole source of that status (and the only ones who, as an institutional matter, can invest them with those tools in the first place). For a project based so fundamentally on the collective will of the community, in certain areas we sure have built up some fairly oligarchical twists to our systems, and this "the people we vote into advanced tools can only be stripped of them by the general agreement of just twelve community members" rule is one the most perplexing and irrational, in my opinion.
  So, as I see it, we're well past time to agree to a way forward for what is clearly something that is within the broader community's remit, and I think the real issue is figuring out a process which requires a robust community support for such CBAN-adjacent desysops, such that they don't take place unless there is support on a similar scale to that required by RfA itself. That is to say, so there is parity between community will for removing tools and the consensus needed to grant them in the first place (or something at least in the same ballpark). That can and should be an exhaustive and carefully-considered debate, but the question of whether the community should be able to exercise its prerogative on who can retain tools in the first place is, in a word, silly: with few caveats, every a priori principle of process on this project arises from community consensus--by quite conscious design and as a fundamental principle of the project. And even in this specific area, it's clearly that same broad community mandate which has the sole prescriptive function for investing these tools. So how can the broader community possibly lack the stature to remove those same tools in cases of abuse? SnowRise ^{let's rap} 09:52, 10 May 2023 (UTC)

Consensus for some sort of community desysop process has existed since 2019. The problem is that no one has been able to come up with a specific process that was able to gain consensus. Anomie⚔ 11:53, 10 May 2023 (UTC)

Sure, and to be honest, it's not surprising that there has been difficulty in nailing down the details of a specific procedure for that purpose. On the one hand, nobody wants a slapdash process for such an exceptional measure as desysop, and on the other, when it comes to community sanctions, there's reasons why the general community doesn't quite care for more structured and formulaic processes like those employed by ArbCom and AE. Finding a solution that both threads that needle and gets broad community support is unsurprisingly not the easiest thing in the world.

Still, I don't see how throwing our hands up in resignation can be considered a solution, and any oppose !vote here based on past difficulties is really missing the point, and abdicating our responsibilities for no concrete gain beyond a declaration of frustration, imo. Of course, no strawvote would be required in order for anyone to make a more concrete proposal for such a process at any time. But, realistically, because there were already proposals above at this moment in time, any additional proposal made in the near future would likely face calls for a procedural close because "we just talked about this".

So if I interpret the purpose of this alternative proposal correctly, it is to keep that door open by creating a clear community mandate to hash this issue out once and for all. Because it will be a real pity if the other proposals above lead to a procedural block on discussing the more general notion of a community desysop process in the near future. Because as you say, this general notion does have broad community support, even if we haven't been able to come to an agreement as to the particulars. So opposing just because of the past failures of particular groups of editors is not a particularly well reasoned-stance as regards whether the matter still warrants attention. SnowRise ^{let's rap} 05:56, 11 May 2023 (UTC)

• Support Actually for the same reason Jayron opposes, the only difference being I think editors do need to be reminded. I also find it hilarious to see opposes (to something that would potentially result in a genuine solution to the core issue) from admins who supported the complete non-solutions above (that are no solution to anything). Its almost as if Admins dont want their tools removed by the people who gave them. Who would have guessed at the conflict of interest there... Only in death does duty end (talk) 11:45, 10 May 2023 (UTC)

Discussion (Alternate proposal: the community supports development of a de-sysop process)

Isn't this just restarting WP:DESYSOP2019 and WP:DESYSOP2021? Galobtter (talk) 02:25, 20 April 2023 (UTC)

Yep, I thought we already reached this "consensus in principle" in DESYSOP2019. Personally I think the only way to break the logjam would be to add "if there is no consensus in the binding RfC for any one proposal, the proposal closest to gaining consensus will be implemented for a six-month trial" to the end of Tony's proposal above, but I'm well aware that there'd be plenty of resistance to that. Extraordinary Writ (talk) 02:36, 20 April 2023 (UTC)

Not really - a 4 year old consensus doesn't establish ground for acting now. I see this more in line with WP:RESYSOP 2019 and the initial principles RfC that established it. The method I proposed for DESYSOP2021 was me one person (me) coming up with a proposal. This would establish the principle, and then direct a RESYSOP2019 style RfC be held to implement. Re-establishing the consensus as a whole is useful, and then directing that a multi-proposal RfC is to be held paves the way. The multi-proposal/statement method tends to work better in these type of cases. TonyBallioni (talk) 02:41, 20 April 2023 (UTC)

I think WP:RFA2021 shows why that doesn't work, though: everyone puts forward their pet proposals, the discussion gets so long that nobody but the diehard policy wonks will take the time to wade through it, and we end up with no consensus. I don't really know what the solution is (maybe it's a brainstorming RfC followed by two or three well-thought-out proposals?), but I just find it hard to see a large multi-proposal discussion getting us any closer to consensus. Extraordinary Writ (talk) 02:59, 20 April 2023 (UTC)

Yeah, but the craziest proposals tend to not get enough support to have consensus, and are usually the later ones proposed. RFA2021 also had the problem (imo) of being about too many principles rather than a single one, and of being an RfC where some people (myself included) didn't participate because no one thought that substantive changes to things that were not RfA would be proposed there.

The differing statements method works well when you have a clearly defined controversial issue that there's agreement something should be done about but no one proposal has received consensus in the past. Things surrounding removal and return of permission is one of them where its worked in the past, imo. TonyBallioni (talk) 05:45, 20 April 2023 (UTC)

Resysop 2019 worked because once the first consensus was found, that it should be tightened, there was a somewhat limited number of ways so consensus could be found. I absolutely agree with EW that this is far more likely to turn into RFA21 where people opposed to community desysop will find flaws with every proposal, not in bad faith but because they genuinely have issues with the concept, as will people who are actually concerned about some specific of that proposal. Best, Barkeep49 (talk) 07:37, 20 April 2023 (UTC)

And there'll be people who don't participate in this RfC, who will then turn out to obstruct anything that by some miracle passes. If WP:RFA2021 didn't teach us that this format doesn't work, WP:ACAS should have. – Joe (talk) 04:39, 26 April 2023 (UTC)

Yeah that's a second reason Resysop 2019 worked: It didn't require on consensus to implement. Rather it empowered (required) a specific group of people to act so people who were unhappy with the result couldn't create a WP:LOCALCONSENSUS during implementation. Best, Barkeep49 (talk) 14:52, 1 May 2023 (UTC)

Yeah, let's not fall into the politician's fallacy, requiring that "something" be done just because it's something. Anomie⚔ 14:56, 29 April 2023 (UTC)

• I wrote up WP:RRA awhile back. It's a process for the community to review an admin's actions and potentially remove the tools. It was designed to reflect and work with all the current policies/processes. If there's interest, I'm happy to start an RfC on it. - jc37 04:49, 20 April 2023 (UTC)
• If finding a good process were as easy as telling the community to come up with a process, we would already have come up with a process.... Dekimasuよ! 13:18, 25 April 2023 (UTC)
• What is this meant to actually achieve? Say there is consensus for this proposal: what then? I don't see how this gets us any closer to coming up with an actual workable implementation of community-based desysop which can in fact gain consensus. Caeciliusinhorto-public (talk) 15:28, 25 April 2023 (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.

Admin block history

I was curious how often admins get blocked, so I did a little data mining. I parsed all the per-year subpages of WP:Successful requests for adminship for account names and pulled all their blocks from the logs. I'm sure there's edge cases I didn't handle correctly; any admin who was renamed won't be handled correctly, for example. And I made no attempt to figure out of the blocks happened while the user held the sysop flag. But it should give you some idea of how often it happens. See User:RoySmith/admin-blocks. -- RoySmith (talk) 18:09, 20 April 2023 (UTC)

@RoySmith Your list currently makes no distinction of blocks vs unblocks, just if it was in the log. Is there a way to check that? Or at least, note the change properly instead of marking unblocks as "indef" Soni (talk) 18:14, 20 April 2023 (UTC)

Good point. I uploaded a new set of results, with the unblocks filtered out. -- RoySmith (talk) 18:38, 20 April 2023 (UTC)

Thank you for this great data. I know it took time, and I appreciate it. How many of these are mistakes? Many admins have accidentally blocked themselves. In the admin interface a block link appears next to every username, including one's own. What about mistaken blocks like this bonehead move which I reversed? Clicked wrong link. What about admin accounts that get blocked after the account no longer has admin rights (the unfortunate downward spiral some have experienced). I think the number of long blocks on current admins is so small that it can be handled bespoke by ArbCom. Jehochman ^Talk 19:27, 20 April 2023 (UTC)

@RoySmith thanks for that, but would it be possible to get it in a table format so it can be sorted by other things than just username? Maybe also filter out blocks with a duration of less than 1 day (most likely tests) or which were reversed after less than a day (more likely errors)? Thryduulf (talk) 19:36, 20 April 2023 (UTC)

No good deed goes unpunished :-) I'll see what I can do, but I was hoping not to turn this into a major project. The script that does this is 24 lines of python that calls the pywikibot library. If there's any pyhonistas who want to hack on it, it's at https://github.com/roysmith/rfa-stats/blob/main/go.py -- RoySmith (talk) 20:01, 20 April 2023 (UTC)

RoySmith As Thryduulf says, you'll want to ignore admins blocking themselves. It's unlikely to happen these days as Special:Block is far more user-friendly, but it used to be embarrassingly easy to make that mistake, as I have ... twice. Black Kite (talk) 20:32, 20 April 2023 (UTC)

I was "this close" to writing the perfect Quarry Query for this, except my query both started sputtering in the middle bad, as well as having no clear way to handle short term blocks (like 30d etc).

Otherwise I would have just done some form of "Sum of unblock timestamp - Sum of block timestamp" to figure out how long people stayed blocked for. (probably like Now - Unblock timestamp or something using DATEDIFF).

Anyway, I pasted the query link, just in case someone optimises the final bits enough to make it consistently work below 10 mins. Then we can get a CSV of everything we need + summaries (block/unblock times for each admin etc). Soni (talk) 21:39, 20 April 2023 (UTC)

Ha! I was literally blocked one time, for one minute, in 2009, just to get my attention when I was on an AWB run. I imagine this was in the days before AWB would automatically stop when you got a talk page message. BD2412 T 21:49, 20 April 2023 (UTC)

I was blocked for WP:NOTHERE. -- RoySmith (talk) 22:20, 20 April 2023 (UTC)

From the timing I'd have to think this was an April Fools joke. BD2412 T 22:53, 20 April 2023 (UTC)

Worth pointing out, I know admins used to block each other to test how it worked and also for fun way back when. Hiding T 22:42, 20 April 2023 (UTC)

Gathering the data was a good idea, but unfortunately not filtering for whether the user was an admin at the time is an issue also. There are users with multiple blocks after they were desysopped. --RL0919 (talk) 23:16, 20 April 2023 (UTC)

1,882 admin blocks? Wow, way more than I thought. For some reason I had the idea that admins blocking admins was rare. –Novem Linguae (talk) 04:34, 21 April 2023 (UTC)

That's not really an accurate figure. Circa 277 are explicitly tests (include the word "test"), another circa 35 are for wikibreaks and the data also includes errors and blocks from before and after the blockee was an admin. Even then as the data goes back to December 2004, and almost all of them were over a decade ago:

Year	Blocks
2004	10
2005	324
2006	376
2007	299
2008	195
2009	122
2010	112
2011	76
2012	37
2013	38
2014	27
2015	51
2016	31
2017	32
2018	47
2019	33
2020	18
2021	27
2022	26
2023	1

Figures found using find and replace, so may not be completely accurate. The one block this year was Barkeep49 partially blocking Geometry guy from WP:BN for 31 hours, after they were desysopped for inactivity. There is no easy way to see how many others were partial blocks. Thryduulf (talk) 09:49, 21 April 2023 (UTC)

I've now looked at all the entries on that list from 2022:

• 9 were of former administrators (7 different blocks)
• 6 were testing (3 editors)
• 5 were mistakes (3 editors, Materialscientist managed to accidentally block themselves 3 times)
• 1 was a compromised account, subsequently resolved
• 5 entries relate to Athaenara who was subsequently desysopped (see Arbitration case)

details of blocks of (former) administrators made in 2022

Former administrators: 1 72-hour partial block for edit warring (William M. Connolley, desysopped by arbcom in 2009) 1 self-requested block after resigning as an admin (AustralianRupert) 1 block (2 entries) indef ("WP:BLOCKNAZIS"), followed by community ban (Bedford desysopped by Jimbo in 2008) 1 block (2 entries) for 12 hours for violating a community sanction, talk page access subsequently revoked (BrownHairedGirl, Desysopped by arbcom in 2020) 1 indef partial block from 1 page, overturned at ANI after ~3 hours (Fram, desysopped in 2019) 1 indef partial blcok from article and draft namespaces for copyvios (Gryffindor, resigned adminship in 2018) 1 24-hour block for edit warring (Kwamikagami, desysopped by arbcom in 2012) Testing blocks: 3 1-minute self-blocks for testing purposes by Cryptic 2 blocks of own alt-account (that was the former main account) for testing purposes (1 indef unblocked after 2 minutes, 1 24-hours unblocked after ~90 minutes), AmandaNP/DeltaQuad 1 self-block for testing by Samwalton9 Mistakes: 1 mistake fixed after 7 minutes (Izno blocked L235 when attempting to block a vandal on L235's talk page.) 3 mistaken self-blocks by Materialscientist, all reversed after 0-1 minutes. 1 mistake fixed after 2 minutes (Gadfium blocked RoySmith when attempting to block someone else) Other: 1 compromised account (Staxringold) 5 blocks of Athaenara who was subsequently desysopped, see Arbitration case

Thryduulf (talk) 10:43, 21 April 2023 (UTC)

@Thryduulf: I'm not sure what of my actions is being questioned or talked about here. If you need some sort of response from me, please ping again with some additional clarity. Thanks, -- Amanda (she/her) 22:48, 21 April 2023 (UTC)

@AmandaNP: none of your actions are being questioned. This is just a factual list of all the times an account that has or had the admin bit was blocked in 2022 (I've improved the formatting to hopefully make that clearer). Your testing blocks (like the other testing blocks) were completely unproblematic. Thryduulf (talk) 23:00, 21 April 2023 (UTC)

Next time you might use the "noping" template as it links to the username without actually pinging them, since a ping could indeed be considered equivalent to "explain yourself." ⛵ WaltClipper -(talk) 17:46, 23 April 2023 (UTC)

If you do get the information to exclude test, self, and AFD blocks, it would be interested to see which admins placed the most such blocks. Jclemens (talk) 04:33, 25 April 2023 (UTC)

I've looked through the list above and the following is a summary of all the blocks of then-current administrators since 2019 (I've run out of time to look further now