User:Nosebagbear/Draft RfC on Confirmation RfAs

Purpose of this Page

This Draft is made to workshop, and then draft, an RfC to formally add that voluntary Reconfirmation RfAs are permitted and can be binding on those who trigger them. There are various components that would make up such a proposal. I have added in the options that jump to mind, but I implore individuals to add their own. That can either be a general concept or a proposed specific wording

My current thoughts on the facets to consider include:

• Permission
• Binding nature
• Nature of the RRfA (standard questions, reason for process, etc)
• Closing of the RRfA (thresholds, Crat Chats etc)
• Restrictions

Permission

Proposal 1 (permission)

Administrators may trigger, at their own discretion (including through use of recall criteria), a Reconfirmation RfA (RRfA). Unless otherwise stated, all criteria and processes apply equally to bureaucrats.

Except where superceded by provisions within this page, the standard rules of an RfA apply.

Comments on Proposal 1 (permission)

• I've provisionally gone for just Admins and Crats as the only ones using RfA. If, say, EFMs and IAs want to use them, I would say they should agree that amongst themselves, but if people think it worth adding them, can do that. Nosebagbear (talk) 15:16, 26 March 2021 (UTC)

Binding nature

Proposal 1 (binding nature)

By transcluding an RRfA nomination (or having it transcluded upon request) administrators commit to a binding process. Failure to acquire a Community consensus will trigger an involuntary desysop and require a successful RfA to regain administrator user-rights. Closing bureaucrats should enact any necessary change.

An administrator may close their RRfA early on their own discretion, but doing so will be reviewed as resigning under a cloud.

Comments on Proposal 1 (binding nature)

"Failure to acquire a Community consensus" is too vague - does that mean only where there is a consensus against their continued adminship means desysopping or also where there is no consensus for or against their continued adminship? Both readings are plausible. Thryduulf (talk) 15:43, 26 March 2021 (UTC)

I feel like it gets clarified below, but you're right that regular RfAs use "no consensus to promote", so "no consensus to retain" would be more logical. Nosebagbear (talk) 15:46, 26 March 2021 (UTC)

Proposal 2 (binding nature)

By transcluding an RRfA nomination (or having it transcluded upon request) administrators commit to a binding process. Failure to acquire a Community consensus will be viewed as resigning under a cloud and require a successful RfA to regain administrator user-rights. Closing bureaucrats should enact any necessary change.

An administrator may close their RRfA early on their own discretion, but doing so will be reviewed as resigning under a cloud.

Comments on Proposal 2 (binding nature)

• This is just a matter of phrasing, as some may view it as feeling a little harsh to be "involuntarily desysopped" just for finishing out a voluntary process, as it may be interpreted as worse than resigning under a cloud. Nosebagbear (talk) 15:16, 26 March 2021 (UTC)
• Same comment as above re "failure to achieve consensus". Thryduulf (talk) 15:46, 26 March 2021 (UTC)

General comments (binding nature)

I think a failed reconfirmation should be put into its own category and not lumped together with resignations under a cloud. I suggest Wikipedia:Administrators § Restoration of adminship should be modified with a new bulleted item to specify that administrative privileges will not be re-granted on request to a former admin who failed a reconfirmation request. isaacl (talk) 20:14, 26 March 2021 (UTC)

In my eyes the "binding nature", simply means that by transcluding the RRFA you have agreed to continue with the consensus met. If someone were to voluntarily put themselves up for RRFA, "under a cloud" would be far too strict, and would be more enlikened to someone asking for their permissions to be removed. Of course, this would be with the caveat that they couldn't just ask for the permissions back. isaacl's comments about having their own category would be suitable. Best Wishes, Lee Vilenski ^{(talk • contribs)} 09:41, 28 March 2021 (UTC)

That sounds fair - any thoughts on wording as distinct from just akin to resigning under a cloud? Nosebagbear (talk) 10:41, 28 March 2021 (UTC)

Perhaps "Administrators whose re-RFA was not successful may not regain adminship other than through a successful RFA." Keep it simple. Thryduulf (talk) 10:28, 1 April 2021 (UTC)

That sounds like a good, neutral, way of doing it. Nosebagbear (talk) 11:05, 1 April 2021 (UTC)

Nature of the RRfA

Proposal 1 (nature of RRFA)

The timeline of an RRfA is also set at 7 days. It may not be SNOW-closed. In exceptional circumstances, bureaucrats may extend RfAs beyond seven days to make consensus clearer, or if technical issues disrupted the functioning of the process.

