Wikipedia:Requests for comment/2019 community sentiment on binding desysop procedure

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

No consensus

TL;DR version: There is wide-spread support for an alternative desysoping procedure based on community input, but does not involve ArbCom. (For example, opening a specific form of discussion on WP:AN/I.) However, except in the case of inactivity there is no clear consensus over what this alternative should be.

Long version: There were a number of themes in this discussion worth noting:

• The only process currently in use that doesn’t involve ArbCom (or resignation) is based on inactivity. (Note: there is an ongoing discussion at the Village Pump about adding another criteria for inactivity. This RfC closure does not modify or effect its outcome.)
• The current process of desysopping an admin is perceived by some as being unnecessarily difficult.
• Some participants at WP:RfA routinely vote against nominees based on the assertion "it’s too hard to desysop an admin". The validity of this assertion was questioned, but not seriously debated. (Note: It has become something of a cliche to state that the process to become an admin is broken.)
• Concern about Admins being harassed for making tough or unpopular calls. (Related to this is that not all admins are 100% confident they made the right decision 100% of the time.)
• Similar to this is the desire to avoid WikiDrama in any desysopping process. It was claimed that opening a case with ArbCom leads to WikiDrama. (Note: WikiDrama exists elsewhere on Wikipedia. For example, threads at WP:AN/I have been known to grow to enormous lengths. The discussion at WP:FRAM is not the only one that, when concluded, was longer than most novels.)
• The desysopping processes at other Wikimedia projects were described, but what works (or doesn’t work) at other projects may not work here.
• The option of requiring admins to be re-confirmed periodically was mentioned, but did not attract any attention that I could find. (This has been proposed in the past.)
• There is a desire for the community to handle problematic admins directly without needing to start a case at ArbCom; the community should be able decide matters like this. Use of a discussion at WP:AN/I was mentioned more than once. ArbCom is a powerful, but often slow-moving process. (Note: this closer admits he would welcome some community-based alternative to ArbCom, but believes that until consensus emerges about what it should be, no community-based one exists.)

Despite all of the comments, no suggested community-based desysopping procedure gathered enough support to be favored by a clear consensus. It was admitted that without some formal process, any community-based procedure could be gamed, & any admin who made an action that was best for Wikipedia yet angered a given group (e.g, Church of Scientology) could still be targeted through it. Any attempt to address this vulnerability complicated the procedure. The result were proposed procedures that, frankly, seemed to be more complex than starting a case at ArbCom, & still offered no guarantee of protecting admins who made difficult actions, let alone reduced WikiDrama, better than using ArbCom. Still, the hope persists.

Useful pages related to this topic: Wikipedia:Removing administrator rights, Wikipedia:De-adminship proposal checklist

Previous discussions are listed at Wikipedia:Requests for de-adminship -- llywrch (talk) 22:51, 23 January 2020‎ (UTC)

---

Should there be a binding community desysop procedure? 00:30, 18 October 2019 (UTC)

During the RfC at Wikipedia:Requests for comment/2019 Resysop Criteria (2), Rhododendrites began a thread in the General Discussion section titled "Is it worth revisiting a universal recall system?". After a day of positive discussion, Wugapodes proposed a 16th statement to get wider feedback from participants on whether a binding desysop procedure should be explored. A number of editors at the RfC and at a subsequent Administrators' Noticeboard discussion opined that the statement was out of scope and should be considered separately. Pursuant to the desire for a wider sense of the community from both those in favor and those opposed, the statement has been spun out to its own request for comment.

Editors are asked to give opinions on the following question:

Should there be a binding community desysop procedure?

Goal

The goal of this RfC is to determine community sentiment on binding administrator recall and compile the concerns and desires of editors regarding the removal of administrator privileges. It is not binding, nor is it a proposal. As administrator recall is a perennial proposal, any hope for success requires that consensus has changed on the matter. The results of this discussion will help those interested in building consensus for a binding desysop procedure understand whether the community wants such a system and how to draft proposals that are in line with community sentiment.

Procedure

This RfC asks a single question. To avoid the problems of straw polls and foster discussion, editors are encouraged, but not required, to provide their opinions without bolded statements of "support" or "oppose". Threaded discussion can occur in response to a statement, and meta-commentary can be made on the talk page.

Discussion

October

• At the resysop RfC, Xeno linked to a discussion with Risker (among others) that changed their mind on a binding recall system. I found the discussion interesting to read. The point on viewing ArbCom as a community process is interesting, but think there is a difference between a lightweight and heavyweight desysop procedure. I think issues around resysoping are really covertly issues about desysopping. The closest community controlled process (Risker's arbcom point notwithstanding) is inactivity requirements, but those are easily circumvented and even when enforced can be undone by request at BN without much community input. Since it's the only lightweight desysop method, and discussion on other desysop measures are usually non-starters, narrowing resysop policies becomes a proxy for widening desysop policies.
  I worry that the harm from the individual recalls may outweigh the benefits of a community desysop procedure. I commented elsewhere on how discussions about people can eat up a lot of resources and quickly degrade into unhealthy conflict. I think that's rightly a common fear, but I also wonder how accurate it is since we've never really tried a binding procedure. I think part of the desire for a community desysop procedure isn't to use this process on abusive admins (ArbCom may in fact be the best process we have for those instances) but rather to have a more nuanced evaluation of what admins are still engaged enough in the community that their access to the tools is a benefit. Admins who log in once a year to make an edit so that they keep the tools clearly aren't here to build the encyclopedia, and that's fine. People and interests change. I think a process by which the community can tell a squatting admin "thanks for all you've done for the community, but you've clearly moved on and we'd like to let you move on" could actually be healthy. No prejudice against rejoining the community or regaining the tools once its clear the editor has returned and gained trust of the current community. The editor gets to leave, the community doesn't need to get into fights at BN over resysops, and the community can handle the merits of de- and re- sysops on a case-by-case basis. Arbitrary thresholds aren't very productive because they capture stuff we want and don't capture stuff we don't want. I think that's the problem with current inactivity thresholds and why we're focused on an c2:AntiPattern of new arbitrary thresholds for resysoping. (Adapted from my comment at the resysop RfC) Wug·a·po·des​ 17:43, 16 October 2019 (UTC)
• Yes. More or less what Wugapodes says above and what I said at the resysopping RfC. We need a mechanism for removing admin tools other than arbcom. We have for a long time. There are multiple ways it could be implemented. The one that makes the most sense to me is to base it on the Commons system (which is not to say copy it exactly). Basically, there's a noticeboard thread to determine whether there's consensus to start a request for deadminship, and the structure of the latter look similar to an RfA. Lots and lots of details to be worked out, and this is just one of many possibilities, but I feel strongly we need to try something. I appreciate the concerns about vexatious and/or time-consuming threads, but simply don't believe the problem is big enough to outweigh the good such a system would do. If this preliminary RfC results in interest in some form of procedure, perhaps we could implement it on a trial basis for a period of 12 months to see if the benefits outweigh the costs or not. — Rhododendrites ^talk \\ 00:47, 18 October 2019 (UTC)
• Yes, based on the Commons system. The German system is too complicated. Many other systems are too simplistic to avoid mob justice. GMG^talk 00:52, 18 October 2019 (UTC)

  To clarify, with more time and coffee, the essential element of the Commons system I refer to is that there must first be a consensus for the desysop discussion itself. The normal consensus building process is robust enough to protect against gaming, off-wiki collusion, bad-faith grudge holding, etc. We also naturally adapt the process in other ways. For example, in particularly complex and controversial discussions, the community fairly naturally decides that a panel of closers will determine consensus rather than a single person, or we routinely close repeatedly opened discussions on the same subject which are disruptive. If there is serious doubt about the legitimacy of the consensus, then it gets kicked over to crats, who may unceremoniously close an open re-RfA if they determine impropriety. If we wanted to go further, we could require that a crat (or crats) be the one to close the consensus discussion itself, and open the deadmin. This could protect against things like trying to game the timing, where crats should make a good faith effort to ensure the user is notified.

  The essential elements of the German system I refer to are over-prescriptive minutiae: x number of editors, y number of days, in z time-frame, not to exceed a or b. Such a system tries to protect against gaming, but it actually encourages it, because users who are legitimately gaming the system can simply plead that they've stamped their forms in triplicate as instructed, and they're just following the overly prescriptive rules. (It's much the same problem we have with our own inactivity and resysop requirements. "I was just following the rules, and making exactly one edit per year as you told me I should.")

  Alternatively, a system like Wikidata requires no pre-consensus whatsoever. A system like Wikiquote simply requires a set number of editors supporting a re-RfA with no need for the discussion to form a consensus. I consider both these to be entirely overly-simplistic for serious consideration here. Pretty much all systems use a standard of 50% for the re-RfA discussion, intentionally lower than for the initial RfA. The English Wikipedia is unique (AFAIK) in applying a discretionary range, and so there are no other examples of how this might be applied to a deadminship discussion. GMG^talk 10:45, 18 October 2019 (UTC)

• Yes, based on the Commons system. Community consensus can promote an administrator, and I don't see why a change in community consensus shouldn't be able to demote one. Vermont (talk) 01:07, 18 October 2019 (UTC)
• Yes, using the Commons system. We likely could have saved multiple lengthy arbitration cases if the community could revoke sysop status. People say that it's "not a big deal," but when the process to remove is much, much more difficult than to give, then it *is* a big deal. CoffeeCrumbs (talk) 01:26, 18 October 2019 (UTC)
• Yes, based on the Commons system, per Vermont. A request for de-adminship, sufficiently advertised, ought to avoid the usual problem with desysop procedures: that an organized group of editors (say, on one side of a contentious content issue) could take the bit from admins with whom they disagree. At the very least, we could trial this and see where it goes. Enterprisey (talk!) 01:30, 18 October 2019 (UTC)
• No. This RfC is malformed because the pollyanna question asked has a natural answer of why not?. However, the issue boils down to the precise mechanism. Commons is totally different from the English Wikipedia (enwiki). Life at Commons is generally straightforward. By contrast, enwiki is the number 1 website where anyone can work to influence public views on issues ranging from sex to politics. Further, while spammers would like a link anywhere, they try particularly hard to promote their products at enwiki because that is where readers will see them. We need admins who specialize in resisting POV pushers and spammers. Their enemies will accummulate and will generate too much hassle for the admin who can go back to handling simple queries at WP:RFPP and similar. There is no evidence of an admin abuse problem, and the small number of desysops that have occurred were done quickly by Arbcom—probably faster than would occur in a community vote. Johnuniq (talk) 01:58, 18 October 2019 (UTC)

• It's a vague question intended to host discussion of why or why not or how. Yes, it boils down to a precise mechanism. By saying no, you are saying there does not exist a mechanism that would help Wikipedia. That's accurate? Affirming "adminship is a very big deal" / life appointment (outside of the very rare trip to arbcom)? Beyond that, if the POV-pushers/spammers can muster enough votes to push something as well-attended as an RfA in a particular direction, we've already lost that battle. Likewise if bureaucrats who close the RfA cannot tell the result is due to grudges from spammers and POV-pushers (who have somehow avoided being banned), we have already lost. These are hypothetical worst case scenarios. Why not go with a trial period to see if anything like this actually happens. — Rhododendrites ^talk \\ 02:48, 18 October 2019 (UTC)

• To those suggesting the Commons system, it is said to be used when the community feels that an administrator is acting against policy and routinely abusing their status - this doesn't really capture the "barely active" (unless policies are implemented to make it against policy to be barely active) - also note that the Commons procedure indicates normal standards for determining consensus in an RfA do not apply. Instead, "majority consensus" should be used, whereby any consensus to demote of higher than about 50% is sufficient to remove the admin. which doesn't seem to really be a consensus as much as a straight up vote on the numbers - a system rarely used here, except perhaps for ACE. –xeno^talk 02:04, 18 October 2019 (UTC)

• Nobody said we have to hit copy/paste on the Commons system. It comes down to some sort of discussion to see if an admin has lost the trust of the community and a well-advertised DfA or new RfA to hash that out. We can set our own specifics. — Rhododendrites ^talk \\ 02:48, 18 October 2019 (UTC)

• So a pre-discussion to ensure there is consensus for a discussion, and if so, a discussion in the form of an RfA- these are the essential characteristics of the Commons system to be adapted? –xeno^talk 03:15, 18 October 2019 (UTC)

• As I see it, yes. Initial discussion on a noticeboard of the sort we have all the time when it comes to long-term problematic behavior, complete with a closure determining whether there's consensus [that the community has lost trust in the admin / that there should be a RfD / that the admin has abused their tools / whatever other threshold we want to give it]. That process should filter out the frivolous requests. Then a separate, more structured and better advertised discussion like an RfA, which has its own set of variables, like discretionary ranges, threshold for determining consensus, etc. Personally, I don't see why it's not worth a pre-determined trial period to see how it goes, anyway (once all the specifics are hammered out, of course). — Rhododendrites ^talk \\ 04:03, 18 October 2019 (UTC)

• I would not support a procedure "based on the commons system" or indeed any other. The Commons system appears to be little better than a popularity vote, with several requests in the archive that were allowed to proceed to a vote based on trivial matters or matters unrelated to the admin bit, and indeed with some dangerously close votes. Admins should not be like politicians, always watching their words and stepping cautiously, afraid of the next election. ArbCom's ability to review administrator misconduct alongside the existing emergency desysop procedures are sufficient. ST47 (talk) 02:25, 18 October 2019 (UTC)
• Yes. No. I firmly believe that admins should be able to pass an RfA at any time. – bradv🍁 02:31, 18 October 2019 (UTC)

  I've been thinking about this all day, and reading the comments from the other participants below, and I have to take back part of my comment. Basically, I can think of three reasons why we may want to remove someone's administrator rights: 1) inactivity, 2) misconduct, or 3) because they're unpopular.

  For the first one, we have an inactivity policy and crats routinely remove the bit from admin accounts that aren't active. I think this policy can be improved, and there is currently another open RfC to address at least part of that problem.

  For cases of misconduct, we have Arbcom – a group elected for their judgment and a process that ensures such decisions are based on evidence. They have a low bar for hearing cases related to admin misconduct, and from the cases they have heard recently it appears the process is working reasonably well (I haven't seen any arguments here that Arbcom doesn't perform enough desysoppings).

  That leaves the third reason, unpopularity. This is the gap that would presumably be filled with a community desysop process, and I'm not convinced it would be appropriate or necessary. We don't ban people at ANI without evidence of wrongdoing, nor do we remove advanced permissions from editors simply because we don't like them. While I do believe that admins should be able to pass an RfA at any time, managing to gauge that level of trust by community vote without turning it into a popularity contest is realistically not possible. I'm convinced we should continue to refine and improve our existing processes rather than adopt a new inferior one. – bradv🍁 02:40, 19 October 2019 (UTC)

• Only if it's resilient to offwiki collusion. The commons system does not even attempt to be; contra what's been said above, it's extremely vulnerable even to a transparent, on-wiki organized group of editors on one side of a content issue. —Cryptic 03:07, 18 October 2019 (UTC)
• When you're tossing around existing practices, don't assume that everyone is going to know the specifics of each one. You need to define them if they are going to be a part of the discussion. — Ched (talk) 03:41, 18 October 2019 (UTC)
• Yes, with caution. The concerns about admins shying away from unpopular but necessary mopping are sensible, but we've gotten ourselves into a Catch-22 where RFA is too hard to pass largely since the bar for losing the bit is so high. This is depriving us of potential good admins, contributing to a perceived class inequity (admins vs nonadmins), and creating needless acrimony about precise criteria for return of the bit in particular. I'm not familiar with Commons, but a system with some sort of gatekeeper (is there a valid issue or just sour grapes?) and then a broad community discussion (same visibility as RFA) that needs to reach a genuine consensus to de-admin seems like a reasonable compromise and worth trying. We'd have to think about and possibly experiment with the details, but it's easy to brainstorm some ideas to explore, e.g. the "gate" is like some admins' (historical) recall criteria, e.g. X users (or admins?) in good standing, or even arbcom needs to refer and admin to RFdA; pretty active bureaucrat clerking at RFdA to ensure valid arguments and NPA. Basically, I have faith that with the right "graphite rods" to prevent discussion from degenerating, and the right visibility to encourage participation from uninvolved users, the power of grudgeholders could be mitigated. TLDR: I don't exactly like the idea, but I like the consequences we're living of *not* having this even less. Martinp (talk) 04:09, 18 October 2019 (UTC)
  • @Martinp: It seems that a few minutes after your comment, I added an English description of the German Wikipedia's recall system below that you maybe didn't get a chance to review. Does that system have any of the "graphite rods" you had in mind, or do you think it might inadvertently lead to a power spike? Wug·a·po·des​ 06:26, 18 October 2019 (UTC)

Thanks for posting that, @Wugapodes:. It has "graphite rods" that presumably work fine there, but I do have a bit of a concern that *here* admins performing yeoman's service in contentious areas or COI could easily accumulate 50 involved or recruited enemies in short order. So I think something based on the Commons criteria, or on some of the criteria admins used to put for voluntary recall a few years ago, might be more successful. A few crazy ideas to spur further thinking by more active, tuned-in members of the community than I am:

Crazy idea A. Any editor [meeting some baseline criteria?] can start a recall petition in a specific subpage in an admin's User Talk:. They need to outline their concern in no more than [200] words (to encourage links to unsatisfactory discussions elsewhere rather than long screeds) with reference to specific, allowed criteria like "pattern of bit misuse", "conduct unbecoming", "uncommunicative", "competence", etc. Admin can but doesn't have to respond, also in [200] words. After [7] days, if [10] [active but uninvolved] editors add (and do not remove) their support for a recall, the admin undergoes a RFdA/"Admin review" where the bit is removed only if there is consensus to remove it, i.e. no consensus = bit kept. If after the [7] days there are fewer than [10] recall supporters, the petition is silently closed, and the starter can't start a new petition [on the same admin / on any admin] for [30] days.

Crazy idea B. The endorsers of the recall, ie. gatekeepers, need to be admins....won't satisfy those who feel there is an editor/admin class divide, but would reduce frivolous/vindictive recall.

