Wikipedia:Administrator elections/October 2024/RFC workshop

This page is for drafting mini RFCs to change the administrator elections process.

• Please do not vote. This will come in a later phase on a different page.
• Feel free to modify RFC text on this page. For example, to include additional options.

For now, anyone should feel free to add mini RFCs. If we end up with too many, we may need to have a talk page discussion where we only pick the most important or most cogent RFCs to proceed to the next phase.

Pass percentage

What should the required percentage be to pass an administrator election?

• Option A – 75.00%
• Option B – 70.00% (current)
• Option C – 65.00%
• Option D – 60.00%

I think we should omit the higher percentages, based on the current debrief, for simplicity. So far, the mood seems to be that a few good candidates missed out, and that they number should either stay the same or go down a bit. —Femke 🐦 (talk) 06:58, 6 November 2024 (UTC)

I think you need to take account of the fact that most people bothering to comment under debrief took part in the process, and were at least a little positive towards it. I'm seeking to accommodate those who loathed the process and will vote for it not to reoccur, some of whom might have voted blanket oppose or may simply have boycotted the process. I, for one, would be a good deal more comfortable with a process that used the same cut off as RfA, ie 75%. If the %age gets decreased below 70% I for one will strongly oppose a rerun, and I don't think I'll be alone in that position. (Less scrutiny and a noticeably lower threshold, no thanks!) Espresso Addict (talk) 07:07, 6 November 2024 (UTC)

The de facto cut-off of RfA is more around 70% than 75%, right? Other proposals below increase the scrutiny already, with a longer discussion, discussion on the weekend, and fewer candidates, and I imagine all of these proposals will pass. I myself would probably like to the lower the support threshold in a smaller step (2/3rd), and see if we need to iterate after the next election. I think that's a more likely option to gain consensus than an increase. We could offer one percentage that increases threshold, perhaps? —Femke 🐦 (talk) 07:18, 6 November 2024 (UTC)

70–75%, afaik, requires a bureaucrat chat, which is explicitly excluded here; I think we need to offer at least one increased %age. Perhaps 72.5%? Espresso Addict (talk) 07:28, 6 November 2024 (UTC)

The highest AELECT candidate only got 82.42% support. This suggests to me that they would have been at 99 or 100% in a normal RFA, and suggests to me that there is a -18% support penalty for using AELECT. So the idea that we should increase the cutoff is a little surprising to me, as in my opinion this is proposing to move the AELECT bar from higher than RFA, to way higher than RFA. –Novem Linguae (talk) 10:00, 6 November 2024 (UTC)

I've said this before but I just don't think this is true. There is no reason to suppose that the candidates in (particularly this first) election have the same profile as those who have stood at RfA recently -- rather the converse, as they have all chosen not to stand at RfA but rather to trial this process. ETA And we're not choosing the threshold, we're choosing the options that will be available to be selected by commenters in a forthcoming RfC. Espresso Addict (talk) 11:08, 6 November 2024 (UTC)

I agree I don't think it should be assumed that the candidate with the highest support percentage would have gotten close to 99% with the open viewpoint RfA process. For the past few years, I think most of those who have been passing the RfA process have been very cautious about only making a request when they're very confident about passing. As far as I recall, the candidates in this election have not expressed that level of confidence. isaacl (talk) 01:00, 7 November 2024 (UTC)

Aren't half of RFAs like 95%+ though? We had 32 candidates in this election. The argument that half of RFAers would get unanimous support, but that not a single one of 32 admin election editors would get unanimous support, doesn't quite convince me. –Novem Linguae (talk) 07:19, 7 November 2024 (UTC)

If a candidate in a normal RFA already has 100+ support votes then there is no point in voting oppose, and voted oppose opens an editor up to hostile reactions. I don't believe that the oppose votes seen in the election are anything unusual. If anything they are due to higher participation in the process, has any RFA ever had 616 participants? The same is true of support votes, many wouldn't add their support when the candidate is already obviously going to pass. When was the last time an RFA had 300+ support votes? Both are simply caused by participants taking part in a secretive ballot. -- LCU ActivelyDisinterested «@» °∆t° 14:19, 7 November 2024 (UTC)

has any RFA ever had 616 participants? according to WP:RECORDS, the highest participation RFA was Tamzin's with 468 !votes, only 16 of them neutral. Her 340 support votes was higher than all-but two people in this election. Thryduulf (talk) 19:24, 7 November 2024 (UTC)

And before Tamzin, it appears to have been was Floquenbeam with 325 support votes. One of the candidates in this election neared these all time highs os support, and neither of those highs come close on participation. Secret ballots just encourage more voting. -- LCU ActivelyDisinterested «@» °∆t° 19:34, 7 November 2024 (UTC)

I agree that increasing the support percentage makes no sense – folks with that view probably just want to abolish AELECt altogether. Toadspike [Talk] 16:01, 6 November 2024 (UTC)

Note for all RfCs – if the Options involve numbers, like here, the Options should use letters (A–E) instead of numbers (1–5) to prevent confusion when the RfCs formally begin. I have altered a few already. Toadspike [Talk] 16:50, 6 November 2024 (UTC)

But we're looking to convert them to the process. I missed all the discussions on this topic because I was hibernating, and the first thing I thought when I saw this project on returning was that it had substantially reduced the threshold. If one looks at the list of results there are eight candidates falling within the 65–75% range, and I'm not at all convinced that all of these would pass an RfA. Espresso Addict (talk) 01:12, 7 November 2024 (UTC)

• I believe the two most intuitive percentages are 70%, as the middle of the regular RFA discretionary range, and 75%, as the top end of that percentage (therefore, the threshold at which someone ought to automatically pass). I prefer the first of these, ie the current option, and would oppose any lowering. Also, the cutoff should - IMO - be at the point where it discriminates between suitable and unsuitable candidates, not the bar which all suitable candidates are able to meet. Obviously people disagree as to suitability - but the mere fact that a good candidate or two fell below 70% isn't enough for me. The question we should be asking is "what is the threshold at which the community would be comfortable with all those crossing it receiving a mop?" 70% isn't perfect, but for me it comes pretty close in this instance. Vanamonde93 (talk) 04:27, 7 November 2024 (UTC)

  Top candidates in RFA get 99–100%, but top candidates in ACE and AELECT only get 80%. For this reason, I don't think we can directly compare the 75% top of RFA crat chat discretionary range to 75% in AELECT. I think 75% in AELECT is more like 95% in RFA. For this reason and others (that the recent election had great candidates in the 65.00–69.99% range), I think it is quite reasonable to lower the cutoff range. However, I suppose I should save these arguments for the actual RFC :) –Novem Linguae (talk) 07:24, 7 November 2024 (UTC)

  I think there's a case to be made for reducing it further, like at 55 or even 50%. I don't believe the community will go for the latter, but 55 seems plausible. Soni (talk) 08:44, 7 November 2024 (UTC)

  The community may well wish to lower the threshold to 55% and it seems reasonable to give that option in this RFC. Perhaps in lieu of the, to my eye, slightly odd 72.5%? (I note with interest that only 1 of the 32 candidates just voted on gained a percentage between 55.7 and 64.7 but am unsure whether ti attach any significance to this.) Gog the Mild (talk) 14:38, 7 November 2024 (UTC)

  I agree that in terms of a threshold for a given user to meet, the percentages are not comparable - but in terms of the proportion of users who are expressing trust in the user, they are. As I've said at ACERFC often, the ACE results aren't directly comparable either, because presumably the average user has a higher bar for an arbitrator than an admin. I'm not necessarily opposed to ever dropping the threshold, but we ought not to rush into it. There's many other factors pulling the overall percentage down that may change in future iterations - trust in the process, blanket opposition, number of candidates, etc. But now I'm making RFC arguments too.

  I would keep it simple; do 75, 70, and 65, and 60 if we absolutely must. 72.5 is an odd number with no obvious benefit. Vanamonde93 (talk) 20:29, 7 November 2024 (UTC)

• Should we consider 67% because that's an even two-thirds, or is that splitting hairs too much compared to 65%? ~~ Jessintime (talk) 15:50, 7 November 2024 (UTC)

  Personally I don't feel that there's any significant motivation to use a 2/3 threshold just to have simpler fraction. In any case, the result is going to be reported as a percentage. I also don't think 72.5% is worth including as an option. isaacl (talk) 16:51, 7 November 2024 (UTC)

  Sure. Removed for now. –Novem Linguae (talk) 22:20, 7 November 2024 (UTC)