RRfA candidates should add a neutral summary of the reason(s) that caused them to seek the RRfA. They can then include reasoning on why they should be re-confirmed as well as any other nomination statement they view as beneficial.

The traditional 3 standard questions of an RfA may be removed by the candidate as unneeded, or included and answered, as they prefer.

Members of the Community may ask the candidate questions, including about issues not raised by the candidate's statement. There is a limit of two questions per editor, with relevant follow-ups permitted. The two-question limit cannot be circumvented by asking questions that require multiple answers (e.g. asking the candidate what they would do in each of five scenarios). The candidate may respond to the comments of others.

Comments on Proposal 1 (nature of RRFA)

• Do we think the first 3 questions can be removed? In things like Floq's RfA post-FRAMGATE, they were waived and people didn't seem to mind that. Is more neutral phrasing possible? It excludes the normal RfA rule that an RfA may be recommenced by 'crats for consensus seeking (not that I've ever seen that happen, or think it could).
  • I think the three questions are unlikely to have changed answers from the first time they ran, or if they are changed, it would either be obvious, or something you would mention in a regular summary. I do think specific questions based around the new process would be more beneficial than a neutral statement, as I'm not sure why anyone running would want to be neutral on the issue. Better to have questions asked as to why this RRFA came to be.Best Wishes, Lee Vilenski ^{(talk • contribs)} 09:45, 28 March 2021 (UTC)

Closing of the RRfA

Proposal 1 (closing)

Consensus in RRfAs is to be determined in the same manner as in RfAs, except that the standard anticipated discretionary bounds for RRfAs is between 50%-60%. The standard anticipated discretionary bounds for RRfBs is between 75-85%.

Proposal 2 (closing)

Consensus in RRfAs is to be determined in the same manner as in RfAs, except that the standard anticipated discretionary bounds for RRfAs is between 40%-50%. The standard anticipated discretionary bounds for RRfBs is between 70-80%.

Proposal 3 (closing)

Consensus in RRfAs is to be determined in the same manner as in RfAs, except that the standard anticipated discretionary bounds for RRfAs is between 55%-65%. The standard anticipated discretionary bounds for RRfBs is between 75-85%.

Proposal 4 (closing)

Consensus in RRfAs is to be determined in the same manner as in RfAs, using the same general discretionary boundaries.

Proposal 5 (closing)

Consensus in RRfAs is to be determined in the same manner as in RfAs, except that the candidate may specify a discretionary range in their nomination statement. Once transcluded, it may not be modified.

Comments on proposal 5 (closing)

• I don't think this is a wise form, but recall criteria do include different ones, so perhaps is worthwhile in case individuals would refuse to utilise their recall criteria unless they could follow the RRFA method of their choice?

Proposal 6 (closing)

• In very exceptional circumstances, such as where bureaucrats learn that an admin with an ongoing confirmation RFA will not able to edit Wikipedia at all for a significant length of time for reasons outside of their control, may at their discretion close the RFA at any point as "no result". Such closures are without prejudice to future (confirmation) RFAs or resysopping following a desysopping for inactivity. The adminstrator is however encouraged to launch a new confirmation RFA within six months of their return.

General comments on closing of RRfAs

• This could well be the most disputed area. Unlike an involuntary proposal, admins should hopefully be less concerned by the numbers since if they heavily disagree they can always choose not to execute it.

Restrictions

Proposal 1 (restrictions)

An RRfA may not be triggered while an ARBCOM case request, motion discussion, or case, considering the candidate remains open.

In the event that an enforced Confirmation RfA (or equivalent) is in progress, or has a significant option of occurring, then a voluntary RRfA may not be triggered.

Proposal 2 (restrictions)

An RRfA may not be triggered while an ARBCOM case request, motion discussion, or case, considering the candidate remains open.

Administrators should not carry out logged actions while an RRfA is ongoing, although there may be exceptions, such as handling an ongoing process that had been started before the RRfA.

In the event that an enforced Confirmation RfA (or equivalent) is in progress, or has a significant option of occurring, then a voluntary RRfA may not be triggered.

Proposal 3 (restrictions)

An RRfA may not be triggered while an ARBCOM case request, motion discussion, or case, considering the candidate remains open.

Administrators must not carry out logged actions while an RRfA is ongoing. In the event that any ongoing process cannot be devolved to another administrator, the admin should consult beforehand with a bureaucrat.

In the event that an enforced Confirmation RfA (or equivalent) is in progress, or has a significant option of occurring, then a voluntary RRfA may not be triggered.

General comments (restrictions)

Given that starting a reconfirmation request is a voluntary process, I don't think there needs to be rules on when a request can't be started. isaacl (talk) 20:28, 26 March 2021 (UTC)