Crazy idea C. An RFdA is started only after a passed motion by ArbCom to do so [or a net-4 arb vote at RFAR?]. Sounds screwy, but the issue is now Arbcom deadmins after a long painful process with a high bar for bit removal and then a very high bar for reinstatement at RFA. This would allow for a lower-fuss and lower-stigma path of "yes, there is a plausible, not merely vindictive, concern that this admin may no longer retain the trust of the community; so let the community decide". (For clarity, Arbcom could still remove the bit for cause, as their way to resolve disputes where community resolution attempts will generate more heat than light.)

Martinp (talk) 11:28, 18 October 2019 (UTC)

• Yes, because the current system is grossly inefficient and makes a spectacle out of the user(s) in question. If the community has the authority to grant adminship, then it should also be permitted to revoke it. -FASTILY 06:23, 18 October 2019 (UTC)

@Fastily:, with specific regard to your first sentence, I'm not sure any other recall method would make less of a spectacle - quicker, but no less dramatic. Nosebagbear (talk) 08:51, 18 October 2019 (UTC)

A recall criteria that is specifically designed to minimize the spectacle might have a chance at succeeding at that, if it is invoked. I wouldn't know if my criteria would fit that bill, but when I was writing that almost three years ago (has it really been that long now?) I specifically wanted to avoid as much of a spectacle as possible if I ever fucked up and needed to be desysopped. I prefer not having my face at ANI. —k6ka 🍁 (Talk · Contributions) 13:43, 18 October 2019 (UTC)

• Not a great question because the main issue is with the details of the proposed system. If it's something along the lines of the Commons system linked to below then I'd have to oppose. The equivalent process here would be a discussion at somewhere like WP:ANI which establishes a consensus for doing something followed by another discussion at WP:RFA. Both of those are generally acknowledged to be toxic, broken processes, so I'm not sure why we'd want to make much greater use of them. Any process would have to have some sort of safeguards to protect admins who have to make controversial or difficult decisions, because otherwise admins will stop working in those areas (e.g. WP:AE). It would also make the unblockables problem much worse, because the unblockable user and their friends could get the blocking admin desysopped. The Commons system seems to be mostly used for cases which would be handled by ArbCom here, possibly without even a full case. Hut 8.5 06:54, 18 October 2019 (UTC)
• In principle I think it could be a good thing. Whether we are capable of putting together and running a reasonably practicable and acceptably fair process is the big question. Most editors who would be eligible to take part probably would not. The discussions might be excessively representative of editors who have been at the receiving end of necessary and desirable admin action in the past. It should be obligatory to declare any such conflict of interest at their first contribution to the RfDA. Also I suggest that participation should be subject to strict procedural and civility constraints with immediate penalties for contravention. Participants may be required to explain their statements. If they are not willing to do so those statements may be struck from the records. Participants should be aware that their history on WP may be scrutinised and made public, as it must be a transparent process. Details to be hammered out elsewhere. · · · Peter Southwood ^(talk): 07:39, 18 October 2019 (UTC)
• I'm somewhat inclined to agree with Pbsouthwood and some others: a good process could save a lot of aggro, but I'm not sure if we can make a system immune to mob rule. I'm creating my own recall procedure atm, but admins who work heavily in more hostile areas (Arbs and AE in particular) would seem more vulnerable even for the same level of undesired actions. Nosebagbear (talk) 08:47, 18 October 2019 (UTC)
• Yes, as a no-brainer. Mainly per everyone's comments above. There are a large number of admins and other experienced editors around - that I don't think it would be possible for a organized group of editors to get an admin desysopped just because they disagree with them, or if it isn't really justified. SD0001 (talk) 09:49, 18 October 2019 (UTC)
• Yes, I believe the larger community wants this, but there are a lot of issues to address. What would be horrific would be losing a useful admin because they'd made too many tough calls. I'm not concerned about mobs of spammers and UPEs; those votes can just be discounted. I'm more concerned about things like unblockables and their fans, or off-wiki canvassing/collusion. I definitely think !votes for recall should be required to provde compelling rationale, and possibly to disclose any conflict they'd had with the editor. I wonder if it might be worth considering requiring a crat chat and giving bureaucrats absolute discretion. --valereee (talk) 10:33, 18 October 2019 (UTC) Tony's convinced me that a community desysop is probably a bad idea. This needs to be done by Arbcom. --valereee (talk) 17:52, 21 October 2019 (UTC)
• Leaning to oppose. What I am very concerned about is state-sponsored troll gangs (about the Chinese Wikipedia, but it's only a matter of time until Xi Jinping wants to "harmonize" us), nationalist editors, cranks, extremists of all kinds, fanatics, highly persistent POV pushers, and other fringe groups. A deadminship process counted by numbers will promote a sense of insecurity for admins dealing with those editors, especially at venues such as WP:AE. Spammers and UPEs are already causing problems at AFD, AFC and NPP - with at least one even getting adminship - and it's only a matter of time before they get more organized. MER-C 10:52, 18 October 2019 (UTC)
• Strongest possible oppose We already have a community desysop system: we elect trusted community members to hear evidence and then vote on conclusions. A system that provides some semblance of fairness while also holding administrators to account and also just as importantly making it clear that the people who ask for a hearing will also have their conduct examined. All previous proposals have failed because any one that would be fair is effectively a proposal to create ArbCom by another name.
  Additionally, there is this idea that it’s easier to desysop someone via community process than via ArbCom. I disagree completely. A popular admin who misbehaves repeatedly will never be desysoped by the community. They would by ArbCom. For all it’s flaws, the ArbCom process at least attempts to give both sides a fair hearing. No other project does that. TonyBallioni (talk) 12:44, 18 October 2019 (UTC)

  It would be replicating one of committee's functions and creating a separate (but presumably equal) "Internal affairs" process. I agree with others that such a process - sufficiently hardened to protect against bad faith, trolling, score-settling, etc. - probably wouldn't solve any problems the committee doesn't already handle, and is likely to generate more community discord than a properly handled arbitration case. –xeno^talk 14:11, 18 October 2019 (UTC)

• Support I added more examples from other Wikipedias to the section below. Basically, all other major Wikipedias already have a desysop vote. The English Wikipedia's stance with this little community accountability stands out. This would also likely make some long-standing issues easier to deal with. Now all admin-related problems need to worsen until they are at the boiling point when they reach ArbCom (and before this point, admins are being baited so that something would finally break the last straw). A community desysop vote before that point would be a lot better, and if the admin would still have the community's trust, the opposers should shut up. --Pudeo (talk) 13:27, 18 October 2019 (UTC)

  Not all of them, the Russian Wikipedia does not have a desysop vote.--Ymblanter (talk) 13:33, 18 October 2019 (UTC)

  Yes, and also Polish IIRC. But...that may actually be the entire list. GMG^talk 14:21, 18 October 2019 (UTC)

• No. I disagree with that part of the opening statement which suggests that the resysop RfC is really about desysopping; i have given s support to two or three statements in that RfC on the basis that it is about what it says it's about with no hidden meanings. In addition, while i have no objection to candidates at RfA agreeing that they will add themselves to the Open to Recall category, we do actually have a means of recall/desysopping, in the ArbCom, which is not really used very often: I can't think of any currently active admin who "ought" to be desysopped for losing trust or COI or abusing the tools. Any binding desysop procedure would have to be at least as stringent to use at ArbCom is, so what would be the point? Happy days, Lindsay^Hello 14:13, 18 October 2019 (UTC)
• No. As an admin active at WP:AE, where admins sometimes need to take action against editors who are linked to well-organized offwiki interest groups, I am not convinced that the added accountability would outweigh the risk of such users engaging in offwiki collusion and gaming the system to attempt to get rid of admins they consider an obstacle. ArbCom seems to do a reasonable job of removing very problematic admins. (Which is a community desysop procedure, just an indirect one.) Sandstein 16:32, 18 October 2019 (UTC)

• It seems like there are a lot of potential creative ways to mitigate this sort of thing. Even if we assume that off-wiki coordination could be substantial enough that it would get by an initial formally closed determination of consensus and a RfD/RfA sort of discussion -- and assuming that doesn't mean that Wikipedia has become a lost cause, since the same would be true of electing admins, etc. -- couldn't we just, say, require participants of such a discussion be extended confirmed (or some other requirement)? — Rhododendrites ^talk \\ 16:49, 18 October 2019 (UTC)

• No, see the recent Icewhiz debacle. TonyBallioni (talk) 16:56, 18 October 2019 (UTC)

• I presume the part where someone tried to open an ANI thread to desysop you, and everyone immediately recognized it as frivolous and unfounded and squashed it immediately. Yeah. That's basically how it's supposed to work. GMG^talk 17:00, 18 October 2019 (UTC)

• No, it’s an example of a lunatic who had been harassing me off-wiki likely for months being impulsive and attempting to get leverage at ArbCom through a non-existent process. Any look at his ArbCom filings would show that if such a process had existed, it would have been much better thought out, and he’d likely have lined up multiple people to get it rolling fast. Sandstein and basically anyone who bothers to work ARBPIA would be massive targets from BOTH sides of that conflict. There is simply no fair way to do this that does not approximate ArbCom. And no, the fact that many other projects have broken desysop processes that open up their most dedicated volunteers to harassment does not mean we should join them. Any look at the disaster that is commons process shows this to be true. We shouldn’t try to imitate a toxic project such as that. TonyBallioni (talk) 17:10, 18 October 2019 (UTC)

• I'm still not totally sure I understand how people square this terrible horrible broken system that could never work^{That nearly everyone uses but somehow haven't found a problem with.} It all comes off a bit like an American trying to tell a Canadian how awful their socialized medicine is. GMG^talk 17:37, 18 October 2019 (UTC)

• Erm, I think you mean "that hardly anyone uses". There are hundreds of Wikimedia projects; heck, there are hundreds of Wikipedias. Formalized community desysop procedures are present on only a very small minority of those projects. Risker (talk) 01:04, 21 October 2019 (UTC)

• A technically true argument, but most of those projects are barely active. If you looked at the top 25 most active projects, you would find that most or all of them have some community desysop process that doesn't involve the local arbcom. Additionally, stewards will and have desysopped a local admin on a small wiki where there is community consensus, even if there is no formalized local policy. -- Ajraddatz (talk) 16:04, 21 October 2019 (UTC)

• Yes and no - I don't think there is much need for a broad community desysop procedure. Admins that are active and when there are concerns with their tool actions can be cased at Arbcom, I don't see that a community chat would be in depth enough to sort those really very occasional situations out. I do think that the community is very capable to have a more narrow method to remove the tools from admins that are only making minimal edits in a clear manner to simply keep the tools and whose edit history is pretty clear and so them keeping the tools has now lost the communities trust, some users with similar edit patterns will I am sure also in such a discussion retain the communities trust, a very experienced contributor that is simply sitting on his hands for example. Neither Arbcom or the Crats are in a position currently to do this and I don't really want them to. This would be a simple process without imo any drama. I partly agree with Sandstein above also, not really the part about off wiki collusion as I think we are savvy enough to deal easily with such situations but that admins editing in contentious areas would be either vunerable to revenge requests and or would just stop admin work in those much needed areas Govindaharihari (talk) 18:28, 18 October 2019 (UTC)
• The German Wikipedia recall procedure exists since 2009, with 227 recalls resulting in 46 voluntary resignations, 48 desysops for not starting an RfA, 55 failed RfAs and 78 successful RfAs.^[p] While any procedure will be either ineffective or abusable, unnecessary recalls (resulting in a confirmation of trust by the larger community at RfA) are a necessary evil. Adminship is justified by community trust, and the community needs to have a standardized, binding way of dealing with a loss of adminship justification. ~ ToBeFree (talk) 16:57, 18 October 2019 (UTC)
• Do we need a community desysop procedure? Yes. I believe we are overestimating the existence of "dark forces" that will cause desysops to become regular and no admin who picks up bad blood will be able to retain their adminship. As proved by Meta steward confirmations and Commons desysop procedures, nope, not true. Simply put, any editor should be allowed to trigger a re-RfA (explicitly/implicitly failing which - desysop) through consensus at a central noticeboard, nothing more, a two-week affair and that's all there has to be to it. We should place more faith in the community, it hasn't been all bad (arguably it's the ones made unilaterally and inside closed doors that cause drama). --qedk (t 桜 c) 17:15, 18 October 2019 (UTC)
• Yes, we absolutely should have such a process. The community should be allowed to make these determinations through consensus and concerns about abuse of process are greatly overstated. Do we really believe that a community deadminship process would attract so little participation that a small group of bad actors would be able to abuse the process? On the contrary, these discussions would attract hundreds of participants. In that context, any admin who incurs enough opposition to form a consensus for removal probably shouldn't be an admin. Lepricavark (talk) 18:23, 18 October 2019 (UTC)
• I don't think this is a useful question without proposing an actual process. It's a bit like when the periodic "Should we improve RFA?" RfCs come out, and of course the answer is "Well, certainly we should." It's when we start getting into what would constitute an improvement that we run into a big load of trouble. I would lean toward saying it would be extremely difficult to come up with a system that simultaneously would be more accurate and effective than ArbCom at identifying conduct deserving of a desysop (rather than one infamous but isolated case of bad judgment), would be resistant to gaming by bad actors or those with a grudge (even if the desysop request fails and the admin is retained, just being able to initiate such a request could be a way to harass an admin who works in contentious areas, whereas groundless ArbCom cases are swiftly rejected), and would, with all that, actually be fit for purpose. Now, if someone thinks they actually have an idea in mind that can do all that stuff and not cause more problems than it solves, sure, propose it. But right now, it seems, first, to be a solution in search of a problem (we already have a way to get rid of admins who go off the rails), and, secondly, to be something that could potentially do a fair bit of damage. I'd like to at least see a specific proposal, not just a generic "Should we do this?". This is a case where the details really matter, and none are provided here. Seraphimblade ^{Talk to me} 19:06, 18 October 2019 (UTC)
• If policy gave Arbcom exclusive jurisdiction over certain issues, that might help to address some concerns. It would guarantee that complex issues couldn't be resolved by a simplistic process open to brigading. NinjaRobotPirate (talk) 19:26, 18 October 2019 (UTC)
• Yes. The system should be an RfC, open for a week, watchlist-advertised, and closed by a crat (i.e., same system as an RfA). Users who abuse the system by repeatedly filing bad-faith or groundless recall RfCs can be TBANed from filing such RfCs. Also, I'd love to see how these discussions/!votes would go if we separated admin !votes from non-admin !votes. I personaly feel that all administrators have an insurmountable conflict-of-interest when it comes to a community desysop procedure. (And yes, I'm aware of how many admin support community desysop, but that doesn't change the conflict-of-interest in my view.) – Levivich 20:29, 18 October 2019 (UTC)
• I've already commented, but I've been thinking about this most of the day, and the more I think about it, the more depressed I become at what this would likely lead to for our community. This is because the issue with a community-based desysop system is not that it will result in more desysops. It won't. In all likelihood, a community-based process would result in substantially less desysops (see Commons as an example). The issue is that we'd gain a tool for people to harass and attempt to silence good people who have no chance of being desysoped, but who work in areas where they've made enough enemies, you could probably start a valid request. I'll be blunt and say I'm probably one of those admins where you could find enough people to do any certification process, but where community removal would be unlikely to happen, and it's not something I'd particularly enjoy, even if as a whole I'm confident I retain the trust of the community. If I didn't feel I had that trust, I would have resigned already.
  The issue here is that any community desysop process will be a spectacle, where all of their flaws will be commented on via aspersions and an angry minority will be able to make their life suck for a week. Who on earth would want to subject themselves to that.
  People are focusing too much on the end-process goal here: yes, the community likely would be able to keep good admins from revenge requests, but that isn't the issue. The issue is the human being on the other side of the screen who will have to go through a week of humiliation, often by people who are likely to be community banned within the year. They'll have their worst moments highlighted rather than their norm, and the community won't stop it, because we give exceptionally wide latitude to people in forums like RfA/RfB/CUOS/ACE, and we'd be very likely to give the same latitude here.
  The end result is the bullying of other human beings, condoned in the name of accountability, targeted at sysops who have no chance of actually being desysoped. We should be better than that, and while ArbCom might be flawed, it is better than every single other process described below at attempting to give all sides a fair shake. That is what we should be focusing on. TonyBallioni (talk) 22:49, 18 October 2019 (UTC)
  • I agree. There is no evidence of a problem—what admin should have been desysopped but wasn't? It is known that Wikipedia is awash with POV pushers and spammers who try every trick in the book to remove opponents. Having a new way to hastle an admin who is active at WP:AE or any other contentious area would make admins do the easy anti-vandal work, while leaving the intractable disputes to fester. Johnuniq (talk) 23:08, 18 October 2019 (UTC)
    • I do think having some sort of community desysop process is a good idea for its own sake, and would be interested in ideas people may have about how to minimize the potentially damaging implications Tony mentions, but at least as important are the implications for RfA. Whenever we talk about reforming RfA, a reason people give time and time again for being reluctant to do so is that the RfA is the community's only opportunity to find potential problems, because once someone has the bit they'll have it forever unless they do things that are so egregious that arbcom will take it away. Opening the possibility for the community to not just grant but also take away sysop rights makes an RfA less of a big deal. If people know that the bit can be taken away, it seems like [at least some] people would be more willing to give the benefit of the doubt. It's a kind of security. Think about literally any other kind of election, and whether you would approach the election differently based on whether or not there was a process to remove that person from power... — Rhododendrites ^talk \\ 23:24, 18 October 2019 (UTC)
      • @Rhododendrites: that's a great theory about RfA, but I've never believed it. RfA is the strongest it has been in year, anyone who is suitable can pass if decide to run for it, and adding a community desysop that would likely result in less desysops than ArbCom is unlikely to have any impact for the positive. It may decrease the people who want to run, because who on earth would want to be a sysop on en.wiki with any procedure documented below, but it would not increase RfA pass rates, and it is more likely than anything to lower desysopings for cause. All it will increase is bullying, and we see below the attempts that will be made to justify the bullying. TonyBallioni (talk) 01:44, 19 October 2019 (UTC)

I don't know what it's like to have such a depressingly cynical view of the community, savages held back by the thin veneer of bureaucracy, lest we consume ourselves in our partisan scrambling for whatever throat can be cut first. I probably wouldn't be here if I did. For anyone wrongly dragged into a few days of discussion, if they care more about the project than they do about their own self-importance, they're liable to weather it fairly well. They might even learn a thing or two, that is, if they assume that the community is leaving feedback in good faith, and are not merely unchained monsters reaching for the closest artery. GMG^talk 23:25, 18 October 2019 (UTC)

Also this ^. If we're at the point that off-wiki canvassing can shape consensus in a high-profile discussion, and if we're unable to craft the process to avoid that outcome, the project is already lost. I don't think that's accurate, though. — Rhododendrites ^talk \\ 23:28, 18 October 2019 (UTC)

I agree–this isn't about -sysop, it's about +sysop. I think the effect of a community-based -sysop if that RfA !voters will be more likely to +sysop, knowing they can -sysop if there's a problem. I also don't understand how we can have concerns about brigading -sysop but not have concerns about brigading +sysop. If you trust the community to give the bit, why wouldn't you trust the community to take it away? – Levivich 23:47, 18 October 2019 (UTC)

I don't think it takes a cynical view of the community to understand where Tony is coming from. False accusations and feeling that the community is closing in when you've obviously done nothing wrong is at best stressful and at worst traumatizing. It's incredibly important that we keep in mind the human being on the other side of the screen, if only because it might be you one day. It's no secret that the community has problems handling harassment, and we should not force each other to choose between the project and our own mental health. If forced into that position, I wouldn't hold it against someone if they chose protecting their own mental health over self-sacrifice to the project. If any thing that's the healthy choice, and developing a proposal that assumes the opposite choice should be made would result in the very loss of good editors that Tony and others have expressed concerns about. Wug·a·po·des​ 02:53, 19 October 2019 (UTC)

@GreenMeansGo: thank you for proving my point. For anyone wrongly dragged into a few days of discussion, if they care more about the project than they do about their own self-importance, they're liable to weather it fairly well is exactly the type of attitude that would make this a process that places titles, false dichotomies, and a project over the legitimate needs of actual human persons. Yes, there needs to be a way to remove bad sysops. No one at all is arguing anything else, but that is not what you are arguing. You are now explicitly arguing that people should be willing to tolerate attempts to bully them because they made enemies for a few days for the greater good. No one, absolutely no one, should have to tolerate the type of behaviour you are excusing. TonyBallioni (talk) 01:44, 19 October 2019 (UTC)

Not at all. I don't buy the assumption that the 900 some odd projects with community review are all toxic hellscapes where the thirst for blood and spectacle outweigh common sense and collaboration. The consensus building process is an effective tool at weeding out frivolous bad-faith gaming. It is the process we use to resolve the vast majority of our problems, only relying on ArbCom for a smattering of cases so complex as to be intractable, at least, in all but one regard, and in that regard we are the exception and not the rule.

I don't buy the assumption that a months long ArbCom case (as likely as anything to get you covered in real-world reliable sources) is somehow less of a spectacle than a week of community discussion. Nor is it particularly effective. Here is a case that required somewhere between four and seven requests for ArbCom to act. Here is a user who had to be blocked four times over two years before ArbCom took action. Here we have fourteen months of poor decision making (more than 100 individual diffs in the evidence page) necessary between "clear abuse" and ArbCom. Here is an instance where it was easier to get a CBAN than to get a case. That's not a system that avoids spectacle; that's a system that feasts on a menagerie of spectacle just to gear up for the main event. And it is a system that fundamentally holds administrators to a lower and not higher standard than the average user.

It is a symptom of our broken and unresponsive system that an attempt to subject administrators to exactly the same consensus based process that governs the entire remainder of the project is somehow construed as an attempt to justify bullying. That is the language of a privileged class afraid of losing their privilege, who view normalcy as an attack, and who would much rather be subjected to even the spectacle of spectacles, because at the end of the day they're still being judged by a different standard than everyone else. Were it the same standard, we wouldn't be having this discussion.

I do not think it should be controversial to say that it should not take months to desysop a user when it only takes 24 hours to ban them. GMG^talk 12:12, 19 October 2019 (UTC)  

• I guess I'll throw in a couple of cents: As time goes on, the more satisfied I've become with having the arbitration process be the primary way we request desysops. There are endless kilobytes of discussions on-wiki complaining about how "RfA is broken" (though I think it has gotten a little better in the last year or so), and the issues inherent in the unstructuredness of RfA will only exacerbate when the stated purpose of an anti-RfA is expressly to take apart a user's contributions list and find reasons to desysop them. It feels like every time I think about reforming the desysop process, my thoughts always go back to the question: "What if we made a process that allows a group of trusted users, who are vetted regularly for their judgement and experience at knowing what's good for the project, be the main body in charge of reviewing administrator conduct?" That is the process we already have. In fact, ArbCom has a pretty low bar for accepting admin conduct cases; there was at least one admin conduct case this year that did not result in a desysop. If you genuinely believe that an administrator should not be an administrator, and you are willing to expend the effort to convince your peers of your opinion, then you can do that already under the current processes. In my view, we are not in a situation at the moment where we consistently fail at holding administrators accountable. Mz7 (talk) 23:32, 18 October 2019 (UTC)
• Yes. I wrote something about a 'bottom up' way to make the current voluntary recalls binding, User:Jbhunley/Essays/Binding community recall. The idea there is to get buy-in from the admin corps piecemeal and convince RfA candidates to sign up to remove the 'admin-for-life' issue which can often lead to opposes and thereby make the process less hostile.

  A formal, top-down, community process may ultimately be better but we have never come close to agreeing on one so... Jbh ^Talk 04:58, 19 October 2019 (UTC)

  • I have always seen "open to recall" as a huge negative for admins. We serve because we have the trust of the community, so if someone says "you're not doing it right" it's our obligation to stop and listen. "Open to recall" amounts to saying "I don't need to listen until you meet my conditions".
    I'm happy with the idea of binding admin recall (it's the specifics of the situtation that are problematic), but I am strongly opposed to voluntary recall. Guettarda (talk) 13:00, 19 October 2019 (UTC)
    • Guettarda, "Open to recall" amounts to saying "I don't need to listen until you meet my conditions" seems a rather negative interpretation. Do you really think that is the attitude of the majority of admins open to recall? What makes you think that admins not open to recall are on average more open to constructive dialogue? · · · Peter Southwood ^(talk): 19:17, 19 October 2019 (UTC)
      • @Pbsouthwood: I can't speak to the majority of the group, because I have no idea who's still in that group. I barley even know who's an admin any more. But most recall criteria I've read a self-serving lists whose subtext is "I don't need to listen until you meet my criteria". But like any group of Wikipedians, there's more variation within the group than there is uniformity, and you can only hope to treat people as individuals. Guettarda (talk) 01:04, 20 October 2019 (UTC)
