Wikipedia:Requests for adminship/2024 review/Phase I#Proposal 13: Admin elections

2024 Requests for adminship review

The 2024 review of Wikipedia:Requests for adminship, Phase I, opened in February 2024, and closed, with the end of Phase III, in April 2025.

Note: this RfC was created with several already existing discussions that were initiated at the village pump; the section headings for proposals 1–4 have been edited for consistency. theleekycauldron (talk • she/her) 08:15, 20 February 2024 (UTC)[reply]

Proposal 1: Impose community sanctions on RfA

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Should the requests for adminship process be placed under community sanctions (GS)? theleekycauldron (talk • she/her) 20:05, 14 February 2024 (UTC)[reply]

  • The structure of this GS area would be modeled after the contentious topics procedure. It covers all participation in the requests for adminship (RfA) process, broadly construed. It does not cover mainspace editing about the request for adminship process, nor does it cover discussion of the same.
  • Uninvolved administrators and bureaucrats are held responsible for enforcing civility and all other behavioral policies and guidelines through all remedies available under the contentious topics model, as well as the ability to strike or remove comments (up to and include the vote itself) that are judged to be disruptive, corrosive, or otherwise in breach of conduct policy. They are not empowered under this topic area to institute "enforced BRD" or "consensus required" restrictions on a page, or to institute revert restrictions on a single editor. No part of this GS can be made to empower administrators or bureaucrats to enforce any policy they are not already tasked with upholding.
  • Requests for enforcement should be placed at the arbitration enforcement noticeboard (AE). An enforcement action can be overturned on appeal only with: a clear uninvolved editors at the administrators' noticeboard (AN); a clear consensus of uninvolved admins at AE; or (in more extreme cases) a clear consensus of uninvolved bureaucrats at the bureaucrats' noticeboard (BN). Standards of review for an appeal to uninvolved editors or administrators are listed here, and the same for uninvolved bureaucrats are listed here.
  • Wikipedia:General sanctions/Requests for adminship is created as the log of enforcement actions and list of procedures. The appropriate awareness and sanction templates can also be created.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 2: Add a reminder of civility norms at RfA

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


This is not a formal change in rules (and I do not see it as mutually exclusive with the above), but an encouragement for admins to use the tools available to them. Add something like this to WP:RFA (i.e. literally add it to the RfA page; wordsmithing more than welcome):

Editors are reminded that the policies on civility and personal attacks apply at RfA. Editors may not make allegations of improper conduct without evidence.

Uninvolved administrators and bureaucrats are encouraged to enforce conduct policies and guidelines, including—when necessary—with blocks.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 3: Add three days of discussion before voting (trial)

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following the passage of this RfC, for 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW (or for six months, whichever happens first), RfAs will last 10 days. For the first 3 days (72 hours) no "Support", "Oppose", or "Neutral" comments/!votes may be made. Optional questions may still be asked and answered, and general comments may still be left. After 3 days, "Support", "Oppose", and "Neutral" !votes may be left for the remaining 7 days (same length as an RfA is now). This RfC does not change other RfA procedures/rules. 17:49, 17 February 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 3b: Make the first two days discussion-only (trial)

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Note I have just added an alternative, proposing a 2+5-day RfA trial instead of the 3+7-day trial originally proposed. Usedtobecool ☎️ 03:00, 20 February 2024 (UTC)[reply]

Pinging people who had commented/!voted already: @Barkeep49, Isaacl, Aaron Liu, Schazmjd, QuicoleJR, JPxG, Ahecht, Enos733, RoySmith, Lepricavark, Seraphimblade, S Marshall, SportingFlyer, NightWolf1223, Mach61, Lightburst, Thebiguglyalien, HouseBlaster, Relativity, Theleekycauldron, SilkTork, 0xDeadbeef, Rhododendrites, Leijurv, Femke, Bilorv, Retswerb, Kusma, Firefly, Serial Number 54129, Szmenderowiecki, Cremastra, AirshipJungleman29, Schierbecker, Voorts, WereSpielChequers, Compassionate727, Ixtal, WaltCip, Bruxton, Soni, MarioGom, Lulfas, Stanistani, Mackensen, and RunningTiger123: Usedtobecool ☎️ 03:00, 20 February 2024 (UTC) Also, @North8000, Novem Linguae, Lightoil, Lee Vilenski, Yngvadottir, Vanamonde93, Wbm1058, Galobtter, FOARP, Andrew Davidson, Tryptofish, Asilvering, Sideswipe9th, Hey man im josh, Fastily, and Schazjmd: Usedtobecool ☎️ 03:08, 20 February 2024 (UTC)[reply]

