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

Interim summary

It's been about two weeks since the start of the RfC and a large number of editors have given opinions. While that's wonderful, it also means editors new to the discussion are unlikely to read all 40+ comments, so I think it's worth looking back at the discussion to try and distill the main points that have been brought up.

---

The community is divided on whether there should be a binding community de-sysop procedure. Some editors are opposed to a community desysop procedure on principle, however many more are concerned about the specifics of the process and the ways it would affect our community and its members. Editors, regardless of their opinions on the question, have two major concerns: an unstructured community desysop structure may have a chilling effect on admins working in controversial areas and that any process with sufficient safeguards would just duplicate ArbCom. In order to address these issues, some suggestions for and desired features of a desysop process have been raised.

The concern with chilling effects is due to the work some admins do in controversial areas. Significant off-wiki collusion has been a problem with the Church of Scientology coordinating edits to promote their organization on Wikipedia and nation states have tried to influence editorial decisions to suit their political objectives. Administrators are needed to work in these contentious areas and enforce policies to prevent disruption. Those concerned of a chilling effect argue that if an unstructured community desysop process were implemented, organizations can collude to remove good administrators who stand in their way. Some editors also worry of on-wiki collusion and the ways a community desysop process would make it harder for popular but tendentious administrators to be removed due to their popularity. Other editors challenge these views as a failure to assume good faith, and that if an organization can game a community desysop procedure then no consensus based process could succeed. Editors also pointed out that the existing (and less stringent) community ban procedures can currently be used against administrators working in controversial areas, but have not been subject to this sort of gaming.

Some editors believe that ArbCom is a sufficient process, or that any process which tries to address the issues of collusion and mob justice would have a similar structure. Editors disagree about the difficulty of getting a case accepted. Some editors say it is hard to get the Committee to hear a desysop case without "smoking gun" diffs of particularly bad actions, and so long term, low level issues that erode community trust are not easily addressed by the committee. Others say the Committee has an appropriate bar to hear cases, but that they cannot hear cases of their own initiative: editors must make a request. Some have suggested that instead of developing a new community desysop process, arbitration and administrator policies can be strengthened by making expectations explicit. These amended policies could set the bar for hearing desysop cases intentionally low, or raise the conduct expectations for admins so that when cases go to arbitration, conduct violations are easier for ArbCom to identify and sanction. Some suggested forming an ArbCom subcommittee specifically for handling desysop requests.

Editors were also concerned about the process turning into a spectacle. Specifically the individual being discussed is likely to have a tiring and unhappy week regardless of the merits of the discussion. Some pointed to structured procedures like ArbCom as a way to mitigate these concerns, however others argue that ArbCom can be spectacle at times.

Some editors believe that the benefits outweigh the costs, and that making it easier to demote administrators would make it easier to promote them. Given the perceived difficulty of removing administrator rights, promotion is seen as a big deal because it creates a risk that low level disruption will not easily be addressed. Editors say that this leads to higher standards for RFAs and difficulty for editors to move between admin and non-admin. Examples from other projects such as commons where admins removed by recall go on to pass subsequent RFAs, sometimes multiple times. They argue that by allowing community desysops, editors will be more willing to promote more administrators including those desysoped for cause or with less than perfect editing history.

Therefore proposals for a community de-adminship process will need to be resilient to gaming, prevent spectacle, and meaningfully distinct from ArbCom in order to find consensus.

But this balance is hard to strike and ultimately a number of editors are opposed in principle regardless of the specifics.

---

It's late and I'm tired, but I'll be back to work on this a bit more. Feel free to edit the summary, in fact, it makes everyone's lives easier if you do. Ideally this will go in the lead at the end of the RfC so hopefully we can get a nice summary of concerns and desires, and maybe even update Wikipedia:Requests for de-adminship for the first time in a few years. Wug·a·po·des​ 09:49, 30 October 2019 (UTC) P.S. Thanks to everyone who has commented so far! It was nice to read through the comments again as there's some really great insights.

Points not covered in the interim summary