• On a formatting note, in the final RfC, I suggest listing the options in sorted numerical order, either ascending or descending. isaacl (talk) 16:51, 7 November 2024 (UTC)

   Done –Novem Linguae (talk) 22:18, 7 November 2024 (UTC)

Maximum # of candidates in each election

What should the maximum number of candidates in each administrator election be?

• Option A - Unlimited (current)
• Option B - 8
• Option C - 10
• Option D - 15
• Option E - 20

Worth explicitly stating how we'd choose which 10 or 15 to go with? First come first served? ProcrastinatingReader (talk) 00:55, 6 November 2024 (UTC)

That should be a separate question. Thryduulf (talk) 01:10, 6 November 2024 (UTC)

Makes sense, created subsection below. ProcrastinatingReader (talk) 01:19, 6 November 2024 (UTC)

Ah, I edit conflicted with you. Do you want to merge the subsections. Thryduulf (talk) 01:27, 6 November 2024 (UTC)

I would rather this question be merged with a larger question of "How frequently should Admin elections be held". Both those questions go hand in hand and I'd rather avoid a Recall Phase 2-esque scenario where dependent questions are decided by separate votes. Whether or not I support Option 1 here is strictly dependent on how often I expect AELECT to happen.

Other questions should be merged similarly, to avoid similar kind of mutually conflicting consensi. Soni (talk) 11:42, 6 November 2024 (UTC)

Agree with Soni. In an ideal world, we hold elections often enough that we have space for all candidates and we don't overload voters. Toadspike [Talk] 16:03, 6 November 2024 (UTC)

• I've added 20 as an option that should be considered. ~~ Jessintime (talk) 15:52, 7 November 2024 (UTC)
• Although I don't think it's necessary for every question, I think for some (often numerical ones, such as the pass threshold and this one) it would be helpful to encourage RfC participants to list an order of preference. isaacl (talk) 22:27, 7 November 2024 (UTC)

Candidate signup priority ordering

Question 1: If there are more prospective candidates for an election than the maximum number allowed (if one is set), which candidates will stand?

• Option 1 - Strictly chronological by sign up order (oldest first)
• Option 2 - Those who have never requested adminship before in sign-up order (oldest first), followed by time since most recent adminship request (longest ago first)
• Option 3 - By number of previous requests for adminship (fewest first), then by sign-up order (oldest first)
• Option 4 - Randomly selected from the list of prospective candidates, with priority given to those who applied but were not selected to run in the immediately preceding election (a random drawing of priority candidates would be held, followed by a random drawing of new candidates if there are more slots available than the number of priority candidates)

Question 2: Will admins facing recall count towards the maximum allowed candidates?

• Option 1 - No, admins facing recall do not count towards the maximum, the allowed maximum number of candidates increases accordingly
• Option 2 - Yes, admins facing recall will count towards the maximum number allowed; but have priority over other candidates.
• Option 3 - Yes, admins facing recall will count towards the maximum number allowed; but if they do not get a slot based on Question 1, they must go via WP:RFA instead.

Better suggestion above
The following discussion has been closed. Please do not modify it.
Option 1 - Strictly chronological by sign up order, oldest first Option 2 - Admins standing for reconfirmation after a recall petition, then as per option 1 Option 3 - Those who have never requested adminship before in sign-up order (oldest first), followed by time since most recent adminship request (longest ago first) Option 4 - Admins standing for reconfirmation after a recall petition, then as per option 3 Option 5 - By number of previous requests for adminship, fewest first, then by sign-up order (oldest first) Option 6 - Admins standing for reconfirmation after a recall petition, then as per option 5

These are the options I've seen suggested so far. Thryduulf (talk) 01:26, 6 November 2024 (UTC)

Suggest the following to split it up into two separate questions? Reduces the number of options on each question, and is easier to follow imo. Feel free to refactor/wordsmith the subsection if you agree (also welcome to delete the threaded discussion afterwards to clean up the page, if you wish) ProcrastinatingReader (talk) 01:42, 6 November 2024 (UTC)

Yes, that's better organisation I've hatted my original suggestion. Let's leave the threaded discussion for now so it's easier for others to respond if they wish. Thryduulf (talk) 03:42, 6 November 2024 (UTC)

• I attempted to clean up and rephrase the options/questions for these. I think this is clearer but may be copyedited further. Soni (talk) 12:07, 6 November 2024 (UTC)
  • I've made a few minor copyedits, again more welcome. Thryduulf (talk) 12:33, 6 November 2024 (UTC)
    • I added an option 4, which should be a bit farer to those not in a timezone that allows them to be online when the call for candidates opens. --Ahecht (TALK
      PAGE) 19:54, 7 November 2024 (UTC)

      I suggest dropping "by a bot", to avoid imposing a specific technical implementation. I'm not clear what you mean by "priority given": are those candidates given a higher weighting in the random selection, or are they assigned a spot first (with a random selection amongst them if there are more first-time candidates than spots)?

      Regarding timezone bias: if people can signup for any future election (or for some number ahead), then I don't think it'll matter much. People can sign up for as many future elections as they want, and their priority order can shift based on the algorithm. isaacl (talk) 22:01, 7 November 2024 (UTC)

      And nominations windows don't all have to open at the same time. e.g. the next election could open at 00:00 UTC, the one after at 06:00 UTC, then 12:00 UTC, etc. Thryduulf (talk) 22:59, 7 November 2024 (UTC)

      I clarified the language on Option 4. --Ahecht (TALK
      PAGE) 19:01, 12 November 2024 (UTC)

Scrutineering

Question 1: Should AELECT elections be scrutineered (voter's IP addresses, user agents, etc. recorded and checked by trusted users for sockpuppetry)?

• Option 1 - Scrutineered by default. Personal data of voters is visible en-masse to scrutineers, similar to ACE elections (current)
• Option 2 - Only usernames are visible by default, and CUs can run logged checks on suspect accounts, similar to RFA

Question 2: If Option 1, who should the scrutineers be in future administrator elections?

• Option A - 3 stewards who are given local CheckUser access solely for scrutineering the election (current)
• Option B - 3 English Wikipedia checkusers

--

A comment on this being raised as an option (not sure where to leave it): I don't feel this should be offered as an option for just AELECT. As we've been discussing it at VPI, it's an issue that equally affects ACE elections and AELECT elections. Either the independence concerns are meaningful, and should affect all elections where PII is processed, or they aren't and there's no reason for one massive PII election to differ from another. Similarly, I don't think the "who should be an electionadmin" question is one to be discussed solely in the AELECT RFC and should be dealt with in the broader RFC being mooted at VPI. The only thing that perhaps should be on an election-specific level is whether to do PII scrutineering, IMO. ProcrastinatingReader (talk) 00:50, 6 November 2024 (UTC)

I disagree. en.wp checkusers are appointed directly by and work closely with arbcom, therefore there is a clear potential for a conflict of interest. The same is not true for admin elections. We can choose to make the same decision for both elections, but we also need the ability to choose different options for the different elections. Thryduulf (talk) 00:57, 6 November 2024 (UTC)

I suppose the independence concerns was ambiguous, and we mean different things by the phrase. Will not repeat myself from the VPI here, but on this RFC's structure, IMO it'd be better for consensus on this issue to be decided in a single and separate discussion rather than rehashed twice. I do think a worthwhile question is whether we should do PII scrutineering by default in the first place (proposed below) ProcrastinatingReader (talk) 01:28, 6 November 2024 (UTC)

I agree the question of whether we should collect PII is worthwhile, but still disagree that we should assume admin elections and arbcom elections are the same (or even similar). If we ask the question, we need to ask the question separately for the very different elections. Thryduulf (talk) 01:31, 6 November 2024 (UTC)

• I have merged the scrutineers/scrutineering sections. Soni (talk) 11:53, 6 November 2024 (UTC)
• I reworded the scrutineering questions back Novem Linguae. I think the phrasing in Special:Diff/1255727575 is inadvertently misleading. Personally, it wasn't until SD0001's phrasing that I realised it's not exactly a binary choice of "either IPs are checked or they aren't" and so I think the options should clearly spell out what both scenarios look like. ProcrastinatingReader (talk) 13:22, 6 November 2024 (UTC)

  Knowing nothing about scrutineering: do we need 3 different people doing it, or might two suffice? Especially if we do the scrutineering locally, a smaller group might be good for privacy. —Femke 🐦 (talk) 19:45, 9 November 2024 (UTC)

  The proposal at Wikipedia:Requests for comment/Arbitration Committee Elections December 2024#Proposal 5: Majority certification to require certification from only 2 of 3 scrutineers found clear consensus against. While it is not the same thing, it is related and worth reading. I don't think reducing to 2 would gain consensus. Thryduulf (talk) 01:18, 10 November 2024 (UTC)

  My understanding is each of the 3 scrutineers checks all voters (rather than splitting it up and checking one third), and the reason we have 3 is to decrease the chances of missing something. While I would not be opposed to decreasing it to 2 or 1, I also don't think we need to, since I don't think finding 3 enwiki checkusers would be a problem. –Novem Linguae (talk) 04:17, 10 November 2024 (UTC)

  One advantage of an odd number of scrutineers is that ties can be broken in the case of differing opinions. That being said, perhaps we could ask some past scrutineers on the likelihood of there being a disagreement during scrutineering, based on the types of issues they look for. isaacl (talk) 06:45, 10 November 2024 (UTC)

• Noting that we need to get explicit consensus to grant CU to the stewards per Wikipedia:Arbitration Committee/Noticeboard#CheckUser access for administrator election scrutineers. I have added something to this effect to option A. HouseBlaster (talk • he/they) 19:57, 9 November 2024 (UTC)

Voter guides

Question 1: For future administrator elections, should Wikipedia:Administrator elections link to unofficial voter guides?

• Option A - No. (current)
• Option B - Yes. A sentence similar to An unofficial list of voter guides may be found at Category:Wikipedia administrator elections 2024 voter guides. will be placed on the page.
• Option C - Yes. A list of voter guides will be maintained on the page (directly or via transclusion).

Question 2: For future administrator elections, what shall the rules be regarding other links to unofficial voter guides?

• Option A - May not be mentioned at Wikipedia:Administrator elections. May be mentioned on other pages such as talk pages. (current)
• Option B - May be linked from any election-related page.
• Option B - May not be linked from any election-related page.

Question 3: For future administrator elections what shall the rule be regarding official voter guides?

• Option A - No official voter guide shall be produced (current)
• Option B - An official voter guide shall be produced, containing only a pre-agreed set of factual statistics in a pre-agreed format
• Option C - An official voter guide shall be produced without restriction on content or formatting

--

• I have merged two voter guides questions together. Soni (talk) 11:53, 6 November 2024 (UTC)

Q1 option 3 is silent on whether linking unofficial guided anywhere in the elections related pages (or anywhere at all) is allowed. – robertsky (talk) 09:09, 7 November 2024 (UTC)

Good point. I've refactored that into two questions, one about a prominent link the other about other links (I've also adjusted the options to use A and B not 1 and 2). Wordsmithing is more than welcome. Thryduulf (talk) 10:27, 7 November 2024 (UTC)

