Wikipedia talk:Requests for comment/Desysop Policy (2021)

Crat/Int Admin

Rschen7754 I’ve added this bit on crats per your suggestion. I can mass ping people who have already voted to this thread to notify them. TonyBallioni (talk) 03:14, 21 February 2021 (UTC)

@MelanieN, Schazjmd, OhKayeSierra, Sdkb, Ajraddatz, Amorymeltzer, Tavix, Thryduulf, Firefly, Tryptofish, Yngvadottir, ToBeFree, Xxanthippe, Billhpike, Britishfinance, Levivich, Power~enwiki, Tom (LT), Swarm, Beeblebrox, Ryk72, Eggishorn, 1.Ayana, Vaticidalprophet, and Dennis Brown: apologies for the mass ping. I've made the change noted above to allow this to be initiated to remove crat/intadmin rights, as well as specifying that those are automatically forfeit if one is desysoped. Rschen7754 has pointed out that stewards will not remove +crat without a policy basis, so this was needed since we otherwise could end up in the weird situation of having a desysoped forever bureaucrat who couldn't pass RfA. TonyBallioni (talk) 03:22, 21 February 2021 (UTC)

No worries about the ping. I'd priced that into my response already. (Always found it funny how you could technically be a crat and not an admin...) Vaticidalprophet (talk) 03:25, 21 February 2021 (UTC)

For interface administrators, community consensus about misuse and loss of administrator access are already removal reasons per WP:IADMIN#Removal_of_permissions, but I don't disagree with the addition. For bureaucrats, I hope it's mostly a theoretical issue, but there is indeed no reason why a successful desysop request after community consensus about tool misuse shouldn't lead to revocation of the bureaucrat flag as well. So the change is fine with me. ~ ToBeFree (talk) 03:32, 21 February 2021 (UTC)

No issues with that addition. -- Ajraddatz (talk) 03:34, 21 February 2021 (UTC)

Thanks for adding it. [1] was the case I thought of where stewards wouldn't do it but I'm sure there are others. --Rschen7754 03:43, 21 February 2021 (UTC)

Seems reasonable and uncontentious, but thanks for letting us know. ~Swarm~ ^{sting} 03:44, 21 February 2021 (UTC)

Thanks for the ping Tony - I half assumed as much and am happy to sustain my support. ƒirefly ( t · c ) 09:36, 21 February 2021 (UTC)

In case my comment gets lost in the long comments section, imo the intadmin part should be removed. Consensus at AN (the requirement for this proposal, too) can already revoke intadmin according to existing policy, without needing the rest of this, which makes it an unnecessary complexity. ProcrastinatingReader (talk) 09:48, 21 February 2021 (UTC)

Thanks for the ping, it doesn't change my !vote. Thryduulf (talk) 12:32, 21 February 2021 (UTC)

It doesn't change my opinion either. Schazjmd (talk) 14:46, 21 February 2021 (UTC)

Quite reasonable — I'm of the opinion that if there's a -sysop for cause or community decision, then -bureaucrat, etc. should follow by necessity. ~ Amory (u • t • c) 15:07, 21 February 2021 (UTC)

We already have -intadmin for -sysop regardless of reason for -sysop. — xaosflux ^Talk 15:34, 21 February 2021 (UTC)

Good change; still support. -- MelanieN (talk) 15:39, 21 February 2021 (UTC)

No issues, still support. Britishfinance (talk) 18:28, 21 February 2021 (UTC)

WL Notice?

A request to add this to WLN (MediaWiki:Watchlist-messages) is open - anyone with feedback on that please reply at MediaWiki_talk:Watchlist-messages. Thank you! — xaosflux ^Talk 20:18, 21 February 2021 (UTC)

WLN added. — xaosflux ^Talk 19:51, 22 February 2021 (UTC)

Proposed amendment

Although it may well be too late, I would like to suggest an amendment to the authors of this proposal. (This amendment is motivated by the process used by the German Wikipedia.) Retain the certification part of the proposal as is. But after that, instead of a desysop RfA, run a binding reconfirmation RfA. The question in this RfA would be if the user in should be granted (again) the admin rights; that is, does the user currently have the trust of the community to have the admin rights. The passing threshold would be the same as for new RfAs and it would be judged in the same way by the crats as new RfAs. No new standards would need to be introduced. Although the distinction may seem minor, I believe that phrasing the RfA question not as whether someone should be desysopped but rather whether whether someone should be reconfirmed as an admin makes the process more positive and less confrontational than the current proposal. Nsk92 (talk) 18:01, 23 February 2021 (UTC)

I feel it's certainly too late; there are over 100 votes already, and a major change such as changing the retention threshold from 40% to 65% would surely change multiple votes. You can suggest it before next year's follow-up RFC. power~enwiki (π, ν) 00:16, 24 February 2021 (UTC)

I would oppose that, and I’m sure a significant number of supporters would as well. The numbers, though arbitrary, were picked for a reason: no one would really like them but enough people could get behind them because they weren’t the worst that could happen and there were other parts of the proposal that they liked. The difficulty with a desysop RfC is what Amory pointed out already: there are two types of opposes and they’re mutually exclusive. To get something like that to pass you have to use metrics that people can accept as a compromise. A new RFA isn’t a compromise so it’d likely fail. TonyBallioni (talk) 00:20, 24 February 2021 (UTC)