note: this was originally a subsection of the above section. I've moved it out here to match the format of the rest of this RfC :) theleekycauldron (talk • she/her) 08:15, 20 February 2024 (UTC) [reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 4: Prohibit threaded discussion (trial)

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following the trial of the discussion-first RfA (provided the proposal is enacted), a second trial of threaded-discussion RfA will run for six months or 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW, whichever happens sooner. A RfC to then be set up to see if elements of either or both trials should be made permanent. In the no threaded-discussion RfA trial, the rules and procedures are to be followed normally, except that, other than 'Crats, nobody is allowed to comment below another user's vote or comment. Each user, including the candidate, may address issues or respond to other comments either after their own vote comment, or by creating their own sub-section in the General comments area. SilkTork (talk) 11:33, 18 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 5: Add option for header to support limited-time adminship (trial)

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following the passage of this proposal, candidates will have the option to include a header between Support and Oppose that will read Support adminship for a year. When closing the RfA, bureaucrats are to grant a year-long term of adminship only when there is no consensus to make a candidate an admin indefinitely, but the combined strength of both support sections does achieve consensus. After this has been tested on five RfAs that are not closed as SNOW or NOTNOW – or six months, whichever is sooner – this trial will end. No candidate may use this option twice.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 6: Provisional adminship via sortition

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following the passage of this RfC the position of "Provisional Admin" will be created, to be selected by sortition at monthly intervals.

Provisional adminship

Provisional admins serve for a period of one year. During this year they may perform any activity a full admin performs, with the exception of enforcing discretionary sanctions or participating as an admin at WP:AE. In addition, full admins are permitted to revert the actions of provisional admins even when they would otherwise be forbidden from doing so by WP:WHEEL.

A provisional admin may at any point elect to go through WP:RfA; should they pass the process they will be permanently granted full adminship. Should they fail their provisional adminship will be revoked.

Provisional adminship may also be revoked at any time by a consensus of full admins at WP:AN, or by WP:ARBCOM.

Selection

Provisional admins are selected by sortition, with an editor who meets the following criteria being drawn once a month by the bureaucrats:

  1. At least 10,000 total edits, including at least 5,000 in main space
  2. At least 1,000 edits in the past year, including at least 500 in main space
  3. Account registered at least three years ago
  4. No sanctions within the past five years
  5. At least one featured article or three good articles
  6. Have never lost adminship under a cloud
  7. Have never previously held provisional adminship

Following the passage of this RfC ArbCom may, as a one-time action, unilaterally alter these criteria before the process goes into effect. Future modifications to these criteria would need to be done through standard processes.[a]

Prior to the drawn editor being announced, the bureaucrats shall inform ArbCom of the editors identity. ArbCom may, if they deem it necessary, silently veto the editor, in which case a new drawing shall occur.

A drawn editor may decline provisional adminship, in which case a new drawing shall occur. 10:54, 20 February 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 6b: Trial adminship

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Proposal: If there is more than 60% support at RfA after three days from the start of voting and at least three admins willing to mentor an incoming admin, then the editor can get trial adminship. As a trial admin, they will get to participate in administrator activities and demonstrate that they have the technical expertise and understanding of policy to keep the tools. Trial adminship could last (extend the RfA) for up to three months (or some other arbitrary maximum), but can be as short as 3-14 days, depending on the level of community support and the finding of consensus by bureaucrats after the initial 7-day period; if there is no consensus above the passing mark but no major objections then a trial might be appropriate (added on 00:43, 23 February 2024 (UTC)). If a bureaucrat closes an RfA as "unsuccessful", if the candidate withdraws, if community support drops below 50%, or if the number of mentoring admins drops below 3, the trial ends as unsuccessful. On the other hand, if a bureaucrat closes an RfA as "successful" the trial ends with promotion to full-time adminship. Reverts of trial administrative actions by mentors would not count as wheel-warring, and reverts of trial administrative actions clearly not in policy does not count either. Awesome Aasim 21:47, 22 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 6c: Provisional adminship via sortition (admin nomination)

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following the passage of this RfC the position of "Provisional Admin" will be created, to be selected by sortition at monthly intervals.

Provisional adminship

Provisional admins serve for a period of one year. During this year they may perform any activity a full admin performs, with the exception of enforcing discretionary sanctions or participating as an admin at WP:AE. In addition, full admins are permitted to revert the actions of provisional admins even when they would otherwise be forbidden from doing so by WP:WHEEL.

A provisional admin may at any point elect to go through WP:RfA; should they pass the process they will be permanently granted full adminship. Should they fail their provisional adminship will be revoked.

Provisional adminship may also be revoked at any time by a consensus of full admins at WP:AN, or by any other process which provides for the revocation of adminship.

Nomination

Full admins may nominate any editor who meets the criteria for provisional adminship. If that nomination is seconded by three other admins, they shall be added to a list of candidates. A nominated editor must be informed of the nomination; they are free to decline the nomination.

Criteria
  • Not subject to any current sanctions
  • Never lost adminship under a cloud
  • Never previously held provisional adminship
Selection

Provisional admins are drawn once a month by the bureaucrats, who may use any sufficiently random process they choose, which may include the development of a simple tool. The drawing shall not occur if there is less than five candidates on the list.

Prior to the drawn editor being announced, the bureaucrats shall inform ArbCom of the editors identity. ArbCom may, if they deem it necessary, silently veto the editor, in which case a new drawing shall occur. 00:00, 7 March 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 6d: Provisional adminship via sortition (criteria to be determined)

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following the passage of this RfC the position of "Provisional Admin" will be created, to be selected by sortition at monthly intervals.