I'm not sure what the logic is for option Q3 Option C. If we do something "Official", surely there should be an agreed list of statistics there? I don't think we need to be discussing format here per WP:BIKESHED. —Femke 🐦 (talk) 09:57, 9 November 2024 (UTC)

Q3B limits what consensus can choose to include in an official guide, Q3C's only limit is what gains consensus (e.g. it could contain subjective commentary if consensus agreed with that). Thryduulf (talk) 00:26, 10 November 2024 (UTC)

So the key difference between B and C is the word "factual statistics", rather than "pre-agreed". Both options will require consensus? As written, the options are not clear. I think there is no chance that an official voter guide with subjective commentary gains consensus, and would prefer for option C to be omitted and B to be rephrased as "An official voter guide shall be produced, containing only a pre-agreed set of factual statistics". —Femke 🐦 (talk) 08:33, 10 November 2024 (UTC)

Suffrage requirements

Who may vote in future administrator elections?

• Option 1 - Use the Arbitration Committee elections suffrage criteria: created their account over 2 months before the election, have 150 mainspace edits by 1 month before the election, have 10 live edits in the year running up to 1 month before the election, not be sitewide blocked during the election, not be vanished, not be a bot, and not have already voted with this or another account. (current)
• Option 2 - Use the Requests for adminship suffrage criteria: SecurePoll will be programmed to require extendedconfirmed on English Wikipedia, not be sitewide blocked on English Wikipedia, and not be a bot. Additionally, scrutineers will remove any duplicate votes, sockpuppet votes, or vanished account votes.

--

There is no way to determine how many that have met the current suffrage requirements who have voted vs how many ec editors who have voted to determine if a stricter suffrage benefits future elections, other vague concerns of voting blocs being forms among the newer editors for nefarious purposes. At 616 votes, a group just need to hassle up 300 meat socks to create the accounts and sustain the accounts. (It can be quite easy for some groups to do so). I feel that this question might be quite contentious when being asked in the rfc. – robertsky (talk) 09:06, 7 November 2024 (UTC)

The benefit is on the back end. Option 2 is a major workflow improvement because it allows WMF T&S to tick a couple boxes in the Voter Eligibility section of SecurePoll and be done with that part, instead of having Cyberpower678 spend several hours using a special tool generating a list, then giving that list to WMF T&S to upload. –Novem Linguae (talk) 10:58, 7 November 2024 (UTC)

Given the obvious benefits to workflow, why do the ArbCom elections use a different threshold? Was it chosen to make it less easy to game? I don't think we should do things just to make workflow easier, though aligning with RfA is an objective. Espresso Addict (talk) 10:57, 8 November 2024 (UTC)

The rules for arbcom suffrage predate extended-confirmed protection (although they have evolved since then so it), e.g. WP:ACE2010 An editor is eligible to vote who (i) has a registered account and has had at least 150 mainspace edits by 1 November 2010; and (ii) is not a blocked user for at least part of the voting period.. ECP wasn't invented until circa 2016 (e.g. Wikipedia:Extended confirmed protection was created in December 2016).