• The summary notes that a popular-vote desysop process risks collusion removing an admin who does good work in a contentious area. That is unlikely, but the real problem is that such admins face enough hassle and it is guaranteed that some of them would stop working in a contentious area if they needed to also respond to walls-of-text at a desysop hearing. See WP:ARBGG where, even without the spectre of a community desysop, only one or two admins remained who were willing to deal with the never-ending disruption.
• I cannot see any examples where an admin should have been desysopped yet wasn't. I have seen a couple of old-time admins who were out of their depth in the Wikipedia of 2019, yet they didn't do any damage other than pontificate. Arbcom would not act because there was no actual problem beyond cluelessness. They would have been removed with a community desysop and we might have felt better, but there was no actual problem. Are there any examples where a desysop was needed yet did not occur?

I think developing a summary is a good idea, and offer these thoughts for possible inclusion. Johnuniq (talk) 22:27, 1 November 2019 (UTC)

Thanks! Feel free to add these points or expand on them in the summary above. I've only got so many eyes and can miss points or wrongly characterize things; criticism and bold edits are very welcome. Wug·a·po·des​ 22:52, 1 November 2019 (UTC)

OK but I don't want to undue the summary too much with my feelings. For point 2, I do not have any examples. Have you, or anyone noticing this, seen any? Johnuniq (talk) 00:21, 2 November 2019 (UTC)

I think this question – who should have been desysoped that wasn't – is both a politically-impossible question to answer (I, for one, am not going to start naming names), and also misses the point of a community-based desysop (which, at least for me, is not at all about being able to desysop admins that Arbcom didn't desysop). For me, this is about making -sysop easier for the community for the purpose of making +sysop easier for the community. For me, a community-based desysop is not about removing admins, but about adding more admins. – Levivich 17:51, 2 November 2019 (UTC)

You don't have to name names; just link to a discussion. Johnuniq (talk) 22:35, 2 November 2019 (UTC)

That would be naming names, John. I'm not going to identify an admin who I think shouldn't be an admin. It's not nice, and it's not necessary, IMO. – Levivich 22:39, 2 November 2019 (UTC)

Making a claim and then literally refusing to provide any evidence for it when called on it doesn't lend strength to your claim - David Gerard (talk) 11:26, 3 November 2019 (UTC)

If you want specific examples, I've already given some in the main discussion. Here is another, where the user was so grossly unqualified that we had crats outright refusing to flip the bit in their individual capacity, and urging the candidate to withdraw. No matter what you do to the rules of inactivity standards, you are only going to make different rules that need to be gamed somewhat differently. Since that time, the user has made exactly zero logged actions, and all of a dozen or so edits. If we want to balance the scales, this user will need to continue at this rate for several years just to break even on the community time spent on their resysop discussion. ArbCom will not remotely entertain a case request based on obvious bad faith gaming of our inactivity standards. That's why none of the users in that discussion, myself included, seriously entertained the idea of opening one.

As I pointed out in the main discussion, here is a user who needed more of a year of sustained poor decision making in order to float an ArbCom case, and that was after the community determined that they had clearly misused the tools. Similarly our last desysop for cause came only after at least three ANI threads, and seven previous cases examining the user's conduct. It's not simply a situation of desysops being needed where they did not occur, but if we look as the desysops for cause that have occurred, particularly for reasons of chronic poor decision making or toxicity, the problem must persist for months or years, and degrade into an intolerable crisis in order to get anything done.

It's also not necessarily even about actually desysopping anyone. Such a system would be most effective where there are no actual community desysops at all, because community feedback doesn't take the form of toothless votes of no confidence ([1], [2], [3]), hoping the user will listen pretty please, because if they don't there's not very much we can do about it anyway. In the best of scenarios, users take community concerns seriously because the discussion carries actual weight, they are responsive to those concerns and adjust accordingly. We improve the community and our governance, and things don't need to escalate to the point of needing to talk about desysop at all. The system we currently have is not that system, and everyone well knows that the grey area between "net-positive" and "intolerable warranting a case request" is a place where users can live indefinitely. GMG^talk 13:32, 3 November 2019 (UTC)