• I support a binding desysop procedure, but since no procedure has been proposed and every procedure I have seen so far has been shot down in flames, I don't see the point of that support. It reminds me of Brexit - the question seems simple, but all the subsequent questions are not. Worm^TT(talk) 08:08, 19 October 2019 (UTC)
• We have a binding community desysop procedure: ArbCom. The tension invoked in discussions like this isn't "community" vs. "non-community" dispute resolution processes; it's open and unstructured processes (e.g. RfCs, AN/I) vs. restricted and structured processes (e.g. DRN, ArbCom, AE). We have always had a mix of the two on enwiki and there is a place for both. But I think for contentious conduct disputes, structured processes are better. Any potential desysop would fall in that category. But it would be nice to see case requests on admin misconduct become less of a "big deal", both in terms of editors being less scared to make them, and the committee being less reluctant to take them. – Joe (talk) 08:58, 19 October 2019 (UTC)
• Been here since 2004, admin. Have seen this discussion go by repeatedly. I am inclined to agree with the commenters who suggest we already have about as suitable and non-toxic a recall process as is fit for purpose - and that's the arbcom. And I've never heard a convincing argument that querulous voters would be more inclined to let RFAs in general through because another recall procedure existed - nor that the inclination to ever-higher bars to clear at RFA would diminish just because another existed - David Gerard (talk) 10:18, 19 October 2019 (UTC)
• I agree with everything said by Tony and Bradv, in particular that it would be a massive, distracting spectacle beyond what a similar process at ArbCom would entail. I also agree with Risker and Joe that ArbCom is a community desysop procedure, and truth be told I think it's one of the more straightforward ArbCom tasks. All that being said, I cannot shake the same belief that appears to plague Bradv; if I may quote my own recall procedure: Adminship is a privilege and responsibility, not a right; as it was given by the community based on all of my previous edits and actions, so too may it be revoked by the community based on any of my subsequent edits or actions. In the end, I feel basically the same as Worm: there should be one but all plans are unsuccessful. I would hope that having a procedure would eventually reduce the drama associated with it, but I do not see a path getting there. ~ Amory (u • t • c) 10:19, 19 October 2019 (UTC)
• Yes. Although arbcom is a community-based desysop, but not a community desysop. As recent events have informed, it can be sufficiently fallable for an alternative, contumacious process to be both harmless and beneficial. ——SerialNumber54129 10:24, 19 October 2019 (UTC)
• Yes. I don't think the sky will fall in if there is such a system; many other wikis have one. I think it's important to have in case it's needed, and also by having it it improves the perception that admins are accountable and therefore, I think, trust in adminds in general by virtue of this. --Tom (LT) (talk) 11:00, 19 October 2019 (UTC)
• Yes, preferably based on the Commons/Wikidata model. I agree with those who say ArbCom does a good job at managing cases that come to it, but it is not a true community process. There are a number of problems with how the enwiki community operates that I think would harm the effectiveness of any community desysop process -- mainly the fact that we encourage people to be addicted to this site, which makes everything a big deal -- but that should not stop us from having a way for the electorate to add or remove an admin. -- Ajraddatz (talk) 13:35, 19 October 2019 (UTC)
• Simple solution: If an admin does something which results in a block which is upheld they lose the bit; If they want it back -- RfA. If it really was a one off then RfA will demonstrate the community at large believes that is the case.

  All this whinging about 'admins who work in contentious areas have make enemies and could not pass RfA' is crap. If an admin can not pass RfA because of how they have been doing the job then by definition they no longer have the trust of the community. If an admin thinks they can not pass RfA now then they have failed and know it. I do not see why this is even an issue. Jbh ^Talk 15:25, 19 October 2019 (UTC)

Agreed, a block should constitute removal of sysop rights and RfA needed to be returned those rights. Trust of the community is a good starting point for drafting desysop policy. comrade waddie96 ★ (talk) 11:48, 5 November 2019 (UTC)

• Yes. I think it is reasonable to ask the question and look into it further. If being an admin is no big deal, so should removing it. This would be a step in the right direction for that. Given its use on other projects without those projects collapsing it seems like the fears about such a thing are largely unfounded. PackMecEng (talk) 15:44, 19 October 2019 (UTC)
• Well, I'll say yes but want to know more. You know what many self-governing people use for no-controversy, no fault 'desysop' - terms of office. After five, seven years or whatever, stand again or move on to the greater joys of being an editor, don't believe it has to be for life. -- Alanscottwalker (talk) 16:15, 19 October 2019 (UTC)
• I encourage the admins who are participating here to take notice of the fact that it is predominately admins who are opposed in principle to community de-adminship. Please consider the impression that gives to the rest of the community. Lepricavark (talk) 20:27, 19 October 2019 (UTC)

• Lepricavark, it's a reasonable point, and the perception issue especially valid. I'd argue that this is different from the apparently-similar issue we saw here for a variety of reasons but in particular because current working admins are the people who are going to be caught up in a vindictive specious case and have to spend time and energy defending themselves. For the average non-admin editor, this idea may seem like a no-brainer -- of course we should have a community desysop procedure -- and even for a lot of admins (like me), it also seemed at first like a no-brainer. But after reading some of the very thoughtful opposes, I believe this may be a can of worms we don't want to open. --valereee (talk) 16:16, 30 October 2019 (UTC)

• We have a community de-adminship process. We the community elect Arbcom, and Arbcom desysops admins. If people want to desysop a bunch of admins that Arbcom won't currently desysop, then set out some new rule proposals, run an RFC, ask pointed questions at the next Arbcom elections, support Arbcom candidates who promise to be tougher against certain types of activity. But don't give us two different community deadminship processes that are liable to tread on each others toes as "Trust & Safety" and Arbcom have during this year's Framgate, that is just a guaranteed trollfest. ϢereSpielChequers 21:39, 19 October 2019 (UTC)
• Cautious support. While arbcom does have removal powers, these powers only tends to get used for the most severe cases of admin misconduct (a behavioral bar that is incredibly easy to avoid). We should quite frankly have a way to remove admins who have lost the faith of the community but whose misbehavior isn't bad enough for arbcom. I think this would be particularly beneficial to the RFA process because voters would be more willing to take chances on candidates. While I support this proposal, I do have two concerns. First, we should have some protections against meritless spite nominations so the community doesn't waste its time every time there is a heated dispute or new user with a grudge. To do this, I think we should require a certain number of users with a certain level of experience to sign on before a desysopping nomination occurs (i.e. 5 users who have at least 500 edits). Second, desysoppings should be advertised at the same level of RFAs and require a supermajority to succeed. I really want to avoid admins being taken out by wikifactions for purely political purposes; we can accomplish this by widely advertising desysopings and requiring a greater proportion of the vote than 50% + 1. (I think somewhere from 55-60% would be a good; this is high enough to prevent a single faction from just barely edging out opposing factions in desysop votes but low enough to make it actually possible to remove admins). Spirit of Eagle (talk) 02:59, 20 October 2019 (UTC)
• Unsure. We always need to keep in mind that we have massive armies of undisclosed paid editors and we have no idea how to effectively deal them. There is a small group of dedicated folks who do their best but with large amounts of money supporting the other side it is little more than a "whack a mole". We regularly pick up groups of 20 accounts doing this work (and are only able to look back 3 months). These people will do anything to game our rules. We need a system that is exceedingly resistant to gaming. Doc James (talk · contribs · email) 02:59, 20 October 2019 (UTC)
  • Doc James, is there quantifiable evidence of "massive armies" of undisclosed paid editors? Can you put a number on that? 20 accounts in three months–even multiple groups of 20 accounts in three months–doesn't seem very massive? – Levivich 03:17, 20 October 2019 (UTC)
    • User:Levivich An exact number? Working on it with User:Bluerasberry for a specific type of undisclosed paid editing. If you spend time at and look through the archives of WP:SPI and WP:COIN you can get an idea of the size of the problem. If you look through upworks / freelancer etc you can also determine some numbers. We have a bunch of known companies here that have been "caught" WP:PAIDLIST and though blocked are still generally active with socks. As those involved try to fly under the radar exact numbers are hard to determine of course. Doc James (talk · contribs · email) 03:25, 20 October 2019 (UTC)
      • I tend to believe Doc James as to the scale of the problem. I block more than 20 UPEs just incidentally every three months just from patrolling the spam CSD queue, and I know I'm far from the only one who does that. And some of them are not just people who show up one day, make ten edits to duck autoconfirmed, and post a spamvertisement; many of them are substantially more sophisticated than that. So it is not beyond reason that they would game such a system against admins who frequently act against advertising and COI. Seraphimblade ^{Talk to me} 00:18, 21 October 2019 (UTC)
        • @Seraphimblade: If they could game such a system to the extent that you fear, then they could already community ban you for your trouble. That they haven't is evidence that the consensus building process is an effective one. GMG^talk 00:22, 21 October 2019 (UTC)
          • @GreenMeansGo:, that is only true if the standard isn't a "reconfirmation RfA". Now, sure, if the same level of support to CBAN is required for a desysop, then that would be really tough to game. But that would mean that, in practice, >70% of those commenting would generally need to be in favor. A CBAN proposal requires a very high level of consensus. On the other hand, if the standard is a "reconfirmation RfA", it only takes ~30% to potentially sink an RfA, and 40% definitely to. On the other hand, a CBAN proposal supported by only 40% of those who commented on it would never pass. That's exactly why I said that, before we comment on the proposal, we need to know the details of what exactly is proposed, not "Should we have something vaguely like...?". If you're proposing making a community desysop as difficult as a CBAN, that would possibly work. Seraphimblade ^{Talk to me} 00:36, 21 October 2019 (UTC)
            • @Seraphimblade: See the below workshop section, which places the standard for even opening a desyop discussion above that required for a community ban. GMG^talk 01:02, 21 October 2019 (UTC)
              • • As I think about this more, I am of the mind that well this sounds theoretically good it could be fairly negative in actuality. Would need to see the specific proposal. One controversial block I made due to incivility was immediately brought to arbcom. Would not have made the block with "a community voting process" as the editor I blocked was simple too popular (despite multiple concerns in their past). The last thing we need is two processes to drag an admin through. Any proposal would need to include that if one process has failed, the other cannot be tried next. Doc James (talk · contribs · email) 01:33, 22 October 2019 (UTC)
• Most of the opposition to this proposal seems to center around the idea that RfA is painful and admins shouldn't be subjected to it unnecessarily. So fix that problem. Currently, RfA is a one-time hazing ritual which is demonstrably interfering with site growth. It should instead be a completely routine and unremarkable process, with no criteria other than "Can this person be trusted, in general, to follow applicable policies and guidelines?" For example, discussions of edit count, "how many articles have you gotten featured?", etc. have nothing whatsoever to do with trust or policies and guidelines, and exist solely to exacerbate Wikipedia's "unblockables" problem. Once you have an RfA that works, it becomes a lot more palatable to put existing admins through re-confirmation RfAs, either on a regular basis or on request. --NYKevin 03:44, 20 October 2019 (UTC)

This is much easier said than done. To a certain extent, some of the problems identified with RfA are inherent to its unstructured nature. After all, the goal of a RfA-like desysop process would expressly be to pick apart a user's contribution history and find reasons not to support. I'm not saying it should be a pleasant week (if someone thinks you shouldn't be a sysop, then it's never going to be a pleasant week), but I feel it should be a structured one that enforces a requirement for substantiation of all allegations and provides ample opportunities to respond to accusations. We already have that with our current desysop process, which isn't perfect by any means, but it is something that we already have. Mz7 (talk) 12:10, 20 October 2019 (UTC)

I'm aware of that. But I don't think it would be too much to add a few simple rules, such as "Any !vote which is solely focused on [list of specific unacceptable criteria] may be indented by any uninvolved bureaucrat and should be ignored during closure." But if we actually tried to pass that rule, I imagine various people would object that they should be allowed to !vote on whatever basis they choose, that indenting their !votes is an abridgement of community decisionmaking, and so on. Never mind the fact that those !votes are steadily turning the Administrentsia into an aristocracy, and slowly killing the project from within. --NYKevin 20:45, 2 November 2019 (UTC)