The reason for the activity requirement was a desire to restrict voting to only those actively engaged with the community (see e.g. Wikipedia:Requests for comment/Arbitration Committee Elections December 2019#Voter eligibility requirements). Changing the requirements to extended-confirmed protection is something that can be discussed, but not here. Suggest it for next year's RFC at Wikipedia talk:Requests for comment/Arbitration Committee Elections December 2025. Thryduulf (talk) 11:43, 8 November 2024 (UTC)

Minimum vote requirement

Question 1: Should there be a minimum vote requirement to elect a candidate? Should there be a minimum vote requirement to elect a candidate?

• Option 1 - no requirement. (current)
• Option 2 - require 20 supports minimum to pass
• Option 3 - require 50 supports minimum to pass
• Option 4 - require 100 supports minimum to pass
• Option 5 - requirement based on quorum, e.g., if a majority of voters abstain, there is no quorum to pass. [I don't understand this one. Can it be reworded for clarity?]

option 6 as an alternative to question 2
The following discussion has been closed. Please do not modify it.
Option 6 - Candidates can only pass if they get more supports than abstensions

Question 2: Should there be a requirement to receive more support votes than abstentions in order to pass?

• Option 1: No (current)
• Option 2: Yes

I've added question 2 based on what I think question 1 option 5 is trying to ask, but it is not mutually exclusive with any of options 1-4 (and maybe also option 5 if I haven't understood it correctly). Thryduulf (talk) 04:20, 6 November 2024 (UTC)

For the sake of keeping the mini RfCs simple, do we need question 2? There is nothing similar in normal RfA world, and if we do not sort out the sorting of candidates well, it gives a clear disadvantage to the final candidates on the list. —Femke 🐦 (talk) 07:21, 6 November 2024 (UTC)

In normal RFA world abstentions aren't really a thing (it appears no successful candidate since at least 2021 has had more than 5% neutral votes), so I don't that that's how we should judge whether the question is necessary. As I noted I wrote it based on my understanding of what option 5 was trying to ask, but looking at it again I'm wondering if it is actually trying to require successful candidates to be supported by at least a certain percentage of all voters? Thryduulf (talk) 08:24, 6 November 2024 (UTC)

I have attempted to phrase Q2 as Option 6, since it's effectively an extra option being added. Feel free to reword or revert. I'm not currently convinced Option 5 or 6 are necessary to present Soni (talk) 12:17, 6 November 2024 (UTC)

I have restored question 2 as it is independent of the other options. For it would be possible to get 70% support with say 70 support votes but 150 abstain votes, with no minium support number it would even in theory be possible to be elected with 3 support votes, 1 oppose vote and 500 abstain votes. Thryduulf (talk) 12:40, 6 November 2024 (UTC)

Option 5 and Question 2 are not the same. I read Option 5 as requiring that Support + Opppose > Abstain, whereas Question 2 requires Support > Abstain (a significantly higher bar). Toadspike [Talk] 16:10, 6 November 2024 (UTC)

Hmm, I hadn't recognised that interpretation of option 5 but now you say it I can see it either way. We could rework Q2 to be something like:

Should there be a requirement to receive more support or more support+oppose votes than abstensions in order to pass.

• Option 1 No (current)
• Option 2 Yes, a candidate must receive more support votes than abstentions to pass (i.e. Support > Abstain)
• Option 3 Yes, a candidate must receive fewer abstentions than the total of support and oppose votes to pass (i.e. (Support + Oppose) > Abstain)

But that is horrible wording and needs significant improvement. Thryduulf (talk) 17:35, 6 November 2024 (UTC)

I support combining the current Option 5 into Question 2. Options 2 and 3 should have parallel wording. Example O3: "Yes, a candidate must receive more total support and oppose votes than abstentions to pass". Toadspike [Talk] 17:44, 6 November 2024 (UTC)

Toadspike's interpretation is what I had in mind :) theleekycauldron (talk • she/her) 00:41, 8 November 2024 (UTC)

In the current ongoing RfA there are 171 !votes but over 10000 page views and I would bet that these contain significantly more 'abstains' than votes... so they would automatically fail with this logic. KylieTastic (talk) 10:21, 8 November 2024 (UTC)

Abstentions are an artifact of the voting format so should not be used. I did not have time to review all of the candidates so I just voted for those I knew and had opinions on, it did not mean that the other candidates would not have got my support. If I thought my abstentions had any negative impact on others I would have refrained from submitting any vote. KylieTastic (talk) 17:54, 6 November 2024 (UTC)

The abstain option is a convenience so that all the votes can be be bundled into one ballot. I don't think it makes sense to require candidate Z to have more support votes than the number of people who wanted to vote on other candidates but not candidate Z. isaacl (talk) 01:10, 7 November 2024 (UTC)

These seem like a solution in search of a problem. In this last election, we had 616 voters, and the lowest support+oppose a candidate received was 318. Assuming we continue to market admin elections the same way in the future (watchlist message, MMS on certain talk pages, etc.), I think there is zero danger of having low quorum. –Novem Linguae (talk) 11:03, 7 November 2024 (UTC)

Call for Candidates phase duration

Question 1: When should candidates sign up to stand in an election?

• Option A: Nomination window - candidates may nominate themselves only during a specified window (current)
• Option B: Open sign up - candidates may nominate themselves at any time up to the deadline

Question 2: If open sign up is chosen, for which elections should nominations be accepted?

• Option 1: Only the next scheduled election
• Option 2: The next scheduled election and the election after that
• Option 3: The next scheduled election and the following two elections
• Option 4: For any future election.

Question 3: If a nomination window is chosen, at what time of day should it open?

• Option 1: The window should always open at the same time (e.g. 00:00 UTC)
• Option 2: The window should open at a different time of day each election (e.g. move forward 6 hours).

Based on feedback in the debrief. More options and better wording for Q3 particularly welcome. Thryduulf (talk) 04:00, 6 November 2024 (UTC)

I think Q2 is superfluous. Question 3, I am not convinced should be asked right away, because it's both a leading question and relatively minor in the overall scheme of things. We should attempt to reduce overall number of questions we present finally. Soni (talk) 12:14, 6 November 2024 (UTC)

Re Q2, why do you think it is superfluous? Is it just because it's dependent on the outcome of Q1? We will need to ask a follow-up question regardless of what the answer to Q1 is, and the goal is to be able to present as proposal with agreed answers to as many significant questions as we can for the "do we continue to have admin elections?" RFC. Feedback suggests that people do see these as important questions. I agree Q3 is badly worded, but I've failed to come up with something better - please improve it. Thryduulf (talk) 12:52, 6 November 2024 (UTC)

Q2 is dependent on the outcome of the Max # of candidates question, and indirectly on the frequency of elections (which doesn't seem to be a question yet?!). I agree with Soni that Q2 and Q3 might clog the RfC with minutia. Reading Q1 Option 1 literally, the default option of Q2 would be Option 4 – we can hash out the specifics in a later RfC, once we know whether Q1 is accepted and we have enough noms for Q2 to be a problem. Toadspike [Talk] 16:19, 6 November 2024 (UTC)

I agree that Question 2 is dependent on election frequency, so perhaps should be discussed after that, or bundled into it. isaacl (talk) 01:13, 7 November 2024 (UTC)

This section is complicated and hard to wrap my head around. May need some simplification. –Novem Linguae (talk) 16:30, 8 November 2024 (UTC)

I've tried to improve Question 3. I'm not sure how to simplify the other two questions. Thryduulf (talk) 18:49, 8 November 2024 (UTC)

Candidate ordering

How should candidates be ordered on the candidate page and in the SecurePoll software?

• Option 1: Chronological by signup date on call for candidates page, random in SecurePoll (current)
• Option 2: Chronological by signup date
• Option 3: Random
• Option 4: Alphabetical
• Option 5: Alphabetical, but the first entry is randomized. For instance, if Alice, Bob and Charlie sign up, the order could be "Alice, Bob, "Charlie" or "Bob, Charlie, Alice", but not "Alice, Charlie, Bob".

I don't know how easy SecurePoll is to configure, and whether option 5 is possible. —Femke 🐦 (talk) 07:32, 6 November 2024 (UTC)

Option 5 is not currently possible. Would require phab:T378313. –Novem Linguae (talk) 10:10, 6 November 2024 (UTC)

Discussion phase length

Question 1: How long should the discussion phase be?

• Option A – 3 days, prior to the voting phase (current)
• Option C – 5 days, prior to the voting phase
• Option E – 7 days, prior to the voting phase
• Option E2 – 7 days, concurrent with the voting phase
• Option F – 10 days, including the 7-day voting phase
• Option G – 14 days, including the 7-day voting phase

Question 2: If options E2, F, or G above are chosen, shall formal questions and answers on candidate pages continue during the voting phase?

• Option 1 – No (current)
• Option 3 – Yes, additional formal questions and answers are permitted.
• Option 4 – Exceptionally, further questions may be permitted but candidates are not obliged to answer them.

Original questions 1 and 2
The following discussion has been closed. Please do not modify it.
Question 1: How long should the discussion phase be? Option A – 3 days (current) Option B – 4 days Option C – 5 days Option D – 6 days Option E – 7 days Option F – 10 days Option G – 14 days Question 2: Shall discussion be allowed to continue on candidate pages during the voting phase? Option 1 – No (current) Option 2 – Yes, but discussion only. No additional questions for candidates. Option 3 – Yes, and additional formal questions and answers are also permitted. Option 4 – Yes, and exceptionally further questions may be permitted but candidates are not obliged to answer them.

Question 3: Shall the discussion phase be required to overlap with the weekend?

• Option 1 – No (current)
• Option 2 – Yes

--

I'd argue again for omitting the options that are very unlikely to garner a lot of support, that is, the 10/14 days. These kind of extreme options do have an impact on the final results, as in, if you include an extreme option, this changes what people perceive as the middle / moderate option, making them more likely to be chosen. —Femke 🐦 (talk) 11:12, 6 November 2024 (UTC)

I've seen multiple people comment that discussions should be open throughout the voting phase, which requires a discussion phase length of at least 7 days, unless this question is clarified to how long the discussion phase should be open before voting begins. Thryduulf (talk) 11:16, 6 November 2024 (UTC)

@Thryduulf I think the easy solution is to change F to "10 days, including the 7-day voting period" and change G to "14 days, including the 7-day voting period". Question 2 would then be "If options F or G are chosen, should new questions for the candidate be allowed during the voting period". --Ahecht (TALK
PAGE) 20:02, 7 November 2024 (UTC)

I WP:BOLDly went ahead and did this, as well as implemented the suggestion below about removing 4 and 6 days. Kept the option numbers the same to avoid confusion. ----Ahecht (TALK
PAGE) 20:36, 7 November 2024 (UTC)

Good solution. Thryduulf (talk) 21:06, 7 November 2024 (UTC)

I'd argue for a different kind of Discussion Phase slider. I think there's value in considering a discussion phase that is flexible based on number of participants. For the simplest mock up idea, "7 days, but extended to 14 days if >15 candidates". Soni (talk) 11:47, 6 November 2024 (UTC)

I'd also omit Option B (4 days) and Option D (6 days). They are functionally identical to A/C/E. Just list the most important granularities, and if people want to add a midway option, they !vote on proposals with B.2 and such anyway Soni (talk) 15:17, 7 November 2024 (UTC)

Yes, 3/5/7/10/14 seem like the most sensible options, and probably stands a better chance of getting consensus. Thryduulf (talk) 19:09, 7 November 2024 (UTC)

Perhaps Q3 should have a note like (Note that this does not extend the discussion time as given in Question 1). Otherwise we might have cases of people being confused whether it's 10 days + voting period (however long). Or 10 days (with some of it overlapping). Soni (talk) 15:19, 7 November 2024 (UTC)

We could probably simplify things by merging questions 2 and 3. Thryduulf (talk) 19:11, 7 November 2024 (UTC)

--

Adding ill-worded option 4 because I think if something new comes up late it would be valuable (possibly to the candidate as well as the questioner) to allow a question-and-answer exchange to explain the issue, but I don't think we should be expecting, as a matter of course, questioning to continue indefinitely. Perhaps we could have one or more moderator(s) who will be allowed to add questions? Espresso Addict (talk) 10:50, 6 November 2024 (UTC)

@Espresso Addict Question 2, and especially Option 4, is currently allowed – on the candidate's user talk page. This might be worth clarifying somewhere. (See Wikipedia:Administrator_elections#Period_3:_Voting, Candidates may be asked direct questions on their user talk pages...) Toadspike [Talk] 16:33, 6 November 2024 (UTC)

I know. However I did not visit the talk pages of candidates again (after I'd reviewed them), it was all just too time-consuming. It's a poor process, imo, where some researching voter finds something genuinely apparently problematic, and is unable to bring it to the attention of the community. (If nothing else it just postpones the inevitable drama.) I don't see how someone finding a serious apparent problem is well served by taking it to the candidate's talk page; for a start, it feels rude, and also it would be easy for the candidate to just delete and ignore it. Espresso Addict (talk) 23:08, 6 November 2024 (UTC)

@Espresso Addict Questions, other than the first three, are always optional, so I fail to see how option 4 is different from option 3. --Ahecht (TALK
PAGE) 20:20, 7 November 2024 (UTC)

Ahecht Yeah, yeah, but OptionalQuestionsAreNotOptional is one of the fundamental tenets of RfA culture. Espresso Addict (talk) 00:42, 8 November 2024 (UTC)

@Espresso Addict Exactly, and I don't think that these "optional" extra questions would be any different. --Ahecht (TALK
PAGE) 00:50, 8 November 2024 (UTC)

--

Question 1 still conflates two entirely separate issues: How long should discussion last before voting begins, and when/whether the discussion pages should be closed prior to the end of voting. Listing a bunch of options mixed from answers to those two questions is really non-ideal. —Cryptic 21:53, 7 November 2024 (UTC)

I think the most convenient way for people to sum up their views is to state how early before voting do they want discussion to start, and how long they want the discussion period to be. Something like "Starting 5 days before voting, for 10 days". (Although my first thought was to ask how many days before voting and how many days during as separate questions, I think for most people the answer for one depends on the answer for the other.) Thus I suggest wording the options in that manner (starting X days before voting, for Y days), and doing the same when asking about the duration of the Q & A period. isaacl (talk) 22:18, 7 November 2024 (UTC)

Thus for example:

• starting 7 days before voting, for 7 days
• starting 7 days before voting, for 14 days
• starting 5 days before voting, for 5 days
• starting 3 days before voting, for 3 days
• starting 3 days before voting, for 10 days
• starting when voting starts, for 7 days

isaacl (talk) 22:21, 7 November 2024 (UTC)

This is exactly the same as before, just with different arbitrary intersections of answers to the two questions. —Cryptic 18:47, 8 November 2024 (UTC)

My intent was to make all the options use the same format in describing the choices, so they can be more easily compared. isaacl (talk) 21:44, 8 November 2024 (UTC)

I think it can be simpler still:

Question 1: How long before voting should the discussion period start?

• Option A: 7 days
• Option B: 5 days
• Option C: 3 days (current)
• Option D: 1 day
• Option E: 0 days - discussion should not start before voting

Question 2: Should the discussion period remain open during the voting period?

• Option A: No (current)
• Option B: Yes, but only for discussion (no additional questions may be asked)
• Option C: Yes, for discussion and questions.

Thryduulf (talk) 23:06, 7 November 2024 (UTC)

Are you assuming that the discussion period will overlap 100% with the discussion period? Otherwise, the duration also needs to be specified, thus my suggestion of the options being based on start date and duration. I think the answers to your questions remain correlated. I can see someone wanting discussion to start at least 3 days before voting, and prefer it to continue for 4 days into voting, but if the result for question 2 was no, they'd prefer discussion to start 7 days before voting. isaacl (talk) 23:24, 7 November 2024 (UTC)

I think it way more likely someone would accept any of "starting 3 days before voting for 10 days", "starting 5 days before voting for 12 days", "starting 7 days before voting for 14 days", or starting "23 days before voting, for 30 days", because the more important issue is not having to hope people read your thread on Wikipediocracy about the hate speech you discovered just after the discussion period ended. Or, if you like, being able to put diffs of apparent hate speech on the discussion page just before discussion ends so that the candidate doesn't get a chance to respond. —Cryptic 18:47, 8 November 2024 (UTC)

Maybe flip it around from the other direction: if I recall correctly, some people want discussion to halt before the end of voting to give the candidates a respite from following it. So perhaps the questions can be: when should the discussion start, relative to the start of voting? And when should it end, relative to the end of voting? Those worried about discussion in other places during voting can opt for ending discussion at the same time as the voting. isaacl (talk) 21:41, 8 November 2024 (UTC)

Supervising the election

What shall the administrator elections page say about who supervises the process?

• Option A - The process is supervised by the bureaucrats. (current)
• Option B - The process is supervised by the electoral commission, in consultation with the community.
• Option C - The process is supervised by the electoral commission, currently consisting of Novem Linguae, in consultation with the community.
• Option D - Delete the bureaucrat sentence, and do not replace with anything.

I'm unsure exactly what direction to go in, but I do know that the bureaucrats didn't play much of a role in our previous election, so I think that sentence needs updating. I personally also think that we don't need a complex electoral commission yet like ACE has, with watchlist notices and yearly electoral commission RFCs and multiple people, but if someone wants to add that as an option, that's fine. –Novem Linguae (talk) 10:36, 6 November 2024 (UTC)

The fact that the first election was successfully run entirely by Novem Linguae and other volunteers makes me question why ACE needs an elected electoral commission at all. Toadspike [Talk] 16:35, 6 November 2024 (UTC)

That's a question for Wikipedia:Requests for comment/Arbitration Committee Elections December 2025 (you can leave a note about it on the talk page). Thryduulf (talk) 17:26, 6 November 2024 (UTC)

Remember the questions that came up and were argued about on the talk page, with an urgency to reach a consensus before the decision became moot? The arbitration committee electoral commission was created to deal with issues that arise when there isn't sufficient time to determine community consensus. isaacl (talk) 01:21, 7 November 2024 (UTC)

I suggest not saying the process is supervised by anyone. Perhaps there can be a list on a separate transcluded page of volunteers who are co-ordinating the process. isaacl (talk) 01:18, 7 November 2024 (UTC)

It doesn't really need supervision. I'd leave this one out. Espresso Addict (talk) 01:36, 7 November 2024 (UTC)

Participating in administrator elections multiple times

Are unsuccessful candidates from an admin election allowed to reapply for adminship at a subsequent admin election?

• Option A: Yes (current)
• Option B: Yes, but not the immediately following one
• Option C: Yes, but no candidate may run more than 3 times.
• Option D: No, any future requests for adminship must go through standard RFA.

— Mox Eden (talk) 13:47, 6 November 2024 (UTC)

I've tweaked the question slightly and added a third option (as option B, because that's clearer). Thryduulf (talk) 14:06, 6 November 2024 (UTC)