Provisional adminship

Provisional admins serve for a period of one year. During this year they may perform any activity a full admin performs, with the exception of enforcing discretionary sanctions or participating as an admin at WP:AE. In addition, full admins are permitted to revert the actions of provisional admins even when they would otherwise be forbidden from doing so by WP:WHEEL.

A provisional admin may at any point elect to go through WP:RfA; should they pass the process they will be permanently granted full adminship. Should they fail their provisional adminship will be revoked.

Provisional adminship may also be revoked at any time by a consensus of full admins at WP:AN, or by any other process which provides for the revocation of adminship.

Criteria

Upon the passage of this RfC a discussion will be held to determine potential criteria. Each criterion will then be voted on seperately, to determine the full criteria necessary to be met for eligibility.

Selection

Provisional admins are selected by sortition, with an editor who meets a specified criteria being drawn once a month by the bureaucrats who may use any sufficiently random process they choose, which may include the development of a simple tool.

Prior to the drawn editor being announced, the bureaucrats shall inform ArbCom of the editors identity. ArbCom may, if they deem it necessary, silently veto the editor, in which case a new drawing shall occur.

A drawn editor may decline provisional adminship, in which case a new drawing shall occur. 00:00, 7 March 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 7: Threaded General Comments

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following this RfC, the General Comments section would become a threaded discussion

Threaded discussion

So, maybe a bit minor, but I do find the general comments section to be a bit weird. We have a discussion, which is almost always bulleted. These are almost always places to comment on either other people's !votes, individual questions or functionary issues with the RfC. Items that get too long get moved to the talk page.

I have seen users complaining about the talk page not being taken into account when closing (I certainly read it, but I can see why people have this reservation). My thoughts, use level 3 headers to thread the discussions in such a way to allow people to discuss items in a more controlled way. This would also run in parralel with deprecating replying to individual !votes. Lee Vilenski (talkcontribs) 12:13, 20 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 8: Straight vote

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Following the trial of the discussion-first RfA (provided the proposal is enacted), a second trial will run for six months or 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW, whichever happens sooner. During the trial, the main RfA page will consist exclusively of a numbered "support" and "oppose" section. The only thing participants will be allowed to type in those sections is their signature. If a candidate receives 65% of the vote, they are automatically given adminship, and there will be no bureaucrat chats. The talk page of the RfA may be used for any relevant discussion. 00:52, 21 February 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 9: Require diffs

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Require all support or oppose comments to also add unique diffs relevant to, and/or supportive of, their comments.

You can still say "also per so-n-so", but you still have to provide unique diffs of your own first.

If you support or oppose a candidate, you should be able to show why. If they are ready for adminship, this should be an easy thing to do. - jc37 05:43, 21 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Require any comment that claims any participant in the RFA, including the candidate, has engaged in specific policy violations or other misbehavior to provide evidence for their allegations* in the form of a link (preferably in the form of a diff) to the alleged misconduct in line with our no personal attacks policy. Claims of misbehavior or policy violations without links to where they occurred may be treated as casting aspersions and summarily removed by [any participant | any uninvolved editor | any uninvolved bureaucrat]**. If the aspersion is cast in the form of a vote, the vote itself may not be removed, but potentially all of the rationale may be. Any editor whose comment is removed must be notified of the removal. Editors who repeatedly cast aspersions without any evidence may be blocked in line with the no personal attacks policy and the blocking policy. Reaper Eternal (talk) 16:02, 4 March 2024 (UTC)[reply]

*This only applies to claims that someone violated a Wikipedia policy, such as "candidate is uncivil" or "candidate adds unsourced content". Personal adminship requirements like "didn't rollback enough vandals", "needs a higher edit count", or "should have written a GA" do not need links.

**Who actually may perform the removal will need to be decided in a phase II RFC. I simply included some examples of likely wording.

Updated to apply only to specific policy violations per discussion. Reaper Eternal (talk) 17:23, 10 March 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 10: Unbundling 90% of blocks

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Identifying vandals and spammers is easy, that's why we hand out rollback like candy. Blocking for incivility and pretty much any block involving goodfaith editors is difficult, and we need to vet candidates for that right very seriously. Uncontentious blocks of IPs and newbies for vandalism are the vast majority of the blocks we currently only have admins to issue. So it would be logical to create a new userright with the block/unblock button and also view deleted. This block/unblock button would only work on IPs and editors who are not yet extended confirmed. Admins would still have the full block and unblock power as at present.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 11: Set some of the Admin criteria

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Much of the angst and disagreement at RFA isn't really about the candidate, it is about the criteria for adminship. Hence the critique of RFA as it being like taking your driving test whilst driving a minibus full of examiners who are arguing with each other about the criteria for the test. This also causes uncertainty among potential candidates as to what the criteria is. Part of the problem of RFA as opposed to Rollback, Autopatroller or other userrights is that we don't have defined criteria for adminship that potential candidates can look at. Some of those criteria, 12 months activity, no blocks in the last month, at least 3,000 edits and some experience could be set by consensus in individual RFCs per criteria.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 12: Abolish the discretionary zone and crat chats

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