• Yes, a binding community desysop procedure would hold administrators directly accountable to the community. While an ArbCom case request is the best way to handle egregious violations of the administrators policy, a motion of no confidence from the community would be more effective for resolving long-term patterns of unsuitability that do not necessarily involve egregious violations of policy. — Newslinger talk 09:00, 20 October 2019 (UTC)
• There should be a binding community desysop process. Agree with Newslinger. OrgoneBox (talk) 13:51, 20 October 2019 (UTC)
• I can only support this if it is limited in scope to improper admin actions. Otherwise it will be a drama-fest of "this person offended me" or "this person isn't doing enough admin work" or what-have-you grievances/soapboxes/axe-grinding. Leave the other stuff for ArbCom. Useight (talk) 00:00, 21 October 2019 (UTC)
• My initial reaction to this RfC was that in theory this sounds like a no-brainer of an idea. Of course there needs to be a method to deal with admins that have lost the faith and trust of the community. However, the more I think about this, the more I come to the conclusion that ArbCom must remain central to that method. De-adminship can't turn into a simple (un)popularity contest. While it very well may be that our normal consensus-building is generally resistant to gaming and collusion, it is a) not infallible in that regard, and b) generally not aimed at building consensus around a specific fellow editor (with the notable exception of RfA, which I think we can all agree needs fixing itself). Entrusting de-adminship, which will almost assuredly be even more contentious and stressful than RfA regardless of the outcome, to a process that only "usually works" just isn't fair to those who could easily be subjected to unfounded attacks and coordinated smear campaigns. The only way to be sure that we're not railroading an otherwise effective and trustworthy admin who may have made a few enemies along the way is to present the evidence, whatever that may be, to the community body we've entrusted to make these kinds of decisions: ArbCom. I'm not saying our current method is perfect, and perhaps there are ways to improve the reporting and/or evidence processes. However, I ultimately believe it does work, and I think we're far better off with what we have than we would with any up-or-down vote by the community as a whole. CThomas³ (talk) 01:59, 21 October 2019 (UTC)
• Cthomas3 above captured a lot of what I am thinking on this subject. Because admins are entrusted to make difficult, oftentimes unpopular, decisions, I cannot think of a viable community desysop procedure that will not result in admins being less inclined to act in sticky situations lest they risk the wrath of the mob. Where I live, the "hire and fire" mentality, i.e. the idea that if you hire someone, you should also be allowed to fire them at any time, does not exist for any but the smallest businesses. If Wikipedia was a German company, it could hire janitors at will but firing them would require a valid reason thanks to legally binding dismissal protections. And if the company fired someone, they can request a review from the labor courts which then decides whether the misbehavior, that has to be proven by the employer, is sufficient grounds for termination. That is basically what ArbCom does at the moment. So to avoid any problems of "mob rule" with a community desysop procedure, affected admins must be granted the right to appeal such a decision to a community elected body. But if we allow such an appeal, why bother with a preliminary community desysop procedure in the first place and not just bring it to ArbCom directly? The current system is far from perfect but I don't see a better alternative. Regards SoWhy 06:17, 21 October 2019 (UTC)
• Conflicted. I don't think I have a clear vote to throw out one way or the other here. Idealistically, I think we absolutely should have a community desysop procedure. It makes obvious sense that if the community has the power to give the tools to a user, it should have the power to take those tools away if the user isn't using them in line with the community's expectations. It's evident to all that our current processes for revoking the administrator tools aren't sufficient. At the same time, I have deep concerns that a community desysop procedure would be a net negative, even simultaneously to achieving its stated goals. Wading into controversial and complex topics is already an undesirable ask of our administrators and something which frequently wears them out or drives them out of the project. Providing those difficult or toxic users in the community - who we routinely fail to admonish or remove - with an additional avenue to attack and wear down our administrators isn't something I feel strongly in favour of. So this leaves me in a position of saying 'idealistically yes, but realistically no'. Sam Walton (talk) 11:53, 21 October 2019 (UTC)
• Hard to say one way or the other. I'd have to see a workable proposal with all of the details laid out before I know whether or not this is even possible. I'd hate to say yes now, but then find no one can come up with a system that works fairly and equitably. --Jayron32 12:46, 21 October 2019 (UTC)
• I see that the Spanish Wikipedia system for removing administrators have been mentioned, so I'd like to share my thoughts about it. In my opinion that system is flawed and has turned into a throwing weapon & popularity contest. Fact is that administrators sometimes have to take "unpopular" decisions which are, in turn, the "right" decisions. This kind of processes (community desysops) favour evaluating someone based on their popularity rather than checking if their actions did really conform or adhere to the project policies. The result is that administrators operating in controversial areas (BLPs, blocks/bans, dispute resolution, etc.) have either stopped from doing so or have been put up for desysop because someone didn't like an outcome because it was "unpopular". I think eswiki even made it worse when the community a) raised the threshold from 2/3 to 3/4 of the votes to pass a reconfirmation RfA (all our polls are pure votes fwiw) and b) removed the one week "cool off" period after the 12 votes to start a desysop vote were reached so the admin could either think about resigning w/o triggering a vote -or- preparing a defence for their actions. Given the size of eswiki, you can get 12 votes pretty much in 5 minutes. The process is simply unfair. While it might be true that the current system at enwiki might not be satisfactory for everyone, I'd prefer to have a body of trusted, community-selected individuals that can hear my case and decide upon the policies rather than the alternative. On the other hand, I agree that if the community has the power to grant adminship it should have the power to remove someone. The difficulty here is to find a fair and balanced process that allows the community to remove "bad admins" while being fair to the admin being questioned overall. Thanks, —MarcoAurelio (talk) 16:49, 21 October 2019 (UTC)
• Yes. It's utterly absurd that WP:ArbCom has arrogated itself sole jurisdiction over desysoping, when the community itself natively has more power than ArbCom (including community bans, and definition of policy aside from WP:OFFICE matters, and removal of arbitrators, and even potential disbanding of ArbCom, though the Foundation itself demands that we have "an" ArbCom or something equivalent). ArbCom has proven time and again (more so in particular incarnations/combinations than others) to be too unwilling to take action against "badmins". I suppose this stands to reason given the "protect the admin brotherhood at all costs" behavior of admins in general, since ArbCom has always consisted entirely of admins (other than I think we've had one arb who was "retired" as an admin). While I'm sure most if not all arbs are more aware and self-critical of such "just side with the admin by default" bias, that bias still clearly exists. It's damned near impossible to get anyone desysopped, unless a) their behavior is unfathomly bad for a really long time, or b) they transgress some technicality that ArbCom cares a lot about but most everyone else does not (cf. some desysoppings for WP:WHEELWAR and all the omphaloskeptic pettifoggery involved in the arguments about such cases).  — AReaderOutThataway ^t/_c 05:32, 22 October 2019 (UTC)
• Conflicted.. Part of my problem is that all these systems benefit people having lots of time, energy and/or bravado to heavily engage publicly with other people (none of which is very enticing to me EVER). The issue is to find a balance between engagement, privacy and effectiveness. So here is a new idea I came up with: Every user can nominate a sysop for reconfirmation by sending an argumented mail to the bureaucrats (or arbcom?). The email's sender is automatically anonimized. Every 6 months the bureaucrats announce a list of sysops who have been nominated more than once in the last 2 years with cause and these sysops then enter Vote for Reconfirmation. Vote for Reconfirmation would state the contents of the nomination emails and is then followed be a simple community vote (object/no objection to reconfirmation) with no comments and the result is either you keep the mop or you get send to RfA. You can only be listed in a Vote for Reconfirmation once every 2 years. I haven't fully thought this one through, maybe it's a bad idea, but at least it is something different. It keeps some privacy, useless stuff will get thrown out by the simple vote, you can't drag people into it over and over again and we only have a ruckus every 6 months. —TheDJ (talk • contribs) 10:18, 22 October 2019 (UTC)

  @TheDJ: all for new ideas, but without some limits 2 users could cause reconfirmation-agedda but just nominating every admin. — xaosflux ^Talk 11:30, 22 October 2019 (UTC)

  Xaosflux, then we track the origin in the database, instead of sending emails. Little bit more work to setup, but not impossible. user gets 1 report per 6 months, extended-confirmed users only. —TheDJ (talk • contribs) 13:04, 22 October 2019 (UTC)

  @TheDJ: The 1 nom per user limit cuts down on a bit, now it would take ~1000 users in Wikipedia:WikiProject Reconfirm all the admins to trigger 500 every 6 months - point is this is ripe for flooding and nuisance reconfirmations with the bar being "2 nominations". I'd be more supportive of perhaps combining the semi-private reporting position you mentioned, but allowing more than 1 nom/nominator/period, but with a higher threshold (maybe 20?) to trigger the reconfirmations. — xaosflux ^Talk 13:40, 22 October 2019 (UTC)

• Yes It seems like a no brainer that if the community can promote an administrator without going through ArbComm, that they should be able to demote an administrator through the same process. The current "nonbinding" system is worse than nothing, since it gives a false sense that we actually have processes in place while admins are free to (and have) modified their non-binding requirements on the fly to avoid having to follow through. --Ahecht (TALK
  PAGE) 17:56, 23 October 2019 (UTC)
• I'm sympathetic to each proposal given. If this ultimately falls through, perhaps there should be a subcomittee of ArbCom for desysopping; there might have already been one in the past that was disbanded (my memory is a bit foggy), but if not it could be a bit more lightweight than ArbCom while still providing a sieve to separate good from bad requests. – John M Wolfson (talk • contribs) 19:51, 23 October 2019 (UTC)
• No, at least as stated, and as repeatedly framed as recall. I kind of stopped reading at GreenMeansGo's "explaining to a Canadian why social medicare sucks" which hits the nail perfectly on the head for this Canadian (there's no recall in Canada and we're fine with it, in case you don't get the analogy). Recall weakens democracy, from my perspective. Sure, on paper it sounds like a great idea if an elected representative becomes unpopular the people can remove them from their office, but in practice you end up with weak politicians forced into following the instructions of small interest groups at peril of mob-justice-style de-election campaigns, and people who should be lawmakers reduced to powerless do-nothing puppets. Which means elections are meaningless, because if the popular vote goes to the wrong person then all the interest groups need to do is recruit enough people to sign a petition and the popular vote is overturned. So anyway no, I don't like recall. As Sandstein said, there are many of us who task ourselves with investigating and enforcing policies against ... let's say thoroughly unpleasant people, some of whom are very well connected, and who do try to use their real-world power to force Wikipedia to do their bidding. If all they have to do is get a bunch of their friends (or say small armies of paid associates) together to force removal of our permissions, Wikipedia is quickly over. I absolutely agree that we need a stronger system for community-based (community-initiated) administrator review, but I can't support any system where administrators can be defrocked by popular vote, for the reasons above (which as usual have been argued much more proficiently by others). De-permissioning of administrators should only be after investigation and weighing of evidence by a neutral tribunal of some sort, like Arbcom if not Arbcom itself. I will support efforts to make that process more accessible to the community; I do think Arbcom sets too high a bar to hear cases of abusive adminning and it's clear that the community desires a more accountable process. Ivanvector (^Talk/_Edits) 22:18, 23 October 2019 (UTC)

• If consensus is so easy to game by nefarious actors, why haven't all these people already been community banned? All it takes is a consensus. GMG^talk 22:45, 23 October 2019 (UTC)

• Some Canadian jurisdictions do allow recall of politicians, and the analogy completely falls apart when you consider the periodic elections in which elected officials can be voted out of office. In fact I imagine there are very, very few elected positions in the developed world where the office holder is elected for life. None in Canada spring to mind. -- Ajraddatz (talk) 23:02, 23 October 2019 (UTC)

• Weak no: Considering the current unfairness of RfA, I don't think this would be beneficial in that admins could lose their user perms for mistakes or minor poor judgment. I'd be open, though, if the community opinion would be stricter to de-sysop than to sysop. From AnUnnamedUser ^{(open talk page)} 00:26, 24 October 2019 (UTC)
• Yes there should definitely be a mechanism for recall and accountability of administrators to the community. Reform RfA to be a simple process - does the community agree that they'll use the functions responsibly? and that's it. Hebrew wiki seems to have a good system for appointing admins for three year terms, with a simple RfA afterward. French wiki seem to have the best method of recall by the community. Both are necessary for the longevity of the project and make it more inclusive, and both will increase civility overall in the project. --[E.3][chat2][me] 14:50, 24 October 2019 (UTC)
• I just wanted to comment that this has been proposed so many times that not only is it on WP:Perennial proposals, but there is an entire essay dedicated to giving advice to people proposing a de-adminship process: Wikipedia:De-adminship proposal checklist. IntoThinAir (talk) 21:27, 24 October 2019 (UTC)
  • Well, the essay was written in 2008 and hasn't been edited in six years. The most recent RfC listed at WP:RFDA was four years ago. – Levivich 02:24, 25 October 2019 (UTC)
• Yes, the community needs a way to remove admins as alternative to arbcom. Being able to remove bad apples could also allow RFA voters to give more leeway, creating more admins. It is somewhat ridiculous that other Wikipedias and Commons have been able to come up with solutions to this, but we haven't. Calidum 20:26, 26 October 2019 (UTC)
• In theory yes, but in practice no. I can't imagine any system that might be impervious to being gamed. I would be happy to consider any proposal that advanced such a system, however. Chetsford (talk) 08:16, 27 October 2019 (UTC)
• As with others I am Opposed more in practice than on principle. I am not aginst the idea, but I have never seen a proposal that would not be subject to abuse. As TonyB noted above; any admin worth their salt is going to have stepped on some toes over their tenure and a process for binding recall would likely have a chilling effect on admins and their willingness to take a controversial position or make a judgement call likely to anger a group of editors. And lastly this strikes me as a solution in search of a problem. No system is perfect, but I think in this case the status quo is adequate. -Ad Orientem (talk) 04:45, 28 October 2019 (UTC)

• Yes, Arbcom has not shown itself to be particularly effective in administering justice or even keeping the peace over the years I've been active in the projects. That said, having been the victim of the "justice" of an organized mob, I don't doubt that abuses of process will happen until better tools are conceived to evaluate editor/admin actions and especially "old-skool" special protection rackets. (e.g. it's pretty obvious that without admin protection, former admin Cirt could not have socked for as long as they did in violation of their topic ban; nor could jytdog have caused all the trouble they did before getting to the point of actually digging up someone's number to call them on the telephone to get them to change their Wikipedia edits...) As someone said in their oppose above there is no solution imaginable that is immune to gaming; I would add especially including the current one. I still think that there should be more circulation between serf class & overlord class. Wikipedia would probably be more fun if you could find yourself demoted to serf class or promoted to trainee overlord class 1,2,3 etc. by random algorithm. (Yes, I know that the WMF requires community vetting of admins... that would have to be part of the pre-process to the random (de)sysopping algo.) 🌿 SashiRolls ^{t · c} 08:03, 28 October 2019 (UTC)

• There's a big problem with answering "no" to this RfC question, and it's that the community grants adminship. While the community can't take it away again, the consequence is that a vote to promote is irrevocable. In my view this one-way-ness is the single biggest issue underlying Wikipedia's ever-inflating RfA standards and all the social and structural issues that flow from en.wiki's governing caste of near-unremovable mandarins.

  The obvious problem with community desysopping is that it would deter sysops from making unpopular decisions, and that leads to all the problems and challenges discussed above. Therefore the alternative to a binding community desysop process, is to end our current binding community promotion process and create an alternative that has the necessary symmetry. So for example, instead of directly electing our admins, we could elect a fixed number of commissioners whose role is to recruit, support, coach, develop, and where necessary, desysop, admins based on their performance over time. These commissioners could take the desysopping part of the job off Arbcom, which I see as a positive.—S Marshall T/C 14:51, 28 October 2019 (UTC)

  S Marshall, I'm not following you that that a vote for adminship is irrevocable and that the community has no recourse to address problem administrators. We as a community (through a community-elected body, ArbCom) have performed a number of desysoppings, and there is nothing preventing anyone from requesting a case be opened if there are other situations that need addressing. CThomas³ (talk) 17:15, 28 October 2019 (UTC)

  Yes, you can get rid of a sysop if you've got that magic smoking-gun diff that shows a clear, massive error of judgment and they then fail to produce the mea culpa of automatic foregiveness on Wikipedia. We can't get rid of the children, who're expected to make judgments with major real life real world consequences and have access to material no child should see; we can't get rid of the people who admit to closing important discussions while drunk; we can't lose the blowhards and the screwups. Gotta have that magic diff and then they've got to double-down on it. Once a user gets tenure as an admin, it's ridiculously hard to hold them to account (unlike the IP users who write Wikipedia and get rangeblocked willy-nilly).—S Marshall T/C 17:34, 28 October 2019 (UTC)

• As ever, we have a solution looking for a problem. ArbCom already exists to deal with egregious misuse of admin tools or misbehaviour by admins. It has shown it is not afraid to use these powers. A minimum entry level for any proposal here should be that it would deal with an issue which ArbCom has failed to handle satisfactorily. Stifle (talk) 16:56, 28 October 2019 (UTC)
• I think I'd support a trial for say 6 months or a year, of something like the French system as below (that would need a year). After that a new decision would be needed to continue. I think the arbcom route catches some types of problem, especially where there are a few egregious abuses, but not longer-term low-level issues. Johnbod (talk) 15:35, 30 October 2019 (UTC)

November