I've also added another option as Option C – it seems like the most straightforward fix if the community is worried about hordes of perennial candidates. Toadspike [Talk] 16:38, 6 November 2024 (UTC)

imo if we place a limit on reapplying for elections, it should go together with a limit on the number of candidates for each election. My rationale is that with a limit on the number of candidates, we should prioritise giving the candidacy to fresh candidates. Without such limit, perennial candidates may just see their number of votes supporting them slipping each time anyway... – robertsky (talk) 17:11, 6 November 2024 (UTC)

@Robertsky see #Candidate signup priority ordering for that. Thryduulf (talk) 17:16, 6 November 2024 (UTC)

@Thryduulf I mean, a limit of the number of candidates per round, which I think #Maximum # of candidates in each election is more applicable. – robertsky (talk) 17:20, 6 November 2024 (UTC)

Well, the two are both relevant as if you have a limit you need to decide how to apply it. Thryduulf (talk) 17:27, 6 November 2024 (UTC)

True that.. – robertsky (talk) 17:44, 6 November 2024 (UTC)

This question is related to candidate signup priority ordering, though not entirely dependent on it. Perhaps in the RfC they should be listed one after another with cross-links after the options. isaacl (talk) 01:26, 7 November 2024 (UTC)

@Mox Eden I would tweak Option B to define a specific period of time, such a "6 months" or "1 year", as it would be hard to vote for that one not knowing how frequently elections are held. --Ahecht (TALK
PAGE) 20:05, 7 November 2024 (UTC)