Interaction with other processes

Proposal 1 (interaction)

If the conditions for an enforced confirmation RFA are met while a voluntary confirmation RFA is ongoing the confirmation RFA will be regarded as an enforced confirmation RFA and subject to the requirements of that process. The administrator will be given reasonable time to complete any additional steps required, or such steps may be waived at the discretion of a bureaucrat.

At their sole discretion, bureaucrats may extend the duration of the ongoing RFA so that it concludes at the time an enforced confirmation RFA would have concluded had the voluntary confirmation RFA not been ongoing at the time.

Proposal 2 (interaction)

If the Arbitration Committee open (or officially indicate they will be opening) a case or pass a motion in which administrator who has an ongoing confirmation RFA is a party, the RFA will be suspended and the RFA page and talk page fully protected unless the Committee direct otherwise. This suspension may be effected by an Arbitrator, Arbitration Committee clerk or a bureaucrat.

If the administrator is desysopped or resigns their adminship during the period of suspension, a bureaucrat will procedurally close the RFA. This closure shall not prejudice any future RFAs by the administrator.

If the administrator is not desysopped and does not resign their adminship, a bureaucrat will, unless the committee direct otherwise (by motion or in the case remedies), unprotect and reopen the suspended RFA for a duration not less than the time remaining (to the nearest whole number of hours) at the point it was suspended and not greater than 7 days, with the exact duration at their discretion.

Proposal 3 (interaction)

If a request for arbitration is initiated in which administrator who has an ongoing confirmation RFA is a party, a bureaucrat may, at their discretion or by request of the administrator, suspend the RFA as above. Such suspension is without prejudice to the outcome of the RFA and a request to suspend shall not reflect badly on them.

A suspended RFA will be unsuspended as in proposal 2 above either when an opened case is closed, a motion in lieu of a case is enacted or the case request is formally declined.

General comments (interaction)

I suspect it's more trouble than it's worth to try codify what to do if an arbitration case is opened at the same time a reconfirmation request is ongoing. I suggest saving the social capital that would be expended on this aspect and using it for the rest of the proposal. isaacl (talk) 20:33, 26 March 2021 (UTC)

Admin bots

Proposal 1 (admin bots)

If an administrator is desysopped following a reRFA then the sysop flag will also be removed from any admin bots they operate.

Proposal 2 (admin bots)

Any restrictions on performing administrative actions during an active re-RFA apply also to admin bots operated by that administrator. This requirement may be waived at the permission of a bureaucrat or consensus of uninvolved members of the bot approvals group during or no earlier than 14 days before the commencement of the re-RFA. Such permission must be explicitly linked on the RFA page.

General Discussion

• @Power~enwiki, Thryduulf, and Isaacl: Now that the term limits RfC has closed, I've created this page as a very initial workshopping of just enabling the general principal of binding reconfirmation RfAs (RRfAs) being permitted. Please feel free to ping anyone who you think could contribute usefully to the project. Nosebagbear (talk) 15:31, 26 March 2021 (UTC)

  As I noted on your talk page, I'm not optimistic about a proposal gaining community consensus. All the same, I'm happy to make suggestions to try to improve the proposal. isaacl (talk) 20:37, 26 March 2021 (UTC)

• I would avoid any suggestion of "enforced Confirmation RfA". If the process is shown to be good and people want to allow ARBCOM to order a Confirmation RfA in lieu of a de-sysop for example, that can be discussed in the future. User:力 (power~enwiki, π, ν) 22:32, 23 April 2021 (UTC)

Simpler proposal

I've been thinking about this and I'm wondering if we should just strip this back down to the simplest it can be:

• Proposal 1: Any administrator may, at their discretion, stand for a binding reconfirmation (re-RFA) for any reason. Consensus will be judged by bureaucrats. Only self-nominations are permitted. Comments based solely or primarily on objection to or support of re-RFAs in principle will not count towards consensus.
• Proposal 2: The discretionary range for re-RFAs is: [range of options]
• Proposal 3: If the re-RFA concludes with a support percentage:
  • Clearly above the discretionary range, the administrator will retain access to the tools.
  • Clearly below the discretionary range, the administrator will have their access to the tools removed.
  • Neither clearly above or below the discretionary range, the administrator's access to the tools will be determined by consensus of bureaucrats.
