Status as of 19:47 (UTC), Sunday, 5 May 2024 (
)
- Phase II is open for discussion! Participants are invited to contribute towards improving and refining the proposals for a reminder of civility norms at RfA, administrator recall, designated RfA monitors, and an RfA mentoring process.
Welcome! Following the passage of proposals 16 and 16c, we have consensus for a community-based recall of administrators. This subpage is for Phase II, so we can refine the implementation details.
The discussion close by Joe Roe is reprinted here:
Considering Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16: Allow the community to initiate recall RfAs, Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16c: Community recall process based on dewiki, Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16d: Community recall process initiated by consensus (withdrawn), in parallel, there is a rough consensus that the community should be able to compel an administrator to make a re-request for adminship (RRFA) in order to retain their administrator rights. However, there is also a consensus that the process(es) for initiating an RRFA needs to be worked out in more detail before this is implemented. Phase II of this review should therefore consider specific proposals for RRFA initiation procedures and further consensus should be sought on which, if any, is to be adopted. The dewiki-inspired process suggested in Proposal 16c was well-supported and should be a starting point for these discussions.
Proposal 16 suggested that a RRFA could be initiated by consensus following a discussion at the Wikipedia:Administrators' Noticeboard (AN). I don't see a consensus for this specific procedure, since a significant proportion of both those against and those in support the proposal were against it. The original suggestion that ANI and/or XRV could also be used to initiate an RRFA was rejected outright.
Proposal 16d offered a more fleshed-out version of an RRFA initiated at AN, but it did not find consensus and was withdrawn.
Proposal 16c suggested adopting the German Wikipedia's admin reelection process, which obliges an admin to make an RRFA
if 25 editors with Extended Confirmed rights vote for it within the last 1 month [or] if 50 editors with Extended Confirmed rights vote for it within the last 1 year. There was a solid numerical majority in favour of this procedure, with supporters pointing to the advantages of using a process that has already been shown to work on another project. However, considering the relatively low participation in this sub-discussion compared to the level of opposition to RRFAs in general expressed elsewhere, this is not necessarily a sign of broad consensus.Amongst those who opposed this proposal entirely (i.e. not just specific implementation details), their main reasons were that desysopping is already satisfactorily handled by the Arbitration Committee, that it would discourage administrators from making unpopular but correct decisions, or that it could be open to abuse. The primary counter-arguments given to these were that other projects have community desysop procedures (dewiki, commons) without issue and that on enwiki the community can already impose harsher sanctions (i.e. site bans) by consensus alone. I cannot see any policy-based reason to weigh one set of arguments more than the other, so the substantial numerical majority in support (43–22 for 16; 25–9 for 16c) will have to speak for itself.
As written, the original 16C proposal was:
- WP:Admin Reconfirmation will be created, where any subpages can be created for individual admins. Editors may sign on those subpages to vote for a reconfirmation.
- The reconfirmation is initiated if 25 editors with Extended Confirmed rights vote for it within the last 1 month. Or if 50 editors with Extended Confirmed rights vote for it within the last 1 year.
- Once a reconfirmation is started, the admin in question must run for a "Reconfirmation RFA" (RRFA) within the next 30 days. Otherwise a bureaucrat can remove their admin rights.
- A RRFA will be identical to any RFA, but with lower thresholds. Instead of 75% "generally passing", it'll be 66%. And the discretionary range for Bureaucrats will be 55% to 66% instead of 65% to 75%. Any admins who fail a RRFA will have their admin rights revoked.
- Any admins may voluntarily stand for RRFAs at any time if they like. This will be otherwise considered identical to a community initiated Reconfirmation.
- Admins who have successfully run for an RFA, RFB, RRFA, or Arbcom elections in the last 1 year are not eligible for a community initiated Reconfirmation. Any votes for reconfirmation in the 1 year after an admin succeeds any of these will be struck.
Open discussion
This section is intended to help narrow us down in scope first. After a few days, we'll vote for specific proposals.
Tweaks to 16C
Per the close, 16C is a good starting point to this process. What changes to the current wording would be sufficiently good? Soni (talk) 15:06, 2 May 2024 (UTC)
- The linked page should probably be WP:Administrator reconfirmations, rather than Admin reconfirmation. I would change the discretionary range from 55–66 to 55–65%, and clarify whether a no consensus close means the tools are kept or removed (also maybe whether Support/Oppose should be retitled to Keep/Remove). Giraffer (talk) 09:11, 5 May 2024 (UTC)
- I do want to point out that there's a difference between "unsuccessful" and "consensus against": plenty of RfAs fall under the discretionary threshold for a pass but certainly stay within "no consensus" territory. 60% support on a normal RfA is a "no consensus" autofail. theleekycauldron (talk • she/her) 09:24, 5 May 2024 (UTC)
- If we're following RfA logic, the idea would be to have to earn the tools, albeit with a lower threshold for success (therefore no consensus = no consensus to grant = remove). The alternative is to really treat this as a confirmation, and have the status quo be keeping the tools, with a no consensus outcome meaning there is insufficient support to remove the tools. Giraffer (talk) 10:20, 5 May 2024 (UTC)
- The latter is the much safer option. If an admin is elected under controversial circumstances, a 5% flip in the electorate shouldn't be enough to take the tools away – that's probably less than random variation in any given RfA period. If the community wants to take someone's tools away, it should have a clear reason why and a clear consensus to endorse it. Otherwise, every AE admin gets a clip in the knees. theleekycauldron (talk • she/her) 10:45, 5 May 2024 (UTC)
- If we're following RfA logic, the idea would be to have to earn the tools, albeit with a lower threshold for success (therefore no consensus = no consensus to grant = remove). The alternative is to really treat this as a confirmation, and have the status quo be keeping the tools, with a no consensus outcome meaning there is insufficient support to remove the tools. Giraffer (talk) 10:20, 5 May 2024 (UTC)
- I do want to point out that there's a difference between "unsuccessful" and "consensus against": plenty of RfAs fall under the discretionary threshold for a pass but certainly stay within "no consensus" territory. 60% support on a normal RfA is a "no consensus" autofail. theleekycauldron (talk • she/her) 09:24, 5 May 2024 (UTC)
- If we've elected someone who turns out to be a total idiot, then we certainly shouldn't have to wait 12 months to defenestrate them.—S Marshall T/C 09:53, 5 May 2024 (UTC)
- Part of me wants to say that if we've selected a total idiot we probably deserve what we get; however, even those who have turned out to be manipulating the system for their own ends have not been entirely atrocious with the mop. While i understand S Marshall's concern, i think that any such that we make admins will find themselves before the Arbs before they'd be eligible for this RRfA process (which would surely be a depeniculation rather than a defenestration?). Happy days, ~ LindsayHello 10:16, 5 May 2024 (UTC)
- The proposal does not remove any of the currently available methods to get rid of bad sysops. We sometimes have RfAs that pass with well over 50 opposers; without a "wait one year" these opposers could immediately start a recall election. If you want to add an "immediate" clause, I suggest to put the threshold for something like that not below 500. —Kusma (talk) 10:41, 5 May 2024 (UTC)
- I think 500 is a bit extreme. I think RRfAs should focus on admin conduct/conduct since the candidate became an admin, so those hypothetical 50 opposers shouldn't be allowed to simply repeat their RfA oppose arguments to start an RRfA or even vote in an RRfA. But that's just my opinion and would have to be formally codified. Toadspike (talk) 12:19, 5 May 2024 (UTC)
- If they're a total idiot, arbcom is already intended as a last resort (which would mean after RRfA has failed). Sincerely, Dilettante 17:05, 5 May 2024 (UTC)
+1 We (meaning "the community without ArbCom intervention") currently can't defenestrate idiots within a year via a recall process. In other words, not allowing early RRFAs doesn't make anything worse.
Spitballing: what if we say something like "people who opposed an admin at an RfA/RRfA/RfB cannot sign a recall petition within a year"? HouseBlaster (talk · he/him) 19:19, 5 May 2024 (UTC)
- The big question that was raised during 16c's discussion stage was "What threshold can trigger an RRFA". I had used "25 editors in 1 month OR 50 editors in 1 year" as a yardstick from dewiki. What would be a reasonable number that doesn't also make RRFAs impossible to hit? Soni (talk) 11:07, 5 May 2024 (UTC)
- I think these are good starting points for discussion. My only issue with the actual numbers advanced, is that they appear (correct me if I'm wrong) to be drawn from the DE status quo. The DE equivalent of Extended Confirmed has only about 1/3 the number of editors as en.wiki. As a result, the numbers associated with the proposed implementation of this reform advances a far more easy-to-initiate process than currently exists at DE, removing an important guardrail against abuse. Since the supported proposal is to adopt a community recall “based on DE” it should not be significantly easier than the process DE uses. I suggest the thresholds to initiate a recall, therefore, be increased slightly to more closely reflect the proportional numbers required at DE (e.g. 35 and 75; though, even those numbers make this an easier threshold than exists at DE, proportionally). Chetsford (talk) 12:22, 5 May 2024 (UTC)
- On a different subject to my previous comment, I'd support eliminating the "Sword of Damocles" provision. The proposal has two petitioning periods, the latter of which (12 months) essentially allows any single editor to unilaterally dangle a Sword of Damocles over an Admin’s head for a year by simply opening a petition page. Aside from how absolutely miserable this sounds for Admins, the unintended consequence of this proposal is that we’ll likely find Admins soon issuing Indefinite blocks against editors with ever increasing frequency to avoid this from happening (not nefariously, of course, but I suspect we’ll see some Pavlovian conditioning occur). For this reason, I suggest we only allow for the 30-day petitioning period and eliminate the longer, 12-month petitioning period. Chetsford (talk) 12:27, 5 May 2024 (UTC)
- I agree with your assesment here, and I'd prefer we stick with the 30-day period only. Draken Bowser (talk) 13:43, 5 May 2024 (UTC)
- I don't read German, but it seems that de:Wikipedia:Adminwiederwahl/Intro has listed 50 users within six months since it was created in 2009. isaacl (talk) 19:27, 5 May 2024 (UTC)
- You are right. During the discussions, I believe @ToBeFree had linked User:ToBeFree/recall as well. I believe I'd misread dewiki criteria while writing 16C, but that should not matter as much as the more relevant "What threshold do we want here?" Soni (talk) 19:33, 5 May 2024 (UTC)
- We should start the 30 day countdown after the next logged action. As point 3 is currently written, an Admin who is on holiday for a few weeks might find themselves ousted without ever knowing they were being recalled in the first place. Some very minor wordsmithing could (a) require the Admin be notified they’re being recalled, (b) start the 30 day countdown from the point it’s confirmed the Admin is actually online. Chetsford (talk) 12:18, 5 May 2024 (UTC)
- So the current wording is intended to cover this edge case, but perhaps it's too subtle. Point 3 is phrased as
Otherwise a bureaucrat can remove their admin rights
instead of "will remove", with the expectation that crats will use this discretion in cases like holidays. This would also cover some other edge cases we haven't considered yet. - I personally think more leeway on "When can crats remove bits" but none on "Do they need to RRFA?" is quite better and simpler than try to handle every edgecase from the initial get-go. Soni (talk) 13:26, 5 May 2024 (UTC)
- So the current wording is intended to cover this edge case, but perhaps it's too subtle. Point 3 is phrased as
- How about "enough editors that, if all of them had opposed during the RfA, it would have fallen below the discretionary range"? * Pppery * it has begun... 15:28, 5 May 2024 (UTC)
- @Pppery: I feel like that would be unfair to older admins who passed when we had significantly fewer editors, and they therefore passed with less supporters but the same rough level of consensus. QuicoleJR (talk) 16:12, 5 May 2024 (UTC)
- It's not unfair at all. It should be easier to recall older admins. * Pppery * it has begun... 16:35, 5 May 2024 (UTC)
- Why? Should a good admin be able to be subjected to a stressful recall vote by a few butthurt editors simply because of their long tenure? The requirement should be uniform across all admins, since RFA totals are not representative of admin quality. QuicoleJR (talk) 17:00, 5 May 2024 (UTC)
- Because we already know that the community trusts more recently elected admins because of their RfAs. We know nothing about how much community trust ancient admins have in the present day, so it should be easier to ensure they continue to have the same level of trust as more recently-selected ones. * Pppery * it has begun... 17:17, 5 May 2024 (UTC)
- Why? Should a good admin be able to be subjected to a stressful recall vote by a few butthurt editors simply because of their long tenure? The requirement should be uniform across all admins, since RFA totals are not representative of admin quality. QuicoleJR (talk) 17:00, 5 May 2024 (UTC)
- Although we would have to decide what to do with old RfAs with no clear support/oppose numbers, people like BradPatrick who never RfAed at all, and cases like RexxS where crats passed below the discretionary range so technically zero or one people would be enough to meet my threshold. Probably all of these can be resolved by specifying a minimum number in addition. * Pppery * it has begun... 16:37, 5 May 2024 (UTC)
- It's not unfair at all. It should be easier to recall older admins. * Pppery * it has begun... 16:35, 5 May 2024 (UTC)
- I think that makes it unnecessarily complicated. Why should the numerical outcome of the RfA suddenly become important for all eternity?
- Also, this is not very future proof in case RfA changes drastically. —Kusma (talk) 16:51, 5 May 2024 (UTC)
- I've mostly skipped over RFAs that were already trending towards 250-2 blowouts, even if I thought the candidate would make a wonderful admin. Because I was under the impression that my !vote would not make any difference whatsoever. I don't think we should retroactively change the meaning of sitting out an RFA. Suffusion of Yellow (talk) 18:34, 5 May 2024 (UTC)
- Discussions are a sampling of the consensus view at a given time and are dependent on context. I don't think it's a good idea to try to combine the outcomes of two distinct discussions that are separated by a significant period of time. isaacl (talk) 18:48, 5 May 2024 (UTC)
- @Pppery: I feel like that would be unfair to older admins who passed when we had significantly fewer editors, and they therefore passed with less supporters but the same rough level of consensus. QuicoleJR (talk) 16:12, 5 May 2024 (UTC)
- Comment a reasonable measure of how much attention an admin contreversey can get is the number of preliminary statements before an arbitration case. Wikipedia:Arbitration/Requests/Case/Portals got 43 uninvolved editors' comments in the span of roughly a week. This is an overestimate of what a RRFA petiton would get insofar as not every editor adding a statement wants a desysop, but its a big underestimate in that the amount of effort it takes to write a statement is much higher than what it takes to add a simple vote. Mach61 16:26, 5 May 2024 (UTC)
- also there's a disincentive to add redundant preliminary statements Mach61 16:27, 5 May 2024 (UTC)
- That's a very good observation. Based on that, it seems like at least 50 in 30 days (and a relatively higher number on one year, if the one year period is even used at all) would not be an unreasonable threshold. Chetsford (talk) 19:39, 5 May 2024 (UTC)
- What happens to the petition at the end of one year if there aren't 50 signers? Is the admin forever immune to recall? Or can a new recall be immediately started, and the same people sign it again? Neither solution seems ideal. Suffusion of Yellow (talk) 18:29, 5 May 2024 (UTC)
- As written, it's a rolling window:
within the last 1 year
. isaacl (talk) 18:33, 5 May 2024 (UTC)- In that case, do people get to "bump" their signatures to a later timestamp? (Also not ideal.) Suffusion of Yellow (talk) 18:39, 5 May 2024 (UTC)
- As written, it's a rolling window:
- Are signers of the petition allowed to give their reasons on the petition page, or it just a straight signature and nothing else? If anything beyond a simple signature is allowed, I can see this turning into a List of reasons why this admin sucks that would rival some off-wiki attack sites. Not to mention the inevitable drama. Suffusion of Yellow (talk) 18:59, 5 May 2024 (UTC)
- I'll be absolutely stunned if this process ever gets used. Plus marks though for creating unneeded bureaucracy that will never be used though. Very creative! --Hammersoft (talk) 19:34, 5 May 2024 (UTC)
Other RFA2024 proposals
How would an RRFA interact with admin elections or another proposal that passed? Soni (talk) 15:06, 2 May 2024 (UTC)
- I think the most interesting edge case I can think of is an admin who chooses to avoid a recall petition by successfully getting re-elected as an administrator privately. is there a strong desire to change that? theleekycauldron (talk • she/her) 10:47, 5 May 2024 (UTC)
- I'm not sure what re-elected "privately" means here. If you mean Admin elections (via Proposal 13), then I am in favour of it being equally acceptable to other ways of gaining adminship. 16C, as written, currently allows for any ways of gaining adminship (RFA/Admin elections) to count for "Cannot be recalled for 12 months" Soni (talk) 10:55, 5 May 2024 (UTC)
- The designated RfA monitors should definitely cover RRfAs. HouseBlaster (talk · he/him) 19:19, 5 May 2024 (UTC)
Implementation details
Are there any implementation details an RRFA process should consider Soni (talk) 02:48, 3 May 2024 (UTC)
- Should admins be alerted by to the existence of a reconfirmation subpage by a talk page message so they can decide whether to watch it? Should reconfirmation pages be created for all existing admins immediately, or only when need arises? Also, it should probably be clarified that people may strike their signatures on the request for reconfirmation subpage at any time. —Kusma (talk) 15:42, 2 May 2024 (UTC)
- There should probably be a category of all admin reconfirmation subpages, populated by a template at the top of the page that explains rules and process. —Kusma (talk) 09:42, 5 May 2024 (UTC)
- I had a few ideas:
- Are we sure we want the 50 editors/1 year clause? It has the risk of turning into a list of grievances against administrators who work in contentious areas. I think it's better if we stick with one month; obvious cases can be handled through this, but more sustained issues (the kind of things that build up over a year) can go through ArbCom.
- Who can strike signatures, clerk, and close the petition? (I would presume only crats for all three.)
- Clarify that it should be 30 days/1 year from the opening, not the most recent signature, otherwise petitions risk turning into permathreads.
- I would make clear what support/oppose would mean in an RRFA, and whether they should be renamed.
- I drafted an example of what these kinds of changes, alongside a few others, could look like in my sandbox. If that's too much change at once, I'm happy to propose it as an alternative when the proposal period opens. Giraffer (talk) 10:11, 5 May 2024 (UTC)
- I think you could make solid arguments against both the 25/month and the 50/year. The former is hotheaded ANI filers, the latter is a buildup of petty grievances. How do we prevent the exigencies of both? theleekycauldron (talk • she/her) 10:52, 5 May 2024 (UTC)
- Raising the number of signatures needed is really the only way to do that. As for the month vs year, I'd still argue that a month with a high threshold is better, because set high enough, the threshold would force the RRFA to be triggered only by a sharp loss of trust. Getting 25 or more people to agree in a month that a user should be desysopped seems pretty difficult. I struggle to see what kind of scenarios would mean that a user should be desysopped under the 50/year clause; all the recent desysops I can think of have been triggered by a single incident, which would fall into the 25/month category. Giraffer (talk) 12:01, 5 May 2024 (UTC)
- I think part of the point here is to allow more desysops in situations that do not rise to Arbcom level. An admin who regularly makes low-profile questionable AfD closes could easily pick up a handful of recall votes per AfD, from different people each time. Perhaps the admin will stop closing contentious AfDs when they have 40 recall voters. Whether that is good or bad depends on the merits of each of these closes. (The provision does not have to be actually used to have an effect). —Kusma (talk) 12:47, 5 May 2024 (UTC)
- Raising the number of signatures needed is really the only way to do that. As for the month vs year, I'd still argue that a month with a high threshold is better, because set high enough, the threshold would force the RRFA to be triggered only by a sharp loss of trust. Getting 25 or more people to agree in a month that a user should be desysopped seems pretty difficult. I struggle to see what kind of scenarios would mean that a user should be desysopped under the 50/year clause; all the recent desysops I can think of have been triggered by a single incident, which would fall into the 25/month category. Giraffer (talk) 12:01, 5 May 2024 (UTC)
- Thank you for your proposal, Giraffer. I have two issues:
- 1. A no consensus outcome would lead to tool removal. Nearly everywhere else on Wikipedia, no consensus means retain the status quo. Now, I have no idea what a "no consensus" close could possibly look like at RRfA, but I feel like it should logically follow the same policy elsewhere on enwiki, which is no consensus = keep the tools.
- 2. Point 5 is confusingly worded. More importantly, if a "a failed desysop motion at ArbCom" basically gives immunity to RRfAs, this would change the behavior of ArbCom in unintended ways. I think the two processes should be kept separate.
- Beyond just this proposal, immunity clauses leave many open questions. Does the first, successful RfA give immunity? What if a new, serious situation arises – could a well-reasoned petition to the 'crats be used to override the immunity period? If we give immunity to the recall process, wouldn't potentially troublesome admins be emboldened to continue controversial behavior? Toadspike (talk) 12:29, 5 May 2024 (UTC)
- I think you could make solid arguments against both the 25/month and the 50/year. The former is hotheaded ANI filers, the latter is a buildup of petty grievances. How do we prevent the exigencies of both? theleekycauldron (talk • she/her) 10:52, 5 May 2024 (UTC)
- Does an administrator become INVOLVED with respect to a User who adds their name to the petition to remove? What are the implications of that for administration of the Project? Can a User become immune from all administration? Can a User become a target of other administrators? -- Alanscottwalker (talk) 11:59, 5 May 2024 (UTC)
- Sounds like WP:AVOIDBLOCK: If I start a recall against every admin, I'll never get blocked! Bwahahaha! Toadspike (talk) 12:32, 5 May 2024 (UTC)
- Well, it would not need to be every just admins active or very active in enforcement (or even fewer, just the ones active in your area). Alanscottwalker (talk) 12:47, 5 May 2024 (UTC)
- Admins do not become INVOLVED if someone Opposes them in an RFA. I do not see why RRFAs should be any different Soni (talk) 13:07, 5 May 2024 (UTC)
- Perhaps because a candidate for admin can't be INVOLVED, those conditions can only arise during adminship? Alanscottwalker (talk) 13:57, 5 May 2024 (UTC)
- Sounds like WP:AVOIDBLOCK: If I start a recall against every admin, I'll never get blocked! Bwahahaha! Toadspike (talk) 12:32, 5 May 2024 (UTC)
- This may be too far afield for a matter as limited as implementation details, and I don't expect it will be warmly received anyway, but I'd just like to note that, while requiring EC on petitions is a good safety valve, I (a) know there are sock farms that control multiple EC accounts, (b) have recently been made aware of the significant sums of money involved in some paid editing (five figures in one recent case of which I'm personally aware), and (c) know some of these farms would probably like to kneecap Admins active in certain areas.
In my ideal version of this proposal, a recall petition - once reaching the required signatory threshold - would be subject to a CU audit as a final step before start of recall. The CU would have the authority to strike the signatures of any "possible" socks. (Full SPI will still be required prior to blocking.) CU without the more robust investigation of an SPI is not onerous to get around, so I don’t purport that this will solve the risk I describe. It will, however, mitigate it at no cost. While this is not something DE feels necessary to do, I’d just keep in mind that the stakes at DE are a lot lower than at EN. Chetsford (talk) 19:47, 5 May 2024 (UTC)
Process
In a few days, the open discussion section will be closed for more specific votable proposals (probably 7 days or so?). Is there a preferred structure for that? Soni (talk) 15:06, 2 May 2024 (UTC)
- My current plan is for "Open discussion" section to be "closed" after 7 days, and then anyone can add a new proposal. A mockup of that structure is at User:Soni/sandbox3. Soni (talk) 13:17, 5 May 2024 (UTC)
Proposals for other RRFA mechanisms
I want to clarify that while I saw a decent amount of support for 16c, and that's why I suggested it as a starting point for this discussion, it didn't gain broad consensus in the first phase. So while tweaking the details of 16c and going with that is certainly an option, it's not the only option. Now that we know the community wants some sort of RRFA, there might be new ideas for how it could be triggered, and I think people should feel free to propose and discuss them here. I also don't see any reason why there can't be more than one triggering mechanism, if multiple proposals find consensus. – Joe (talk) 13:00, 5 May 2024 (UTC)