From Wikipedia, the free encyclopedia
Content deleted Content added
|
|
|||
| Line 341: | Line 341: | ||
|
*”’B”’ No per @[[User:Eggroll97]]. [[User:JuxtaposedJacob|JuxtaposedJacob]] <small>([[User talk:JuxtaposedJacob|talk]]) | 🙂 | he/him | </small> 21:59, 12 September 2025 (UTC) |
*”’B”’ No per @[[User:Eggroll97]]. [[User:JuxtaposedJacob|JuxtaposedJacob]] <small>([[User talk:JuxtaposedJacob|talk]]) | 🙂 | he/him | </small> 21:59, 12 September 2025 (UTC) |
||
|
*”’Option A”’. I see this as a potential fix for candidates who fall a little short of the requirements in the two questions above this one. And we definitely should be doing more to encourage having nominators, instead of self-noms. Experience so far has been that self-noms rarely get elected. I get the argument that admins are not “more special” than other editors, but they ”do” have some expertise in what this question is about. –[[User:Tryptofish|Tryptofish]] ([[User talk:Tryptofish|talk]]) 22:06, 12 September 2025 (UTC) |
*”’Option A”’. I see this as a potential fix for candidates who fall a little short of the requirements in the two questions above this one. And we definitely should be doing more to encourage having nominators, instead of self-noms. Experience so far has been that self-noms rarely get elected. I get the argument that admins are not “more special” than other editors, but they ”do” have some expertise in what this question is about. –[[User:Tryptofish|Tryptofish]] ([[User talk:Tryptofish|talk]]) 22:06, 12 September 2025 (UTC) |
||
|
*”’Option B”’ Strong oppose to this, regardless of the number of nominators or their permissions/roles. I sympathize with what this attempts to address, but the culture and expectations of the community are not in alignment with this. —[[User:Sirdog|<span style=”color:#056300″>”’Sirdog”'</span> ]]([[User talk:Sirdog|talk]]) 22:54, 12 September 2025 (UTC) |
|||
|
=== Comments (Q7. Candidate admin nominations) === |
=== Comments (Q7. Candidate admin nominations) === |
||
Latest revision as of 22:54, 12 September 2025
Below are some RFCs about proposed changes to the administrator elections process. The WP:RFCBEFORE for these occurred at Wikipedia:Administrator elections/July 2025/RFC workshop; you may want to read that page to see some background and motivations for each question. Consider responding to each section one at a time to avoid edit conflicts.
| An editor has requested comments from other editors for this discussion. This page has been added to the following list:
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below. |
Please opine on the below questions related to the English Wikipedia administrator elections process. –Novem Linguae (talk) 08:48, 12 September 2025 (UTC)
What should the required percentage be to pass an administrator election?
- Option A – 70.00% (current)
- Option B – 66.67%
- Option C – 65.00%
- Option D – 60.00%
- Option E – Other (specify)
Survey (Q1. Pass percentage)
[edit]
- Option A – 70.00% (current) – Based on the results of the past two October 2024, July 2025, there appears to be a pretty clear cliff in the 65-66.67% territory. So I don’t think we should go below super-majority of 66.67% to err on the side of caution, given that WP:AELECT is an automatic confirmation, as compared to WP:RfA where the goal is 75% is a typically pass, whereas
RfAs that finish between 65 and 75% support are subject to the discretion of bureaucrats (so, therefore, almost all RfAs below 65% will fail).
- So, I definitely think we don’t want to go down to below 65%, but I’d rather stay on the cautious side of that cliff-territory (just as initially 70% for AELECT is basically the “happy” medium between 65% and 75% that RfA had as “it depends”), but preferring higher. I’ll note that if we go down to 66.67% (B), the last July 25 election results would have been unchanged (9 elected, 7 not-elected). The October 24 results would have passed 3 more people who came in above 66.67% (changing from 11 to 14 passed, 21 not elected to 18 not-elected), so I think if we do want to lower the threshold from the current 70%, doing it conservatively to 66.67% would be as far as I’d go.
- I did one more small analysis, trying to look for patterns, now that we’ve had two elections to draw from and was adding support share as a yet-untracked new metric to compare between support ratio and support share (which currently we are not considering), but I think there might be some value as it actually shows that the 70% threshold may indeed actually have some magic value as that’s where support share starts falling below 50% (total voted shares were 616 for the Oct 24 and 541 for the Jul 25 election respectively). The below table includes all candidates that had >=65% support ratio:
|
- So maybe 70% is the right target after all, it seems to get us both a good confidence between support ratio (support/(support+oppose)), but also, appears to give us a close to 50%+ for total support share (support/(support+oppose+abstain)) – this helps guard against a candidate passing due to the mere fact that no one knows the candidate and the majority of people abstains.
- Another interesting detail gleamed from this is, that participation between the two elections wasn’t dramatically different (75 less voters in Jul 25 compared to Oct 24), but it appears that the confidence in a lot of the candidates passed in the second election was higher as seen by table (sorted by support share). So actually on review, I’ve convinced myself that 70% somehow actually is the right place. (note the above table only includes candidate with a support ratio >=65% as the dropoff below that was pretty clear). Raladic (talk) 09:59, 12 September 2025 (UTC)
- Can we collapse the table in this response? It’s taking up a lot of room. fanfanboy (blocktalk) 12:28, 12 September 2025 (UTC)
- I agree, so I did it. (Just click to see what’s inside.) —Tryptofish (talk) 21:34, 12 September 2025 (UTC)
- Can we collapse the table in this response? It’s taking up a lot of room. fanfanboy (blocktalk) 12:28, 12 September 2025 (UTC)
- The threshold at RFA is 75% absent even minimal arguments sufficient to sway the bureaucrats, which by design are not present here. It is irresponsible to combine a lower pass percentage with the reduced scrutiny compared to RFA, and telling that the initial proponent of lowering the cutoff – again! – wanted options going all the way down to 55(!) in order to skew the probable result. E. —Cryptic 10:25, 12 September 2025 (UTC)
- Option A (current). In the absence of very clear evidence that there are a group of people achieving below 70% support that exclusively contains people who would unquestionably make good administrators. Two elections provides insufficient data to be certain of that, but Raldic’s analysis suggests that early results are not indicating a strong likelihood of this being the case. Thryduulf (talk) 10:33, 12 September 2025 (UTC)
- Option C > B I think we should lower the pass percentage, but I am okay with Option A as it’s a safe choice. I oppose Option D as it’s too low. fanfanboy (blocktalk) 12:32, 12 September 2025 (UTC)
- B I think we should lower the requirements a bit but not too much. But I am fine if the current one remains.–Plutus 💬 mess — Fortune favors the curious 12:45, 12 September 2025 (UTC)
- Option A (current), per Cryptic. —Fortuna, imperatrix 12:54, 12 September 2025 (UTC)
- Option A – shouldn’t allow for any lower without discussion to explain why. —SarekOfVulcan (talk) 13:01, 12 September 2025 (UTC)
- Option B – Radalic argues above that there is a cliff between 65% and 66.67%. What’s clear from the October elections is that if we had 66.67% in place at that time, that we would have had few extra admins. With admin recall now a thing, I think we can perhaps relax a wee bit and have 66.67% as an automatic pass with down to 60% with crat discretion. TarnishedPathtalk 13:02, 12 September 2025 (UTC)
- Option A, seems to be working fine. — xaosflux Talk 13:21, 12 September 2025 (UTC)
- Option A (current). I don’t see any reason to change it. Kudpung กุดผึ้ง (talk) 13:26, 12 September 2025 (UTC)
- Option A Nothing has changed since the last time this question was asked. — LCU ActivelyDisinterested «@» °∆t° 13:34, 12 September 2025 (UTC)
- Just in case of a bartender close, I directly oppose any other option. — LCU ActivelyDisinterested «@» °∆t° 13:59, 12 September 2025 (UTC)
- Another thing a closer could take into consideration if there is no definite concensus in this this RFC is the multiple past RFCs on the same issue. — LCU ActivelyDisinterested «@» °∆t° 19:55, 12 September 2025 (UTC)
- As every the “RFA gets higher results” arguments hold no water. There is a extremely high cost to publicly opposing a popular candidate in a normal RFA, and absolutely zero benefit of doing so when it won’t change the outcome. In a private vote that isn’t the case, so it is perfectly normal that private votes would get lower results. That any particular editor believes that a candidate they like should have passed isn’t a reason to lower the threshold. — LCU ActivelyDisinterested «@» °∆t° 14:17, 12 September 2025 (UTC)
- Just in case of a bartender close, I directly oppose any other option. — LCU ActivelyDisinterested «@» °∆t° 13:59, 12 September 2025 (UTC)
- Option A One way of determining natural breakpoints is to plot all of data on a number line and look for natural gaps, which means that you’re reducing the number of close calls if you assume past data is predictive. Combining the two previous elections, the largest gaps between 60% and 80% are 4.7% around 62%, 3.7% around 80%, and 2.7% around 70%. Of those, 62% seems way too low and 80% seems way too high, leaving the current value of 70% as the best option. —Ahecht (TALK
PAGE) 13:42, 12 September 2025 (UTC) - Option C: we need more administrators, and anyone who would make it into the discretionary zone in terms of support would likely pass a regular RfA. The people above seem to ignore that 85% is the ceiling of support we have seen, for a candidate who would obviously get ~100% in a traditional RfA. As for a request for additional data that these people would make exceptional admins, we didn’t demand complete certainty that 70% would work. I also think it is unwise to draw conclusions by the number of abstentions. Abstentions are literally choosing not to vote, for any reason. HouseBlaster (talk • he/they) 13:49, 12 September 2025 (UTC)
- You could use the same argument to say that 14% is the floor of support we have seen, for a candidate who would obviously get WP:SNOW closed in a traditional RfA. —Ahecht (TALK
PAGE) 17:30, 12 September 2025 (UTC)- When considering both together, a linear interpolation of floor-to-ceiling puts us slightly below option C. Chaotic Enby (talk · contribs) 20:04, 12 September 2025 (UTC)
- You could use the same argument to say that 14% is the floor of support we have seen, for a candidate who would obviously get WP:SNOW closed in a traditional RfA. —Ahecht (TALK
- Option A. The discretionary range in a normal RFA is 65 to 75%, and those at the lower end of that range rarely pass. I see no reason whatsoever why we should apply a different standard here. If editors oppose a particular candidate then they oppose them, and it’s a feature of admin elections (or a caveat, depending how you look at it) that opposers’ reasons for opposing aren’t open to scrutiny here. But it would be a big mistake to simply cast those opposers’ votes aside just because there’s a feeling that some of the failed candidates should have passed. I can understand those candidates’ frustration, as they won’t know what it was that caused them to fail, but that’s the choice they made when they opted to go through election rather than traditional RFA… and the latter remains available for anyone who wishes to pursue it further. (As an aside, I’m not sure why some editors are getting notified about this RFC but not others, I’m here because I saw these RFCs on various people’s user talks on my watchlist but I didn’t receive one; a sitewide notice should be put up ASAP IMHO) — Amakuru (talk) 13:51, 12 September 2025 (UTC)
- Option A Agree with Amakuru’s rationale for maintaining the status quo, and as I expressed in the July 2025 debrief, anything lower would have elected candidates that I opposed in both elections. While I agree with Novem that a WP:BARTENDER close would be appropriate if 80% of commenters want a lower threshold, this is WP:NOTAVOTE and 55% wanting a lower threshold will not suffice if those supporting Option A present stronger arguments. ViridianPenguin🐧 (💬) 14:28, 12 September 2025 (UTC)
- At most A, oppose anything higher. To @Cryptic: as discussed last time, the reduction in scrutiny is already compensated by the increase in unexplained opposes. The best candidates at RfA had 100% support whereas here we’ve only gotten to 85%. If anything, a percentage based on the 75% discretionary range bound would be about 60%, and 60% ADE candidates seem to have similar problems as 75% RfA candidates, if not less. This is not an endorsement of 60% at all—as you say, the reduced discussion engagement means there should be some greater scrutiny, and 70% seems to more than do that well.Percentages have rose across the board since last time, perhaps due to the lower amount of candidates increasing engagement-per-candidate, making me weak oppose C since this round’s evidence says the candidates that would’ve passed under C had debatable and unresolved issues. Aaron Liu (talk) 14:38, 12 September 2025 (UTC)
- Option A. I hold to my previous view [1] [2] that the threshold in the middle of the RFA discretionary range is the most logical one, and I would need to see a strong reason to lower it. I also believe this threshold has been empirically validated. In my view as a regular RFA participant no candidacy that I would expect to sail through RFA failed to reach the 70% threshold at EFA, and while some excellent candidates did not reach the threshold, each of their candidacies had an aspect of preparation or experience or presentation that would have made them a harder sell at regular RFA. The current threshold is discriminating between these, and as such I don’t think we should lower it, or raise it, for the moment. Vanamonde93 (talk) 14:45, 12 September 2025 (UTC)
- Option A. This seems to work fine. No reason to lower it. Intothatdarkness 14:49, 12 September 2025 (UTC)
- Option A * Pppery * it has begun… 15:18, 12 September 2025 (UTC)
- Option A, reflects the RfA discretionary range. CMD (talk) 15:42, 12 September 2025 (UTC)
- Option A per Hog Farm last time: “Several of those wanting to lower the threshold seem to be basing it on this idea that if people they liked didn’t pass, then the standards need to be lowered. The AdminElection system as it is set up isn’t really designed to handle a particularly controversial case. As long as this is going to function as a somewhat lower-scrutiny process, it should take a higher-threshold to get through said process than the comparable process with a higher rate of scrutiny.” And I agree with Vanamonde93’s assessment of the recent results. Extraordinary Writ (talk) 16:17, 12 September 2025 (UTC)
- Option C per House blaster. 65 is a better percentage as you don’t know what is an EC user is considering. Many new users !vote oppose just because they aren’t familiar with the candidate. Further, enwiki is already ‘infamous’ for tough requirements.[3] ,[4] Ophyrius (he/him
T • C • G) 16:19, 12 September 2025 (UTC)- How do you know that new users tend to oppose those the candidates they are nor familiar with? · · · Peter Southwood (talk): 16:55, 12 September 2025 (UTC)
- As one of the users of focus in the cited commentaries, I agree that it’s not a good thing that en has specifically such heavy standards for adminship. It’s a bundle of tools that nowadays can be easily revoked through recall. EggRoll97 (talk) 20:44, 12 September 2025 (UTC)
- Option A is sufficient, and I haven’t seen a good reason to lower it. If a BARTENDER close is what ends up happening, I am willing to weakly support B as a second choice, although I oppose C and D. I also oppose raising the threshold at all. QuicoleJR (talk) 16:58, 12 September 2025 (UTC)
- Option C or Option D We need more administrators, and in the 19+ years I have been one, I have seen candidates who obviously shouldn’t get the bit fail with well under 50%. I think that the candidates who get less than 70% but more than 50% generally have one minor issue that voters don’t like. Remember, there are no administrative tasks that can’t be undone and if someone is voted in and misbehaves, he/she can be de-sysoped. I would be interested in seeing the number of administrators who got the bit removed for misbehavior and if many of them got sysoped with a vote just over 70%. —rogerd (talk) 18:59, 12 September 2025 (UTC)
- Option C – Administrator elections have a range compression effect compared to regular RfAs. Candidates who would have gotten 100% of votes at RfA (respectively 0%) tend to get around 85% at AELECT (respectively 15%). With a linear interpolation, the 70% middle of the discretionary range becomes 64%, which is closest to option C. Chaotic Enby (talk · contribs) 19:48, 12 September 2025 (UTC)
- Option D We need more administrators, and frankly becoming an admin needs to stop being seen as such a big deal. Everything an admin does is easily (barring maybe a select few tasks that most admins, I would wager, are not even aware are possible with the admin toolset) reversible. EggRoll97 (talk) 20:41, 12 September 2025 (UTC)
- Option A. I think I argued for lower in the last RFC, but these results have convinced me that there is something meaningful in the <70% drop. As a “compromise” answer, I would also be happy with 67% (ie, a supermajority, slightly rounded). I don’t think we should go any lower at this time. RFA can have some wiggle room because we have extended discussion and crat chats. EFA, less so. — asilvering (talk) 21:10, 12 September 2025 (UTC)
- Option B, with C as second choice. I think that a lot of the arguments for keeping the status quo are misinformed. There’s nothing magical about the number we use for conventional RfA. And for ArbCom elections, we use an entirely different threshold. A close examination of the most recent election, during the “post-mortem” of that round, showed that a lot of the candidates who fell below the cutoff were well-qualified and probably would have passed a traditional RfA. So, as with ArbCom elections, there are a lot more oppose votes than in a traditional RfA (where oppose comments get challenged in public view). Thus, it makes sense to lower the threshold here. This isn’t making the standard lower than regular RfA. It’s making it more similar. And it’s counterfactual to say that AELECT candidates get less scrutiny. Perhaps the oppose votes are less-well thought out, but there’s no deficiency of opposition. I think a modest lowering of the cutoff makes sense, empirically, and we can always revisit it in the future. —Tryptofish (talk) 21:44, 12 September 2025 (UTC)
- Option C. I don’t think the modern concern has been “too many administrators,” and the ones in the iffy range were good candidates. JuxtaposedJacob (talk) | 🙂 | he/him | 21:51, 12 September 2025 (UTC)
- Here’s the candidates that were in each range in AELECT1 and AELECT2. So one way to look at this question is, are the candidates in these percent ranges candidates you’d trust to be admins?
- Note to closer: this question may need a WP:BARTENDER close. Imagine this hypothetical: 20% !vote for A, 20% B, 20% C, 20% D, 20% E. Per WP:BARTENDER, closing this as “no consensus” (and defaulting to the status quo A) would be incorrect, because B+C+D+E 80% is a clear consensus to do something besides the status quo. –Novem Linguae (talk) 10:22, 12 September 2025 (UTC)
- This might be fair to ask if the options weren’t deliberately chosen so as to force your preferred outcome. I’m surprised you stopped at 55% and didn’t go all the way down to 15% so everyone would’ve passed. —Cryptic 10:42, 12 September 2025 (UTC)
- You’ve got the wrong idea about me. Before you !voted above, I did some additional research and discovered that for candidates in the 60-69.99% range, in AELECT I voted 4 support 3 abstain 2 oppose. Meaning I only felt really good about 4 of those candidates out of 9. With that new data, I am now leaning towards abstaining on this one. I feel like your comments
in order to skew the probable result
andThis might be fair to ask if the options weren’t deliberately chosen so as to force your preferred outcome. I’m surprised you stopped at 55% and didn’t go all the way down to 15% so everyone would’ve passed
implies that I am very biased on this issue, which is disappointing. I don’t think biased people usually look at data and change their mind. –Novem Linguae (talk) 10:47, 12 September 2025 (UTC) - Also, where were you while we workshopped this for weeks at Wikipedia:Administrator elections/July 2025/RFC workshop#Q1. Pass percentage? That would have been a great time to opine that you think this should be a “should we lower the pass percentage? yes/no” instead of its current format. If you had spoken up during the workshop, then you wouldn’t need to make personal attacks and aspersions against me during the RFC phase. –Novem Linguae (talk) 10:53, 12 September 2025 (UTC)
- If all the options but one are to lower the pass threshold, and the person who posed the question and initially picked the options says “this means the threshold is going to lower at least a little”, what did you expect the reaction to be? (And I didn’t find the workshop until this popped up on CENT.) —Cryptic 11:07, 12 September 2025 (UTC)
- There were multiple people discussing how this question should be worded, and no one objected to these being the options. Novem is not the only person responsible for the design of this question. fanfanboy (blocktalk) 12:26, 12 September 2025 (UTC)
- If all the options but one are to lower the pass threshold, and the person who posed the question and initially picked the options says “this means the threshold is going to lower at least a little”, what did you expect the reaction to be? (And I didn’t find the workshop until this popped up on CENT.) —Cryptic 11:07, 12 September 2025 (UTC)
- You’ve got the wrong idea about me. Before you !voted above, I did some additional research and discovered that for candidates in the 60-69.99% range, in AELECT I voted 4 support 3 abstain 2 oppose. Meaning I only felt really good about 4 of those candidates out of 9. With that new data, I am now leaning towards abstaining on this one. I feel like your comments
- This might be fair to ask if the options weren’t deliberately chosen so as to force your preferred outcome. I’m surprised you stopped at 55% and didn’t go all the way down to 15% so everyone would’ve passed. —Cryptic 10:42, 12 September 2025 (UTC)
- At some point this question needs to be dropped. I missed the workshop, but if I hadn’t I would have opposed it’s inclusion. This is a question that has been asked multiple times before. — LCU ActivelyDisinterested «@» °∆t° 13:52, 12 September 2025 (UTC)
- Agreed. We shouldn’t keep asking the same thing because some people don’t agree with the consensus. I’m sure this RFC was started in good faith, but WP:DROPTHESTICK is something that could apply here. — Amakuru (talk) 13:55, 12 September 2025 (UTC)
- @Amakuru I’d guess you weren’t notified because you’re not on the Wikipedia:Administrator elections/Newsletter list, which is linked from Wikipedia:Administrator elections#Newsletter. Aaron Liu (talk) 14:40, 12 September 2025 (UTC)
- We didn’t send out a WP:MMS for the debrief phase or workshop phase. Watchlisting WT:AELECT is probably the best way to be notified of those phases. –Novem Linguae (talk) 22:29, 12 September 2025 (UTC)
Election clerks carry out the todo list and setup the SecurePoll software. Should election clerks be restricted from certain election activities, to avoid an appearance of impropriety?
- Option A – No restrictions (current)
- Option B – Restrictions on public actions: Election clerks may not nominate candidates, publicly state an opinion about candidates, create a voter guide, or ask official questions on the discussion page
- Option C – Restrictions on public and private actions: Election clerks may not nominate candidates, publicly state an opinion about candidates, create a voter guide, ask official questions on the discussion page, or vote
Survey (Q2. Restrictions on election clerks)
[edit]
- Option A. Full disclosure: I am an election clerk. If option B or option C restrictions were to be adopted, then I would not have been able to nominate SD0001 in AELECT1, nominate Sohom Datta in AELECT1, nor create stats-based voter guides for AELECT1 and AELECT2. If people think it’s bad that I am nominating people and creating stats-based voter guides, then sure, pick an option that has more restrictions. But I don’t really see how forbidding me from these activities would help Wikipedia. In regards to option C which would ban me from voting, I see no problem with election officials voting since it is a secret vote. Election officials in real life are usually not barred from voting. –Novem Linguae (talk) 09:27, 12 September 2025 (UTC)
- Option A – I’d say given that the election is done through SecurePoll, and that we have multiple Scrutineers, who are not election clerks, I don’t think restricting the election clerks from voicing opinions, or votes is necessary. Given that the actions of restrictions would all be transparent in the editor logs (unless there were something that needed WP:REVDEL, any editor can see what has happened to the pages). Raladic (talk) 10:08, 12 September 2025 (UTC)
- Option A I don’t see a real problem here. fanfanboy (blocktalk) 12:34, 12 September 2025 (UTC)
- A they are trusted so why not?–Plutus 💬 mess — Fortune favors the curious 12:47, 12 September 2025 (UTC)
- A per SecurePoll/trusted clerks. —SarekOfVulcan (talk) 13:02, 12 September 2025 (UTC)
- Option A Per the argument of: If real life election officials can vote, why can’t the one’s here? We anyways have a lot of backups and cross-checking, so one person can’t alter the results, or interfere. ~/Bunnypranav:<ping> 13:11, 12 September 2025 (UTC)
- Option A , it’s a secure poll. Kudpung กุดผึ้ง (talk) 13:29, 12 September 2025 (UTC)
- Option A There’s enough community oversight that such restrictions aren’t necessary. — LCU ActivelyDisinterested «@» °∆t° 13:36, 12 September 2025 (UTC)
- Option A. * Pppery * it has begun… 15:19, 12 September 2025 (UTC)
- Option A LGTM. Ophyrius (he/him
T • C • G) 16:21, 12 September 2025 (UTC) - Option A I see no reason with letting Novem do what he’s been doing. QuicoleJR (talk) 17:06, 12 September 2025 (UTC)
- Agreed! JuxtaposedJacob (talk) | 🙂 | he/him | 21:53, 12 September 2025 (UTC)
- Option A I was marginally persuaded possibly by B, but frankly it’s pretty unnecessary. EggRoll97 (talk) 21:01, 12 September 2025 (UTC)
- Option A. I thought seriously about B, but I’m persuaded by the comments above. I hope that future clerks will continue to take their roles seriously. —Tryptofish (talk) 21:48, 12 September 2025 (UTC)
- Option A Their vote probably is more important than mine anyway, because they are more knowledgeable. JuxtaposedJacob (talk) | 🙂 | he/him | 21:52, 12 September 2025 (UTC)
- Option A None of the work a clerk performs warrants restrictions on their actions in my view. —Sirdog (talk) 22:23, 12 September 2025 (UTC)
Scrutineers use CheckUser tools to discover and eliminate votes from sockpuppets. Should scrutineers be restricted from certain election activities, to avoid an appearance of impropriety?
- Option A – No restrictions (current)
- Option B – Restrictions on public actions: Scrutineers may not nominate candidates, publicly state an opinion about candidates, create a voter guide, or ask official questions on the discussion page
- Option C – Restrictions on public and private actions: Scrutineers may not nominate candidates, publicly state an opinion about candidates, create a voter guide, ask official questions on the discussion page, or vote
- Option D – Restrictions on private actions: Scrutineers may not vote
Survey (Q3. Restrictions on scrutineers)
[edit]
- Option A. Scrutineers look for sockpuppets and strike their votes. That’s kind of an objective process: they look at data and act accordingly. If they have a bias towards or against a candidate, I don’t really see how there’s enough subjectivity or wiggle room in their workflow for that to affect their work. There’s also 3 of them, so they are checking each other’s work. In regards to option C which would ban them from voting, I see no problem with election officials voting since it is a secret vote. Election officials in real life are usually not barred from voting. –Novem Linguae (talk) 09:32, 12 September 2025 (UTC)
- Option A – similar to my answer for Q2. the public actions on Wiki are public, and any editor can see them in the log. As for the voting side – I think that’s why we have 3 Scrutineers, so barring a collusion between all 3, I’d say we stick with following WP:AGF and hope that if they got disagreeing results, that those would be raised to the community to decide. Raladic (talk) 10:12, 12 September 2025 (UTC)
- Option A I think we can trust our CheckUsers. fanfanboy (blocktalk) 12:36, 12 September 2025 (UTC)
- A they are trusted so why not?Plutus 💬 mess — Fortune favors the curious 12:48, 12 September 2025 (UTC)
- A if we can’t trust them, they shouldn’t have the power in the first place
- A We have a lot of backups and cross-checking, so one person can’t alter the results, or interfere in any ways. ~/Bunnypranav:<ping> 13:11, 12 September 2025 (UTC)
- D these editors are still part of the community, but should not be voting in an election that they are in charge of removing votes from. — xaosflux Talk 13:24, 12 September 2025 (UTC)
- A, if they can’t be trusted, they shouldn’t be CheckUsers. Kudpung กุดผึ้ง (talk) 13:31, 12 September 2025 (UTC)
- A Again I think there’s enough community oversight that such restrictions aren’t necessary. — LCU ActivelyDisinterested «@» °∆t° 13:37, 12 September 2025 (UTC)
- Option A There’s no potential for bias here, even in theory, since the scrutineers do not know who voted for whom. * Pppery * it has begun… 15:20, 12 September 2025 (UTC)
- A Ophyrius (he/him
T • C • G) 16:22, 12 September 2025 (UTC) - Option A If we thought they would do anything unacceptable, we wouldn’t have them as CheckUsers. QuicoleJR (talk) 17:08, 12 September 2025 (UTC)
- Option B I trust our scrutineers, but we should still avoid the appearance of impropriety. —Ahecht (TALK
PAGE) 17:34, 12 September 2025 (UTC) - Option D per xaosflux. I’m fine with public actions, sure, but scrutineers should be officially uninvolved in the election’s outcome if they’re able to view the private info of voters. EggRoll97 (talk) 21:02, 12 September 2025 (UTC)
- Option A. There is no serious potential for bias here, we trust CUs to not be dumbasses, and, as I mentioned in the discussions during the election, actual election scrutineers for political elections are expected to be partisan. That is, bias is expected, and the process works anyway – because there are multiple scrutineers from multiple parties. To seriously throw an election, the scrutineers would have to be not only biased, but colluding. — asilvering (talk) 21:14, 12 September 2025 (UTC)
- Option C. I suspect that our checkusers will do this of their own volition, but I want us to put it in writing. Having checkuser access, access to editors’ personal information, is a big deal, so I agree with what Xaosflux said, but I would go even further. —Tryptofish (talk) 21:53, 12 September 2025 (UTC)
- Option A They should be allowed to have the same rights as the rest of us. JuxtaposedJacob (talk) | 🙂 | he/him | 21:53, 12 September 2025 (UTC)
- Option A My gut reaction was option D, but I have been sufficiently convinced by Novem and asilvering’s rationale. —Sirdog (talk) 22:31, 12 September 2025 (UTC)
Monitors keep an eye on candidate pages during the discussion phase and moderate rude comments. Should monitors be restricted from certain election activities, to avoid an appearance of impropriety?
- Option A – No restrictions (current)
- Option B – Restrictions on public actions: Monitors may not nominate candidates, publicly state an opinion about candidates, create a voter guide, or ask official questions on the discussion page
- Option C – Restrictions on public and private actions: Monitors may not nominate candidates, publicly state an opinion about candidates, create a voter guide, ask official questions on the discussion page, or vote
Survey (Q4. Restrictions on monitors)
[edit]
- Option B. The work of monitors is a bit more subjective than that of scrutineers and election clerks. Deciding who to warn or block for poor behavior on candidate discussion pages does have some subjectivity to it. It would be good if monitors are seen as neutral and not favoring or disfavoring any particular candidate (or that candidate’s supporters and opposers). This would be similar to how RFA monitors are not supposed to show any bias either. In regards to option C which would ban them from voting, I see no problem with election officials voting since it is a secret vote. Election officials in real life are usually not barred from voting. –Novem Linguae (talk) 09:37, 12 September 2025 (UTC)
- Option B. Monitors are there to impartially ensure that the election runs smoothly and in accordance with the rules. While I don’t see a justification for disenfranchising them, it is important that both act with impartiality at all times with respect to all candidates and equally important that they are perceived as doing so, which means that they should not be publicly nominating, endorsing or not endorsing any candidate. Thryduulf (talk) 10:38, 12 September 2025 (UTC)
- Option B Per both above, my exact thoughts. fanfanboy (blocktalk) 12:42, 12 September 2025 (UTC)
- B per above Plutus 💬 mess — Fortune favors the curious 12:48, 12 September 2025 (UTC)
- Option B, obviously. —Fortuna, imperatrix 12:57, 12 September 2025 (UTC)
- B, but not convinced it’s really necessary. —SarekOfVulcan (talk) 13:05, 12 September 2025 (UTC)
- Option B, perhaps but I’m not sure of the need for the rule if there hasn’t already been impropriety. TarnishedPathtalk 13:08, 12 September 2025 (UTC)
- Option A: From my experience as a candidate, conversation with those involved with the election actually made the whole process far less daunting and improved transparency. The election volunteers should be capable of making their own judgement calls, and I witnessed volunteers privately make decisions expressly for the sake of ensuring that impropriety was avoided. I have a high degree of trust in them. ~ Pbritti (talk) 13:12, 12 September 2025 (UTC)
- Option B. Monitors should recuse themselves from commenting. They need to be neutral. There’s no reason to disallow their participation in the secure poll. Kudpung กุดผึ้ง (talk) 13:36, 12 September 2025 (UTC)
- B * Pppery * it has begun… 15:20, 12 September 2025 (UTC)
- B Ophyrius (he/him
T • C • G) 16:23, 12 September 2025 (UTC) - Option B I have no problem with them voting in private, but publicly, them showing an opinion on a specific editor would make them appear biased with regards to issues with that editor’s candidacy. Obviously I trust them enough to not let that bias affect their decisions, but I’d still prefer to avoid the appearance of impropriety. QuicoleJR (talk) 17:13, 12 September 2025 (UTC)
- Option B per Quicole. —Ahecht (TALK
PAGE) 17:35, 12 September 2025 (UTC) - Option B given the subjectivity issue and to avoid the appearance of impropriety. The role can’t be compared to something like scrutineers which is a more technical and objective process, where it would be harder for bias to creep in. Chaotic Enby (talk · contribs) 19:33, 12 September 2025 (UTC)
- Option B, though perhaps without restriction on asking questions. The other activities I don’t believe are appropriate for a monitor to be engaged in. EggRoll97 (talk) 21:03, 12 September 2025 (UTC)
- Option B. I don’t mind if monitors vote, but anything public is contrary to what monitors are here for. —Tryptofish (talk) 21:55, 12 September 2025 (UTC)
What are the minimum requirements to become a candidate?
- Option A – Be extended confirmed (current)
- Option B – Have at least 1000 edits on English Wikipedia
- Option C – Have at least 2500 edits on English Wikipedia
- Option D – Have at least 5000 edits on English Wikipedia
- Option E – Have at least 7000 edits on English Wikipedia
- Option F – Other (specify)
Survey (Q5. Candidate edit count requirement)
[edit]
- Option D first choice for me. Options B, C, or E second choices. The idea behind having a minimum edit count is to reduce WP:BITE of new editors that see the call for candidates watchlist notice, then sign up, not realizing that they have no chance of success. I think we had 2 or 3 of these folks in AELECT2, whom we had to talk to after they signed up and convince to withdraw. The most recent RFA or AELECT candidate to pass with a low edit count is Sohom Datta with 7,735 edits in 2024. If you go back farther, it was GoldenRing with 2,385 edits in 2017. I don’t think we’ll ever have a 2,385 edit count passing RFA candidate again, since standards have risen since 2017. I think 5,000 edits strikes a nice balance between pushing 7,735 a little lower, while still making it clear to newer editors that they aren’t quite ready for this process. –Novem Linguae (talk) 09:48, 12 September 2025 (UTC)
- Option D – 5,000 seems to be a reasonable balance between ensuring an editor likely had a broad amount of different experiences, which the options below that can’t quite “guarantee”. It takes most editors a while to find their niche (other than most of us being drawn here due to some topic we may start with). Since this is about WP:MOP tools, any candidate has to have a decent reason of why they want/need those permissions instead of regular extended permissions, and we want confidence in admins, and an edit count of 5,000 is a reasonable indicator that likely some time has passed and they have hopefully wet their feet in several areas of the project and have a decent idea of which side they would like to help with mopping. Whether that’s AfDs, CfDs, AIV, SPI, ANI, AE, RM or whatever other project-space special interest they may have. The current 500 (ECP) is too low, both practically speaking, as well as just the chance that it means we could get someone that manages to WP:PGAME their way there and somehow we miss it and they’d be in the election. Getting to ECP happens often enough as editors that are active in WP:CVU work can tell you, so we should just definitely increase it. I’d say 2,500 is likely a bare minimum, but 5,000 seems to be the better medium. Raladic (talk) 10:22, 12 September 2025 (UTC)
- Option A (no change). Edit count is a very poor metric by which to judge someone’s suitability to be an administrator, and the very high minimum numbers proposed here will exclude good candidates who make thoughtful edits while encouraging those who make many rapid-fire but poorly considered edits despite the former being a better temperamental match to adminship. Thryduulf (talk) 10:43, 12 September 2025 (UTC)
- Option A Requirements should be the same as RfA. Also per Thryduulf as he makes a good point. fanfanboy (blocktalk) 12:40, 12 September 2025 (UTC)
- A per Thryduulf–Plutus 💬 mess — Fortune favors the curious 12:50, 12 September 2025 (UTC)
- Option A, I see no reason for the requirements to be different from RfA. Suntooooth, it/he (talk | contribs) 12:55, 12 September 2025 (UTC)
- Option D – While I get that edit count is a poor metric, I think it’s unreasonable for most people to be able to gauge anyone’s readiness and how they act with the tools with only as little as 500 edits. 5,000 is still pretty a good bit below the lowest passing edit count of ~7,000ish and will stop most WP:BITEs. Sophisticatedevening(talk) 12:56, 12 September 2025 (UTC)
- Option E as, really, reflecting the actualité. —Fortuna, imperatrix 12:59, 12 September 2025 (UTC)
- D – if you want to make a case sooner, make it at RFA. —SarekOfVulcan (talk) 13:06, 12 September 2025 (UTC)
- Option D – I made a lot of fuck-ups prior to 5,000 edits and I still fuck-up a bit. I think 5,000 is a good benchmark for when most editors start to get a bit of an idea. TarnishedPathtalk 13:12, 12 September 2025 (UTC)
- Option C: The lowest edit count I’ve seen on someone I thought would make a decent admin was about 3,100 edits. They would have never passed in an election, but setting the bar a tad higher than it is might discourage some of the disappointment certain newer users have when they feel pressured to drop out very early in the election process. ~ Pbritti (talk) 13:16, 12 September 2025 (UTC)
- Option A – if the community wants or doesn’t want someone, it will be clear in the votes. — xaosflux Talk 13:26, 12 September 2025 (UTC)
- Option A or the lowest other choice. It unlikely that an editor with very few edits would be elected, but that should be up to the community. — LCU ActivelyDisinterested «@» °∆t° 13:40, 12 September 2025 (UTC)
- Option A – per Xaosflux. The results of the elections will reflect what the voters think. Kudpung กุดผึ้ง (talk) 13:43, 12 September 2025 (UTC)
- A: In addition to “voters can think for themselves already”, I would’ve loved to see a certain candidate’s nomination go live in July. Aaron Liu (talk) 14:44, 12 September 2025 (UTC)
- A, followed by the others from lowest to highest threshold. In practice I think it’s unlikely that I will support someone with fewer than 1000 edits, but that’s not the question here. Voters determine candidate suitability. We set an eligibility requirement so as not to waste community time with unserious candidacies: but I see no evidence that such time is being wasted, I don’t want us to encourage editcountitis, and I don’t see how 5000 is a reasonable lower limit for serious candidacies when GoldenRing’s RFA was not that long ago. Vanamonde93 (talk) 14:50, 12 September 2025 (UTC)
- Option A I see no reason why the technical minimum for elections should be even higher than it is for standard RfAs; the voters know how to filter out inexperienced candidates and not make them admins. * Pppery * it has begun… 15:21, 12 September 2025 (UTC)
- C Many inexperienced ECUs created nom pages. So I think this would be better. Ophyrius (he/him
T • C • G) 16:25, 12 September 2025 (UTC) - Option A, voters should decide, not an edit count threshold which often isn’t representative of experience. Adding a higher minimum threshold might also lead to even more inflation to the (already high) pass expectations. Chaotic Enby (talk · contribs) 19:36, 12 September 2025 (UTC)
- Option A Why would we make it higher for AELECT than for RfA? EggRoll97 (talk) 21:03, 12 September 2025 (UTC)
- Option A, I would live (but unhappily) with B and C, and outright vociferously oppose D and E. Please, editcountitis is bad enough without it being codified. People who are unready for adminship will run no matter what we try to do to stop them – because they are the kind of people who run for adminship when completely unready! Yes, it hurts to watch. Let’s not shoot ourselves in the foot because we got stung by a bee. — asilvering (talk) 21:17, 12 September 2025 (UTC)
- Option A. At first I was partial to the argument that a higher threshold might avoid us the hopeless run of the occasional unexperienced user, but then I noticed that all 4 withdrawn candidates in the previous elections (see Candidates list: 2024, 2025) had edit counts way above 5000 edits. Thus a higher edit threshold wouldn’t have helped at all in those cases, while theoretically stopping a good candidate with a low edit count. It’s up to the community to decide based on contributions, not edit count(itis). Sophocrat (talk) 21:46, 12 September 2025 (UTC)
- The folks that withdrew during the discussion phase (the ones you mention) tend to be decently experienced users. There’s another group of withdrawn candidate that was talked out of things in the call for candidates phase, and those are the ones that this RFC question is intended to address. Examples: [5][6][7]. –Novem Linguae (talk) 22:13, 12 September 2025 (UTC)
- Option D Seems reasonable to me, although it is unlikely to make much of an impact. I don’t see how you can assess the content creations of a user with very few edits. Hawkeye7 (discuss) 21:50, 12 September 2025 (UTC)
- Option D Per Novem JuxtaposedJacob (talk) | 🙂 | he/him | 21:55, 12 September 2025 (UTC)
- Options C or D, about equal preference, strong oppose to A. Expectations for traditional RfA are for a lot more than being EC, with pretty strict use of WP:NOTNOW, and we need to do the same here. (There’s a question below, that provides a fix for exceptions.) In the elections we’ve had so far, some NOTNOW candidates have dropped out. It would have saved them the trouble, and perhaps embarrassment, if we had spelled this out. —Tryptofish (talk) 21:59, 12 September 2025 (UTC)
- Option A Ideologically, I do not believe it’s beneficial to have 2 separate eligibility requirements for processes that have the same outcome. If the community is interested in raising the number of edits required to become an administrator that should be something that applies to both RfA and AELECT. I also strongly concur with Thryduulf and asilvering. —Sirdog (talk) 22:46, 12 September 2025 (UTC)
Comments (Q5. Candidate edit count requirement)
[edit]
- Note to closer: this question may need a WP:BARTENDER close. Imagine this hypothetical: 20% !vote for A, 20% B, 20% C, 20% D, 20% E. Per WP:BARTENDER, closing this as “no consensus” (and defaulting to the status quo A) would be incorrect, because B+C+D+E 80% is a clear consensus to do something besides the status quo. –Novem Linguae (talk) 10:23, 12 September 2025 (UTC)
- Agreed here. TarnishedPathtalk 13:13, 12 September 2025 (UTC)
- What do people think of making the minimum advisory but more prominent? Compare the commentary for elections (WP:Administrator elections#Eligibility, which just says to look at WP:Administrator elections/July 2025#Candidate eligibility) and RFA (WP:Requests for adminship#Nomination standards). —Cryptic 13:53, 12 September 2025 (UTC)
- I would support that. —Ahecht (TALK
PAGE) 17:37, 12 September 2025 (UTC)
- I would support that. —Ahecht (TALK
If Q5 introduces a new requirement, should the Q5 new requirement be modified to also include “and an account age of 1 year or greater”?
- Option A – Yes
- Option B – No
Survey (Q6. Candidate account age requirement)
[edit]
- Option A – I think it’s unlikely that we’d have confidence in someone speedrunning things to build up enough of a breadth of experience in a short period of time. So, while I don’t think realistically there will be many candidates that would be here less than a year, we might as well make it explicit. Raladic (talk) 10:25, 12 September 2025 (UTC)
- Option B Requirements should be the same as RfA. I’m not against Option A though. fanfanboy (blocktalk) 12:43, 12 September 2025 (UTC)
- Option A While I’m sympathetic to the idea that requirements should be the same as RfA: they are deliberately not elsewhere (see above), so it would be illogical to insist on parity here. —Fortuna, imperatrix 13:01, 12 September 2025 (UTC)
- A – if you do 5000 edits in less than a year, I want a little more time to make sure you know how to make the harder ones too. —SarekOfVulcan (talk) 13:08, 12 September 2025 (UTC)
- 2 years or greater It’s extremely easy to do 5,000+ semi-automated edits in 1 year. TarnishedPathtalk 13:16, 12 September 2025 (UTC)
- B – don’t think we should split this only for admins that want to use this process. — xaosflux Talk 13:27, 12 September 2025 (UTC)
- A – but 6 months instead of 12. It’s rare for anyone to ass an RfA at less than 12 months anyway. As for the edit count, it’s the quality of the edits that counts. Kudpung กุดผึ้ง (talk) 13:47, 12 September 2025 (UTC)
- B: I would’ve supported this iff it wasn’t tied to Q5. You’ll telling me we’ll defend against some prospective candidate who racked up 5000 edits in under a year? That’s ScottishFinnishRadish. This feels like a Wikipedia:Solution looking for a problem that would turn something evaluated case-by-case into an improper blanket ban. Aaron Liu (talk) 14:55, 12 September 2025 (UTC)
- B Extendedconfirmed suffices, for the same reason as in the previous question. * Pppery * it has begun… 15:21, 12 September 2025 (UTC)
- A per Sarek. —Ahecht (TALK
PAGE) 17:38, 12 September 2025 (UTC) - B, per my answer to the previous question. Account age is also a poor proxy for experience. Chaotic Enby (talk · contribs) 19:38, 12 September 2025 (UTC)
- B No, per my response on Q5. EggRoll97 (talk) 21:03, 12 September 2025 (UTC)
- Option B. I suppose I might accept the 6 months that others are suggesting. But again I don’t think this would solve any problems that we actually have. — asilvering (talk) 21:20, 12 September 2025 (UTC)
- A I was nervous about this one, but concerns about people HATting are bigger. JuxtaposedJacob (talk) | 🙂 | he/him | 21:57, 12 September 2025 (UTC)
- A, definitely, per WP:NOTNOW. —Tryptofish (talk) 22:00, 12 September 2025 (UTC)
Comments (Q6. Candidate account age requirement)
[edit]
- The minimum requirements should be extended confirmed and six months tenure. While edit count is a very poor metric for determining suitability for adminship, there is absolutely no substitute for experience. Six months is enough time for someone to know whether they have the experience or not, and long enough for others to know whether they are here in good faith or not. I’m not sure whether this means I should support or oppose Q6. Thryduulf (talk) 10:44, 12 September 2025 (UTC)
If Q5 and/or Q6 introduce a new requirement, should the Q5/Q6 new requirement be waived if the candidate has a nomination from a current administrator?
- Option A – Yes
- Option B – No
Survey (Q7. Candidate admin nominations)
[edit]
- Option B – No, that could “in theory” open a scheme of daisy chains. While I hope that we don’t get someone pulling the wool over the eyes, it’s not a guaranteed, so having the edit count/account age limits at reasonable guards that avoid risks of WP:GAMING should not be sidestepped by the (while hopefully small) risk that an admin could then nominate their friends and it becomes a thing. It does feel a little bit tin foil hat, but I just don’t really see a benefit for the exception. Raladic (talk) 10:28, 12 September 2025 (UTC)
- Mixed. A candidate who has an admin nominator should not need to meet any edit count requirements beyond extended-confirmed imposed in Q5, but they must still meet any account age restriction imposed in Q6. This is why I argued against asking this as a single question in the RFC workshop – it’s not a binary. Thryduulf (talk) 10:49, 12 September 2025 (UTC)
Option B Nominators can be very helpful, and I encourage all future candidates to get one, but there should still be the option for them to run on their own.Option A I misread the question. A nominator should definitely waive restrictions. fanfanboy (blocktalk) 12:47, 12 September 2025 (UTC)- @Fanfanboy this is not about requiring a nominator to run, but about whether candidates who have a nominator are subject to lesser minimum requirements than those who do not have a nominator. Thryduulf (talk) 13:03, 12 September 2025 (UTC)
- Misread the question. My bad. Will change vote accordingly. fanfanboy (blocktalk) 13:06, 12 September 2025 (UTC)
- @Fanfanboy this is not about requiring a nominator to run, but about whether candidates who have a nominator are subject to lesser minimum requirements than those who do not have a nominator. Thryduulf (talk) 13:03, 12 September 2025 (UTC)
- Option B per Raladic. —Fortuna, imperatrix 13:02, 12 September 2025 (UTC)
- B for various unarticulated reasons —SarekOfVulcan (talk) 13:10, 12 September 2025 (UTC)
- Option A if there are 2+ admin nominators. Otherwise B per above. TarnishedPathtalk 13:18, 12 September 2025 (UTC)
- B – no, nominators that happen to be admins shouldn’t be “special”. — xaosflux Talk 13:27, 12 September 2025 (UTC)
- B No definitely not. Making it so that newcomers have to meet certain restrictions, but then waving those restrictions if you have the backing of an insider is a terrible idea. — LCU ActivelyDisinterested «@» °∆t° 13:44, 12 September 2025 (UTC)
- B – no. Admins’ nominations have failed RfA in the past. Kudpung กุดผึ้ง (talk) 13:50, 12 September 2025 (UTC)
- B, we should at least try to not further reduce the no-big-dealness of adminship. CMD (talk) 15:49, 12 September 2025 (UTC)
- B Ophyrius (he/him
T • C • G) 16:26, 12 September 2025 (UTC) - Option B, while I don’t personally agree with the restrictions, if they are here, they should be here for everyone. Chaotic Enby (talk · contribs) 19:44, 12 September 2025 (UTC)
- B No. Administrators are not any more important than any other editor. EggRoll97 (talk) 21:08, 12 September 2025 (UTC)
- Option B. I think it is a terrible idea to run without nominators, but nevertheless this question has outraged me so thoroughly I need to go take a nap. Absolutely not. — asilvering (talk) 21:22, 12 September 2025 (UTC)
- B No per @User:Eggroll97. JuxtaposedJacob (talk) | 🙂 | he/him | 21:59, 12 September 2025 (UTC)
- Option A. I see this as a potential fix for candidates who fall a little short of the requirements in the two questions above this one. And we definitely should be doing more to encourage having nominators, instead of self-noms. Experience so far has been that self-noms rarely get elected. I get the argument that admins are not “more special” than other editors, but they do have some expertise in what this question is about. —Tryptofish (talk) 22:06, 12 September 2025 (UTC)
- Option B Strong oppose to this, regardless of the number of nominators or their permissions/roles. I sympathize with what this attempts to address, but the culture and expectations of the community are not in alignment with this. —Sirdog (talk) 22:54, 12 September 2025 (UTC)
Comments (Q7. Candidate admin nominations)
[edit]
Shall a link to the voter guide category (e.g. Category:Wikipedia administrator elections July 2025 voter guides) be added to the election’s header template (e.g. Wikipedia:Administrator elections/July 2025/Header)?
- Option A – No (current)
- Option B – Yes
- Voter guides remain incompatible with having discussion close before the end of voting. They shouldn’t be in the header. (Or anywhere else.) —Cryptic 10:32, 12 September 2025 (UTC)
- I agree with Cryptic, voter guides should not be permitted at all for admin elections so making them more prominent and adding even more appearance of being official is the opposite way they should be going. Thryduulf (talk) 10:50, 12 September 2025 (UTC)
- Option A they should remain as intended, that is, the personal, subjective assessment of individual Wikipedians with no official standing. —Fortuna, imperatrix 13:03, 12 September 2025 (UTC)
- @Fortuna imperatrix mundi your rationale sounds more like a reason to support not adding them to the header (i.e. option A)? Thryduulf (talk) 13:05, 12 September 2025 (UTC)
- “Facepalm”… Thanks, Thryduulf, a temporary brain fart. Now adjusted accordingly. —Fortuna, imperatrix 13:09, 12 September 2025 (UTC)
- @Fortuna imperatrix mundi your rationale sounds more like a reason to support not adding them to the header (i.e. option A)? Thryduulf (talk) 13:05, 12 September 2025 (UTC)
- A per not promoting personal assessments in this particular case. —SarekOfVulcan (talk) 13:12, 12 September 2025 (UTC)
- Option A – Not needed. TarnishedPathtalk 13:20, 12 September 2025 (UTC)
- Option A They should not be seen to be given any official backing. — LCU ActivelyDisinterested «@» °∆t° 13:46, 12 September 2025 (UTC)
- A per everyone before me — Preceding unsigned comment added by Ophyrius (talk • contribs)
- Option A: The on-project voter guides are very good but they should not be overly emphasized. ~ Pbritti (talk) 17:26, 12 September 2025 (UTC)
- Option B They are more useful for non-experienced editors such as myself; a lot of the people who have voted so far seem to be pretty experienced, for better or worse. Being able to easily access a list of names, some of whom I don’t know, and the recommendations on those names from someone I do know is very valuable. JuxtaposedJacob (talk) | 🙂 | he/him | 22:02, 12 September 2025 (UTC)
- Option A, and I feel very strongly about this. Voter guides are nothing more than one person’s opinion. We should do nothing to make them look “official”. If a voter can’t be bothered to do their own checking on candidates they don’t know, they should at least make an itsy bitsy amount of effort to find the voter guides. —Tryptofish (talk) 22:09, 12 September 2025 (UTC)
There is a situation that may arise in the future where an election clerk has both decryption keys and database access. (Database access includes the ability to view the table of votes as a whole, while the keys are needed to decrypt individual votes.) This combination (decryption keys + database access) would give them enough access to read individual private votes (although it would take several steps to do so, and it would violate the Wikimedia Foundation Privacy Policy). Should changes be made to avoid this?
- Option A – No. Election clerks are trusted enough not to do this. (current)
- Option B – Yes. We will create a rule that a different election clerk must hold the decryption keys, and not share them with anyone with database access. Clerks with database access can still do the todo list and SecurePoll setup list, and be a poll administrator in the SecurePoll software. They just cannot know the decryption keys.
- Option C – Yes. We will forbid people with database access from being poll administrators in the SecurePoll software. This means they could do the todo list, but cannot do SecurePoll setup.
Survey (Q9. Election clerks with database access)
[edit]
- Option A first choice. Option B second choice. Full disclosure: I am an election clerk with database access. I added this question because I received database access recently and I want to make sure it’s not too controversial. There are other positions on Wikipedia where an individual has access to something and is asked not to look at certain things (for example checkuser), so I am hoping this isn’t too controversial. If it is controversial, now’s a good time to put some rules in place. –Novem Linguae (talk) 10:11, 12 September 2025 (UTC)
- Option A first choice (option B second choice). Doing anything potentially inappropriate or controversial wrt the election is firmly against the WMF code of conduct those with database access must adhere to. Getting access in the first place is a big enough deal that we can absolutely trust people who have it not to abuse it. Thryduulf (talk) 10:56, 12 September 2025 (UTC)
- I’ve sorry you’ve personalized this in such a way, but the whole point of having secret ballots is so that nobody is able to determine, even in principle, how a voter voted. I do acknowledge that WMF employees were able to do that for past elections, but at least we can assume they were disinterested in the process, both in general and specific. You’ve shown yourself to be very interested in the process both in general – you practically created it – and in specific, having nominated candidates. I trust you, but think a chilling effect would be inevitable. B or C. —Cryptic 12:00, 12 September 2025 (UTC)
- Option B > A I trust that nobody will do anything crazy. fanfanboy (blocktalk) 12:57, 12 September 2025 (UTC)
- Option B/C per Cryptic. Separation of powers is both harmless and useful. —Fortuna, imperatrix 13:06, 12 September 2025 (UTC)
- Option A I’m not sure why we’re even encrypting the votes here. It might make sense for ACE, since it is conceivable that someone running would have database access and could subtly retaliate in their position as Arb against those that didn’t support them, but I cannot fathom a situation in which someone running at AElect would have database access and be in a position to retaliate without recourse. The main points of having a “secret” ballot is to reduce hostility and badgering in the !votes section, reduce peer pressure on voters to “go with the flow”, reduce anxiety in candidates watching the !votes come in in real time, and to reduce the discouragement that comes with candidates reading tons of negative comments about themselves. None of those require that votes be completely secret from every person on earth. —Ahecht (TALK
PAGE) 13:31, 12 September 2025 (UTC) - Option B. While I trust Novem Linguae (the only person this probably effects) not to abuse their access, I would prefer to truthfully be able to make the claim currently made at Wikipedia:Administrator_elections/July_2025#What data does SecurePoll collect? that
Who you voted for is encrypted and the software keeps it completely confidential, even to election clerks and scrutineers
; if we allow this the only other options are telling lies to children (yuck) or rehashing this exact discussion in the voting instructions (also yuck). * Pppery * it has begun… 15:24, 12 September 2025 (UTC) - B, (C as second choice) per others. Ophyrius (he/him
T • C • G) 16:31, 12 September 2025 (UTC) - Option B or C per Fortuna (regarding separation of powers) and to avoid the appearance of impropriety. I trust Novem, but it is always better to have safeguards baked into our systems instead of relying on our trust of the people in charge (which might not be the same from one year to the other). Chaotic Enby (talk · contribs) 19:43, 12 September 2025 (UTC)
- B This is fine. I doubt it’s something that would happen, but I don’t see any problem with formally prohibiting what would be a massive breach of trust if it were to occur. EggRoll97 (talk) 21:10, 12 September 2025 (UTC)
- C I trust people, but let’s prevent accidents. JuxtaposedJacob (talk) | 🙂 | he/him | 22:03, 12 September 2025 (UTC)
- Option B. I think that B is a reasonable approach, and it will avoid any possible dramas in the future. —Tryptofish (talk) 22:12, 12 September 2025 (UTC)
Keeping in mind that there was an RFC that stated that AELECT should be held every 5 months, that AELECT2 was in July 2025, and that the arbitration committee elections are from Nov 2 – Dec 1, when should AELECT3 be held?
- Option A – Nov 25 – Dec 16 (Nov 25 Call for Candidates, Dec 4 Discussion, Dec 9 Voting)
- Option B – Jan 6 – Jan 27 (Jan 6 Call for Candidates, Jan 15 Discussion, Jan 20 Voting)
Survey (Q10. Next election date)
[edit]
- Option B. This is 6 months after AELECT2, not the recommended 5 months. But it avoids a bunch of holidays and it avoids WP:ACE. –Novem Linguae (talk) 10:18, 12 September 2025 (UTC)
- Option B. Reviewing the slate of candidates for AELECT takes time, so does ACE. So I think between that, plus holidays that a fair amount of en-wiki editors may be away for some periods of time (or just downtime), it’s just easier to do it in January. Raladic (talk) 10:30, 12 September 2025 (UTC)
- Delaying a month just accelerates the next conflict. A, at least unless election 4 is to be held on its (normal) schedule in May regardless. Neutral otherwise. (Disclosure: I think I was the first to suggest having the time of elections change year-on-year.) —Cryptic 10:39, 12 September 2025 (UTC), 13:06, 12 September 2025 (UTC)
- Option A. The periods when one would be reviewing ACE and AELECT candidates does not overlap, and we will run into a bunch of holidays and other issues for some editors regardless of what time of year we hold the election so there is no reason to deviate from the agreed schedule of 5 months. Thryduulf (talk) 10:58, 12 September 2025 (UTC)
- Option A We chose this 5 month schedule because it would not be be on repeating months year after year for the purpose of giving everyone a chance to participate at some point. Let’s not deviate from that. fanfanboy (blocktalk) 12:52, 12 September 2025 (UTC)
- Option A per Fanfanboy. —Fortuna, imperatrix 13:07, 12 September 2025 (UTC)
- A per Thryduulf. —SarekOfVulcan (talk) 13:13, 12 September 2025 (UTC)
- Option A per much of the above. Of perhaps we can mix things up a lil sum and run a process from the end of next month? TarnishedPathtalk 13:24, 12 September 2025 (UTC)
- Option A: The whole point of 5 months was that the dates change, and so does the overlaps with various events including regional holidays. Let’s stick to the consensus of last RfA. Also, if I am reading this correctly, discussion (the more involving phase for everyone) of EFA starts 3 days after ACE completely closes completely, so should not be a big deal IMO. ~/Bunnypranav:<ping> 13:25, 12 September 2025 (UTC)
- Option A It’s always a holiday somewhere, that’s the point of the 5 month cadence. Plus some editors might have jobs that make it so that a holiday makes it easier for them to apply or vet candidates when they have extra time off. —Ahecht (TALK
PAGE) 13:35, 12 September 2025 (UTC) - Option A Kudpung กุดผึ้ง (talk) 13:52, 12 September 2025 (UTC)
- Option A, the point of the five-months is that it rotates, and therefore it will sometimes clash with other things. CMD (talk) 15:51, 12 September 2025 (UTC)
- A Ophyrius (he/him
T • C • G) 16:27, 12 September 2025 (UTC) - Option A, rotating schedules with a prime number is a good thing. Chaotic Enby (talk · contribs) 19:40, 12 September 2025 (UTC)
- Option A The 5 month schedule works sufficiently, I don’t see a need to change it just because of ACE. EggRoll97 (talk) 21:12, 12 September 2025 (UTC)
- Option A The 5 month schedule was chosen because 5 is relatively prime to 12, and the date will therefore move through all the months of the year. Some dates will be more convenient than others. Hawkeye7 (discuss) 22:01, 12 September 2025 (UTC)
- Option A I don’t want to preempt consensus. JuxtaposedJacob (talk) | 🙂 | he/him | 22:06, 12 September 2025 (UTC)
- Option B. The 5-month consensus was never something so sacred that it needed to be set in stone, so let’s move this to after the ArbCom elections and the holiday season. —Tryptofish (talk) 22:14, 12 September 2025 (UTC)
- Folks can propose or add more options if they want. Although I’d suggest using a 3 week date range, and starting it on a Tuesday. That worked pretty well last election. Also, my work schedule may make some date ranges impractical. Options A and B would for sure work with my work schedule though. –Novem Linguae (talk) 10:18, 12 September 2025 (UTC)
- I don’t think we should tailor the decision based on one person’s work schedule. If everyone who is capable and trusted by the community to serve as an election clerk has an issue, then of course as a matter of practicality, the possible dates would be constrained accordingly. isaacl (talk) 13:48, 12 September 2025 (UTC)
- Other than AELECT5 being held in October 2026 (the same month of the year as AELECT1 in October 2024), each month of the year would only have AELECT once every five years. So, the five-month schedule sounds reasonable. Like the previous two elections, the next six elections (from December 2025 to January 2028) would also be held in 31-day months. After January 2028, the next four elections would then be held in 30-day months (June and November 2028, and April and September 2029). Finally, there would be an election in February 2030, which has only 28 days, so we may need to rethink about the five-month schedule after September 2029. GTrang (talk) 16:41, 12 September 2025 (UTC)
- Elections don’t have to be entirely inside certain months. Also, one election in February every 5 years doesn’t sound too bad. fanfanboy (blocktalk) 18:13, 12 September 2025 (UTC)