I think the goal with this is to prevent perennial candidates taking up slots, if so that applies regardless of election frequency. If you think a specific time period is a useful option then I suggest adding it as an additional option (Between the current B and C would probably make the most sense). Thryduulf (talk) 21:20, 7 November 2024 (UTC)

+1 agreed, a time period probably makes more sense as a write-in. Like "Option C: Yes, but no candidate may run within a certain timeframe (declare the timeframe in your response)" Leijurv (talk) 00:28, 8 November 2024 (UTC)

When restricting this, I think it's important to keep in mind which kind of candidates we'd like to have another try: that is, those who almost made it and just needed a bit more experience in some areas, or needed a nominator and weren't clear in the previous election that that was still something voters expected to see.

Whether option B is restricting these candidates depends the frequency. With 2 months between elections, it's fair. If it's 2x per year, we'd be restricting good candidates. I think we should write the questions in such a way that none of the answers depend overly on other questions, so I'd support rewriting B as "Can run only once per 6 months" or smth. —Femke 🐦 (talk) 19:35, 9 November 2024 (UTC)

Election frequency

Question 1: Ideally, how often should administrator elections be held?

• Option A – Every year
• Option B – Every six months
• Option C – Every three months
• Option D – Every two months
• Option E – Every month

Question 2: Shall the election run based on the number of candidates that sign up?

• Option A – No, regularly scheduled elections should run regardless of the number of candidates. The election is only skipped if there are zero candidates.
• Option B – Yes, regularly scheduled elections should run only if the maximum number of candidates has been reached, otherwise the election is skipped.
• Option C – Yes, regularly scheduled elections should run only if some other minimum threshold (write-in your number) of candidates has been reached, otherwise the election is skipped.

Question 2 Option B requires a consensus for "Maximum # of candidates in each election".

Toadspike [Talk] 16:24, 6 November 2024 (UTC)

Until local elections are a thing (see T301180) only options B and G are possible. Thryduulf (talk) 17:40, 6 November 2024 (UTC)

Not quite. The list of SecurePoll elections [1] has a lot of free slots we could use. Also, elections in the same language can overlap, since they don't require VoteWiki's interface language to be changed. This means that AELECT could run at the same time as enwiki ACE, Board elections, U4C elections, and anything else from Meta. (Please correct me if I'm wrong, this is an important topic to figure out.) Toadspike [Talk] 17:55, 6 November 2024 (UTC)

@Toadspike Not just in the same language. Elections in multiple left-to-right or multiple right-to-left languages can overlap. You just can't mix the two text directions. --Ahecht (TALK
PAGE) 20:07, 7 November 2024 (UTC)

Even better! The most recent right-to-left SecurePoll vote I see is a Farsi Wikipedia vote in October/November 2023. These seem to take place every two years or so. Otherwise, there are no conflicts. Practically, it looks like the only limitation until we have local elections is the capacity of the various humans involved (T&S, scrutineers). Toadspike [Talk] 20:11, 7 November 2024 (UTC)

I've added the word "ideally" to make this less binding. Right now we are dependent on a couple key people (me) and partners (WMF T&S, Cyberpower678, 3 stewards) to run elections, which severely limits how often we can run them (in particular the WMF T&S election calendar). Even when Wikipedia:Village pump (idea lab)#Determining who should be an electionadmin is completed and we are not so dependent on the WMF T&S election calendar, running elections is still an expensive process in terms of electoral commission time, voter time, etc. –Novem Linguae (talk) 21:47, 6 November 2024 (UTC)

I understand if it's impractical / too vague, but I feel as though none of these are ideal. A fixed schedule is not ideal because it does not adapt to demand. Demand too low: if only 0 to 2 candidates run every month, there could be a chilling effect due to being unable to blend in with the crowd, and as Novem says, it would be a big waste of time. Demand too high: either we allow unlimited candidates (which seems to have strong consensus against), or, more likely, we have some cap. Then, there will be weird incentives and issues, for example if we open a candidate list every month there could be a rush to sign up, and we'd have to worry about prioritization order and disqualifying repeat runners and such. Whatever we do, there should be some mechanism to allow supply to rise/fall to match demand. Here's my suggestion: Option H - Regularly scheduled every month, but skipped if the current number of candidates has not reached the limit Or it could be a separate question: Question 2: Shall elections be skipped if fewer candidates sign up than the cap? Leijurv (talk) 22:32, 6 November 2024 (UTC)

Isn't this just Option F/G but with a schedule to boot? Toadspike [Talk] 22:39, 6 November 2024 (UTC)

Yes. Hence why I waffled about whether it should be part of the same question or another. "Only run the election if we reach a minimum quantity of nominations?" is a good question to ask, but there are a few details, I think there are at least 4 reasonable answers: 1. "No, don't do that (ignore the number of candidates)" 2. "Run it immediately when that happens" 3. "Run it X days after whenever that happens" 4. "Run it at the next regularly scheduled interval" (my preference). Arguably, the frequency question is independent of this. So perhaps this should be two questions? Leijurv (talk) 22:46, 6 November 2024 (UTC)

Got it. Feel free to reorganize the question above into a few separate ones. I worry that there are so many different possibilities, each with their own numbers/details to work out, that this could balloon pretty quickly. Toadspike [Talk] 22:53, 6 November 2024 (UTC)

I've tried my hand at a rewrite, but I feel as though this is tricky and hard to phrase given the overlap between the questions. For example, if the election runs on a regular schedule no matter what, I might support a longer schedule, say annually, whereas if we'll skip it if we don't get enough candidates, I'd support a much quicker schedule, say, monthly. I'm left unsure whether my edit is an improvement, anyone please feel free to revert/rewrite! Leijurv (talk) 23:01, 6 November 2024 (UTC)

I think this looks very good, actually. Thank you! Toadspike [Talk] 23:06, 6 November 2024 (UTC)

(edit conflict × 3) I think it should be up to the candidates. If they are happy running in a very small field we should let them do so. As an OTTOMH suggestion for how it could work.

Every candidate when signing up specifies the minimum field size they are happy to participate in, up to a maximum of two fewer than the cap (e.g. 13 if the cap is 15). The candidate may change this at any time before deadline day.

On deadline day the maximum number of candidates is now known.

• If there are more candidates than slots, then candidates are sorted per the method decided in this RFC, any that don't get a spot are put on a waiting list in case of last-minute withdrawals.
• If fewer than 60% of the slots are filled, those candidates whose minimum is greater than the number of candidates are moved to next month. e.g. if there are 5 candidates but person A's minimum is 6 then person A is withdrawn from this election.
• This process continues until either there are no candidates (no election) or all candidates have a minimum that is greater than or equal to the remaining number of candidates (election with than many candidates).

Thryduulf (talk) 23:08, 6 November 2024 (UTC)

I think this is interesting but 1. it makes more sense as a subquestion of #Maximum # of candidates in each election rather than here and 2. it's quite complicated. I like it but it might be a bit too convoluted. Also, I think the idea of a minimum would also be to "not waste the community's time" with a SecurePoll election for like 1 or 2 candidates. Therefore, to some extent it's up to the comfort of the candidates, but not entirely. I see this in your 60% floor, but, I guess I feel as though the 60% to 100% range is not that compelling relative to the added complexity. But maybe I'm wrong and we'll want a minimum that's different than the maximum? Leijurv (talk) 23:22, 6 November 2024 (UTC)

With an open signup list, I think we can leave it up to the nominators to decide if they want to withdraw. I think that will be simpler for everyone. isaacl (talk) 01:30, 7 November 2024 (UTC)

Thruduulf, that is logical but extremely complicated, and I think it is likely to result in a no consensus RfC. Toadspike [Talk] 09:29, 7 November 2024 (UTC)

