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

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

• 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, Template:Re: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)
• 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)

• 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 hold 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. 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 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)

Descriptions of de-adminship systems on other projects

• 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 treshold 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.

References

See also

• Wikipedia:Requests for de-adminship information on history of de-adminship processes
• Wikipedia:Administrators/RfC for binding administrator recall most recent RfC from September 2015
• c:Commons:Administrators/De-adminship de-adminship process on Commons
• Category:Wikipedia administrators open to recall