• Proposal 4a: If a re-RFA is withdrawn, it will be deemed unsuccessful and the administrator's access to the tools will be removed.
• Proposal 4b: If a re-RFA is withdrawn, a bureaucrat will determine whether it will be treated as successful (the admin retains access to their tools) or unsuccessful (the administrator's access to the tools is removed). Such determination will include consideration of the length of time the re-RFA was open and the comments received before it was withdrawn.
• Proposal 5: Any administrator whose re-RFA is unsuccessful may regain the tools only following a successful RFA.

Procedural matters

All these procedural matters may be changed, added to or removed by simple consensus at Wikipedia talk:Requests for adminship

• Re-RFAs will be transcluded in the same manner as RFAs and will be conducted using the same rules and processes as RFA, including timescales and question limits, except as noted below.
• The nomination statement must clearly note that it is a re-RFA.
• The standard questions for RFA candidates are optional for re-RFA candidates.
• When commenting at a re-RFA "support" means the person commenting is happy for the person standing to continue as an administrator, "oppose" means the commenter believes the person standing should have the tools removed.
• Unless subject to specific restrictions, an administrator may initiate a re-RFA at any time except (a) within 12 months of their most recent RFA or re-RFA, or (b) when arbitration proceedings or requests in which they are a party are open.

Thryduulf (talk) 21:26, 5 April 2021 (UTC)

Comments on the simpler proposal

• @Thryduulf: this is a really good proposal. The only thing I'd disagree on (factoring in the "range of options" bit) is your prohibition on re-confirmation RfAs within 12 months. I can think of circumstances where that would be beneficial, and so long as it remains the candidate's choice to run, it seems unneeded Nosebagbear (talk) 22:00, 5 April 2021 (UTC)
  • Ok, I've struck that part. As for the range of options I think maybe go with the same ones suggested in the initial proposal. Thryduulf (talk) 01:16, 6 April 2021 (UTC)
• @Power~enwiki, Isaacl, and Lee Vilenski: any comments on this version? Thryduulf (talk) 19:44, 6 April 2021 (UTC)

  As I mentioned previously, I don't feel it's worth the effort to try to establish consensus on times when an administrator can't start a reconfirmation request. I think it can be handled as a special circumstance should it occur. I feel that people will be understanding if an admin chooses to defer a reconfirmation request in those scenarios.

  Although I understand why it is proposed to disallow comments based on the principle of having a reconfirmation request, I think there is a fine line between this and opposing because you've lost trust in the administrator's judgment based on their choosing to make a reconfirmation request. I think there will be less opposition to continuing to allow bureaucrats to evaluate how to weigh the stated opinions. isaacl (talk) 21:25, 6 April 2021 (UTC)

  If we're going to do that, I'd want to specifically note that, rather than the first person in a non-clear case having to make their case that even interpretation of not clearly-wrong !votes being allowed Nosebagbear (talk) 21:41, 6 April 2021 (UTC)

  It's much the same as now for requests for administrative privileges: bureaucrats decide how much weight to give any support or oppose views, evaluating how relevant the viewpoints are. For example, opposing on the basis that there are enough administrators or because one objects to the process isn't expressly forbidden. isaacl (talk) 22:26, 6 April 2021 (UTC)

  If somebody wants to showboat with a re-confirmation RFA during an ARBCOM case, let them. If they can actually pass one, maybe there's a reason. User:力 (power~enwiki, π, ν) 22:34, 23 April 2021 (UTC)

  I think the more probable concern is if an administrator's recall criteria is triggered at the same time and some upset editors insist that the reconfirmation request must be filed immediately as per the administrator's recall process. As I said, though, I think editors will be amenable to deferring until after any relevant case is completed to decide on next steps. isaacl (talk) 23:20, 23 April 2021 (UTC)

  That is likely the case, and certainly a possibility. I made sure when I created my criteria to include an ARBCOM exception, but I know it's not universal Nosebagbear (talk)

  I thought it was already established that "binding recall" wasn't actually site policy. If somebody wants to ignore their own recall guidelines because of a simultaneous ARBCOM case, ... well, I'm not sure this is the policy that should be cited. User:力 (power~enwiki, π, ν) 15:23, 24 April 2021 (UTC)

  I suspect that a majority of people who have voluntary recall criteria *do* think that it's binding, so it makes sense to include it. Nosebagbear (talk) 15:47, 24 April 2021 (UTC)

  We just watched a massive failed RFC try to standardize recall. Even if recall criteria are binding, I don't think it's our job to fix some theoretical admin having a drafting error in their criteria. User:力 (power~enwiki, π, ν) 15:49, 24 April 2021 (UTC)

• Thanks to a username change I received no pings about this page's creation, and started a thread at WP:VPI before reading any of it. User:力 (power~enwiki, π, ν) 22:29, 23 April 2021 (UTC)