Personally, I think the best approach to build momentum is to have a regular cadence, so it becomes a normal, expected event. If after a few iterations there are fewer or more candidates than desired, the frequency can revisited. isaacl (talk) 01:35, 7 November 2024 (UTC)

Question 2, Options B and C would open the possibility of having back to back elections at the current pace of setting up and running the elections proper. There will be a fatigue among the election organising team. – robertsky (talk) 02:38, 7 November 2024 (UTC)

I agree with concerns about fatigue – my comments on cadence here and elsewhere are not just for the benefit of candidates, but all volunteers, including those co-ordinating the election, scrutinizing votes, and voting. isaacl (talk) 03:10, 7 November 2024 (UTC)

I don't like B or C either. If we think they are unrealistic to ever reach consensus, should we replace 2 weeks with a more realistic longer option, perhaps 2 months? Or perhaps that just means the "whenever the list fills up" approach is not plausible in the first place. Leijurv (talk) 04:10, 7 November 2024 (UTC)

I propose to strikethrough 1F, 2B, and 2C because I don't think snap elections would plausibly reach consensus. Thoughts? Leijurv (talk) 22:00, 7 November 2024 (UTC)

I've got no objection to that. There has been a lot of feedback that voters expect candidates to be responsive to questions, etc. and so candidates should know when they need to be around and so can choose to stand at a time convenient to them. Thryduulf (talk) 22:51, 7 November 2024 (UTC)

I've gone ahead and removed the snap election options, and simplified the remaining ones to a yes/no. Leijurv (talk) 00:14, 8 November 2024 (UTC)

Question 2 needs at least one option for a minimum number of candidates between zero and max (perhaps 3 and 5). Say the maximum is set as 15, almost everyone will be happy to run if there are only 14 but not everyone would be if there are only 2. Thryduulf (talk) 00:28, 8 November 2024 (UTC)

If there are only two, the person unwilling to run can withdraw. I think it's reasonable to allow the single person to run alone if the candidate is willing. isaacl (talk) 00:34, 8 November 2024 (UTC)

I think it's possible that there could be a "death spiral" where someone withdraws, causing someone else to withdraw, etc etc etc. I don't think we can really prevent that, so let's just leave it up to the candidates - if they don't like it they can withdraw at any time. With respect to the number, I guess that should be a write-in? Something like Yes – Regularly scheduled elections should run only if some minimum number (write-in your number) of candidates has been reached, otherwise the election is skipped? Leijurv (talk) 00:42, 8 November 2024 (UTC)

Sure, it's a reasonable question to pose to the community. (My personal preference is for the community to accept the cost of making the train run regularly as a sunk cost, and from a voter perspective, I don't think having one person in an election makes the voting process less efficient. Scrutineers might feel that their time isn't being leveraged as much as they might like.) isaacl (talk) 00:51, 8 November 2024 (UTC)

Sure, I think the first option is totally reasonable. I've added the write-in option here Leijurv (talk) 00:57, 8 November 2024 (UTC)

I realised that we might one to spell out that the election may close early if it ends up with everyone withdrawing, and the next election will be as scheduled, i.e. not brought forward. – robertsky (talk) 10:45, 9 November 2024 (UTC)

How about, if a max number of candidates proposal gets consensus, elections run whenever the number of candidates pending for election reaches the maximum, with a minimum of 1 week break between elections and a maximum of 2 months a single user can spend on the pending list (i.e. an election will run for all pending candidates when at least 1 candidate has been waiting 2 months since the last time they did an RfA, RRfA or made the pending list)? MolecularPilot 07:31, 8 November 2024 (UTC)