• We already have a community-based desysop process. I mostly stayed away from this, having more or less been quoted right up at the beginning of this discussion, but I'll expand on my words from several years ago: Arbcom, which is explicitly elected by the community, and explicitly holds responsibility for desysopping, is entirely community-based. It acts on community requests (when provided with sufficient evidence), it will carry out desysoppings in certain circumstances without a request from community members (e.g., socking admins, hijacked accounts), and it has established and published procedures that are relatively straightforward - to the point that the only Arbcom case that I've ever filed was specifically to get sysop and other permissions removed from someone. If ever the ability and willingness of Arbcom to appropriately act on the handling of administrator permissions was in doubt, it should have been put to rest based on the committee's actions in the past year (noting, in passing, that we are talking November/December 2018 and January to present 2019, two different committees). Arbcom quickly and sensitively handled a significant number of desysoppings (and approvals of resysoppings) for admins whose accounts had been hijacked in late 2018 and early 2019. They desysopped two more by case, and an additional one by motion. More impressively, Arbcom correctly interpreted the genuine ambivalence of the community when addressing the Fram situation and whether or not to resysop him. They did the right thing there, as difficult as it was to do: they allowed the community to make the decision directly. It seems to me that the one thing Arbcom does just fine is to desysop for cause, without the drama or destruction that would come with any of the processes outlined below. Risker (talk) 05:58, 2 November 2019 (UTC)
  • Oh come now @Risker:. Surely you must recognize that all this "ArbCom is community based" business is just so much equivocation. Precisely the point of specifying "community based" is to juxtapose a direct-democracy-based system with a representative-democracy-based system. The federalists of the American versus the federalists of the French revolution, diametrically opposed as they would have been, all naming aside. If you think the unwashed masses (the people actually writing and maintaining the encyclopedia) are just too capricious and impulsive to take care of their own dirty laundry, then you should just say so plainly, and American federalist you are. But don't couch it in an argument based entirely on using words to confuse meaning.
    Besides that, if you think that the supremely bureaucratic ArbCom is "straightforward", then I have nothing for you. I consider this self-evidently false. GMG^talk 13:20, 2 November 2019 (UTC)
  • "We already have a community-based desysop process" is just semantics. If, instead of "community-based desysop process", we called it a "desysop based on consensus in which any editor in good standing can !vote", there goes the entire argument about Arbcom already being that process. I think we all understand the difference between the Arbcom process and what is being discussed on this page. It's a real difference. There is just nothing to the argument that "what you want already exists". It doesn't. – Levivich 17:43, 2 November 2019 (UTC)
    • Responding to both of you in one go. Compared to many other processes on this project, starting a request for arbitration is extremely easy - just try starting an AfD without using any scripts, while following all the steps. Both of you are clearly viewing this discussion as one about politics. I see it as a discussion about human resources, and one of the most important aspects of addressing human resources issues (in this case, reports that someone is not doing their job correctly) is keeping the politics and the interpersonal nastiness out of the proceedings.

      There is no doubt that this is a community-based process; it was determined by a community-ratified policy (the arbitration policy, one of the few really clearly community-authorized policies on this project), and has been supplemented by the community-based policy on administrator activity levels. When people are electing arbitrators, they are electing the people who will implement and act upon the policy. Anyone who wishes to participate in a desysop arbcom discussion can do so within the restrictions set for all arbcom discussions. That several thousand people don't get to directly vote doesn't make it less community-based. Risker (talk) 03:57, 4 November 2019 (UTC)

      • That several thousand people don't get to directly vote doesn't make it less community-based. It does if by "community-based", one means "based on a discussion in which any editor in good standing can !vote." – Levivich 22:09, 4 November 2019 (UTC)
• No. ArbCom does this ,and acts as a gatekeeper against mobs. As per all the previous times this has been suggested. Guy (help!) 22:31, 3 November 2019 (UTC)
• No. As the current RfC stands, it is quite easy to be subjected to desysop gaming. Just like what Ivanvector said, the process can be manipulated by "special interest groups". Not successful? Try, try again because as it doesn't preclude evidence used in previous cases to desysop certain admin to be used again in future cases. You can have people continuously filing desysop requests from the same evidence over and over again (as Chinese Wikipedia had experienced with one of their de-bureaucrat process) until it finally succeeds. OhanaUnited^{Talk page} 23:32, 3 November 2019 (UTC)
• Most certainly no. Whenever a perennial proposal with a long history of failing to pass is brought up for a new discussion, the first question to ask is: "What has changed since the last time this was considered that might justify a new result?" In this case, the answer is as obvious as it is unfortunate. There is a saying in U.S. law that "bad cases make bad law" and the recent events are perhaps the epitome of a bad case. Changing consensus based on these events is going to create a bad precedent. Furthermore, as others have mentioned above, the way in which adminship recall works in many sister projects is susceptible to bad actors. Wikipedia is seeing more and more attempts by organized bad actors ranging from internet mobs to corporations to special interest groups to even national governments to corrupt the project. If any such organization decides an admin is in their way, the level and volume of resources they can deploy to achieve that goal is beyond the ability of either any one admin to resist or for the general community to offset. Any new recall process is asking for damage to the project to increase. Eggishorn (talk) (contrib) 05:20, 4 November 2019 (UTC)
• Clear support from me. I haven't had time to research options or form an opinion on them, but I would envisage a process to bring a "motion of no confidence", which, if successful, would lead to the candidate standing in a new RfA to see if they still have the trust of the community — Martin (MSGJ · talk) 08:18, 4 November 2019 (UTC)
• I would discourage working on this. Years ago, I was the most conspicuous proposer of WP:CDARFC, and that was because I thought that something along those lines was needed to satisfy a then-unmet need. My overall view of administrator accountability hasn't changed much. But what has changed is that ArbCom has become quite capable of dealing with this stuff. And that is a more thoughtful process than a binding recall procedure is likely to be. --Tryptofish (talk) 21:02, 4 November 2019 (UTC)
• No. I have more faith that the elected subset of community (Arbcom) will more often make better informed decisions on admin suitability than the self-selected subset of the community who will most likely participate in such proceedings. Has anyone read ANI recently? It's not about "not trusting the general Wikipedia community to do this", it's just the vast majority of the community won't actually participate anyway. Scribolt (talk) 12:12, 6 November 2019 (UTC)
• Strong oppose: We don't want a "mob-rule system" where POV-pushers, spammers and others, through canvassing likeminded friends on or off Wikipedia to "community desysop discussions" in order to outnumber other participants in those discussions, can easily get rid of any admin who tries to enforce the rules here. - Tom | Thomas.W ^talk 11:59, 10 November 2019 (UTC)
• No, until... I've said before, and I'll state now; identify the problem that a desysop procedure outside of ArbCom is intended to solve. I'm not interested in whether other projects have such a system. That is a Wikipedia:Other stuff exists argument. I am interested in somebody identifying an administrator who should and likely would have been desysoped by such a process, and how this process would have prevented damage to the project that the current process didn't prevent. If any promoters of a desysop procedure can not answer that question, I will remain opposed. Below, we've got 5 different proposals on how this will process will be constructed, yet no one has identified exactly what the problem is. How can anyone evaluate whether a procedure has a chance of working or not if you have not identified the problem to solve? It's like rooting around in a toolbox for a tool, but you have no idea what you're going to need the tool for. In short; show me the problem. --Hammersoft (talk) 15:48, 10 November 2019 (UTC)
  • The problem is we have about 500 active administrators to tend to almost 6 million articles and several thousand active editors. We don't have enough admin, and as a result, admin tasks get backlogged (see WP:AN#Open Tasks, e.g., currently there are 75 unblock requests and 73 copyvios pending). Because adminship is a lifetime appointment, RfA !voters are too reluctant to make new administrators, holding candidates to a standard of infallibility (see recent RfAs). So that's the problem. Creating a community-based, rather than Arbcom-based, desysop procedure will make it so that adminship is no longer a "lifetime appointment", allowing RfA !voters to feel comfortable loosening their criteria, which in turn will encourage more qualified editors to stand for RfA. Also, I encourage you and everyone to read and contribute to the summaries on the talk page. – Levivich 17:06, 10 November 2019 (UTC)
    • Would you please show me where people who frequent RFA have been asked whether they would be more likely to support if a desysop procedure were in place? --Hammersoft (talk) 17:17, 10 November 2019 (UTC)
      • This page is the place where people are discussing whether, for example, a community-based desysop would lead to more sysops. I frequent RfA and I would be more likely to support if a desysop procedure were in place. How about you? – Levivich 17:21, 10 November 2019 (UTC)
        • In concert with considering the ramifications and unintended consequences of implementing a system, I might consider it. I don't like the idea of creating a system because we think people would respond in a way we imagine. Here, we are supposed to be judging community sentiment to the idea in general. Yet, below, we are now workshopping different proposals on how this will move forward. This is dramatically cart before the horse. --Hammersoft (talk) 17:29, 10 November 2019 (UTC)

          I mean, above our comments here, are tens of thousands of words about the ramifications and unintended consequences of implementing various potential systems. Summaries of these ramifications and unintended consequences are on the talk page. The next subthread below has a collection of descriptions of the desysop procedures used on other wikis, which also helps us consider the ramifications and unintended consequences. I don't think it's accurate to say that no problem has been identified, or that no ramifications or unintended consequences have been considered. Just this latest round of this perennial discussion has been going on for almost a month. Note, also, the number of comments that call for specific proposals to be put forward for consideration, rather than general discussion. The process by which we're going about this seems to be well on track to me. – Levivich 17:42, 10 November 2019 (UTC)

          • • I think it's highly accurate to say no problem has been identified. It's also inappropriate to be discussing solutions without scoping out the desired results from implementing the system. This is very common in any sort of problem solving structure. See Problem_solving#Problem-solving_strategies. Yet, it's not been done here. Right now, the proponents of this are working on the very last step; evaluating solutions. Plenty of other proposals have failed on this point alone. I strongly recommend the people who support this attempt to figure out what the problem is first, rather than an abstract 'it would be good'. There is no way this can work without it. Best regards, --Hammersoft (talk) 17:56, 10 November 2019 (UTC)
• I think we should add a community binding desysop procedure for year to effectively have a trial to see whether it brings a net good or bad to the English Wikipedia. After the year, I think we should have a deep review to see if it is fit for purpose or not. If not, we can simply revert back to how we do desysop through ArbCom.  Spy-cicle💥  ^Talk? 19:47, 11 November 2019 (UTC)
• No mostly per Risker. There are other reasons, but the expression of them would likely start another round of drama. — Ched (talk) 22:24, 11 November 2019 (UTC)
• Yes, there should be a binding community desysop procedure. Here is my own simple proposal. Tim Smith (talk) 17:19, 13 November 2019 (UTC)
• [1]. The Blade of the Northern Lights (話して下さい) 02:50, 21 November 2019 (UTC)
• NOTAVOTE, but here are some numbers:
  • 79 editors have weighed in
  • 31 "yes", 30 "no", 18 undecided/other
  • Of the 31 "yes" !votes: 6 are admin, 25 non-admin
  • Of the 30 "no" !votes, 22 are admin, 8 non-admin
  • On this issue, the divide is real. – Levivich 02:34, 29 November 2019 (UTC)
    • It would be interesting to know if the divide is more a matter of editors experienced with drama and attempts to resolve drama, versus editors whose time at ANI is more incidental. Johnuniq (talk) 02:43, 29 November 2019 (UTC)
      • I think it's editors who are affected by the proposed change v. editors who are not affected. It's comparatively low risk for me to support because I won't ever be the subject of a de-RfA. – Levivich 03:15, 29 November 2019 (UTC)

Descriptions of de-adminship systems on other projects

See also: Wikipedia:Adminship in other languages

• Commons system: De-adminship process as a result of abuse of power: In the rare case that the community feels that an administrator is acting against policy and routinely abusing their status, it may seek de-adminship in the same way as adminship is sought. Please note this process should only be used for serious offenses in which there seems to be some consensus for removal; for individual grievances, please use Commons:Administrators' noticeboard/User problems. De-adminship requests that are opened without prior discussion leading to some consensus for removal may be closed by a bureaucrat as inadmissible. Previous cases may provide some guidance.

Although the process is not a vote, normal standards for determining consensus in an RfA do not apply. Instead, "majority consensus" should be used, whereby any consensus to demote of higher than about 50% is sufficient to remove the admin.

Commons also has a desysop for inactivity policy here.

• Dutch system Any editor with more than 100 edits in the twelve months before the vote may initiate the procedure. The admin must be notified 48 hours before. The admin will be desysopped if he or she loses the trust of more than 25 % of the voters. See: w:nl:Wikipedia:Afzetting moderatoren.

• Finnish system Any editor with more than 100 edits and an account older than 1 week can initiate a binding desysop vote. A recent RfC lowered the desysop threshold from 60 % to 51 %. See: w:fi:Wikipedia:Poistettavat ylläpitäjät.

• French system Any editor with more than 500 contributions and an account older than 3 months may file a report against an administrator. The report must be backed up with diffs of misuse of the tools or loss of trust. The "challenge" will stay for 6 months, and if six different editors have filed a valid challenge during that period, voting will commence. The desysop vote will have the same threshold as a RfA vote. See: w:fr:Wikipédia:Contestation du statut d'administrateur.

• German system: If 25 qualified editors within one month, or 50 qualified editors in 6 months, endorse recall the admin must stand for reconfirmation and initiate an RfA within 30 days. An admin cannot be recalled within 1 year of being elected to adminship or within 1 year after being recalled. See w:de:Wikipedia:Adminwiederwahl.

• Italian system Anyone can start a reconfirmation vote if one year has passed from the RfA. There are two ways a reconfirmation vote is handled: if less than 15 valid oppose votes are cast in 7 days, the admin is reconfirmed in "tacit mode". If more than 15 opposes occur, the vote will be transformed into a full 14-day procedure. To retain the tools, the admin must have enough support votes to satisfy the Italian Wikipedia's quorum requirement and have equal or more than 2/3 of the vote. See: w:it:Wikipedia:Quando sono revocate le funzioni di amministratore.

• Portuguese system In case of a violation of the admin policies, a simple majority can desysop an administrator. The admin must be notified 48 hours before the vote, and voting will last 7 days. See: w:pt:Wikipédia:Política de administradores#Regras para remoção por votação

• Spanish system Any editor with more than 1000 edits and an account older than 6 months may start a desysopping procedure. However, there are requirements for what is a valid reason to begin this, and allegations of abuse must be backed up with diffs. 12 other eligible voters will have to back the vote proposal. The admin will require a 3/4 share of support votes to retain the tools, which is the same treshold as a succesful RfA. See: w:es:Wikipedia:Revalidación de bibliotecarios.

• Chinese system The system in Chinese Wikipedia includes three phase. (1) Endorsement phase: endorsement may only be opened 48 hours after a discussion in Village Pump. Endorsement by seven users eligible to vote are required in no more than 7 days. (2) Defensing phase: Community can raise questions about the admin and admin may comment. This lasts five days. (3) Vote phase: The vote lasts 14 days and required more than 50% support with no less than 25 support or oppose votes (endorsement are counted as support automatically, unless stricken).

• Hebrew System. In the Hebrew Wikipedia admins are appointed to three year terms, after which they need to pass a confidence vote as in normal RFA (60% support).[2] Any five Wikipedians, with AFD votings rights (100 mainspace edits in last 90 days), may initiate desysop for cause which requires a normal majority (50%).[3]

Notes

Workshops

Workshop

Subject to the normal consensus building process, the community may determine through discussion on a centralized noticeboard, that sufficient concerns have been raised regarding administrator conduct, that they should stand for community review in a reconfirmation RfA. Such a discussion should be closed by one or more bureaucrats, who will weigh the evidence and arguments presented as community discussions are normally evaluated and closed. The closing bureaucrat(s) will summarize the concerns of the community in their closing statement, and if consensus is found to do so, will open a reconfirmation RfA within a reasonable time frame. If necessary, notification may be posted at WP:BN, of the need for such a discussion to be formally closed.

The closing bureaucrat(s) will make a good faith effort to ensure that the subject of the review is aware of the discussion pending review, including posting a notice on the user's talk page, or and sending an email message if the user has this option enabled. Subject to their discretion, the review may be postponed for a reasonable amount of time to allow for the subject to respond to questions asked by the community. However, such a review should not be excessively delayed, and mere inactivity or unresponsiveness on the part of the subject is not sufficient reason alone to delay such a discussion the review beyond justifiable limits. If such a discussion the review is to be postponed, bureaucrats should explain the reasoning and timing in a public forum, while respecting the privacy of the subject. The subject of the discussion review may prepare a statement to be displayed at the top of the page if they so choose. The subject is not compelled to participate in the discussion in any way, but may respond to community questions as they see fit. If the administrator resigns rather than stand for review, such a resignation is to be considered "under a cloud", and they may reapply for adminship via RfA at any time.

The community review will take place according to the normal process of an RfA, except that the decision-making limit will be set at a simple majority (50% + 1), rather than the higher standard set for RfA. As in the case of an RfA, bureaucrats are granted limited discretion in evaluating the arguments presented review, within a few percentage points of the limit, given the weight of evidence and argument presented. If the review is closed with a finding of no-consensus to retain the administrator, the closing bureaucrat will remove the user right, and annotate the reasoning in the log accordingly.

In the case that a review is closed with a consensus to retain the administrator, users are strongly cautioned to consider the guidance at WP:FORUMSHOP, prior to opening a subsequent similar discussion. Such discussions which are disruptive may be closed according to the normal consensus building process, and users who open such discussions in a way that is disruptive may be subject to sanctions, including the loss of editing privileges.

Users who have their access removed may reapply through the normal RfA process at any time, subject to no limitations.

• At least that's what I would put forth as a first draft. GMG^talk 17:15, 19 October 2019 (UTC)
• that sufficient concerns have been raised regarding administrator conduct – isn't that the point of an arbitration case? If this is based solely on misconduct, why create a duplicate process? – bradv🍁 17:21, 19 October 2019 (UTC)

  Because, as I indicate above, the standard effectively set by ArbCom is often months or years of misconduct, and not merely conduct incongruent with community consensus. GMG^talk 17:27, 19 October 2019 (UTC)

  That's not accurate at all. In June of this year someone was desysopped for a single bad administrative action. – bradv🍁 17:29, 19 October 2019 (UTC)

  Which ArbCom seems particularly well suited to depose by motion in acute cases. In other chronic cases, they apparently need more than a year of bad blocks and questionable actions [4]. GMG^talk 17:42, 19 October 2019 (UTC)

  I would suggest again, as I did in my comment above, that any actual or perceived problem with the way Arbcom holds administrators accountable be dealt with through the existing process, rather than creating a new one. This proposal is redundant. – bradv🍁 17:55, 19 October 2019 (UTC)

  Refine the existing process by doing what? GMG^talk 18:05, 19 October 2019 (UTC)

  Voting for arbcom members who share your view or petitioning for a change to ARBPOL to make this clearer. Wug·a·po·des​ 00:17, 20 October 2019 (UTC)

  What if the actual or perceived problem is the Arbcom, the institution, itself? Then can we work on a different process? Because I'd rather binding community desysop replace Arbcom than supplement it. – Levivich 02:50, 20 October 2019 (UTC)

  Levivich, theoretically the entire arbitration committee could be disbanded using the ratification and amendment process spelled out in the arbitration policy. – bradv🍁 02:55, 20 October 2019 (UTC)

  Before that's done, we need a binding community desysop process in place. – Levivich 03:04, 20 October 2019 (UTC)

  Well that's a catch-22 then. – bradv🍁 03:07, 20 October 2019 (UTC)

  Not a catch-22; a simple two-step. Step 1: institute binding community desysop. Step 2: disband Arbcom. – Levivich 03:14, 20 October 2019 (UTC)

  The committee has other responsibilities beyond administrative conduct review. –xeno^talk 07:17, 20 October 2019 (UTC)

  Yes, and if Arbcom were disbanded, those responsibilities would need to be reassigned. But that’s a conversation for another time and page. – Levivich 15:21, 20 October 2019 (UTC)