David Gerard, straw man. Who made the claim that we need community based desysop in order to desysop admins that arbcom hasn’t desysoped? It’s not “my claim”; I didn’t make the claim; and I actually don’t see anyone making this claim as a primary reason for community based desysop. Yet at the same time, it’s fairly easy to substantiate, as GMG has done. Let’s dispense with the fiction that there are no bad apples among us. Let’s also rise above focusing just on specific bad apples. – Levivich 14:38, 3 November 2019 (UTC)

Summary of arguments

Arguments in favor

1. Consensus decision making. Community consensus is sufficient for an editor to receive access to administrator tools, and therefore community consensus should be sufficient to remove access. If the community can be trusted to grant access, then it should be trusted to remove access.
   • Counterargument 1: While that may be true "as a matter of principle", as a practical matter, there are good reasons not to have a direct community-based desysop process (such as the reasons listed in the "Arguments against" section below).
2. Will improve RfA. Participants at RfA have high standards because if the community promotes a borderline candidate and regrets it, removing administrator tools is difficult. These high standards suppress the number of RfA candidates. RfA participants would be more willing to support currently-borderline candidates if they knew community consensus could remove admin rights without having to meet the standard of an Arbcom case. RfAs would be less contentious if the decision was not for a "lifetime appointment". A less contentious climate at RfA would attract more editors to request adminship leading to more admins for the project.
   • Counterargument 1: No evidence has been provided that projects with community-based RfAs and RfDAs have observed any of these benefits.
   • Counterargument 2: RfA reforms without a desysop process could provide these same benefits with different or fewer drawbacks.
3. Addressing chronic-but-never-acute problems. Currently, an admin will only lose admin rights due to egregious misuse of tools, which generally means a clear and serious violation of a written, unambiguous WP:POLICY. There is no method for removing admins who never rise to this level of "acute problem", but who may nevertheless be problematic. For example, an admin who is chronically rude, and who loses the community's trust because of their chronic rudeness, may never be desysopped if their "rudeness" does not rise to the level of serious incivility.
   • Counterargument 1: This is a feature, not a bug. If it doesn't violate a policy, then an admin's action does not rise to the level of meriting a desysop. What is a "chronic problem" in one person's eyes may not be a problem at all to others. The very reason for a representative-based Arbcom-style desysop procedure is that trusted editors will vet complaints to separate those that are serious and supported from those that are not.
4. Constant community trust. An RfA directly measures the community's trust in an editor. Each administrator needs to maintain the trust of the community whether or not the community can remove administrator access. Without a community desysop process an admin may lose community trust, but continue to be an admin regardless. Arbcom does not, and cannot, measure the community's trust; rather, it only looks at whether an admin's actions have violated policy. There is currently no way to address an admin who has lost the community's trust, but hasn't violated any policies (or hasn't violated policies enough to merit an Arbcom case).
   • Counterargument 1: An admin who hasn't violated a policy hasn't lost the community's trust.
   • Counterargument 2: Arbcom cases allow for community input, and therefore, Arbcom can measure the community's trust, and can take appropriate actions if that trust is lost.
   • Counterargument 3: The community can amend policy to make unwanted actions violations that ArbCom can act on, or direct ArbCom to take certain actions.

Arguments against

1. Open to gaming and abuse. A community-based desysop process can be abused by bad faith editors. Disgruntled editors could initiate desysop procedures against administrators enforcing policy, and groups of editors could attempt to enact mob justice on administrators they do not like. Even if this does not happen in practice, the potential threat of this happening will have a chilling effect on admins who will not enforce policies when the action would be unpopular. Conversely, a problematic administrator could avoid desysop if they are popular enough and turn the process into a popularity contest.
   • Counterargument 1: This is already possible on enwiki, e.g. via community-banning admins, or taking admins to ANI or Arbcom, yet it does not happen, or it happens so rarely as to be negligible and thus has no chilling effect.
   • Counterargument 2: There is no evidence that this happens on other wikis that have a community-based desysop.
   • Counterargument 3: Controls can be implemented to mitigate abuse. Various wikis have systems with various controls; various admins subject to WP:RECALL have systems with various controls; and many such systems have been proposed on enwiki.
   • Counterargument 4: This argument assumes bad faith on the part of our community of editors.