If I understood your reference to Amory's comment correctly, you mean the one where he mentions that there are opposes based on the "angry mob" concerns and there are opposes based on the 3-admin part of the certification requirement concerns, which they view as too entrenched. I don't think those opposes are mutually exclusive. To some extent I share both of those concerns. In the case of an admin crossing one of the unblockables, the 3-admin certification requirement will be no obstacle. Unblockables usually have a large fan following including admins (that's what makes them unblockables). In such cases the "angry mob" aspect of the process can easily take over. But, say, in the case of an admin who routinely makes bad vandalism related blocks against relatively inexperienced users, the 3-admin requirement may prove to be a serious barrier. Apart from these two types of opposes there are others. E.g. the last oppose, by Hammersoft, raises several objections, including 60% being an arbitrary number. I'm not sure that a successful proposal needs to be a compromise beftween different types of opposes. I think it may be sufficient if it addresses several of significant concerns raised. Ultimately, I prefer to think about this problem not in terms of what kind of proposal has the best chance of passing but of what kind of proposal would provide a better system. Nsk92 (talk) 01:14, 24 February 2021 (UTC)

Nsk92 unless I'm mistaken, it's never been known for a once desysoped admin to pass another RfA. Even ones who were otherwise highly active, well respected, and never misused their tools, and the December 2015 reform put the lid on that possibility for good. My main concern therefore is that there should be some form of appeal against corrupt Arbcom verdicts (a re-RfA is not an appeal), but that is not up for discussion here. The question is what is worse: being judged by Arbcom or hung, drawn, and quartered by a barbaric peanut gallery (ironically probably the former because they were elected on the premise of being honest, forthright, and equitable). Kudpung กุดผึ้ง (talk) 01:12, 24 February 2021 (UTC)

I must admit that I am not sufficiently familiar with the issue you mention. I don't know how many desysopped admins have tried to run for RfA again, if anyone tried more than once, how close they came to passing, when the last such attempt happened, etc. In general, I do feel that any form of community desysop procedure will, to some extent, make life more difficult for admins who perform difficult blocks and other difficult admin tasks (e. g. AE, enforcing DS in entrenched POV battles, etc). That's one of the reasons why I'm still unsure that implementing a community desysop procedure is the right way to increase admin accountability. Nsk92 (talk) 01:33, 24 February 2021 (UTC)

😐 Moneytrees🏝️^{Talk/CCI help} 03:54, 25 February 2021 (UTC)

If memory serves me right, SarekOfVulcan (talk · contribs) successfully re-RFA-ed. (It looks like it was technically a resignation under a cloud, but still.) power~enwiki (π, ν) 02:35, 24 February 2021 (UTC)

Not quite. Sarek (*cough cough*) resigned after Arbcom explicitly declined to desysop him. He then ran RFA3, which failed, requiring RFA4 later. One of the crats had stated that if he had just requested the bit back instead of failing an RFA, there would have been no barrier to resysop. After RFA3 failed, of course that went out the window. --IamaPOVpushingSPA (talk) 17:49, 25 February 2021 (UTC)

Everyking was successful in regaining his adminship, although it took many attempts.-gadfium 05:04, 24 February 2021 (UTC)

@Kudpung: you are mistaken. I looked at this in January 2020 and found that at, at that time 49 editors had been desysopped by arbcom for cause (i.e. not due to inactivity or as a precautionary measure) and who were not currently blocked or locked. Of those only approximately 10 had run for RFA following the desysop, 5 had been successful (not necessarily at the first attempt) and 5 unsuccessful (one or more times). The remaining 39 had not stood for RFA. See User:Thryduulf/What happened after a desysop for the full details. Thryduulf (talk) 04:46, 25 February 2021 (UTC)

(edit conflict) Looking at what links here for that page, I found that I did some further investigation: "Between 2015 and January 2020, only 3 editors desysopped by arbcom have run for re-RfA so there is really too little evidence to make any general statements about standards in this regard. Those three editors were: 1 (Rich Farmbrough) was unsuccessful because the issues that resulted in the desysop were continuing, 1 (Hawkeye7) was unsuccessful (twice) because of new issues since the desysop and 1 (Fram) was unsuccessful immediately after the case closed. Nobody who has taken the time to demonstrably resolve the issues that led to the desysop and has not done anything (else) that would prevent a successful first RFA since has stood." looking again now that is still true - nobody who was desysopped by arbcom stood for RFA in 2020 and none have done so far in 2021. Thryduulf (talk) 05:02, 25 February 2021 (UTC)

Thanks - interesting. It would also be interesting to know how many continued editing at all. I get the impression that, at least recently, many who run into serious trouble of various sorts leave & never come back. Johnbod (talk) 04:55, 25 February 2021 (UTC)

I didn't look at that but I will if I get a chance. I did note that as of January 2020 two of the 49 were known to be deceased. Thryduulf (talk) 05:05, 25 February 2021 (UTC)

@Johnbod: I've now updated User:Thryduulf/What happened after a desysop. The stats are now 52 editors desysopped for cause by ArbCom or the WMF Office who are not currently blocked or locked. Of those 52, 2 are now known to be deceased. Of the remaining 50, 26 made their most recent edit within the last 12 months (not counting one who has not edited since 2014 other than 1 day in April 2020). Of the three editors desysopped in the past 12 months, all have made their most recent edit within the last 7 days. No editor desyopped for cause has stood for RFA since September 2019. Thryduulf (talk) 14:07, 25 February 2021 (UTC)

Of those editors desysopped more than 1 year ago, 9 made their last edit less than 7 days after the desysop, 5 between 7 days and 1 year, and 36 more than 1 year after the desysop. Thryduulf (talk) 14:24, 25 February 2021 (UTC)

Wow - that was quick! Thanks very much. The trend appears to be the other way to what I thought (recent cases keep going). The death toll is mildly worrying, but the group size too small to make much of, I suppose. But rather a lot do shake WP's dust from their heels and depart. Johnbod (talk) 14:35, 25 February 2021 (UTC)

Of those 17 desysopped in 2015 or later and who are not blocked, only 2 have not edited within the last 12 months - user:Malik Shabazz (desysopped 2015, last edit 2019) and Alex Shih (desysopped February 2019, last edit October 2019). A quick glance at the contribuions suggests that the former's departure might have been (in part) due to the actions of now WMF-banned Icewhiz. The group size as a whole is really too small to draw any firm conclusions - only 13 people have been desysopped by arbcom in the last 5 years, two of whom (Edgar181 and Od Mishehu) were desysopped by motion for proven sockpuppetry and remain blocked. It is impossible to say anything reliable about resysoppings as nobody has even stood since 2019 and at least two of the three who did most recently would have failed a first RFA at the time. Thryduulf (talk) 15:51, 25 February 2021 (UTC)

I have to question "edited in last 12 months" is much use. Edits in last full month vs penultimate month of adminship would probably be a better comparison - someone whose editing contracts by 90% shouldn't be viewed in the same way as someone who keeps their previous editing load (bearing in mind that they would not have the time spent on admin activities) Nosebagbear (talk) 22:05, 1 March 2021 (UTC)

@Nosebagbear: Firstly that's much harder to measure, especially as many of them will have put a lot of edits into the arbitration case in their last month as an admin and the volume of edits varies immensely by editing style and task for both admin and non-admin actions. As just one example, closing an RfD results in typically about 1-3 edits per page per discussion and it's not too uncommon to get 10-20 nominations on a given day where consensus is obvious so an admin can rack up 30 or 40 edits pretty quickly, especially if they use automation. In contrast something like verifying and formatting sources on a long article can take far more time for a single digit number of edits. Additionally there are editors like me who go through phases of what tasks we do making any such comparison even less reliable. Thryduulf (talk) 01:45, 3 March 2021 (UTC)

Yes, "edited in the last 12 months" is a crude metric and can't capture more than "is/is not engaged with the project in some way", but I don't believe that relative edit counts can reliably tell us anything better. Thryduulf (talk) 01:50, 3 March 2021 (UTC)

Formatting/numbering issue in the oppose column

Oppose number 55 by User:Huggums537 appears to have broken the numbering in the Oppose column, both because of the use of the colon and of a talkpage quote that involves a bulleted list. I tried to fix the problem myself but it didn't work. Would someone more proficient please take a look? Thanks, Nsk92 (talk) 10:58, 24 February 2021 (UTC)

Nsk92, I gave it a tweak and I think that's sorted it. Worm^TT(talk) 11:04, 24 February 2021 (UTC)

OK, great, thanks! Nsk92 (talk) 11:09, 24 February 2021 (UTC)

What's a "desysop"?

10 minutes of Google searching and I still have no clue. Could someone enlighten me? Cheers, Fredlesaltique (talk) 06:26, 26 February 2021 (UTC)

The removal of sysop (system operator, i.e. admin) privileges. Extraordinary Writ (talk) 06:45, 26 February 2021 (UTC)

Thanks! Fredlesaltique (talk) 10:00, 26 February 2021 (UTC)

Process question?

For those of us who are not as current on wikiprocess as we might be, what's the actual process here? What percentage does this need to pass? -- RoySmith (talk) 15:19, 26 February 2021 (UTC)

As the strength of both sides is weighty, I would say anything above ~66% is fair to close. I would suggest that as this RfC involves admins and desysop, it be closed by a crat or a non-admin editor, than an admin. Lourdes 15:40, 26 February 2021 (UTC)

RFC's are not "votes" - they get closed by showing (or failing to show) that there is a consensus. As this is a proposed change to a policy, it should reflect a wide acceptance among editors. — xaosflux ^Talk 15:53, 26 February 2021 (UTC)

What Xaosflux said. For instance, numerically I am in support but I list several reservations I have with this proposal. Some people who share similar reservations (e.g. that 40% of editors would be enough to keep a sysop) are numerically in oppose. A good closer will read all this and consider whether there is consensus to change the proposal in this way and thus consensus to implement. The bolded votes are, in my experience as a closer, a helpful way of guiding the closer in the overall tenor of the comments (for instance I'm ultimately willing to live with the limitations while someone opposing for a similar reason is not) but should not be exclusively the method to close this discussion. Now I would personally be surprised if a no consensus/consensus against would be found if the number of supports were above 2/3 and a consensus for if the number of supports were below 3/5 but just because it would be surprising would not necessarily indicate it had been closed wrong. For that we would have to rely on the closing statement to see. Best, Barkeep49 (talk) 16:02, 26 February 2021 (UTC)

Historically, there has been a lot of politicking during RfCs about desysopping proposals, over what % should be needed for the proposal to be approved, with opposers hoping for a higher % threshold and supporters hoping for a lower one. (I'm not saying that anyone here has done that.) I hope that we can avoid that, this time around, and simply let the discussion process play out with the understanding that WP:CONSENSUS and WP:PROPOSAL apply. --Tryptofish (talk) 20:54, 26 February 2021 (UTC)

Come to think of it, maybe it would be a good idea for a Crat (or Crats) to close this one. --Tryptofish (talk) 21:07, 26 February 2021 (UTC)

The irony is that by asking it not be brought up, you're the first to bring it up... isaacl (talk) 21:06, 26 February 2021 (UTC)

I didn't say no one should bring it up. I just said pre-emptively that I hope no one comes along and says something like "for something this important, anything less than 65% percent should be a fail", followed by someone else saying "anything from 51% up should be a pass". There's nothing wrong with asking what the procedure will be. And now, I hope no one is going to say that they find those hypothetical statements about 65% or 51% too high or two low. (loud sigh) --Tryptofish (talk) 21:12, 26 February 2021 (UTC)

Tryptofish, I certainly agree that this needs to be closed in a more authoritative way than just some random admin coming along and closing it. Whether that's a admin team close, or a crat (or as you suggest, a crat team), or even bringing in a steward, it's important that the close be unassailable. -- RoySmith (talk) 21:20, 26 February 2021 (UTC)

I imagine it would have come up anyway. I'm just saying by bringing it up, the chances of it being discussed in ways you wish to discourage have probably gone up, if only slightly. isaacl (talk) 17:15, 27 February 2021 (UTC)

Wikipedia bureaucrats aren't super-closers, particularly for discussions like this that aren't based on policy, but individual estimations of the pros and cons of the proposal. Personally I'd look for a closer experienced with large, contentious discussions, whether or not the closer is a bureaucrat. (Bureaucrat chats are, by design, limited in the number of participants and at least in recent years, have been fairly cordial.) isaacl (talk) 17:30, 27 February 2021 (UTC)

Actually, Crats are chosen in large part for being trusted to determine consensus of RfAs and RfBs. --Tryptofish (talk) 21:30, 27 February 2021 (UTC)

Yes, I know; I didn't say anything contrary to that. isaacl (talk) 21:51, 27 February 2021 (UTC)

Hmm. This discussion is about establishing a new policy. It's not based on policy as you note, but it is about creating a new policy. --Hammersoft (talk) 22:43, 27 February 2021 (UTC)

@Hammersoft: if by "this discussion" you are referring to Wikipedia:Requests for comment/Desysop Policy (2021) - it is not attempting to create a new policy, as stated it is seeking to amend the existing Administrator policy. — xaosflux ^Talk 02:12, 28 February 2021 (UTC)

Observation on opposes

It's interesting (to me anyway) to see that oppose reasons include both that the proposal is insufficiently strict/too lenient on rouge admins and that it is excessively strict/too harsh. Stifle (talk) 11:24, 2 March 2021 (UTC)

Yeah. That does not bode well for its chances as well as for any other non-Arbcom desysop proposal. Jo-Jo Eumerus (talk) 11:42, 2 March 2021 (UTC)

Or, to be honest, for any significant proposal.--Ymblanter (talk) 11:48, 2 March 2021 (UTC)

See, it might be both: too strict (why require a visit to WP:CESSPIT?) and too lenient (10 editors is not enough). Though frankly since I have no clue whether the current system is posing any problems (how often is there really a need for desysoping involving ArbCom, that is besides for inactivity)? RandomCanadian (talk / contribs) 16:24, 2 March 2021 (UTC)

It's certainly going to make closing an interesting task. There's also I trust ArbCom along with ArbCom can't be trusted, I'd support this with a trial period along with I'd never support a trial period, and the ever-popular I'd like to support but I won't. I suppose one way to evaluate the consensus is to consider any and all reasons to oppose as counting towards consensus against; but one could also make a case that rationales that directly contradict each other should be treated as cancelling each other out. --Tryptofish (talk) 19:44, 3 March 2021 (UTC)

• 81 administrators have been desysopped for cause out of ~2175 successful RfAs, or about 3.7%. --Hammersoft (talk) 16:48, 2 March 2021 (UTC)

How many voluntarily resigned "under a cloud" (i.e. ignoring resignations not because of behaviour but for various reasons, ex. as protests to the WP:FRAMBAN incident)? Even if I assume that is a similar number, and if we assume that these would have had the potential to go the ArbCom (both dubious assumptions); that still leaves about 160 admins over the course of, I don't know, let's say from 2005-2021: 16 years. So we have something that refers to, potentially, depending how you want to count it, from less than half a dozen to a dozen incidents per years. Beyond the philosophical "the community should have a say in this", and given concerns I have with the specifics of this implementation, I'd wonder if this is really too much to handle for ArbCom. I mean, if I had to guess, I'd say that if there are legitimate concerns about an admin, it is always possible to petition ArbCom directly (preferably, I would say, after a prior discussion at an appropriate place): if this is a proposal to formalise this process (and potentially allow bypassing ArbCom entirely), then I'm probably neutral in spirit (if it ain't broken don't fix it - a bigger concern would be fixing the atmosphere and personal laundry lists at RfA; especially if this kind of process has the possibility to actually reduce the number of admins, as per the stats ToBeFree provides) but I'd have to move my !vote to oppose on the specifics RandomCanadian (talk / contribs) 23:45, 2 March 2021 (UTC)

• Well ...

  1. The request must link to at least one thread at a community forum such as AN or ANI that closed within the last 6 months where the closing statement indicates that there was consensus that the administrator behaved inappropriately.

  can be read in many ways. "Inappropriate" is a hopeless word for black and white text. It can be being gruff to a newcomer asking a reasonable question, or a complete inability to understand or follow the text at WP:CSD. The thread participants may have no idea that the thread is going to be used as a seed for a desysop. --SmokeyJoe (talk) 00:06, 3 March 2021 (UTC)

I agree. That is exactly what I thought when I opposed it. The process will be missused by provoking admins to say something that can labelled "inappropriate", and then ANI will be used as a field to get others to confirm this "inappropriateness". Problem editors will game the system.--Berig (talk) 05:23, 3 March 2021 (UTC)

Everyone agrees that community desysop is the solution to a problem, just not the same problem. Levivich ^harass/_hound 05:41, 3 March 2021 (UTC)

I must have missed a lot of drama. I remember that a long time ago, adminship was not a big deal, and in my mind it still is not. However, I get the impression from some of the supports that it is indeed a very big deal that raises a lot of strong feelings. The vast majority of the admins have received the position based on votes on their common sense and maturity, and they are accutely aware of the drama they may raise by using the tools that were untrusted to them. This is a proposal of "one strike and you're out", which will be inevitably be abused in ANI by editors with an axe to grind against an admin. It will also increase the load on ANI with these editors planting seeds for desysoping. I really hope I am wrong, but what I read in the supports makes me concerned. We are in dire need of more admins, not fewer. We also need admins that dare use the tools in potentionally controversial situations, as in blocking the unblockables, and admins are humans and cannot be expected to be infallible.--Berig (talk) 07:12, 3 March 2021 (UTC)

Alternative proposal.

Forced admin re-confirmation

To force an admin to be subject to reconfirmation, Wikipedians may use the following steps:

1. Formal complaints at WP:AN.

Start a thread at WP:AN, titled beginning "Admin:<user> fails to meet minimum standards of a Administrator." In the thread, a minimum three Extended confirmed user must agree to the complaint, in addition to all thread participants collectively establishing a consensus that there has been a failing of an administrator minimum standard. Any user may insist that the thread not be archived without being formally closed.

2. Formal WP:BN case of repeated (3 or more) upheld formal complaints at WP:AN

Start a thread at WP:BN, titled "Admin:<user> to be recalled." This thread must cite three (3) different, non-overlapping threads of the type above at #1, and must establish a consensus that the admin has repeatedly failed an administrator minimum standard. Evidence presented must relate to complaints alleged in one or more of the WP:AN complaint threads and persisting subsequent to the WP:AN thread.

3. A bureaucrat's recognition that the Admin has lost the support of the community.

If any bureaucrat finds a consensus for doubt that the admin enjoys the support of the community, then the bureaucrat may close the WP:BN thread with a finding that the admin must submit for a reconfirmation WP:RfA. In the meantime, the admin must cease the exercise of administrator privileges.

Comments

Unlike the proposal on the front page being !voted on, this process cannot be seeded with a minor complaint that is closed without drawing attention to what it is. Nor can a past minor matter be subsequently retold as a deadmin trigger. The precise page (WP:AN) and section title requirements means that a start to this process is clearly and opening flagged.

There is a quorum (3 extended confirmed) for the AN thread proceeding, but unlike the proposal on the front page being !voted on, there is no 10/3 quorum for proceeding with regardless of other's input.

There are no time limits. Time limits create a rush to action where it is not yet justified. The recalled admin may choose their own time for their reconfirmation RfA. In the meantime, they need not be deadminned, just stop using their admin privilege, which presumably means they stop doing the admin thing that people object to. --SmokeyJoe (talk) 06:11, 8 March 2021 (UTC)

I support this proposal, though not as much as the main one. 🐔 Chicdat  ^{Bawk to me!} 13:05, 8 March 2021 (UTC)

The problem is that admins seldom or never do anything about admin behavior. And so a process that requires admins to do that three times before it even starts is a process for never doing anything. If there were an alternate proposal, I would like to see one for community imposing of milder remedies. Warnings, guidance etc. North8000 (talk) 13:57, 8 March 2021 (UTC)

Milder remedies include corrective comments in review forums, I what I prefer to call “continuing education”. WP:DRV is the main example. DRV doesn’t see malicious admin actions, but careless or over-reaching actions, and they get corrected, by consensus, and very few admins have their actions brought to DRV repeatedly. There is currently no review process on admin behaviour, which would compare and contrast how the admin behaved, and a different form of behaviour. The WP:AN complaint could be morphed to perform this function, although I think that an explicitly “review” forum would be better at reviewing and deciding as a softer remedy. ArbCom did three desysops about a year ago, all for long running behavioural issues for which there was no review forum, but for all three a consensus review of problems earlier might have led to a better outcome. —SmokeyJoe (talk) 20:15, 8 March 2021 (UTC)

Another alternative

I don't have the spoons to write this at the moment (and am unlikely to in the foreseeable future), but...
If we're saying RFAs are too adversarial and people's standards are too high, what if we added a fourth option to Support/Oppose/Neutral in RFAs, giving Support/Support Term/Oppose/Neutral? "Support Term" would be a way of supporting the admin being appointed for (say) a one-year term, with a confirmatory RFA at the end of the year. This option would provide a possibility for a trial, giving the admin the tools and the community the chance to see how they perform, safe in the knowledge that if they turn out to be terrible, they do not have a (perceived) too-high barrier for removal.

The closing bureaucrat would first treat "Support Term" as "Oppose", and determine whether there is a consensus based on "Support" only. If so, the editor would be appointed full admin in the way that exists now. If not, they would then treat "Support Term" as "Support", and if there is a consensus to promote, the editor would get a one-year term.

To be determined:

• Length of the term (I have just put 1 year for the sake of argument)
• How many times an admin could be renewed for 1 year terms before the community would have to decide support/oppose
• Whether the consensus percentages should be different

Potential objections:

• Unfair on future admins versus existing ones
  • Response: If they meet today's standards they should get full-admin anyway
  • Response 2: It is generally agreed that there are too many admins, and this may make it easier to get more
  • Response 3: Don't let perfect be the enemy of good
• Admins on 1-year term may be "on best behaviour" and intentionally flip over to being rouge when confirmed
  • Response: This is no worse than the status quo; you have a good admin for one year then a rouge admin thereafter
• Too much bureaucracy
  • Response: RFA is not currently overly busy
• Confirmation time may not be convenient for the admin
  • Response: Admin could choose an earlier time

Please expand, contract, praise, or criticize in any way you wish, but I would ask people to refrain from doing !votes or bolded "support/oppose", as this is here as a random idea and not a full-blown proposal. Stifle (talk) 11:04, 17 March 2021 (UTC)

Stifle, I like this idea, but I'd go one step further. Make *all* new admins probationary, requiring confirmation after some fixed time period. A year seems too long, maybe 3-6 months. Other positions like SPI clerk and ArbCom clerk have training periods, requiring explicit promotion to full clerk status. This would be similar. IRL, probationary periods for new hires are common in many occupations, for the same reason. The best way to tell if somebody is going to be good at something is to watch them do it. In cars, you get a learner's permit before you get a permanent driver's license. Even airplane pilots get student licenses at first.

It might reduce the anxiety at RfA of not being sure if somebody deserves a lifetime mop. Since it's a one-time thing, it wouldn't impose a huge burden of constantly running re-confirmations for 1000 admins.

It would not address the issue of how to recall pre-existing admins, but the more I read responses to this RfA, the more I'm convinced community recall just isn't what we need. It sounds like a good idea, but I haven't actually seen any convincing arguments that ArbCom is incapable of handling it. -- RoySmith (talk) 13:49, 17 March 2021 (UTC)

I'll note that this idea has been thrown around enough to be on my list of RfA reforms. Best, Barkeep49 (talk) 01:58, 18 March 2021 (UTC)

Before proposing desysop, try to improve the sysop, and more random thoughts

Sometimes admins do stupid things or say stupid things. At other times, they make mistakes, perhaps because they are working in an area of this project that they aren't familiar enough with. We can then (a) desysop them or (b) help them understand what they are doing wrong. Both (a) and (b) can help to prevent the same thing from happening again, but with (a) we are down one sysop, with (b) we are not. Obviously I find (b) preferable (not the least because it is more constructive than adversarial), and would only choose (a) if (b) does not work. Our standard method of desysopping (ArbCom) is rather adversarial, but at least usually checks whether (b) has been tried and failed before deciding on (a), and often recommends (b).

There is an asymmetry that makes it much easier to stay an admin than to become an admin. (It is a bit like it is much easier for articles to be kept at AFD than it is for drafts to be accepted at AFC). I am not a huge fan of this asymmetry, but there are two ways to approach it, and making it easier to become an admin is my preferred choice. —Kusma (t·c) 16:32, 17 March 2021 (UTC)

I supported this as a step forward in an area where there is near-zero accountability, and because the proposal has a lot of safeguards. But, putting what you said in a different way, this goes from zero accountability to discussing ways to give the community the authority of the death penalty but still not allowing the community to write a parking or warning ticket. North8000 (talk) 16:48, 17 March 2021 (UTC)

Wouldn't the warning be made the closer if the admin goes through the process and aren't desysoped? That's how it works at ANI. In no way is someone being reported there a "death penalty" or a guarantee of the person being blocked. In most cases nothing comes of an ANI report except for a bunch of mouthing off and finger pointing by both sides until the problem is defused or otherwise resolved. I see no reason this would be any different. --Adamant1 (talk) 00:01, 18 March 2021 (UTC)

My own opinion is is that to fix this, 2/3 fix the broken RFA process is that we need a small group of the highest quality admins (thoroughness, kindness, empathy and toughness combined, sense of duty, complete self-control, objectivity, immense wiki-experience and expertise) who would handle the cases requiring all of the above including guiding admins and experienced users when they need it. Everything short of Desysop. North8000 (talk) 00:21, 18 March 2021 (UTC)

While I agree that the RFA process needs fixing, my concern is that the same excuse of "RFA can't be fixed until it's easier to desysop admins" can and will be made if there is an attempt to change the RFA process first. Since IMO the arguments against this are more about a skepticism of change in general (which will totally transfer over to anything that tries to be done about RFA) then it is anything to do with the particulars of this proposal. Not to mention, if this is shot down purely because the RFA process "should" be fixed first, then it's extremely likely anything even similar to it can ever be proposed again let alone passed, because it sets up a precedent that the community is just against these kinds of changes. Then your left with a flood of new admins, that were voted in with lower standards, that can't more easily be desysoped if need be. Plus, it's way less likely the new admins will vote for something like this later on when it goes against their self interests. Even if it might be the right policy to implement. --Adamant1 (talk) 00:27, 18 March 2021 (UTC)

The underlying and biggest RFA issue is the dichotomy of what is bundled within the admin role. Much is "no big deal" and some is a "very big deal". Since basic RFA confers the latter, the process is very cautious. We need to by practice (it's not a tool issue) have a subset of admins that handles the "very big deal" stuff. The other half of the fix is to guide / organize / outline the RFA discussion along the needed qualities. North8000 (talk) 19:29, 31 March 2021 (UTC)

Time to close

Discussion is settling down on the RFC page and with 52% support (55% excluding neutrals) I think it's time to tag this one {{failed}} and move on. Stifle (talk) 14:49, 31 March 2021 (UTC)

Agreed that it's time for a closure. I'd like to see the proposal closed more formally though. This is the closest any desysop proposal has ever come to consensus, and it would be good to hear takeaways from a closer. I'm particularly curious about how they respond to the fact that people object both that the policy makes desysoping too easy and too hard. Do those objections cancel to some degree, and if not, can we ever get a community desysop policy? Tamwin (talk) 17:24, 31 March 2021 (UTC)

And as others have pointed out earlier, it would be best to have a thoughtful close from someone who is uninvolved and experienced at determining consensus, probably an admin or crat. This is not the time for a hasty non-admin close by an inexperienced user. --Tryptofish (talk) 18:45, 31 March 2021 (UTC)

Tryptofish, I don't think there's any doubt about the outcome. The real value in the close is going to be a cogent summary of the arguments on both sides, which could be used to guide the next proposal. -- RoySmith (talk) 18:55, 31 March 2021 (UTC)

My concern, and it was first raised by other editors earlier in these discussions, is that some naive new user will make a wrong-headed close that will have to be reviewed and redone amid much heat. --Tryptofish (talk) 18:57, 31 March 2021 (UTC)

Tryptofish, No disagreement there. -- RoySmith (talk) 19:03, 31 March 2021 (UTC)

A closure has been requested at WP:ANRFC. Stifle (talk) 08:36, 1 April 2021 (UTC)

This seems a very rare case where a non admin closer might be better. So Ive stepped up to do the necessary. From an initial scan it seems an obvious no consensus. Therefore I see no need for a panel close, as that more than triples the work.

I'll now closely read the entire discussion. In the unlikely event I find a case to heavily discount the oppose votes, and hence possibly pass the Proposal, I'll just re-open with a recommendation for a 3 member panel to take over. (Ideally 2 non admins & one Crat – won't include myself as I would think it might take more than a week to discuss and come up with an agreed combined decision & close, which I'm not up for.)

Otherwise, unless I'm distracted, I'll probably have wrote up a close in the next 3 hours or so. There seems to be quite a few different lines of argument – I will try to do justice to the quality and complexity of the discussion! FeydHuxtable (talk) 14:15, 17 April 2021 (UTC)

I think rare is the RfC that needs a panel close, and I doubt that this is such a time, so I applaud you for stepping up Feyd. However, if you do recommend one I disagree with the idea that it needs to be two non-admin and one crat. It needs to be a panel of competent closers whatever userrights they might have. Best, Barkeep49 (talk) 14:39, 17 April 2021 (UTC)

Admin closers are not a problem at all, and most of the best closers probably happen to be admins or crats. I believe Primefac said he's working on a close for this? But what does need to happen here is a holistic evaluation of the comments (as this is not a poll). There are a lot of conditional comments on minor tweaks that would've caused editors to jump to the other side. If there is no consensus for this proposal, the closer can note the points which do have consensus (and those which could've been improved), and that could guide those who plan to draft WP:DESYSOP2022. ProcrastinatingReader (talk) 16:05, 17 April 2021 (UTC)

Thanks Barkeep, and fair enough, its not something I feel that strongly about.

OK, I've tried to close with the cogent summary of both sides that Trypto asked for. The complexity and volume of the discussion made it hard to do so in a way that's at once clear, comprehensive and correct. My close is a little non standard, and much longer than is customary for these things. If anyone doesn't think its helpful, then providing they've been here for at least a year and have at least 1000 edits, no objection to them just reverting my close.

I intentionally didn't touch the "Comments" section , including the mini RfC by SilkTork. I see no chance of that leading to any imminent policy change. But it does already have some pointers that may help anyone who makes a future community desysop proposal, and I guess there is a small chance it will get more input now the main discussion is closed. So maybe it should be left open for another week or so...

@ProcrastinatingReader In terms of explicit conditions, those were more commonly found in the support section. RoySmith had a whole package of conditions that would have caused him to jump to support from neutral, but not a minor tweak. As conditional votes on balance seemed to weaken the case to Support, and as there was little commonality among them, it didn't seem worth it to dwell on them too much.

In terms of implicit conditions, one could argue that most of the 80 or so editors who opposed on the view that the Proposal lacked protection for admins, might have supported a more admin friendly package. A fair proportion of these Opposers explicitly said they are not opposed to a Community de-sysop in principle. So one could argue that a Proposal with more protection for admins would have just about had consensus. That may be misleading... I'd suspect if such a proposal was launched, there would be much more opposition on the grounds that it would make dealing with abusive admins even harder than it is now. A view yourself and about 20 others seemned to have even about Tony's existing proposal. FeydHuxtable (talk) 18:07, 17 April 2021 (UTC)

Before the next desysop proposal, whenever that is, perhaps a few decent admins who believe they're 'controversial' (because they deal with a lot of conduct issues?) could go file a 'reconfirmation WP:RFA'. That way, we'll actually have hard data on exactly how much of the community is willing to desysop an admin due to personal grievances vs how many are more objective. And we can also see what the resulting % is like.

Best case, they fly through and there's now hard evidence that those concerns aren't real, and it can guide the passing % for the next proposal. Worst case, a few admins become non-admins (probably by resigning, as presumably the crats wouldn't pull the bit). ProcrastinatingReader (talk) 19:08, 17 April 2021 (UTC)

That's an innovative suggestion, & I suspect we do have a few admins who would be selfless enough to do that. The prospect of opposes from the "Oppose all reconfirmation RfAs on principle" / "You attention seeker!" crowd may put them off though ... FeydHuxtable (talk) 19:55, 17 April 2021 (UTC)

Presumably the crats would afford such opposes zero weight and remove them from the count, same as votes from socks effectively. But I guess the only way to be sure is to ask at WP:BN in advance. ProcrastinatingReader (talk) 19:59, 17 April 2021 (UTC)

Feyd, shouldn't your close state whether there was consensus for a community desysop in general? Apologies if I'm missing something. Kolya Butternut (talk) 19:14, 17 April 2021 (UTC)

Good shout. Strictly, as closer I only had to assess consensus for the specific proposal, but yes there would have been value in adding a line or two about the general case. As per the 2019 RfC there is probably still solid consensus for a hypothetical perfect community desysop process, though this one may have slightly dampened the prospects of us agreeing on a specific one in practice. I may add a line to this effect once I've slept on it. FeydHuxtable (talk) 19:55, 17 April 2021 (UTC)

If you read the discussion carefully, I think you'll find that most of the support opinions for the idea of having a community desysop procedure were fairly perfunctory and axiomatic (the same is actually true for the 2019 RfC). The arguments were usually generalized, e.g. "we need to keep the admins accountable or more accountable", but not really explaining why a community desysop process is a good way of achieving that goal. Relatively few people tried to provide substantive arguments, e.g. arguing that the existence of a community desysop process would make it less likely that people will oppose well qualified RfA candidates. (And arguments such as this one were received quite skeptically.) Personally, I believe that much of the opposition was really generated by the fact that many people didn't understand why the proposal was needed. They might have even said "I think that a community desysop procedure is needed", but, without a clear understanding why, once they started to analyze the consequences of the proposal, they came on the "oppose" side. I think the lesson here is that a successful version of such a proposal, if there is another iteration, cannot simply rely on the conclusion of a previous RfC that a community desysop procedure is needed. It also needs to articulate, in concrete terms, why that is the case, what the benefits of having such a procedure would be, and what problems, if any, its introduction is meant to solve. Nsk92 (talk) 20:24, 17 April 2021 (UTC)

I think many people feel that since the community decides who becomes an administrator, the community should equally have the power to decide who we no longer have confidence in to remain an administrator. Kolya Butternut (talk) 23:28, 17 April 2021 (UTC)

On a slightly different topic, standardized voluntary recall

• I'm thinking the next step is to get a standardized voluntary recall process. I don't participate in recall, largely because there's no standard practice, so I'd be making something up. If there was some standard procedure which a lot of admins had signed onto, I'd be much more likely to sign onto it too. I recognize that forced desysopping and voluntary recall are very much not the same thing, but at least it's a step in the right direction. And, if we can ever agree on what's a reasonable recall process, it might well act as the germ of a desysop process. -- RoySmith (talk) 19:19, 17 April 2021 (UTC)

  Roy, isn't there the sample process? Sdrqaz (talk) 19:26, 17 April 2021 (UTC)

  Sdrqaz, Hmmm, I wasn't actually aware of that (actually, I suspect I've seen it at some point, but long since flushed from cache), so thanks for pointing it out. It doesn't look very standardized, however, with only 5 incoming links from user space. -- RoySmith (talk) 19:33, 17 April 2021 (UTC)

  You might be recalling the section about it within the Comments section. isaacl (talk) 20:05, 17 April 2021 (UTC)

  There seem to be quite a few based on User:Lar/Accountability, which is effectively the sample process but with slightly more stringent requirements. Sdrqaz (talk) 20:12, 17 April 2021 (UTC)

  The issue with recall is that the admins who sign up to it are generally not the ones people consider 'controversial'. A good question to ask is: who is sufficiently 'controversial' yet still a good admin; in Category:Wikipedia administrators open to recall there's a few names who do make difficult blocks (including 3 current arbs and a bunch of functionaries). ProcrastinatingReader (talk) 19:37, 17 April 2021 (UTC)

• I hope that people will give more serious consideration to unbundling admin tools now. There are several areas with persistent and growing admin backlogs where creating a new userright (or userrights) would be useful, particularly AIV and RPP. E.g. creating a new userright, that would allow an editor to issue short blocks (say up to 72 hours) to IPs and non-autoconfirmed users, and to semi-protect pages for short periods (say up to a week) in case of vandalism or other severe disruption, would be useful and would likely attract quite a few takers. Nsk92 (talk) 19:52, 17 April 2021 (UTC)

  Nsk92, Please see Wikipedia:Requests for comment/Responder role -- RoySmith (talk) 20:10, 17 April 2021 (UTC)

  Very good, thanks! I had no idea that this draft RfC existed, but I'll certainly take a look. Nsk92 (talk) 20:31, 17 April 2021 (UTC)

  For the benefit of other editors, to avoid forking conversation, I suggest continuing this aspect at Wikipedia:Village pump (idea lab) § Adminship rights debundling (I know Nsk92 and RoySmith have already participated in that thread). isaacl (talk) 20:14, 17 April 2021 (UTC)

• I think one of the failings cited in the recall process was that someone can promise to be open to recall in their RFA but then revoke that after succeeding, and there isn't really any consequence for that. Stifle (talk) 16:20, 19 April 2021 (UTC)

  People promise all kinds of things in their RfAs and then legitimately change their mind later. (In my RfA I said I wouldn't block established users indefinitely. A few months' experience changed my mind, and if you see what I said in my RfA as a promise, I have broken that). So a promise to be open for recall should also not be valid forever. —Kusma (𐍄·𐌺) 16:40, 19 April 2021 (UTC)

  Stifle, I know recall isn't perfect. But, here's my (perhaps fantasy world) view of how things might work. First, we agree on a standardized recall process. Gradually, it becomes the norm through socializing. Once we've got, say, 3/4 of the admins on board with the same criteria, we can use that as the basis of a new RfA. From the closing summary, the largest block of objections was, too little protection against being used to harass admins. With a standard already in place, it'll be much easier to go back and say, "Most admins are comfortable that this sufficiently safeguards them from abuse. And our experience over the past year (or whatever) bears that out. Now let's make it policy for everybody". -- RoySmith (talk) 17:13, 19 April 2021 (UTC)

What next?

IMO there is probably a strong consensus for some extra review of admin actions or action behavior of admins with some concern that review by other admins isn't working well enough.

IMO this proposal in essence (figuratively speaking) was to give the community the power to issue a death penalty but still not the power to issue a warning ticket. (I'm not dissing it, I supported it). Despite that drawback, and one could argue the inherent "COI" that might influence participating admins, it garnered 56% support. How about a proposal for a well-designed community venue to review admin conduct & actions and issue milder results such as guidance, critique etc ? North8000 (talk) 17:57, 19 April 2021 (UTC)

I've started Wikipedia:Village_pump_(idea_lab)#Reconfirmation_of_Adminship_(ROA)_proposal. I think that before any proposal to force admins to have a re-confirmation can find consensus, there needs to be consensus on a proposal to allow them to voluntarily seek re-confirmation. User:力 (power~enwiki, π, ν) 00:04, 20 April 2021 (UTC)

My assumption about the proposal was that any ANI complaint that didn't result in desysoping the admin would inherently involve "milder results such as guidance, critique etc." Since there would be plenty of both in the ANI discussion. Is that a wrong assumption and wouldn't having multiple processes for different potential outcomes (I.E. a community venue critique admins and a different one to desysop them) just unnecessarily convolute the whole thing? It's also my belief that the various admin noticeboards, talk pages devoted to them, Etc. Etc. already serve the purpose of critiquing and giving feedback to admins by other admins. I've seen more then one discussion on an admins talk page where they were being "guided" by other admins. So is it really that there isn't any feedback mechanisms, there needs to be more of them, or that feedback (guidance, or whatever) isn't always (or usually) the answer to the problem this proposal is trying to solve? --Adamant1 (talk) 01:06, 20 April 2021 (UTC)

I'm not sure that I understand your question. My own opinion is that the current guiding / critiquing process is nearly non-existent. For multiple reasons. First, there is no such venue. WP:AN and WP:ANI are defacto considered to be for / limited to more severe behavioral cases, those where the remedy is severe enough to require admin tools. Second there so much extra deference shown by admins to admins, combined with deference / hesitancy associated with it being a "peer to peer" situation with nobody having the reviewing role that such guidance/ feedback/ review of the situation never gets done. North8000 (talk) 03:00, 20 April 2021 (UTC)

I think the other alternative is a "fix-forward" whereby some conditions such as the above-mentioned 1-year trial period be put in place for new admins from a certain date. Stifle (talk) 09:54, 20 April 2021 (UTC)

Stifle, One of our problems is widespread (and largely justified) fear of the RfA process. The most common response I get when I find good admin candidates and ask them if they would accept a nomination is, "Thanks, but there's no way I'm going to subject myself to a week of public abuse at RfA". I would imagine it'll only get worse when that becomes a week of RfA hell, with the promise of another round next year. -- RoySmith (talk) 12:52, 20 April 2021 (UTC)

I think there is a consensus to be had that RfA is broken (a stronger consensus than we should have community desysop, that's for sure). However, in putting together User:Barkeep49/RfA Reform I've come to the conclusion that there is no consensus about how RfA is broken and without consensus about what the problem is there is no chance of arriving on a solution to fix it. Best, Barkeep49 (talk) 15:27, 20 April 2021 (UTC)

Would it be a stupid idea to present everything on that page in an endorse-y survey/poll and see which ideas/problems resonate the most with people? ProcrastinatingReader (talk) 15:50, 20 April 2021 (UTC)

ProcrastinatingReader, not stupid at all. But to actually change something, it would need to be packaged in a full and structured RfC, probably a multi-round one like WP:RFA2013. Who knows, perhaps we agree more on what the problems are these days than we used to? —Kusma (𐍄·𐌺) 16:16, 20 April 2021 (UTC)

It can be tried, but as long as changes can be stalemated by a small number of vocal persons, as is the case when trying to establish true consensus, I'm not optimistic about something getting done. isaacl (talk) 17:09, 20 April 2021 (UTC)

Barkeep49 Here's how to fix both RFA and this situation in one short paragraph. Set up a group of admins that are astoundingly good, thorough, calm and expert in every respect. (admins like you) We'll need about 20 of them. Give them the job of reviewing admin conduct issues, plus tough cases on etablished users. Everything short of desysop. (ones that severe are rare enough for arbcom to handle) This makes regular admin less of a "big deal" which 1/2 fixes RFA. To finish fixing RFA, determine and define the qualities needed, and organize the discussion so that 90% of the discussion is about meeting/ not meeting those qualities. (instead of the random walk that we have now) North8000 (talk) 16:35, 20 April 2021 (UTC)

Isn't that just ArbCom? I mean, just because (real or perceived) ArbCom doesn't like taking cases doesn't mean that setting up ArbCom-lite is the solution. Just have these 20 admins run at WP:ACE. ProcrastinatingReader (talk) 17:07, 20 April 2021 (UTC)

Sorry I wasn't clear. I meant that each would act individually. North8000 (talk) 17:19, 20 April 2021 (UTC)

So what you're describing is: A single admin (who is part of this new body) can unilaterally issue advisories on whether there's an admin conduct issue in a given report, and presumably after a few separate incidents resulting in advisories you'd have sufficient evidence for an ArbCom case calling for a desysop? ProcrastinatingReader (talk) 17:28, 20 April 2021 (UTC)

I appreciate why there is discomfort with hierarchy as it definitely has disadvantages. But a large group quickly diverges in personal aims (where large is defined by a pretty small threshold) such that group conversations lose effectiveness. Consensus is easily stalemated, and the demands of keeping up with all comments and replies becomes too onerous (the N-squared problem). At a minimum, groups have people who will lead conversation to guide it towards a conclusion, and make definitive assessments of the best way to proceed, or they have votes with strict thresholds. isaacl (talk) 17:45, 20 April 2021 (UTC)

Possibly that comment reads more dismissing than I meant it, but I was just trying to understand what's proposed here, rather than passing an opinion on the idea. But if that is indeed the proposal, it sounds like it shares a bit in common with Iridescent's binding RFCU idea. ProcrastinatingReader (talk) 17:59, 20 April 2021 (UTC)

I was making it more complicated by trying to fix admin accountability and RFA all in one small paragraph. :-) On the former, maybe some would progress to Desysop, but I'm thinking that 99% of the problems are where, after a review, the Admin just needs to be told that they are making errors or behaving poorly and how to remedy the situation. North8000 (talk) 19:23, 20 April 2021 (UTC)