• I suggest striking The subject is not compelled to participate in the discussion in any way. Further, I believe that failure to respond should be a prima facie reason for desysop per WP:ADMINACCT. The I'm not participating so maybe things will blow over strategy that I have seen used at ArbCom can not be allowed in a community process. Admins are responsible to the community and failure to respond to a recall petition is a fundamental failure of duty and obligation. Jbh ^Talk 17:49, 19 October 2019 (UTC)

• The problem is that you can't hold someone up under ADMINACCT if they haven't actually done anything. Keep in mind that this is a proposal to account long-term for poor action as well as chronic inaction, gaming the system by logging in every July 23rd to make a single edit. In the case that someone does have an acute crisis (e.g., I happen to legitimately be stuck in Morocco with no internet access for three weeks) that shouldn't necessary mean that their entire history as a (presumably) productive member of the project should be forfeit. It seems this is merely in compliance with WP:COMPULSORY and were it stricken, it would still be in effect. GMG^talk 18:00, 19 October 2019 (UTC)

• The basis is of ADMINACCT is the idea that admins must be responsible for what they do as admins. While they are volunteers being a volunteer means one agrees to follow the rules and norms of the organization one is volunteering for. One of our rules, a rather fundamental one, is ADMINACCT. It seems nonsensical to me to explicitly exempt and admin from such a requirement precisely at the time the community is questioning their fitness to be an admin.

  I would be OK with something like The subject is not compelled to participate in the discussion in any way, however failure to do so shall be strongly indicative of the subject's lack of fitness to continue such a position of trust as an administrator. That would be in line with both ADMINACCT and COMPULSORY. Jbh ^Talk 19:02, 19 October 2019 (UTC)

  Stricken. I don't see the bit as core to the proposal in the first place, but I do think that no proposal which tries to legislate what should or should not be "strongly indicative" of this or that, has very little chance of succeeding. GMG^talk 21:57, 19 October 2019 (UTC)

• So, a discussion which can be started at any time, which needs only establish that "concerns have been raised", triggers a simple majority vote? Still opposed. Needs either a requirement that the admin's use of the administrative tools has either deliberately or repeatedly violated some policy, as judged by (crats|arbcom), or a substantially higher vote threshold to remove, or both. ST47 (talk) 18:26, 19 October 2019 (UTC)

  Does it really matter why 50%+ think an admin should not continue to be an admin? A quorum of 25, 50 or even 75 to make the vote valid would keep down brigading.

  One does not need to be a malicious admin to be a bad admin. No longer holding the community's trust is all that needs to be demonstrated. Jbh ^Talk 19:06, 19 October 2019 (UTC)

  I mean, if your standard for a community recall is that it not be a community recall, then I think we're at an impasse. GMG^talk 21:34, 19 October 2019 (UTC)

• Going off how ANI discussions work, I'm concerned about the timing set-up for this. While it would stay open (probably) for the admin to answer questions, I assume it won't force every individual who has already ((!)?)voted to come back and review the whole case. I'd be very firmly indeed against anything that allowed anything beyond the initial issue and diffs to be posted before an initial response had been given a reasonable chance to be made (perhaps 72 hours - we want a quicker method, but the change of a few days is not going to make it ARBCOM length). Otherwise you risk the subject of the recall to be fighting an uphill battle. If it's a complete poor case then obviously that won't matter, but I'd imagine we have cases which are fairly close, and 20 (!)votes made prematurely could very well be critical. Nosebagbear (talk)