2. Instability. Community-based sysop and community-based desysop will lead to instability, as editors are made admins, removed from adminship, and restored to adminship, repeatedly, based on "shifting political winds" in the community.
   • Counterargument 1: This is a feature, not a bug. Adminship should be WP:NOBIGDEAL, and should not be a lifetime appointment, so it's a good thing if editors rotate in and out of the admin core. There should not be "lifetime appointments" or "lifetime bans" on adminship. The community changes over time; the admin core should change over time with it.
3. Time wasting. The RfAs and de-RfAs will take up editor time without providing meaningful return for the investment of time.
   • Counterargument 1: This is unknowable until we try. If it results in a huge increase in quality admins, then we will have obtained a meaningful return on our time investment.
   • Counterargument 2: This could actually save time that is currently wasted on futile or fruitless ANI and Arbcom reports.
4. Bad feelings. Repeated RfAs and de-RfAs will involve much editor time evaluating admins' performance. This will engender bad feelings between admins and the community, especially their critics. Admins shouldn't feel constantly under a microscope.
   • Counterargument 1: Admins are already subject to criticism; to some extent, this is an unavoidable consequence of holding a position of responsibility or authority in any community.
   • Counterargument 2: Controls can be implemented to mitigate this effect. For example, de-RfAs do not need to be contentious, confrontational conversations, just as other dispute resolution forums do not need to be.
   • Counterargument 3: Other dispute resolution forums, like Arbcom, already engender bad feelings. There is no reason to think contention will be worse in a de-RfA than it is in an Arbcom case, or ANI thread, or any other consensus-building process we have.
5. Unnecessary. No evidence has been presented to show that there is actually a problem that the current system does not address. No one has yet presented evidence that the wiki is overrun by admins who should not be admins but who cannot be removed from adminship.
   • Counterargument 1: We do have evidence that we don't have enough admins and that not enough editors are standing for RfA. Specifically, the admin-to-article and admin-to-editor ratios continue to fall.
   • Counterargument 2: It is untenable for editors to publicly "prove" this by providing a list of names of "bad admins". Thus, this argument requests proof that may exist but that no one is willing to publicly provide.
6. Redundant. Any proposal which has sufficient safeguards would wind up mimicking the structure of ArbCom.
   • Counterargument 1:

Discussion about summary of arguments

I appreciate Wug's invitation to edit the interim summary above, but I didn't want to TNT it altogether, so instead, here is an alternative summary format, in list style, with pros/cons. This is very much a first draft. Any editor is invited to edit this summary of arguments directly. That includes adding, condensing, reordering, changing the wording, etc. I think we'll all be well-served by a short, neutrally-worded, list of the pros and cons, including counterarguments to each pro and con, and counterarguments to the counterarguments, etc. This could help us segregate and identify the issues in dispute, and see where, for example, we might want to gather more evidence about one thing or another. Thanks, by the way, to everyone participating in this discussion; it's been very interesting to read. – Levivich 18:55, 2 November 2019 (UTC)

@Levivich: This is really useful! From reading the discussion do you think there's consensus on how these should be weighted? For example, I think there's consensus that "open to gaming" is a strong concern as many editors brought it up and the workshoped proposals are working hard to address it. While those counterarguments were made (and worth keeping in your list as documentation) I don't think the community views them as very strong objections. For example TonyBallioni gives a rather serious example of a user who used ANI to harass him, and that editor wound up blocked by ArbCom for off-wiki harassment. Hut 8.5 makes good points about how ANI is just generally toxic, and raises a point about how it will make it harder for unblockables to get desysoped. Conversely, I think the community has agreed that the "unnecessary" point you list is not particularly strong for the reasons given in the counterarguments. I'd be interested in your thoughts. Wug·a·po·des​ 22:07, 2 November 2019 (UTC)