RfA has a discretionary zone as part of its "not a vote" tradition. At some point (when RfAs had become rare), individual bureaucrats no longer wanted to exercise this discretion so crat chats were born, leading to additional days of bureaucrat scrutiny of the voters' arguments. This was a nice idea when it started, but now the community anticipates the crat chats. This means that during voting, people are inclined to make more and more lengthy arguments to ensure their vote is counted, further increasing the contentiousness of the discussion and the stress for the candidate. A simple hard pass/fail boundary would help to calm things down instead of inflaming things further like the anticipation of crat chats.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 12b: Abolish crat chats and allow discretionary relisting

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Basically the same rationale as proposal 12: bureaucrat chats rarely produce a result contrary to the numeric result of a 7-day RFA discussion, thus they needlessly elevate the tension of an already-stressful process. In my analysis of RFA statistics, a review of the discretionary ranges showed that, since 2009, RFAs ending with a numeric result below 70% nearly always fail, despite having expanded the discretionary range down to 65% in 2015. This suggests that bureaucrat chats aren't meaningful in determining consensus. Thus I propose that we eliminate bureaucrat chats and replace with a discretionary relisting period. If after 7 days an RFA carries a numeric result between 70% - 75%, it is automatically relisted for an additional 7 days. If the result remains below 75% after one relist then the RFA fails. Ivanvector (Talk/Edits) 15:39, 28 February 2024 (UTC) [reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 12c: Lower the high end of the bureaucrats' discretionary zone from 75% to 70%

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


