Wikipedia:Requests for comment/Desysop Policy (2021)

Even several opposers seemed to agree that Tony's proposal was well crafted. That it fell so far short of consensus suggests how difficult a task it may be to create a significantly more successful one. Especially as no-voters arrived from partly opposed perspectives: Some felt the proposal would make de-sysoping too hard, v some who felt the opposite. (or at least that it would have a net discouraging effect on Admins.) Yet with the benefit of hindsight, the following might help:

1) Have better (luckier) timing. Many feel that the current Arb system is working well. So before launching the next attempt, maybe wait until such a time when there's either more community discontent about Arbs making it too hard to bring a case against an Admin, or conversely that the Arbs are passing desysop remedies too easily. Then less might oppose with the 'solution in search of a problem / Arbcom is working fine' argument.

2) While ~20 opposed due to feeling the proposal would make it too hard to de-sysop, these were outnumbered about 4:1 by those concerned it would make de-sysopping too easy (or at least provide too little protection against admins being harassed by the process, even if such attempts were not likely to result in tool loss). So a process that is more difficult to trigger (though not necessarily more difficult to get the end result) may be more likely to get consensus.

3) If this can be done while retaining suitable safeguarding, make the next proposal simpler.

4) Maybe reduce the requirement for a 3 admin sign off.

5) Don't require the admin to transclude their own de-RfA (but retain some ability for them to control the timing, maybe give them a greater than 2 week window for this.) Over 10 voters expressed a preference for this, including some of the supporters and a neutral.

6) Possibly introduce as a trial, promising a revert to the status quo after 1 year unless a 2nd discussion green lights a continuation with a clear consensus.

7) Prior to the next proposal, maybe have a RfC to help fine tune it, perhaps as exemplified by Silktork in the "comments" section.

8) Read this whole discussion – there's about 50 suggestions for improvement I've not touched on above, but which might resonate more with current community thinking, whenever someone gets round to re-proposing.

Overall, an exceptionally high quality discussion, both in terms of collegiality and strength of argument. It's challenging case to sum up, as there were multiple partly incompatible and even incommensurable lines of argument, both for and against.

This is WP:NOTAVOTE , yet I'll make use of numbers to indicate relative contribution towards consensus. Other than the simple 'totals' , all numbers given are subjective. For example, if you look closely, on some of the individual votes, it's not always easy to classify their rationale. Yet I hope the figures are of some help in summarising how many held the various widely shared views.

Support vote break down. 168 votes in total.

In contrast to the Opposes, very few supports had consistency issues with other support rationales. The clearest exception to this was Maile's vote which was conditional on upping the threshold to retain an admin from 40 > 60%.

About 20 supporters expressed reservations. (This being a high subjective figure - some might say lower than 10 if they count only the stronger reservations. Or >50 if they count folk who made suggestions for modification to Tony's proposal, with only a faint hint of reservation.)

Most support votes were essentially per Proposal, but quite a few advanced additional arguments.

DGG & AKG made especially strong individual votes – not that I agreed with them, but as former Arbs, their position that the wider community is better placed to call the shots on desysops, had to carry extra weight.

A few made the extra argument that the proposal would make new RfAs easier to pass. This was not rebutted, so slightly added to the support consensus.

Richite333 made the argument that opposing admins might have their view discounted on COI grounds – I agreed with this, but only very slightly.

Sam-2727 made a concise but effective argument rebutting the Oppose view that the proposal would lead to frivolous filings, which again slightly added extra weight to the support case.

Several, most tellingly Swarm, pointed out the inconsistency in the oppose vote on the 'too easy / too hard' to desysop dimension. This reflected my own reading of the Oppose case, to the extent of making me discount it collectively by about 5% . This being by far the biggest weighting change – all the others points had at most a 1% influence. But it still only brought the weighted support % close to 60%. So far from the threshold for consensus, especially as on balance other factors pushed the weighted consensus partly back down in favour of oppose...

Several made the 'perfect is the enemy of the good argument', and the allied case that we won't be able to properly assess the pros and cons of the Proposal until after its been tried. Though not fully refuted, several editors countered this idea, most especially by Dirk Beetstra.

Several suggested that similar proposals had worked on other large wikis, along with the closely related view that data trumps speculation. However, in terms of providing specific and well presented data, none could compare with Hammersoft, so I considered this argument well rebutted.

Oppose vote break down There were 138 oppose votes in total.

About 80 could be classed as opposing largely out of the concern that the proposal made desysopping 'too easy' , or at least had too little protection against being used to harass admins. Comments by Beeblebrox and Sandstein were among the most persuasive in this regard. Conversely, there were about 20 Opposers who seemed to feel the proposal would make it too hard to desysop. Sandy Georgia and Joe Roe made especially strong arguments on these lines.

And there was a handful of voters who (correctly in my view) pointed out that the proposal risked doing both. So when looked at closely, the Oppose case seemed less incoherent than it first appeared.

A couple of voters made the case that the whole Proposal was based on a misconceoption - that Arbcom is already a community process. While this only seems true up to a point, it added slight extra weight.

More common oppose rationales included that the proposal was too complex and that it was an unnecessary solution in search of a problem. Others felt it might create an unpleasant spectacle that could add to negatively and interpersonal strife. And then there were a few opposes simply due to not liking elements of the proposed process. Perhaps only a single vote could be slightly discounted for not being specific enough.

Editors who especially added to the weight of the oppose case, without being easy to succinctly classify, include Hammersoft, Huggums537 & NSK92. While less cohesive than the support votes, I felt that the oppose votes were generally stronger on an aggregated individual bases.

The neutral votes also added slightly to the Oppose case (But only very slightly – if you want your statement to effect consensus, you should make it either in the Oppose or Support section. In my view at least, crats almost never pay much attention to a neutral vote, even when it makes an exceptionally well argued point.) In terms of highlighting parts of Tony's proposal to tweak, the Neutral by RoySmith may be especially helpful.

Reading the overall discussion outside the Voting blocks, the balance seemed to lean towards Oppose, especially in the 'Hammersoft' & 'Elephant' sections. (Though again, this only very marginally effected my reading of no consensus, unless Voters explicitly referred to the discussion section as part of their rationale.)

A final factor that slightly favoured Oppose, was the fact that over the last few weeks, the trend had been towards Oppose, including several voters switching votes in that direction.

All things considered, the Opposers did enough to quite easily block the formation of consensus.

PS - As it may be useful for newer editors to see which arguments had the most sway on a closers view of consensus, I mentioned a few editors who seemed to make the very strongest arguments. Literally over 100 editors seemed to make particularly noteworthy contributions, so the list could have been a lot longer. Also, strongest doesn't mean best – some of the most insightful or eloquent contributions, e.g. from Barkeep or Chicdat, were maybe too nuanced to have the strongest contribution to consensus.