Thanks, Wugapodes! (I'm pretty sure I got the idea from isaacl.) I agree with your analysis about the weight, which is why I listed "gaming" first and "unnecessary" last. I'm sure that I haven't captured all the arguments/counterarguments, nor stated the ones I've captured as well as they could be stated, nor ordered everything in the right order. But I'm hoping other editors–particularly those making the arguments/counterarguments that are listed (and that aren't)–can make necessary tweaks. W/r/t Tony's example, I think the counterargument for that is that the ANI thread to desysop him was promptly identified as entirely unsubstantiated and closed–I'm among the editors who see that example as an example against the gaming argument, rather than supporting it–I think bad-faith filings will be quickly identified as such. I'm thinking the "gaming" thread might be one where we list counterarguments to counterarguments, because I agree it's one of the big considerations for editors and one of the most-discussed aspects. I do agree this is the #1 argument against–the one thing everyone is worried about. W/r/t Hut's points, my intent was to capture the toxicity aspect in "bad feelings" (which maybe should be renamed to "toxicity"), and to capture the unblockables point in "popularity contest" (which maybe should be renamed to "unblockables"). Thanks, btw, for starting this talk page discussion, I think it's a very productive move at this point in the conversation. – Levivich 22:29, 2 November 2019 (UTC)

I was in fact considering recasting the summary into separate lists of arguments with counterpoints, as I just find that an easier format to read, so thanks for doing it first :-). In the interest of conciseness, I'm somewhat wary of getting into too much detail on weighting, as I feel those reading the lists can reach their own conclusions. However it is useful to lay out the argument and the counterargument with links to associated discussion. I wouldn't starting listing counter-counterarguments; I'd just roll that up into the original argument and revise both argument and counterargument accordingly. isaacl (talk) 22:40, 2 November 2019 (UTC)

Regarding the term "toxic", as different people interpret it differently, personally I would use more specific terms like animosity, combativeness, or whatever other characteristics you are referring to. In a similar way, I would avoid using the term "unblockable" and prefer describing the context that makes a given user difficult to block. isaacl (talk) 02:18, 3 November 2019 (UTC)

I object quite strongly to the term "unblockables" being used anywhere. There's actually no such thing, as has been proven time and time again. Anyone can be blocked, should their behaviour be egregious enough, and that includes administrators and longterm editors. There are lots of editors (including admins) I've seen deemed "unblockable" who have been blocked and whose blocks have stuck. So we should stop pretending that's actually a thing. The same is true of the term "toxic"; this is almost invariably used for "someone who does something/holds an opinion I don't agree with". One of the first times I saw that term used, which involved blocking a supposedly toxic administrator, resulted in the administrator who did the blocking having to give up the ability to block anyone. Indeed, I'd be inclined to suggest that anyone using the term "toxic" to describe another editor should be blocked for making a personal attack. Risker (talk) 22:12, 28 November 2019 (UTC)

I would not use the term and I don't think any one can literally never be blocked regardless of circumstances, but I do think that the difficulty in gaining a consensus to block popular editors is a thing, be it good, bad, neutral, or some combination of the three. In a similar way, "toxic" has connotations that increase the sense of confrontation, and so isn't a great term to use. Yet there are certainly conversations that unduly personalize the discussion and are unnecessarily confrontational, which discourages collaborative participation and results in editors being less willing to engage in certain actions or conversations. isaacl (talk) 22:54, 28 November 2019 (UTC)

I've replaced the terms with phrases that I trust reflect your intent. isaacl (talk) 22:40, 28 November 2019 (UTC)

Thanks. I agree better to avoid the terms, they distract from the point. – Levivich 01:21, 29 November 2019 (UTC)

• Sorry I was late to find these - both summaries are excellent. Some of the counteraguments have counter-counterarguments, but perhaps best if we don't topple down that rabbit hole just yet. Nosebagbear (talk) 21:41, 28 November 2019 (UTC)