If an RFA candidate has 70% or more support, they have earned the community's trust and the 'crats should not be obligated to determine consensus. City of Silver 21:49, 1 March 2024 (UTC) [reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 13: Admin elections

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


In addition to the existing RfA process, Admin elections are held every six months.

Candidates must sign up by a certain date, followed by two phases of debate:

  1. Three days for discussion and questions - no bolded !votes.
  2. If candidates choose to progress, a secret ballot for a full week. Voter suffrage would initially match Arbcom elections. Candidates who achieve 70% Support would pass and become administrators.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 14: Suffrage requirements

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Currently All Wikipedians—including those without an account or not logged in ("anons")—are welcome to comment and ask questions in an RfA, but numerical (#) "votes" in the Support, Oppose, and Neutral sections may only be placed by editors while logged in to their accounts. In practice, editors with low edit count who cast "votes" are usually suspected to be trolls or socks, and the discussions around reverting or striking these votes just lead to more unnecessary heat. It would be easier to just set a minimum bar for participation. For example, we could just use the rules from the Arbcom elections (account is 2+ months old, has 150+ mainspace edits and has made ten edits in the last year).

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 15: Community-based process for appointing CheckUsers and Oversighters

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I think we should consider the idea of having the community appoint CUs and OSs in a similar process that RFAs are run by. I think in this way, the community has more of a say in who is most qualified for these positions. Interstellarity (talk) 01:22, 25 February 2024 (UTC) [reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16: Allow the community to initiate recall RfAs

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Administrators currently retain their permissions indefinitely, and the community itself has no means to revoke administrator permissions once they are given. The only way to remove an administrator is for the Arbitration Committee to open a case and rule against the administrator in light of egregious conduct. There is no means to remove permissions for administrators who have lost the trust of the community unless they have committed egregious or ban-worthy offenses.

If this proposal passes, the community will be able to revoke the permissions of an administrator pending a new RfA. A recall will occur if a consensus is found to do so at WP:AN, WP:ANI, or WP:XRV, similar to how community bans are currently handled. The administrator will then be required to pass a new RfA to retain administrator permissions.

Benefits of this proposal would be that administrators can be better held accountable for repeatedly acting against consensus, failing to abide by policy, or other serious infractions that do not rise to the level of ARBCOM. It would create a binding alternative to the currently optional recall process, which has been criticized for its inefficacy. The potential drawback is that it would limit an administrator's ability to take necessary but controversial actions that may prompt a kneejerk recall: there are ways this could be mitigated, such as requiring only a simple majority at RfA to be reconfirmed. Thebiguglyalien (talk) 03:48, 27 February 2024 (UTC)[reply]

Update: I've struck WP:XRV as a forum for recall per the comments below. Thebiguglyalien (talk) 17:32, 27 February 2024 (UTC) WP:ANI has also been struck. Thebiguglyalien (talk) 07:30, 28 February 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16b: Require a reconfirmation RfA after X years

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


As described in the previous proposal, administrators are only subject to ARBCOM once they are given administrator permissions. There is no means to remove permissions for administrators who have lost the trust of the community unless they have committed egregious or ban-worthy offenses.

If this proposal passes, administrators will be required to pass a new RfA after a certain number of years to confirm that they still have the trust of the community and need for the tools. The number of years will be decided by the community, either in this proposal (if there is strong consensus for a specific number) or in a follow up discussion. Administrators who do not initiate a new RfA will have their administrator permissions expire in good standing with the option to reapply at a later time. This will replace the current inactivity rules for administrators. Current administrators will not be immediately subject to reconfirmation if they have served longer than X years. If several administrators must be reconfirmed in a short period, reconfirmations may be staggered at bureaucrat discretion to allow sufficient time for review.

Supporters of this proposal may condition their support on a minimum or maximum number of years they would be willing to support. As with the previous proposal, the benefit would be stronger accountability for administrators who have lost the trust of the community. It would also simplify the current inactivity rules. The potential drawback is that it would make administrators less likely to take necessary but controversial actions, though it would allow time to pass before an RfA due to its scheduled nature, preventing kneejerk reactions. This drawback could be further mitigated through means such as requiring only a simple majority to reconfirm. Thebiguglyalien (talk) 03:48, 27 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16c: Community recall process based on dewiki

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


This is a way to initiate recalls for admins without requiring WP:ARBCOM. Seeing the calls for a formalised process in Proposal 16, I'm presenting one based on dewiki's Admin recall process.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Any admins may voluntarily stand for RRFAs at any time if they like. This will be otherwise considered identical to a community initiated Reconfirmation.
  6. 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.

If there's any one part of this proposal you'd prefer editing, please state so in the discussions below. I'm happy for the exact details to be tweaked by a future RFC or proposal closers by community consensus, as long as there's support for the overall recall process outlined.

Soni (talk) 14:28, 29 February 2024 (UTC)[reply]

Edits : Used RRFA as a short form for clarity, add line about rights removal (if no RRFA happens), rephrased RRFA thresholds to match intent (same as RFA, but lower thresholds) Soni (talk) 19:12, 29 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16d: Community recall process initiated by consensus

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Any extended confirmed user may begin a recall discussion at WP:AN. They must inform the administrator being discussed and must explicitly state that the discussion is to initiate a Reconfirmation RfA (WP:RRfA). Following a minimum period of seven days and a minimum !voter turnout of at least 20 users, any uninvolved bureaucrat or arbitrator may close the discussion. Any user may comment in the discussion, but only !votes by extended confirmed users will be considered by the closer. Should the minimum turnout not be reached, the discussion should be closed. An admin may have no more than one AN thread for recall opened in a three month timeframe.

Should consensus be found in favor of desysopping them, the user in question must be notified via their talk page by the closer. The user will have one month to initiate a RRfA. Like a typical RfA, an RRfA would be listed at the WP:RfA page, appear on watchlists, and be listed at WP:CENT. They may have one or more nominators or opt to self-nom, just as in a typical RfA. During this time, they may continue to use any tools included in the administrator user group.

Should they elect not to hold an RRfA, their administrator permissions will be removed. If, at a later date, they wish to regain their administrative tools, they must run through an RfA with the typical thresholds (75% automatic and 65% 'crat chat at the time of this writing). Should they choose to participate in an RRfA, it will run with lower confirmation thresholds than a normal RfA (65% for an automatic pass and 55% for a 'crat chat). Should the RRfA fail, a bureaucrat will desysop them.

An admin may not go through an RRfA until at least one year after the conclusion of their previous RRfA or RfA. Sincerely, Novo TapeMy Talk Page 17:17, 29 February 2024 (UTC) [reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16e: Allow the community to initiate recall RfBs

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Bureaucrats currently retain their permissions indefinitely, and the community itself has no means to revoke bureaucrat permissions once they are given. The only way to remove a bureaucrat is for the Arbitration Committee to open a case and rule against the bureaucrat in light of egregious conduct. There is no means to remove permissions for bureaucrats who have lost the trust of the community unless they have committed egregious or ban-worthy offenses.

If this proposal passes, the community will be able to revoke the permissions of a bureaucrat pending a new RfB. A recall will occur if a consensus is found to do so at WP:AN, similar to how community bans are currently handled. The bureaucrat will then be required to pass a new RfA to retain bureaucrat permissions.

A recall RfB may be bundled with a recall RfA’s, but are not required to be.

Benefits of this proposal would be that bureaucrats can be better held accountable for repeatedly acting against consensus, failing to abide by policy, or other serious infractions that do not rise to the level of ARBCOM. It would create a binding alternative to the currently optional recall process, which has been criticized for its inefficacy. The potential drawback is that it would limit a bureaucrat’s ability to take necessary but controversial actions that may prompt a kneejerk recall: there are ways this could be mitigated, such as requiring only a simple majority at RfB to be reconfirmed. 16:37, 3 March 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16f: Require a reconfirmation RfB after X years

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Partly the same motivation in 16e above, and in some of the other proposals to narrow or eliminate the discretion zone and cratchats - bureaucrats retain their permissions indefinitely, with no means for the community to remove them unless there's misconduct severe enough for arbcom to become involved; and the current cadre of bureaucrats are nearly all ancients, with only one of the 18 having registered after 2010, and a few who have almost no interaction with the community besides participating in one or two cratchats a year.

Unlike 16b, there's few enough bureaucrats that we can schedule re-rfbs without overwhelming the process - a two-year term, for example, would average one new reconfirmation starting every 40 days. And unlike 16e, regularly-scheduled reconfirmations don't have the stigma recalls do, and severely limit the potential for retaliatory recalls following controversial-but-necessary actions.

This still has all the benefits of 16e, albeit slower, in that bureaucrats who act outside policy or against consensus can eventually be removed. It will also allow us to get new blood in the bureaucrat corps without risking making cratchats less of a pure consensus process and more of a vote (and there have already been a few that looked like the latter: discussion, then a poll, then closed according to the majority rather than trying to convince the holdouts). —Cryptic 20:12, 5 March 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 17: Have named Admins/crats to monitor infractions

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


For Arbcom cases there are named crats clerks who oversee some aspects of the process – keeping word counts within reason, applying some discipline where necessary, etc. In a contrary position is RfA, where there is/are no named individual(s) to take responsibility for personal attacks, borderline disruption, etc. This means that when there is (for example) an uncivil oppose, there is a pile on of further comments and RFA turns into another disruptive sink.

Having a small panel of three or four named admins and crats per RfA (with a notice at the top of the RfA, similar to the notice at Arbcom) to deal with problematic behaviour would stop some of the disruption.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 18: Normalize the RfB consensus requirements

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Reduce the successful RfB threshold from 85% to 75%

Put quite simply, there's no other area of the project that requires 85% of participants to support something for it to happen. We only have 18(!) 'crats, and we need more of them if we want robust civility clerking (for example, if we want there to be 'crats on-call for each RfA). It should be the same as RfA; I'd also support lowering it to 75% with no discretionary range.

To be clear: the standards for bureaucrats are already higher than they are for admins. This isn't making RfB as easy as RfA, the requirements are still more stringent, and RfB !voters uphold that. But if 75% of participants agree (a full 3:1 ratio) that a candidate does meet those higher standards, that is nearly always a consensus, and we should treat it like one. theleekycauldron (talk • she/her) 21:23, 27 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 19: Discussion-only RfAs

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I am proposing to change RfA by removing ongoing voting during the week-long RfA process. During the RfA, users can either ask up to two questions of the candidate, or provide a statement in support or in opposition of the candidate's RfA, similar to a user statement at ArbCom. Threaded discussion could also take place. At the end of one week, the RfA is closed as a discussion, and then a user vote would take place through a secret ballot process. (A possible addition may be that the admin closing the discussion may judge that the RfA has no chance of succeeding before voting starts.) This takes the two proposals above and places the focus completely on the vetting process, which users can then read before casting their vote.

Basically, there are three types of RfAs: clear supports, clear fails, and edge cases. We struggle the most as a community with the edge cases. My belief is completely separating the voting from the discussion process will actually be less stressful for the candidate, who can use the week focus on simply answering questions about their work and their interest in the admin toolset instead of having to worry about whether consensus is breaking for or against them.

Addendum: per the discussion below, the intent here is to create a process which generates a discussion that users can use to cast a vote on a timeline of the candidate's choosing, similar to something you might receive from a political party or candidate before an election in a democratic political system.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 20: Make RFA an internal non public process

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


One of the criticisms of RFA is that the whole process is public, anyone can see it. This deters some from running, especially if they edit under their own name.

If RFAs were only visible to accounts that were extended confirmed, then it becomes an internal process, only visible within the Wikipedia community. They don't publish recordings of job interviews and driving tests on the internet, why publish RFAs?

I appreciate this would require some IT work, but the WMF can afford to employ some programmers and I believe they want to make RFA less stressful. Once an account becomes extended confirmed they would be able to see RFA pages and take part.

I appreciate that this has similarities to the proposal to limit voting to extended confirmed accounts as a side effect, but some of the opposition to that was from people who saw no benefit.

The watchlist notice would also need changing so that it only promoted RFA to extended confirmed editors.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 21: Reduce threshold of consensus at RfA

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


One commonly cited trope at RfA is that "an oppose is worth as much as three supports". This may be a reason that individual opposes get so much badgering, from the basic underlying premise that their vote is effectively worth more than yours.

Currently, an RfA requires 75% support (ie: support / support + oppose) to be usually considered successful, and 65% support to be under consideration by bureaucrats.

This proposal would reduce the thresholds to 66% and 50% respectively.

In other words, a candidate simply has to get more people supporting than opposing to be considered appropriate for adminship, and can be generally considered suitable at two-thirds majority support.

This could be considered the "Holy Grail" clause from a line in Monty Python and the Holy Grail ... "but all the decisions of that officer have to be ratified at a special bi-weekly meeting by a simple majority, in the case of purely internal affairs, or by a two-thirds majority, in the case of ...." Or, if you prefer, "strange women lying in ponds distributing swords is no basis for determining adminship".

The most recent RfA this might have made a difference is Wikipedia:Requests for adminship/Tails Wx, which might have persuaded them to continue the RfA instead of withdrawing. (Note, I opposed at that RfA). Ritchie333 (talk) (cont) 11:54, 28 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 21b: Slightly reduce threshold of consensus at RfA

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Lower the discretionary range from 65–75% to 60–70%.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 22: Change the name from RFA to "Nominations For Adminship"

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The people that we really need are the capable "I'm willing to serve" people rather than the "I want this" folks. RFA has an "I want this" atmosphere / basis, a basis and environment that the "willing to serve" folks are often unwilling to go into. Also, it puts the crowd and conversations at RFA into a "you are asking for this, you'll need to fight/grovel/beg for it" mode. Changing the name to "Nominations For Adminship" would shift the psychological ground in all of these areas.North8000 (talk) 15:29, 29 February 2024 (UTC)[reply]

Names and words in titles are very powerful and influential in Wikipedia, including for the common shortcuts. For example the widely used word "Onus" (WP:Onus) does not exist in policy, Wikipedia:Tag teaming exists only as a redirect to an essay And so the word "request" in RFA. North8000 (talk) 14:27, 7 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 23: All Admins are probationary for first six months

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I'm resurfacing an idea I advanced in 2021 [6]. Namely, all Admins are on probation for the first six months of their tenure. During this period, the Admin will be subject to a compulsory binding recall process using a to-be-determined formula if such a recall process is initiated. If the administrator is not recalled within 180 days, the probation is lifted and the current status quo with respect to recall processes (voluntary) resumes.
This would significantly lower the stakes of RfA and make RfA less of a life-or-death struggle. Chetsford (talk) 03:08, 1 March 2024 (UTC); edited 16:48, 1 March 2024 (UTC)[reply]

A point of clarification: There seems to be some confusion that I'm suggesting all new Admins must go through RfA a second time after six months. This is not the case. All this is, at the end of the day, is Proposal #16 with the restriction that community-initiated recall is only binding on an Admin in the first 180 days after they are sysoped (the "probationary period"). After 180 days, Admins can voluntarily expose themselves to recall or not at their discretion (identical to the status quo), but it ceases being compulsory. Chetsford (talk) 16:44, 1 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 24: Provide better mentoring for becoming an admin and the RfA process

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I am proposing to expand the mentoring options available for users considering putting their hat in for the mop.

My general idea is to provide an additional process for mentorship besides the optional candidate poll by creating a separate, distinct process which would feature the following:

  • structure the RfA poll to make the user provide more information on why they are interested
  • time when the feedback will happen, perhaps annually or bi-annually, and promote it to allow as much feedback as possible
  • start promotion the week before as a call for people potentially interested in being admins to express their interest publicly
  • use a support/oppose/unsure system instead of a 0-10 poll
  • moderate it to keep things as civil as possible. Unlike an RfA, this would be a chance for someone who would oppose to have an honest discussion directly with the candidate. I think you would probably have to disallow directly responding to other users in a threaded manner.

I've noted above I believe the problem we're trying to solve here are the edge cases, the candidates who either don't fail so spectacularly or aren't complete shoo-ins, because the community can get very difficult about deciding what conduct is and is not disqualifying when vetting a candidate.

Right now my two biggest reasons for not wanting to be an admin are that I don't want to do anything which might increase my time spent on here and that I don't want to go through an RfA. Right now, the only real way of getting public feedback is through the optional poll, which is often poorly attended, and feedback not necessarily helpful.

Changing the way we do admin intake to make it more conversational and collegial before an RfA is even started should help candidates understand what they are "up against" when being formally vetted.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 25: Require nominees to be extended confirmed

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I'm proposing to make extended confirmed a formal requirement for admin candidates. Currently, the RfA page is already extended protected, so non-EC editors need to ask for somebody else to transclude their nomination (per a 2017 discussion). By streamlining this, we can slightly reduce the wall of text at WP:RfA. Furthermore, with admin elections (proposal 13) on course of gaining consensus, we may succeed in lowering the bar for nominees. This also raises the risk of a new editor wanting to apply with no chance of passing. Preventing them from asking to be nominated will avoid some discouragement. —Femke 🐦 (talk) 08:46, 2 March 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Proposal 26: Have the admin corps select its own members

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


  • Executive summary. Just what the title says. Everything else is arguments and details, but the key point is in the first two paragraphs.

Close to 100% of functional large organizations have promotions given by a boss, often with discussion/approval of other bosses and/or the bosses boss etc. (I would suppose). Close to 0% percent have promotions have promotions given by public discussion vetting by all the employees (with no veto power by the boss(es)).

Most of these organizations by far exist to make profit. Making profit is very much enhanced if your internal organization, and the procedures for maintaining it, work well. If the latter method worked well, it would tend to increase profits. Therefore you would see it used in a non-negligible number of functional large organizations, which number would tend to increase over time. That is how it tends to work with large organizations in our system, period.

"Doing what basically every other large successful organization in the free world does" is certainly something to look at closely, n'est-ce pas? Sure we're different -- nonprofit, with article content crowd sourced to volunteers, which works very well, altho crowd-sourced management doesn't seem to -- but I'm sure Goodwill Industries or the Red Cross and so on use a basically similar paradigm. We are an encyclopedia publishing house. We are not the Hog Farm or the Oneida Community. The public lemon-squeezing adoration/flagellation system has got to go. It is horrible, cruel sometimes, and not working that well. When you deselect for sensitive people, you are going to get insensitive people. We have enough of these already in the admin corps and its not getting better.

Howevvvver...we don't have bosses. Well, not exactly, but the admin corps does a number of boss like things -- firing people, and a number of others. They're kinda-sorta the bosses. And (important!) They are supposed to be the best of our best -- vetted as being the most experienced, honest, intelligent, thoughtful, and so on. Who better to decide who they want to promote into their ranks.

Also important -- politics is everywhere (including here of course) and politics is the art of the possible. The admin corps might go for this, big time. There are a number or proposals that are just not going to fly. The admin corps is made of humans, and I don't think are ever going to allow admin recall even if they themselves are grandfathered in, and some of these other also, and at the margins they have ways to pretty much make this stick. And significant enthusiasm on the part of the admin corps would be a huge boost for this proposal. Some people do tend to follow those they consider to be our best and brightest, and some people tend to follow leaders.

The admin corps would go for it I believe because would give the admin corps more power. Who doesn't like that. Also more work, sure, but the work could be mostly given to a small group of admins (there would be plenty volunteers), with whatever oversight from the corpse general that they like. The could all vet on their Discord server or mailing list or whatever they use; all this'd be up to them.

Optional: the admin corps could also be empowered to remove members. Let's not consider that right now, we've got enough to ponder with just what I've laid out here. Herostratus (talk) 21:03, 3 March 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 27: Introduce training/periodic retraining for admins

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


As the title says, we need better training for admins. Especially around accurate deletion tagging as we've had a few candidates fail because their deletion tagging looked heavy handed to many !voters.

Fifteen years ago I did User:Filll/AGF Challenge 2 Directions I think that's not been maintained for quite a few years, though some of it still looks good to me..

My hope is that some candidates would do the training before RFA and either hold off till they'd got better scores or do better at RFA. It may even give some the confidence to run. More importantly, the admins who get desysopped are often people who've been around for years and drifted away from community norms. If we had proper training modules and periodic retraining then one hopes that drift would become rarer and community confidence in admins would rise.

Why does this relate to RFA, well it is at least as relevant as all the recall options.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 28: limiting multi-part questions

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Clarify that multi-part questions count as multiple questions. For example, What would you do for the following usernames would count as one question per username.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 29: Provide a few paragraphs of respondent-guidance / advice on the RFA page.

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Provide a few paragraphs of respondent-guidance / advice on the RFA page. It would include things like the qualities needed for admin and advise evaluating and commenting on those. It would advise avoiding some of the common problems that have been occurring. Including problems inherent to a crowd responding/discussing North8000 (talk) 21:59, 5 March 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 30: Emphasize that just granting the tools does not mean that they will be blocking experienced editors tomorrow

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Emphasize that just granting the tools does not mean that they will be blocking experienced editors tomorrow. In reality, most newer admins start in safer areas and evolve into the rougher high impact areas like blocking experienced editors at WP:ANI and similar high tension high impact blocking areas. But WP:RFA sort of assumes that they will be doing this tomorrow and sets a very grueling standard accordingly. The WP:Administrators page gives some very weak guidance to this effect. The proposal is to strengthen the guidance there along these lines as well as developing this as more of a public expectation. So newer admins (and RFA) can start where it really is "No big deal" and then grow into the areas where it really is a Big Deal. North8000 (talk) 22:10, 5 March 2024 (UTC)[reply]

So this is not to solve a current a problem with admins. It's is to: 1. Reinforce the current practice. 2. get RFA respondents to lower the bar accordingly. North8000 (talk) 03:06, 6 March 2024 (UTC)[reply]
I'm afraid I did a bad job of explaining this because it has been misunderstood. To put it another way, RFA is a high bar because respondents view it as if every candidate is going to be doing the heaviest duty stuff immediately. In reality (with rare exceptions) newer admins work in the areas where they are comfortable with their ability in, and evolve into the heavier duty areas. The main proposal is to make this current reality clearer so that respondents at RFA will go a bit easier on candidates. Sincerely, North8000 (talk) 14:07, 7 March 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 31: Eliminate the support, oppose, and neutral sections and instead: publish the entire !voting sequence and threaded discussion in one section, as participants arrive

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The RfA model of segregating and tallying !voter commentary is demonstrably conducive to group think and piling on whereas the AfD model, for example, is much more discussion oriented and demanding of respondents to individually reach and own the opinions they publish. While it will be more difficult to assess consensus, I believe it will result in far less toxicity, overall.--John Cline (talk) 10:17, 6 March 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 32: Add OoA: Offer of Adminship

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


RfA remains a seperate process. Additionally, any editor who reaches a set of milestones (account age, edit count, block-free period, et cetera, numbers and details TBD) receives a friendly message on their talk page, offering adminship. If they accept they get the mop. If they mess up, the ordinary 4-level warning system applies. 4th warning, admin assesses situation, mop kept or removed. No admin action logged for a year, mop removed. This offer is once-off. — Preceding unsigned comment added by Pgallert (talkcontribs) 19:24, 7 March 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.