Clarifying that becoming a pending candidate, means that there is space to (i.e. the list of people pending isn't full yet).

We can have a waiting list for the pending list as well if wanted. MolecularPilot 07:32, 8 November 2024 (UTC)

That's basically Question 2 - the election would run only when the number of candidates reaches some threshold. The difference would be a regularly scheduled election versus a snap election. See the discussion above and on the Debrief page, I don't think an unscheduled snap election would get consensus. For example the candidates wouldn't know ahead of time when they're signing up for being available to answer questions. Leijurv (talk) 17:25, 8 November 2024 (UTC)

WP:ORCP as a requirement

Should it be a formal requirement that admin election candidates must have raised a Optional RfA Candidate Poll (ORCP) prior to submitting their candidacy?

• Option A - No (current)
• Option B - Yes - ORCP must have been created during the 6 months prior to the election
• Option C - Yes - ORCP may have been created at any point prior to the election
• Option D - Yes - Unless they are nominated by a current administrator

BugGhost🦗👻 19:22, 6 November 2024 (UTC)

Adding this after being encouraged by @Espresso Addict: on my section in the debrief page. My reasoning for suggesting this as a requirement: Those who want more feedback will get it, the "barrier to entry" would be raised slightly so less "why not?"/NOTYET candidates would make it to the ballot, and the ORCP would be available at the time of the discussion phase, and so important topics would have been raised in advance. It would also (hopefully) mean that the candidates would know what areas they were weaker in, and also provides a good place for potential nominators to volunteer. As EA suggests, ORCPs may need to be renamed if this idea gets traction (maybe "informal RfA candidate polls"?), but we can cross that brige when we get to it. BugGhost🦗👻 19:22, 6 November 2024 (UTC)

Just a historical note: Anna Frodesiak created the optional RfA candidate poll as a way to give potential candidates a very quick read on their suitability to become an administrator (her original idea was just a numerical score). She asked for lists of possible admins from anyone, and posted messages to all of them inviting them to run a poll. She wanted to give them a little push of encouragement to make a request for administrative privileges. That was several years ago, and the regular commenters at the optional RfA candidate poll have changed, so currently they're more open to having more discussion and providing general feedback. I appreciate that processes can change, but nonetheless I would feel a bit sad to see Anna's original idea morph from an encouraging word to a mandatory review process.

One consideration to note is that there are prominent editors who think the benefits of the optional RfA candidate poll are better achieved through other means (such as asking an experienced RfA nominator for feedback privately), thus avoiding the drawback of getting potentially overly pessimistic projections, listed publicly for others to see and pick up on. isaacl (talk) 01:50, 7 November 2024 (UTC)

We could consider an extra option of WP:ORCP is suggested but not required for candidates running without nominators. Espresso Addict (talk) 01:57, 7 November 2024 (UTC)

There are already places that suggest holding a poll if you're interested in becoming an admin, including Wikipedia:Administrator elections § Eligible candidates, so I don't think an option is needed for that. isaacl (talk) 02:20, 7 November 2024 (UTC)

I added an Option D to address that. --Ahecht (TALK
PAGE) 20:13, 7 November 2024 (UTC)

I'm not sure what you're addressing? I don't support including option D, and I propose removing it. The reason I raised the consideration is not to say candidates with an admin nominator should be treated differently (and I mentioned feedback from someone experienced at nominating candidates, not necessarily an admin). It was to say that some editors think no serious candidate should undertake an optional RfA candidate poll, as they feel the downside outweighs the upside. isaacl (talk) 21:47, 7 November 2024 (UTC)

What's the motivation behind making this mandatory? If the motivation is to solve WP:TOOSOON problems, well, maybe this is a solution in search of a problem, since we didn't have any egregiously underqualified candidates (<5000 edits) in the last election. –Novem Linguae (talk) 07:31, 7 November 2024 (UTC)

+1 Toadspike [Talk] 09:36, 7 November 2024 (UTC)

I agree with skipping this question. It currently looks like we will have 20 questions to finetune this process, so I'd prefer limiting to the most requested ones Soni (talk) 15:16, 7 November 2024 (UTC)

The reasoning behind suggesting this as a mandatory requirement is to lower the number of candidates in a natural way (as an alternative to the candidate quantity limits that are also being considered). Raising the barrier to entry by getting feedback to candidates early makes the candidates self-select a bit more - not just on edit count but more general feedback as well. It also would take pressure off if there's another large set of concurrent discussions, as some opinions would have been brought up at the ORCP before the discussion phases. If this is an unpopular suggestion I'm fine with it being skipped, just offering it up as an alternative to candidate limits. BugGhost🦗👻 18:23, 7 November 2024 (UTC)

I agree this is a good question to ask. It's an easy bar to pass, yet I think it would still effectively discourage wasting spots, especially if those spots are limited. Leijurv (talk) 01:00, 8 November 2024 (UTC)

Me too. In addition to the points already mentioned, it gives a starting point for voters to understand the candidates, rather than having to start from scratch on all the ones that are unfamiliar, potentially making research easier and thus blanket opposes/neutrals less likely. In RfA one can easily find out what candidates are like by reading the existing votes. Espresso Addict (talk) 10:41, 8 November 2024 (UTC)

I think making it clear that nominators are very welcome in the EFA process will have a similar effect. People will ask potential noms and get feedback. I don't think this is likely to get consensus, and support skipping this question, partially because there are sometimes grumpy regulars at ORCP and that goes against the spirit of the election to lower the bar. —Femke 🐦 (talk) 19:23, 9 November 2024 (UTC)

ORCP is flawed at best. Like Femke, I'd recommend nominators, but this seems to me like a question that is way down the priority list. Valereee (talk) 21:57, 9 November 2024 (UTC)

Voting instruction in the interface

In the introductory text within the voting interface, should the following change be made to align it with the order of the radio buttons?

−

indicate your preference for each candidate with "Support", "Oppose", or "Abstain".

+

indicate your preference for each candidate with "Oppose", "Abstain", or "Support", in that order.

Ca ^{talk to me!} 13:48, 7 November 2024 (UTC)

Background: Wikipedia talk:Administrator elections/Archive 4 § Voting interface; order

I don't think an RfC is needed for this question; it can just be discussed on the talk page and a change made if desired. On a copyediting note: I think in that order isn't needed. isaacl (talk) 15:12, 7 November 2024 (UTC)

I agree with both isaacl's posts - this isn't an RFC issue and "in that order" isn't needed. Thryduulf (talk) 18:40, 7 November 2024 (UTC)

Good idea. In hindsight, RfC is not necessary for a small change like this one. I imagine I would make an edit request, but I am unsure as to where. Perhaps Wikipedia talk:Administrator elections? Ca ^{talk to me!} 01:34, 8 November 2024 (UTC)

Remind me next election and I'll make the change to the SecurePoll messages. For the last election, this happened over at phab:T371454#10245702. Oh, and I added it to my notes just now. –Novem Linguae (talk) 08:01, 8 November 2024 (UTC)

I would like that it be briefly discussed ahead of time; I have some feedback. isaacl (talk) 15:36, 8 November 2024 (UTC)

Community Chat for borderline candidates

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 a support percentage of 10% less than the promotion bar (currently would mean 60 to 70%) automatically trigger an RfA-like open voting period, where any extended confirmed user can !vote support/oppose?

• Called "community chat" - designed to elicit nuanced consensus based on actual discussion for candidates where they are nether clearly desired by the community nor clearly undesired.
• This time, many of the borderline candidates within this range would have succeeded at a traditional RfA, and (imo) all of them would have made good admins, but may be too scared to actually open one given their results.

Variations:

• Variation A: RfA thresholds, including crat chat
• Variation B: per WP:NOBIGDEAL just need to confirm more people didn't change to oppose when oppose reasons become public - so 60% promotion threshold, everyone else below that fails.
• Variation C: 65% or higher promotion threshold - no crat chats
• Variation D: 70% or higher (a.k.a RfA) promotion threshold - no crat chats

More technical points on how it would work:

• Extended-confirmed users can !vote anything, regardless of if they voted in the election, or what they voted.
• This would last for 4 days, as there's already been 3 days of questions & discussion during the election election.

• Each candidate would get a page in WP:AELECT/<time>/Community Chat/<Candidate>
  • The election questions & discussion are transcluded into the community chat page
  • New questions can be asked, and new neutral discussion points can be raised, but under "Community Chat Questions" and "Community Chat Neutral Comments".
  • !voting happens under "Community Chat !votes - Support" and "Community Chat !votes - Oppose". Threaded discussion is allowed, but going off topic and making unsupported claims/attacks are not.

• Election monitors can strike votes, remove comments and moderate as they wish, like they did during the election's discussion period (no need for new monitors).

• Summary page with an automatically updating !vote table and links to candidate pages at WP:AELECT/<time>/Community chat.
  • Listed on the Centralised Discussion template, as "There are X Administrator Election Community Chats open", linking to above.
  • Candidates can withdraw if they want by removing their name from the wiki table, subpages will be G6'ed if the page only has transcluded content.

MolecularPilot 05:17, 8 November 2024 (UTC)

Discussion

If I understand the proposal correctly, the idea is to introduce a range that would trigger an open viewpoint RfA. While it's something that the community can discuss, and of course consensus can change, I'll note that the consensus from previous discussions was that a clear cutoff is one of the advantages of admin elections. This proposal feels like running candidates through both processes back-to-back, so they'll experience the disadvantages of one and then the other. isaacl (talk) 05:34, 8 November 2024 (UTC)

I guess so, but I think where an anonymous, no reason for opposing and clear-cut AELECT shines is in either very good or very bad candidates (like 70+ [minimises pile-on oppose badgering from the many supporters] or less than 60 [they don't have too read all the (to them, potentially hurtful) oppose reasons or see someone they like oppose them]), but where RfA shines is candidates where it's a little more blurry - so, imo, the proposal makes sure that we get the best of both worlds, but I'm not too sure about it - that's why I posted it here to see what others think, thanks for sharing your opinion! MolecularPilot 07:56, 8 November 2024 (UTC

You don't get the benefit of a clear-cut threshold by eliminating it. I think there are better ways for candidates to gather feedback even during the election process. For example, if they want open feedback, they can ask for it at the top of their candidate statement. As a middle ground, they could ask for people who don't mind contacting them privately to send them feedback by email. They could set up a meeting time on a Discord channel to ask for feedback. As suggested in various places, they could contact experienced editors (particularly those who have nominated candidates) and ask for feedback. My personal feeling is that coupling the processes together makes them more complicated than necessary. isaacl (talk) 15:50, 8 November 2024 (UTC)

I will vote against this if it makes it to RFC. Not having crat chats seems to me to be a clear strength of administrator elections. Crat chats cause an extreme amount of stress for candidates, and the idea behind AELECT is to reduce candidate stress. –Novem Linguae (talk) 08:03, 8 November 2024 (UTC)

I guess saying it was "based off crat chats" gave it bad branding...

Seriously though, I think we can remove the "crat chat" threshold in the community chat, and make it a strict oppose/fail based on votes - but these votes are more ideal for that kind of candidate (borderline) - public, needing a reason (cause some people this round literally "oppose[d] all candidates" cause they didn't like the proposal, and also encourages more community discussion) & open to 2 way discussion (so everyone can weight the merits and people may change their vote).

Also I wasn't too sure about this, if no-one else likes it I'll get rid of it I just wanted to see what people thought. MolecularPilot 08:10, 8 November 2024 (UTC)

Variations have now been added! :) MolecularPilot 08:14, 8 November 2024 (UTC)

Thank you, but I still cannot support it. This is adding a lot of complexity to an elegantly simple process. –Novem Linguae (talk) 08:19, 8 November 2024 (UTC)

If candidates desire something very like this they just can run for RfA when voting is concluded. Espresso Addict (talk) 10:45, 8 November 2024 (UTC)

I agree this doesn't feel like something that should be part of the election. There is no minimum time between an election and an RFA, and feedback can be given at any time on the editor's talk page. As a voter I'd want to see some evidence that they'd taken the feedback onboard and acted on it before supporting, regardless of how they did in the election. I couldn't support any of the variations if this came to the RFC. Thryduulf (talk) 11:01, 8 November 2024 (UTC)

Agreed with Novem, I see the whole point as avoiding stress. This would pull the elections far in the direction of being more like RFA, which is what we want to avoid. Leijurv (talk) 17:34, 8 November 2024 (UTC)

I also don't think it makes sense in the first place. The point of crat chats is ostensibly to gauge consensus by actually reading the supports and opposes. In this case, the votes are intentionally anonymous. There's nothing more to read into beyond the actual numbers. (Because the Q&A / candidate discussion page intentionally does not actually have votes) Leijurv (talk) 18:35, 8 November 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.

Expressions of support and opposition

During the voting phase, people should be free if they wish to make brief, reasoned expressions of public support or opposition on the candidate's nomination page for their candidacy, in a section of the page dedicated to this purpose. FOARP (talk) 14:38, 8 November 2024 (UTC)

Like, support and oppose sections at RFA? Feel free to flesh this out and also format it like an RFC, if you think an RFC is needed for this. Else we may move it to the talk page. –Novem Linguae (talk) 16:26, 8 November 2024 (UTC)

Novem Linguae - Like this?

Question: Should a section be added to the Candidate nomination page in which brief, reasoned expressions of support/opposition can be voluntarily made after voting opens?

• Option A: Yes
• Option B: No