I have some other thoughts, mainly based off things that are found in almost every current recall process (e.g. things like whether individuals previously blocked (and not assessed as bad blocks) by the admin will be able to vote. Nosebagbear (talk) 21:46, 19 October 2019 (UTC)

In a nutshell, the standard to open an deadmin discussion is only slightly higher than that required to indefinitely community ban someone. GMG^talk 21:51, 19 October 2019 (UTC)

• This doesn't seem lightweight at all, especially compared to systems on other projects. Looking over the above list, the process on most projects is "an editor in good standing (variously defined) can start a reconfirmation RfA if a year has passed since the last one." Checks and balances are important, but this seems to be a rigmarole. Wug·a·po·des​ 00:17, 20 October 2019 (UTC)
• So you're proposing letting an admin be removed with less support than is needed to delete an article, change a part of the MOS, unban someone, or any other community decision? That's quite frankly ridiculous. 65% would be the minimum needed if we're going off of our standard consensus guidelines, and even then that'd be low. If you want "fairness" numbers wise, go with a reverse RfA: 75% needed to guarantee a desysop, 65% for a crat chat on desysop.
  Of course, that won't get rid of the issue of RfDA being a show-trial that will be used to bully people and not actually be used to desysop people, but if you want to try to be fair, actually making the policy work like the rest of Wikipedia works and not be some magic exemption from the principle of consensus seems like a start. TonyBallioni (talk) 02:30, 20 October 2019 (UTC)

• some magic exemption from the principle of consensus I...don't know whether to take this comment seriously or not. It is a discussion which requires consensus, before we can have a discussion which requires consensus. Would you like consensus for a consensus for a consensus instead? GMG^talk 03:35, 20 October 2019 (UTC)

• No. You are asking for 50%+1 to remove someone. That is an exemption from our normal consensus process, which in practice means supermajority. Noticeboard discussions can easily be gamed, and don't attract large attention in many cases, so starting one would be pretty easy to do.
  Don't get me wrong: I'm still opposed to discussions that will desysop less people who need to be desysoped than ArbCom, but if you actually want something to be a consensus based process, it needs to actually follow Wikipedia's consensus process, and that would mean having it be supermajoritarian since we require that for anything as small as hyphens vs. dashes.
  I'll also address the issue you raised with Levivich below: most other projects have significantly smaller active editor based than us, and getting much more than 50% on anything controversial would be extremely difficult in terms of raw numbers. Mid-sized wikis (which would be developed enough to have their own desysop procedures) have about 20-30 active editors. Assuming only 15 or so participate in a desysop discussion, getting 75% would be really hard to do. I'm aware that some large projects have this, but this is a real consideration on many projects.
  I'm also going to push back on the idea that hundreds of wikis have a communit desysop process. Most of those hundreds don't have permanent adminship because they aren't big enough to support it. Of the ones that have grandfathered permanent adminship (i.e. big enough 10 years ago to support it, one guy with a fiefdom today) they have community desysop processes on paper, but in reality they have no desysop process and stewards cannot act to remove them in all but emergencies. This is because there aren't enough active editors to actually put into place the procedures. On the larger projects, the politics of RfDA is significantly more complex in many cases than the summaries above point out.
  All this to say: "a ton of projects do 50%+1 and have deadminship by community" is an extreme oversimplification, and really is dodging legitimate questions about how any proposal would work. TonyBallioni (talk) 04:27, 20 October 2019 (UTC)

• I feel that the true oversimplification here is that if noticeboard discussions can be so easily gamed, so much so that it can be hand-waved off as a given, then why would these cabals of off-wiki coordinated partisans bother for desysopping in the first place? "Gaming a consensus" at a noticeboard is all that is required for a CBAN, without a crat as a closer, nor the risk that this false consensus would be immediately undone in a subsequent broader discussion. We've seen admins community banned while still holding the tools, yet we don't seem to see some rash of posses community banning admins for doing the right thing.
  That the vast majority of projects have no ArbCom at all, and that the majority of those which do still employ a community recall, is simply the truth. Make of it what you will. The French seem to to think it works well enough to disband their ArbCom entirely within the past month. GMG^talk 12:17, 20 October 2019 (UTC)

Really? Cool. Do you have a link handy? I personally like the idea of frequent, even random, no-fault desysoppings, just to keep everyone on their toes. ^^ 🌿 SashiRolls ^{t · c} 14:15, 20 October 2019 (UTC)

@SashiRolls: See this comment below. These are not "no fault" desysoppings, but are examples where a functioning system can treat both the granting and removal of access as something other than a divine anointment or a death sentence. GMG^talk 14:44, 20 October 2019 (UTC)

• I must agree with GMG here. At RfA 25%-35% 'Oppose' is enough to prevent an editor from becoming an admin, allowing an admin to retain their tools at 50% 'Oppose' after poor enough behavior to get a recall opened is a gift. If an admin can not garner 50%+1 support for retaining the tools then they have demonstrably lost the trust of the community -- badly. Jbh ^Talk 02:12, 21 October 2019 (UTC)

• I like it but have a few questions:
  1. Why is it 50%+1 and not "the same as RfA"?
  2. Why not leave the review open for 7 days like an RfA?
  3. Should or sending an email message be changed to and sending an email message instead? – Levivich 02:53, 20 October 2019 (UTC)
     1. Because that's what many other projects use. In my experience, this also accounts for the "enemies" question. In a discussion which will involve somewhere between one and three hundred participants, it is unlikely that some bad faith conspiracy will be able to rouse 25 to 75 supporters, and the remainder will be those evaluating the case on it's merits.
     2. The review is open for seven days. The discussion for consensus may continue until it is closed by a crat.
     3. Done. GMG^talk 03:31, 20 October 2019 (UTC)

        Thanks, GMG. But what's the rationale for a lower threshold for -sysop than +sysop? This seems to me to be the kind of decision that should have supermajority support, rather than simple majority support–broad consensus rather than borderline consensus. – Levivich 03:51, 20 October 2019 (UTC)

I'm not sure I see it flowing in the same direction. I see the simple majority as making it easier to retain sysops, in comparison with RfA, not easier to remove them. That said, opinions vary cross-wiki. Most do seem to use the simple majority, but those that don't tend to use systems that err less on the side of the subject and not more. We could call these "true RfA" systems. As in the above synopses, 75% for the Dutch and Spanish, 66% for the Italians, as far as support needed to retain. If I'm being totally candid, looking at places I contribute to other than here, Commons, Wikidata, and the English Wikiquote all use 50%. So I suppose that just seems fairly natural to me personally. But on a more practical note, I'm not sure a supermajority to retain would satisfy the more conservative elements, and I'm not sure a supermajority to remove would satisfy the more reactionary. That is, of course, assuming any proposal at all can achieve consensus. In the case it can, adjusting raw numerical thresholds seems to be the one place we actually can get a consensus for with regard to RfA. So we can always return and adjust the limits once we have any process in place whatsoever, if we find that a simple majority tends to err too much in a conservative or reactionary direction.

I tend to think across the board, that we should have a low bar for granting, removing, re-granting, and re-removing, as that tends to ensure that our governance is most responsive, most closely matches the sentiments of the community, and tends toward a system where we actually guide the organizational climate, rather than a forced choice between ascending to a peerage, or chopping of heads. I don't think it is a sign of a healthy responsive system, that in the entire history of the project (as far as I am aware) we have had only a single admin resysoped after removal for inactivity, and only a single admin ressysoped after removal for cause. That's not a system that responds and adapts and allows people to learn and improve, while serving the community to the best of their ability. GMG^talk 13:07, 20 October 2019 (UTC)

If we want more concrete examples, here is a user who was promoted (2010), retained (2011), recalled (2011), re-promoted (2013), re-retained (2016), and re-recalled (2019). They're as likely as anything to get the bit back if they take the community's feedback on board and reapply. Here (the log is funky) is a user who was elected as a crat (2005), recalled (2009), declined (2011), re-declined (2012), re-re-declined (2014), and re-promoted (2015), and continues to be one of our most prolific contributors. To my mind, as someone who contributes to both those projects, that is a functioning system that provides responsive feedback, doesn't hold grudges, and where those with advanced permissions truly serve at the behest of the community. That RfA on the English Wikipedia is treated as an absolute annointment with the divine right of sysop is only half the problem. The other half is that desysop is effectively a death sentence for any hope of ever holding advanced permissions ever again. Both these problems are effectively served by a responsive mechanism for the community to provide meaningful approval or disapproval. GMG^talk 14:40, 20 October 2019 (UTC)

There's definitely something to the first side, unfortunately (one of the reasons I said yes to me having them) but the latter is definitely more open for dispute. If we'd always had universal recall, I think it would be true, but I'm not quite sure how well the community will actually treat recall desysop as less than a death sentence for a future RfA. Which definitely has chicken and egg concerns, but I do feel for the first few admins removed by a process, especially those who aren't clear-cut. Nosebagbear (talk) 16:09, 20 October 2019 (UTC)

Thanks again, GMG, I think I understand your point now. I tend to agree with a simple majority for RfA, which I think would be more palatable if there was a community desysop procedure. 50%+1 to give the bit wouldn't be a big deal if falling below 50%+1 could also result in taking the bit away. I'd support a community desysop at either simple majority or supermajority. – Levivich 17:24, 20 October 2019 (UTC)

I expect there will be a few users with an axe to grind that will pounce on the opportunity as a convenient new weight loss method. I expect that the type who frequent centralized discussion boards are fairly well adjusted people with good heads on their shoulders, who can recognize bad-faith opportunism for exactly what it is. I expect there are a few users who will need to adjust to the notion that they cannot simmer in the grey area just below a critical boil of a case request, they must yes, actually uphold community standards for administrator conduct. These users will adapt, or they will not be administrators any longer. If they cannot adapt, then I hope that the new found community agency in being allowed to grant and revoke access will allow them to reapply in good time. GMG^talk 21:35, 20 October 2019 (UTC)

• Comparing enwiki to other projects, when they have radically different processes for (a) selecting administrators (b) expectations of administrators (c) in most cases, do not have other processes for removing administrators (i.e., an Arbcom with authority to remove permissions - some have arbcoms that can't do that) is a fool's game. Should we want to go down this path, we need our own practices. For example, we don't have basic data such as how many administrator actions are performed on each of those projects as compared to enwiki. (Hint: we block more accounts in a month than most of the projects listed above block in a year.) Our scales are radically different. Anything that is justified by "that's how other projects do it" should be immediately discounted, since other projects don't deal with what we do. If we're going to have this discussion, we should be figuring out what we need, what we want, what we don't want, and so on. We shouldn't be looking at one aspect of adminship in isolation. Let's have a discussion about the whole big picture. Risker (talk) 17:31, 20 October 2019 (UTC)

I reject outright the assertion that the English Wikipedia is terminally unique. It isn't. If that is your line in the sand, then we are at an impasse, and I would only suggest that you contribute more to our sister projects to learn just how unique we aren't. GMG^talk 21:46, 20 October 2019 (UTC)

I'm sorry that you're rejecting this. I think English Wikipedia is unique. I also think every other project is unique. Each has developed in different ways; we're the only one that developed with Jimmy Wales holding tight to the controls for a very long time, whereas he's had (at best) minimal direct influence on every other project. That, by itself, makes us unique, in that we had a single user who for the first many years of this project was, in fact, able to exert a level of control that has never been known on any other project. But all other projects are also unique - they have developed in different ways, with different communities, different philosophies, different priorities, and different levels of importance related to the permissions granted to the members of those communities. This is a reality. We are not like Commons, we are not like Wikidata, we are not like any other language's Wikipedia (neither French, nor German, nor Cebuano, nor Swedish - all of which have practices and policies that we have explicitly rejected), and I think we're pretty obviously not like Wiktionary, Wikisource, or Wikiquote in any language. (And Bengali Wikisource isn't like Punjabi Wikisource, for that matter.) I do get out, and I have invested a lot of time and energy in learning about other projects by talking to the people who work on them, reading what they have written, and looking for ideas on what we can do better. In this particular case, I believe that the solution we found for desysoppings is significantly superior to that of any other project, and the reason that many of them have been unable to implement it is that they don't have an Arbcom with teeth. Risker (talk) 05:36, 2 November 2019 (UTC)

If we want to get into a comparison over credentials...(<-this ellipsis signifies me checking to find exactly what I expected to find) I don't particularly consider your 19 contributions to file space on Commons to give you an especially in-depth understanding of the inner workings of the project. Nor your 65 contributions to Wikidata. I don't consider myself anywhere near an expert on WD, and I've contributed that much in the past month. I'm not trying to denigrate your contributions to the overall movement at all. There is no requirement for anyone to be highly involved across multiple projects, and most people probably aren't. But if you are not, then you will perhaps forgive me if I don't consider your cross-wiki opinion to be an especially informed one. You have precisely the opinion of someone who contributes almost entirely to one project, and those people tend to see their project as especially unique regardless of what their home project happens to be. GMG^talk 13:52, 2 November 2019 (UTC)

I really don't think you want to get into a comparison over credentials, GMG. There are more ways to have conversations and to learn about communities than by editing on a project. I come to my opinions from years of working closely with people from dozens of projects and Wikimedia communities; I realize that you're probably unaware of what I do outside of enwiki because a lot of it is on Meta and other places that aren't particularly visible. That's why I know that each project is unique, not just English Wikipedia. I feel sorry for you that you have to take a dig at me personally in order to try to invalidate my opinion. Risker (talk) 16:28, 2 November 2019 (UTC)

@Risker: Not at all. I appreciate your contributions. I should be a fool if I miss any opportunity to thank you for them. I will absolutely move heaven and earth to the greatest extent of my ability to help you in any way to continue to to do so. If I have ever failed to do exactly that for any user, please bring it to my attention so that I may correct myself.

At the same time, I would be disingenuous if I addressed your argument for anything other than what it is. You were the one who brought personal credentials into the equation. If any debacle with the Foundation in the history of any project has illustrated anything, it is that philosophizing about, talking about, planning about any project, even with the very best of intentions, is no substitute for actually being a part of those communities. The argument that every project is a special snowflake and no comparison can be drawn between them defies common sense. GMG^talk 21:48, 2 November 2019 (UTC)

This. This is exactly why I have little faith in the community for it to take on this responsibility. The unnecessary snideness of your comments, when I explain where I come to my opinions, the belittling of experience of others, and just as importantly, the unwillingness of anyone else to say that this is a step too far and that the comment is doing nothing to further the discussion....this is exactly what the problem is with giving every account the leverage to smack down people they don't like. It's exactly why we got rid of RFC/U so many years ago, and why this kind of dispute resolution was centered on processes within a (comparatively) controlled environment that limited the denigration of users, who may or may not have been acting outside of the accepted bounds. That you choose not to agree with me is fine; there's room for a lot of different opinions here. That you're a jerk about it, really isn't. I suppose I should thank you for giving us all an illustration of the types of comments we could expect to see at a "community desysop request". Risker (talk) 02:43, 3 November 2019 (UTC)

Well my intention was certainly not to be a jerk at all, and I'm sorry I came off that way. GMG^talk 22:14, 3 November 2019 (UTC)

Even if none of the comments on this page were snide or had a jerk quality, Risker's point is very valid because an open community has all kinds of humanity, including jerks and trolls. That fringe group would exploit any opportunity to poke an admin who takes an action they don't like. The English Wikipedia is not like Commons or any other website because it is only the English Wikipedia that is a top-ranking site for POV pushing, spam and trolling. Johnuniq (talk) 23:40, 3 November 2019 (UTC)

While I generally agree with everything Risker has said, if you're going to make the argument that only en.wiki people think that community desysop isn't ideal, you should look at what MarcoAurelio (courtesy ping) has said above. He's the only non-en.wiki steward to comment, but I know there are several others who have shared similar thoughts with me. "Community-based" systems only work effectively on mid-sized wikis, where you have 20-50 core participants who will all show up to the vote. On large wikis, they only cause drama. Yes, there are large wikis that have them, but the actual effectiveness of community desysop on other projects is not nearly as universally regarded as you are suggesting it is. TonyBallioni (talk) 03:38, 3 November 2019 (UTC)

• I would suggest being much more specific about what "sufficient concerns" might be. I see at different points in the page people arguing that the issue is one or more of:
  1. More-or-less inactive admins who make few contributions in project space but are active enough to pass the very minimal activity standards [disclosure: I probably fall into this category ;) ]
  2. Admins who repeatedly violate specific policies/processes but not so obviously that Arbcom de-admins them
  3. Admins whose conduct falls short of what's expected in terms of communication, combativeness, escalating drama, etc, which Arbcom doesn't deal with
• I am concerned that without "sufficient concerns" being set out in more detail, people will have radically different expectations and we'll end up with a whole pile of drama. (Also, but of secondary importance, I feel that if the problem to be solved is the first one I listed, the best route to it is probably to tighten up the admin activity requirements rather than create a discussion process...) ThanksThe Land (talk) 18:19, 20 October 2019 (UTC)

  The Land That's a great summation, more specific indeed, yes. Govindaharihari (talk) 18:29, 20 October 2019 (UTC)

  Good summation indeed Nosebagbear (talk)

  I do not think that we can legislate to the community which of their concerns are legitimate and which are not. If your own level of conduct or inactivity falls below the level expected of the community, then you should not be an admin. Being an administrator is not a notch in your belt. It is a tool. If you can turn that wrench in a way that helps us to accomplish our shared objectives, then we will allow you to do so, we should place the wrench in your hands. If you cannot or will not, then we will give that wrench back to you when at some point you can. GMG^talk 23:22, 20 October 2019 (UTC)

  To my mind it's not about legislating what concerns the community is 'allowed to have', but what behaviour the community expects to see from admins. Expectations around activity and how the tools are used are pretty clear, expectations around civility and conduct are not and I would prefer some clearer expectations on the latter (or at least the enforcement of the existing expectations). But better for community expectations to be expressed as guidelines, and to have a process to remove adminship where the guidelines are broken, than to have a process that could become arbitrary and over-dramatic. The Land (talk) 16:03, 21 October 2019 (UTC)

• This won't remove our ARBCOM process, and so I perhaps feel that we should specifically state that it can't start while an ARBCOM case request is in process, and if an ARBCOM case considers actions this (or any) recall process can't then be run on them. Otherwise we're going to end up with an unpleasant version of double jeopardy. ARBCOM looks unpleasant, and I'm sure it's worse to be the subject. Making it through once successfully should be sufficient to demonstrate a recall case is unwarranted. Nosebagbear (talk) 19:35, 20 October 2019 (UTC)

This...is actually a sticky situation, and exactly why I don't want to over-legislate things. There could very well be a situation where ArbCom is unresponsive to the community, and it is perfectly legitimate to seek alternative reprisal. There may be instances where users just don't get the answer they want, and so they FORUMSHOP to the community recall. At the end of the day, this upholds the core purpose of ArbCom, which is to resolve intractable disputes that the community cannot. I trust that the community is level headed enough to tell the difference. GMG^talk 00:15, 21 October 2019 (UTC)

@GreenMeansGo: - "alternative reprisal - is that genuinely how you feel? That's a major concern if that's the viewpoint behind a recall process. The lack of a double jeopardy clause (which would need to run both ways) is enough to make me a very firm oppose. ARBCOM aren't designed to run off community perceptions but the actual case and pre-agreed rules. I feel that relying on the community to so overwhelmingly reject forumshopping that not even enough individuals to trigger the process can be found is too optimistic. Nosebagbear (talk) 16:23, 29 October 2019 (UTC)

@Nosebagbear: If ArbCom does drop the ball completely, then their intransigence shouldn't prevent the community from seeking alternate routes. If the case has merit, then this is the normal process in seeking alternative steps in the dispute resolution process. If however, a case is meritless, and people are actually forum shopping, just trying to get the answer they want, the community is perfectly capable of recognizing that and shutting it down. We do it all the time with little fanfare. If you feel that the community are simply too roundly imbecilic to follow basic policy, then I'm afraid there's not much I can do for you there. That's a personal problem. GMG^talk 17:44, 29 October 2019 (UTC)

@GreenMeansGo: - I am confident that more than enough of the Community would identify forum-shopping to stop someone going through a full ARBCOM case and then desysopping them without more complete grounds. The 2nd half of my statement referred to the issue of the lower boundary to triggering the process, which could easily be reached by those not identifying that or deliberately ignoring that. I suspect this process will be unpleasant even for those who are not desysopped. As such, I'm trying to avoid unwarranted cases being opened when it's already been considered. Nosebagbear (talk) 18:29, 29 October 2019 (UTC)

@Nosebagbear: I'm not sure I understand what you mean by "lower boundary to triggering the process". I'm not sure I see a consensus at a centralized notice board as a lower boundary at all. It's not subject to the "pseudo-consensus-but-only-within-limits-of-a-pure-headcount" that RfA is, and is a discussion where the closer would be within policy to discount a 100 inane !votes in favor of a single comment making a sound argument, like we do in all normal consensus building processes. GMG^talk 19:24, 29 October 2019 (UTC)

• If a normal RfA requires at least 65% support to even have a slight chance of passing, a de-RfA should also require 65% support (meaning support for removal) to have even a slight chance of passing. Consensus is required to reverse a previous consensus; no consensus means the status quo ante remains. In that case, the status quo is that the admin is an admin, and a consensus should be required to change that. Seraphimblade ^{Talk to me} 00:22, 21 October 2019 (UTC)
  • Agree status quo until a super majority supports otherwise, so 65% community support to have a chance of passing. Doc James (talk · contribs · email) 01:38, 22 October 2019 (UTC)
  • I also agree with this formulation. bd2412 T 16:20, 27 October 2019 (UTC)
• Would all admins commenting on this proposal please declare their conflict of interest. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:27, 21 October 2019 (UTC)

  If you refer to Wikipedia:Conflict of interest, this situation is not described there, ergo it is not conflict of interest for administrators to comment there. You can try to invoke WP:INVOLVED, but I am afraid it also does not exactly refer to this situation.--Ymblanter (talk) 08:34, 21 October 2019 (UTC)

  I don't refer to either, which is why links to those pages are glaringly absent from my post. Please do not invoke straw men. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:05, 21 October 2019 (UTC)

  Would you please formulate a policy-based argument, with a link to a policy.--Ymblanter (talk) 09:23, 21 October 2019 (UTC)

• I like this approach, since it allows the community to determine what "sufficient concerns" they have, rather than trying to make this a rigid CSD-like process (the reason CSD has specific requirements is because is bypasses the consensus-building discussion that this process has baked in). I'm almost of the mind that the requirement for passing a re-confirmation RfA should be the same 65% it is for a normal RfA, but I can see the logic in lowering the bar to 50% to account for brigading by jilted editors. I don't think it's reasonable to require only 35% support, since there's no way that an administrator who has the support of less than half of the community should retain their post. --Ahecht (TALK
  PAGE) 18:07, 23 October 2019 (UTC)
• I like the basic idea for the reasons given above; the potential for abuse and politics is indeed unfortunate but is outweighed by the need to have a lightweight desysop procedure in order for adminship to truly be NOBIGDEAL. I agree with Nosebagbear that ArbCom stuff should preempt this, as well as the above ideas that the bar should be raised to 65%-75% to match that of RfA. – John M Wolfson (talk • contribs) 20:10, 23 October 2019 (UTC)
• I should clarify that though I'm somewhat very firmly against the current format for the various reasons above. If and only if there is general consensus for it, however, I wanted to specifically consider consensus level. I'm very firmly against re-requiring 65%, and think that 50% is the right mark. But also that even this can be moved a few % either way by the 'Crats depending on the strength of arguments made - perhaps it could be thought of as a 45-55% discretionary zone. I also think any method should only be trialled for 1 year and require consensus to continue (not discontinue) Nosebagbear (talk) 08:35, 24 October 2019 (UTC)
• What's the RFA level, 75-80%? Should be at least that. Will voters be qualified, e.g. by age and/or number of edits? - David Gerard (talk) 22:32, 28 October 2019 (UTC)

Workshop (2)

In summary, the process is initiated once a user prepares a request for de-adminship page, the request is seconded by another editor, and the candidate is notified of the request. The candidate is given one week to make a statement after which the request may submitted for certification. At least 48 hours after being submitted for certification, a bureaucrat will determine if the request has been certified and either close it as not certified or open the discussion for community questions and comment. This discussion lasts at least 7 days, at which point a bureaucrat will open a bureaucrat discussion lasting at least 48 hours in which bureaucrats gauge community consensus. Finally, a bureaucrat will close the bureaucrat discussion and implement the consensus decision.

Prerequisites

The prerequisites to submit an RfDA request for certification are:

• Examples of recent or ongoing behaviour incompatible with adminship must be supplied.
• At least two recent or ongoing examples must have resulted in separate attempts of genuine dispute resolution of some sort (including extended community discussions involving the candidate, noticeboard threads, RfCs, or arbitration).
• A request may be filed for a single incident with dispute resolution if a candidate has exhibited behaviour grossly incompatible with adminship (though in such cases the Arbitration Committee may be better suited to handle).
  • Examples with dispute resolution must not have been examined in a previously certified RfDA; examples used in a previous uncertified RfDA should only be submitted alongside fresh examples including at least one with dispute resolution.
• At least one other editor must second the request before the request may be submitted for certification, requests not seconded may be deleted.
• The candidate must be informed on their talk page of the RfDA's existence and be given the opportunity to make a statement and schedule the process; if no statement is made within one week, the request may be submitted for certification.
  • During certification, a candidate may restrict their statement to the subject of certification; however, if the request is certified, they should consider to expanding their statement to address the concerns raised.

Certification

Once the RfDA sub-page is created and a candidate has been given one week to make a statement and arrange scheduling, it may be posted by a bureaucrat for a 48-hour certification period unless it obviously does not meet the prerequisites.

During the certification phase, community members are invited to provide their opinion on whether the prerequisites have been met.

It is important to note that the certification process is not about whether the candidate should remain an administrator, but only if the prerequisites to submit the request have been met. A user may certify the request yet still opine in the later phase to retain the administrator, and indeed if a participant feels strongly that the candidate should remain an administrator they should not oppose certification on these grounds alone - only on the grounds that the request has not met the prerequisites. Comments rejecting certification on these grounds alone may be weighed accordingly by the bureaucrat processing the certification.

Similarly, a participant should not certify a request if they feel the prerequisites have not been made out (even if they feel the candidate should not remain an administrator). The certification process is in place to ensure that requests for de-adminship do not proceed without evidence of recent and ongoing behaviour incompatible with adminship coupled with prior attempts at dispute resolution. As above, comments will be weighed accordingly.

Questions may be raised in the certification discussion but these questions should remain focused on the certification process; if certified, there will be an opportunities for questions of a wider scope.

Once the minimum certification period has elapsed, a bureaucrat will determine if the request has been certified by the community. If the bureaucrat determines the request has been certified, the request moves into the opinion phase; if not, it is closed.

Questions about certification decisions should be raised with the bureaucrat in question first, and bureaucrats noticeboard if necessary.

Opinion period

Once certified, a bureaucrat will open the opinion phase which is similar to an RfA:

• The discussion runs for at least 7 days (no "snow" or non-bureaucrat closures).
• Optional questions may be posed to the candidate.
• The community is invited to opine in support, neutrally, or in opposition to the administrators' continuing adminship.
• Bureaucrats and uninvolved users are tasked with monitoring the discussion and attempting to maintain decorum.

The 7 day period is merely a minimum; the request remains open for comment until placed on hold by a bureaucrat and may be extended at bureaucrat discretion.

Closure

After at least 7 days have elapsed, a bureaucrat will place the discussion on hold and open a bureaucrat discussion which will remain open for at least 48 hours.

Uninvolved bureaucrats will review the RfDA and provide their comments as to whether community consensus exists to withdraw administrative privileges (not whether they personally feel the candidate should remain an administrator).

After at least 48 hours have elapsed, a bureaucrat will review the bureaucrat discussion to determine consensus among the bureaucrats and implement the decision. If the consensus is not obvious, the discussion should be closed by a bureaucrat who did not participate in the bureaucrat discussion.

Attribution: Special:PermanentLink/891619964.

This is the procedure that led to the discussion linked by Wugapodes in the opening. It's pretty resilient in my opinion, uses existing structures, etc. - basically a reverse RfA. I don't support it because arbcom is already a community binding desysop procedure and it seems pretty unpleasant besides (maybe even moreso than an arbitration case). See also: User:EVula/opining/RfA overhaul#Possible concerns. Perhaps adequately workshopped, these concerns could be addressed (if consensus is found that a separate but equal process from committee action is required).

Disclosure: current bureaucrat. –xeno^talk 13:14, 21 October 2019 (UTC)

On the issue of practicality, if we have users who are concerned that an open-ended discussion (which would probably easily involve dozens of editors over several days prior to reaching consensus) is vulnerable to gaming by cliques of partisans, I don't hold out much hope that a hard-numerical-cap system requiring only two editors to reach quorum would garner very much support. The English Wikiquote also uses a hard-numerical-cap system and it requires three editors on a project with about 500 active users. Proportionally, that would require a quorum of somewhere around 800 users on the English Wikipedia. GMG^talk 13:30, 21 October 2019 (UTC)

The quorum would be determined in certification. I have to wonder how much the appetite for a "community RfDA process" is related to the shuttering of RFC/U. There isn't really a structured way for the community to organize and deliver constructive criticism on administrator behaviour short of arbitration anymore. The closest we have right now would be a thread at WP:AN, but those are ad hoc and can be acrimonious (not that RFCUs weren't sometimes, mind...). –xeno^talk 16:11, 21 October 2019 (UTC)

Maybe more to the point, threads at AN or ANI that are about misconduct are perennially given the boot based solely on the basis that the correct forum is ARC. Maybe ironically, there's been an ARC or two given the boot based on the fact that there hasn't been a sufficiently bloody ANI thread. At any rate, based on my experience (I've successfully opened desysop proceedings on two other projects), the initial discussion normally has a way of sorting things out without the need to resort to deadmin proper. But on projects where a disaster equals a punt to RfA, the discussion tends to have more teeth than it does here, where the subject can always say "have fun with your petty discussion, look me up when you have five or six of them to justify an ARC". GMG^talk 16:47, 21 October 2019 (UTC)

If this were to happen, this wouldn't be a bad way of doing it. And it would have the advantage of a) relieving this workload from Arbcom and b) allowing discussion of someone's conduct in general, rather than in the context of a case where other issues would be more prominent. I would prefer a bit more specificity around grounds for opening such an RfDA (see my comments above). I would also prefer the number of proposers to be both raised (maybe as high as 5?) and capped (i.e. if 2 is to be the number it should be exactly 2 and excessive proposers should be removed - a situation where 25 people show up to sack someone is unhealthy). And I would prefer the definition of dispute resolution to be less strict, including e.g. good-faith attempts at dialogue directly with the admin concerned. I think it would also be a good idea to make it clear that admins facing RfDA can discuss the timings of it (with the bureaucrats?) so within reason they can make sure they can attend to it. It also needs to be spelled out whether an admin resigning while an RfDA is being proposed etc counts as "under a cloud" - I would suggest that it should not (on the grounds that if they voluntarily resign, and THEN request the bit back, there is still the option to bring an RfDA if at that stage it is still necessary). The Land (talk) 18:34, 21 October 2019 (UTC)

The Land: feel free to re-jig it at User:EVula/opining/RfA overhaul, EV won’t mjnd (and I’m pretty much done with it). –xeno^talk 23:32, 21 October 2019 (UTC)

• It's worth a try. Though there have been reasonable objections presented here, there would be equally reasonable objections about our present system. The system will have the possibility of being abused, but that's just like every other aspect of our system. I can't see how it would be actually worse than, for example, the current RfA process. I'd suggest a one-year trial period, after which another vote to continue would be needed. (My personal guess is that is the percentage to de-sysop is any higher than 50%, there will be between 0 and 2 actual desysops.) The basic problem we're trying to solve is arb com's reluctance to deal with chronic medium level cases. This could be solved by either very different arbs being elected, or a change in arb policy saying they should specifically consider this sort of malfeasance; the first seems unlikely, as most arb com elections do not give rise to major changes in how the committee works; the second might be worth trying, but how the committee implements it would probably also not be much of a practical change,and a very high supermajority is required anyway to amend arb policy. DGG ( talk ) 07:41, 22 October 2019 (UTC)
• Two main points here: 2 is too few to kickstart the process and are we indicating to the 'Crats a guideline on what is sufficient community consensus. I ask the latter because consensus for a change in policy usually takes c. 60% of justified !votes, is that what they'd need to desysop? Or are we on c. 50%+1? While they can obviously vary a bit from strength of arguments, a base point needs to be given. Nosebagbear (talk) 08:56, 22 October 2019 (UTC)
• I would support this (under the rationale that we should try something), but I find it too bureaucratic and prefer the simpler, first #Workshop proposal. I'm not convinced that we need to put in a system of rules intended to reduce abuse, because I don't think the process will be abused that much. Right now, anyone can nominate anyone for RfA, but we don't see a slew of bad nominations. Anyone can take anyone else to a noticeboard, but you don't see editors bringing everyone they're in a content dispute with to ANEW or AIV or even ANI. Editors who do over-report or bring bad faith reports are rather quickly and easily identified and dealt with, e.g., by a TBAN from a noticeboard. Even that doesn't happen that often. Off the top of your head, how many editors can you name who are TBANed from ANI? I think the concerns that a "mob" will start making bad recall nominations are more imagined than real. – Levivich 15:34, 22 October 2019 (UTC)

agree the first is simpler, aand possibly we can simplify it further.

there's another benefit to having some process of this sort. I suspect about half the admins reasonably challenged at this process will correct themselves , even if they are not removed. And some will resign the tools rather than face a vote. DGG ( talk ) 17:20, 22 October 2019 (UTC)

Indeed, the statistics TBF posted above from German Wikipedia seem to support this prediction. – Levivich 18:57, 22 October 2019 (UTC)

• This seems overly bureaucratic and needlessly complicated, especially compared to Workshop (1). I would support it as better than nothing, but I'm not sure its the way to go. --Ahecht (TALK
  PAGE) 18:02, 23 October 2019 (UTC)

Workshop (3)

The current ArbCom-based process is satisfactory, has shown that it works, is not subject to revenge-based or heat-of-the-moment nominations, and is not broken. Any proposal should set out why it is better than the ArbCom-based process, and include examples of when it would have potentially worked better than the current process had both been available at the time.

Stifle (talk) 17:00, 28 October 2019 (UTC)

• Support I am not opposed to a better system of community based de-sysoping, provided it would be actually better. No one has proposed any system that wouldn't give power to coordinated groups of axe-grinders, trolls, and the like to take down all of the admins willing to work the hard cases. No one has yet shown that ArbCom is insufficient for dealing with the situation. I'm willing to be convinced; I just haven't seen anyone do it yet. --Jayron32 17:49, 28 October 2019 (UTC)
• I'm not sure I understand that this does anything other than beg the question. It seems fairly straightforward that support or opposition for community desysop is predicated precisely on whether people think the current process is operating satisfactorily. The only thing this proposal really says is Before we consider an alternative, the proposal must start by admitting how really really great our current system is. I mean golly gee it just works so well. Then, they need to make the argument that we should replace something so gosh darn awesome. Well no, I'm not going to start from that premise, because if I thought the current system worked well, I wouldn't be going to the trouble of suggesting an alternative. GMG^talk 19:14, 28 October 2019 (UTC)

In case we need a quick recap, since what this is asking for is exactly the discussion going on above:

• ArbCom is notoriously bad at handling chronic misbehavior. You can wheel-war once after years of productive contribution, and your head is on the chopping block, because there is a "smoking gun" diff that rises to the level of a case request. Where there is not, and the problem is years of sub-par contribution, especially as it concerns toxicity, ArbCom are wont to decline the case for lack of acute egregiousness. The last desysop for cause required between four and seven case requests for a desysop, and only achieved one after an Office ban initiated a constitutional crisis. (Other examples are given of desysop for cause where behavior necessarily needed to go from bad to abundantly intolerable to warrant a case.) Presumably, the community would have handled this much sooner and much better, because when they were given the opportunity, they disposed of it rather decisively. As it turns out, as unfortunate as a single instance of wheel warring is, it doesn't actually have the same persistent eroding effect on the project as chronic toxicity, exactly the problem ArbCom seems ill-equipped to handle.
• The vast majority of projects don't have any ArbCom at all, and most of the ones that do still have a community desysop procedure. This applies to large projects, smaller projects, Wikipedia projects, and multi-lingual projects. These projects have somehow not descended into partisan chaos, with admins so cowed by the mob that they're afraid to lift a finger.
• The argument against a consensus-based desysop have, at no point that I can tell, actually addressed the issue that if consensus is so easy to game, then why haven't these admins doing the right thing in controversial areas simply been community banned, because a simple consensus is sufficient to do so.
• The argument against the "spectacle" of a re-RfA, have, at no point that I can tell, actually addressed this issue that an ArbCom case can take months, and is almost guaranteed to be covered in traditional media, while RfA takes a week, and is covered only in places like Wikipediocracy, the old haunt of banned users who have literally nothing better to do than talk about Wikipedia.
• Completely unaddressed, but something I've been arguing for years, is that ArbCom is so needlessly esoteric and bureaucratic, that it completely disenfranchises not even inexperienced users, but even the majority of experienced users, who still don't feel that they have the competency to file a request, much less pursue a case to conclusion. It is only a venue for the tiny minority of users experienced in it, to the point where they could probably rent their services as counsel to represent others, and we should probably consider appointing counsel for the uninitiated.

The effect of all this is that the standard at RfA has continually risen, removal of advanced rights is all but a death sentence for ever holding them again, and consistently sub-par admins are still elected for life, only in the case that they don't shoot someone in broad daylight. Wikipedia is not a democracy, but if we are to make the comparison, there is simply no system of rational government in the world the elects its leaders for life, and only removes them in the case that a tribunal of other members of the aristocracy determine that they have committed a crime. GMG^talk 23:14, 28 October 2019 (UTC)

I'm open to considering that the lack of a desysop process short of ArbCom is impeding otherwise good candidates from passing an RFA. Do we have any data on that? Stifle (talk) 17:16, 30 October 2019 (UTC)

@Stifle: Well the number of applicants has surely been shrinking steadily. It is general knowledge that as the larger the project grows, so do it's standards, but the English Wikipedia has actually declined in the meanwhile. This is not to mention the re-admin bit, as I discuss above, where as far as anyone can tell, we've only ever had a single admin resysoped after removal for inactivity, and a single admin resysoped after removal for cause, things that are fairly common place on other projects, so much so that I'm not entirely sure where to link you to other than anywhere but here. GMG^talk 00:00, 31 October 2019 (UTC)

• Oppose The fact that RfA voters are terrified to promote anyone with the slightest deficiency in any small area shows that there is insufficient community confidence in the current ArbCom-based process. --Ahecht (TALK
  PAGE) 19:31, 28 October 2019 (UTC)

  The fact that some RfA !voters are terrified to promote anyone with the slightest deficiency in any small area more likely shows that we have some editors who are a little unreasonable in their expectations of what an admin is likely to do with the tools. · · · Peter Southwood ^(talk): 18:41, 30 October 2019 (UTC)

• Support. Give us a process that is compellingly better - David Gerard (talk) 22:31, 28 October 2019 (UTC)
• Regarding The argument against a consensus-based desysop have, at no point that I can tell, actually addressed the issue that if consensus is so easy to game, then why haven't these admins doing the right thing in controversial areas simply been community banned, because a simple consensus is sufficient to do so. I think the reason for this is that in community banning processes the complainant's own conduct is also reviewed - as is the history of their supporters. People wishing to game a consensus process tend to have unclean hands and many of them will know that they'll get themselves banned if they go to Arbcom or ANI. Also, at ANI or Arbcom you as a complainant are even more likely to run into a wall of opposition/sanctions than at RFA if you arguments don't hold water. Jo-Jo Eumerus (talk, contributions) 07:12, 29 October 2019 (UTC)

• If you mean to say that the normal consensus building process is effective at weeding out bad faith gamesmanship, well then yes, that's exactly why the first workshop proposal requires a centralized community consensus in order to open a recall in the first place. In fact, the standard to open a recall is set slightly higher than the standard for community banning someone. GMG^talk 10:39, 29 October 2019 (UTC)

• Oppose. Getting desysopped by Arbcom is like being eliminated in limbo by a pole hanging from a second story window: possible, but only for monumental mishaps. This is hardly an effective bar to misbehavior. Also, I agree that the current situation makes people unwilling to give RFA candidates the benefit of the doubt, since adminships are incredibly hard to lose. Spirit of Eagle (talk) 18:48, 29 October 2019 (UTC)
• Oppose Arbcom only deals with the difficult cases and I support that they continue to do that. The easy cases, none of which would be revenge-based or heat-of-the-moment nominations, or would attract coordinated groups of axe-grinders, trolls, and the like to take down all of the admins willing to work the hard cases, can and should imo be easily be dealt with by the community. Govindaharihari (talk) 07:15, 30 October 2019 (UTC)
• Comment Possibly the biggest problem with Arbcom is that they are too prone to decline. Perhaps there should be a mechanism by which the community can instruct Arbcom to take a case, after which they continue as normal. · · · Peter Southwood ^(talk): 16:08, 30 October 2019 (UTC)

I'd support this. Letting arbcom handle things would address any concerns about gamesmanship and politically motivated removals, and would also require less infrastructure than creating a brand-new "request for de-adminiship" process. Spirit of Eagle (talk) 20:39, 30 October 2019 (UTC)

Yep - that sounds good and may work: the community can bring a 2/3 vote or a 50% vote to throw it to arbcom, who can then examine it on policy - David Gerard (talk) 21:54, 30 October 2019 (UTC)

Now this, this is tempting. A standalone set-up would be good but it would also make a good third option for any recall procedure (I'd probably say 60% for the first and a plurality for the latter). Obviously ARBCOM's work will up a little, but I think it would genuinely ease some of the problems with ARBCOM taking cases. Should probably be split off into proposal 4. Nosebagbear (talk) 13:59, 31 October 2019 (UTC)

If it's added as a proposal, and gains support (or a later consideration gives it support), that would probably need to be put as a proposal for an ARBCOM policy amendment Nosebagbear (talk) 21:03, 31 October 2019 (UTC)

This would definitely need to be an amendment to ARBPOL, meaning the consent of the committee or 100 supports regardless of the consensus, even if there is no consensus or consensus against, but it receives 100 supports. I'll just let that stew on anyone arguing that ArbCom is somehow an extension of community consensus. GMG^talk 23:32, 31 October 2019 (UTC)

• Weak oppose I might be able to get on board with this if ArbCom is easier and less bureaucratic, and if the community can bindingly throw a case at ArbCom. As I might have said earlier, the whole "bad-faith desysop" argument, while not entirely without merit, not only fails to assume good faith of the community but runs contrary to NOBIGDEAL by painting admins as some holy caste whom the big, bad, crowd is out to get. – John M Wolfson (talk • contribs) 20:08, 1 November 2019 (UTC)
• Stifle, your proposal already has community consensus, but the level of dialogue in these workshops has gone down hill so fast that no one is going to comment here, halfway down the page after a lot of other text. TonyBallioni (talk) 03:22, 3 November 2019 (UTC)
• Support. At least until we fix RfA to the point where meaningful numbers of new admins are being promoted. Guy (help!) 22:34, 3 November 2019 (UTC)
• If there is to be a desysop process, the deal-breaker for me is some kind of mechanism that enforces a requirement for substantiation of all allegations. If you make a claim without evidence, your vote will be struck. None of the sort of "I have a vague negative feeling about this user"-type opposes that are sometimes allowed to remain counted at RfA. We need actual diffs, perhaps in an /Evidence subpage, and due consideration of alternative remedies, such as editing restrictions or sanctions on other editors who are also involved in the conduct dispute. And perhaps the outcome of the discussion should be decided primarily by a group of editors who are annually vetted for their good judgment and experience.... Support. Mz7 (talk) 06:49, 5 November 2019 (UTC)

Workshop (4)

The community may hold a discussion at the administrators' noticeboard to determine if the Arbitration Committee should hold a case to examine an administrator's conduct. Should the discussion reach a consensus in favor of holding such a case, the Arbitration Committee shall open a case to examine the conduct of the administrator in question. While this process will not require the Committee to take any specific actions or remedies, the Committee must open the case, and must complete it unless the administrator resigns their privileges during the case. An administrator who resigns adminship while a discussion whether to direct the Committee to take a case about them is underway shall be considered to have resigned under controversial circumstances, and may only regain the tools by passing a new RfA.

Seraphimblade ^{Talk to me} 22:44, 2 November 2019 (UTC)

• This would require that Wikipedia:Arbitration/Policy#Requesting arbitration be amended. In order to submit an amendment for ratification, 100 editors must sign a petition in favor, or a majority vote of the committee must agree to submit it for ratification. Wug·a·po·des​ 01:11, 3 November 2019 (UTC)

  The committee could choose to enact this as part of its arbitration procedures as soon as it likes. To place it beyond the scope of the arbitration committee to rescind in future, though, an amendment to the arbitration policy is required. isaacl (talk) 02:27, 3 November 2019 (UTC)

  The more I look into and think about this, the more I'm convinced ArbCom could not do this by motion. WP:ARBPOL, which supersedes Committee internal rules, is pretty explicit that the committee can deny hearing any case it wants and cannot be bound by external consensus. They could pass a non-binding resolution stating that they will take any case which is the result of a discussion with consensus to send to ArbCom, but ARBPOL prevents it from being binding and forcing them to hear such a case. The critical part of ARBPOL is "[The Committee] will not be bound by the views of the parties to the request and other interested users". By my reading, consensus from an AN discussion to send to ArbCom falls under "views of the parties ... and other interested users", so unless that part gets changed a "Sense of the Committee" resolution is about the most that can be done. Wug·a·po·des​ 00:36, 4 November 2019 (UTC)

  I don't know about by motion. Though of course the community has the option of putting forth a suggestion to the arbitration policy, but regardless it says ArbCom can set their own policies under it by motion. And it actually would not be unprecedented for ArbCom to have an "auto-accept" criterion for a case, though I only know of it happening once: Wikipedia:Requests_for_arbitration/Daniel_Brandt_deletion_wheel_war#Arbitrators'_opinions_on_hearing_this_matter. Seraphimblade ^{Talk to me} 02:49, 4 November 2019 (UTC)

  You'll notice that that particular clause was not included in the current policy ratified in 2011, and would no longer apply. However, I'd rather they just say that they'd automatically review all requests for desysop without requiring the noticeboard discussion, if this was to go forward. Risker (talk) 03:25, 4 November 2019 (UTC)

  The arbitration committee can deny any case request if it wants; it can also choose to decide to accept them based on specific criteria if it wants. It can make any rules it likes regarding its internal procedures. Although it is not bound to follow a suggestion from the community on setting such criteria, it can choose voluntarily to adopt them. However in theory nothing would stop it from rescinding those rules whenever it wishes. Community suasion would be the only tool to get the committee to avoid doing this arbitrarily. isaacl (talk) 04:33, 4 November 2019 (UTC)

• Please change "under a cloud", an expression that isn't used in much of the English-speaking word, to what I assume you mean, "under controversial circumstances". I think we should be upfront in what we mean when we're imposing penalties on people.

  Otherwise, I agree with Wugapodes; if it is to become a requirement (ironically, the only type of required case delegated to Arbcom), it would require an amendment of the Arbcom policy. Risker (talk) 02:34, 3 November 2019 (UTC)

• What's Arbcom's current acceptance rate for cases from noticeboard threads closed with "send to Arbcom" consensus? Isn't it close to 100% already? – Levivich 02:50, 3 November 2019 (UTC)

• I don't know a particular number. I know some above have stated that ArbCom is, at times, too hesitant to take such cases in their opinion. I know that when I was on the Committee, the general consensus was that, since only ArbCom can address administrator misconduct, we should err on the side of accepting any cases alleging such misconduct unless they were clearly frivolous. But I don't know if that's always been so. Seraphimblade ^{Talk to me} 03:36, 3 November 2019 (UTC)

That was the prevailing opinion back when I was on Arbcom, even longer ago than you, Seraphimblade, so even if it wasn't always so, I think it would be safe to say that it's been consistent for the last 10 years. I appreciate your working to come up with a different idea, but given the tone of some of the comments just on this page (without even dealing with allegations about specific admins), I'm genuinely concerned about mandating an additional dramafest location. Risker (talk) 03:41, 3 November 2019 (UTC)

• Support this and endeavouring to get an ARBPOL update (I'd suggest lobbying the soon to be incoming Arbs so we can avoid needing to find 100 editors twice). Nosebagbear (talk) 15:01, 5 November 2019 (UTC)
• small support I like the idea as a benefit to community empowerment, although I don't think it will be used much and see some concerns regarding Arbcom possibly having to judge community concerns over policy exceeding current arbcom remits. Considering all of the previous, I don't see a danger of much additional drama as per Risker's concerns. Govindaharihari (talk) 08:42, 6 November 2019 (UTC)
• Support I believe this has the best chance of being a useful means of removing tools from an admin based on community consensus. It is still useful to have a small body of trusted users to administer something resembling due process before tools are removed, but compelling the ArbCom to act on significant community concerns would at least help the situation. --Jayron32 18:30, 13 November 2019 (UTC)

Workshop (5)

The community are allowed to, using WP:CONSENSUS, to remove the administrative permissions of users they believe are long term inactive, a WP:RFA would be then be required for the user to have those permissions returned.

Govindaharihari (talk) 09:39, 6 November 2019 (UTC)

• We've just been through quite a lengthy pair of RfCs which covered this aspect - it did in fact shrink the maximum time permitted before inactivity removed the tools in the current setup. That seems to work well enough for now. Nosebagbear (talk) 00:00, 7 November 2019 (UTC)

  Thanks. Yes I know but that is still not stopping users with advanced permissions turning up every couple of years or whatever it is now and making one or two edits simply to keep them without any real need or any benefit to the project. Govindaharihari (talk) 05:42, 7 November 2019 (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.