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:
Table
Candidate
Support Ratio (%) (s/(s+o))
Support Share (%) (s/(s+o+a))
Result
Election Date
KylieTastic
85.00
69.13
Elected
July 2025
Queen of Hearts
78.74
63.14
Elected
October 2024
Kj cheetham
84.54
64.70
Elected
July 2025
CoconutOctopus
74.12
58.23
Elected
July 2025
Ser!
77.53
58.04
Elected
July 2025
Jlwoodwa
76.77
58.04
Elected
July 2025
Smasongarrison
76.10
57.67
Elected
July 2025
UndercoverClassicist
75.99
56.75
Elected
July 2025
SilverLocust
82.42
56.32
Elected
October 2024
Curbon7
77.11
54.16
Elected
July 2025
Dr vulpes
76.48
52.27
Elected
October 2024
ThadeusOfNazereth
78.48
52.11
Elected
October 2024
Rsjaffe
78.19
51.78
Elected
October 2024
SD0001
75.18
49.68
Elected
October 2024
DoubleGrazing
74.63
49.68
Elected
October 2024
Ahecht
76.32
49.19
Elected
October 2024
Sohom Datta
73.40
48.38
Elected
October 2024
Hinnk
72.22
48.06
Elected
July 2025
Peaceray
71.62
43.83
Elected
October 2024
FOARP
71.66
43.51
Elected
October 2024
Pbritti (July)
66.49
46.21
Not elected
July 2025
Patient Zero
65.79
46.21
Not elected
July 2025
Pbritti (Oct)
67.37
41.23
Not elected
October 2024
AntiDionysius
64.75
40.26
Not elected
October 2024
Usernamekiran
64.62
42.88
Not elected
July 2025
Hilst
66.57
43.05
Not elected
July 2025
MarcGarver
68.91
43.18
Not elected
October 2024
The Squirrel Conspiracy
64.55
42.86
Not elected
October 2024
LindsayH
66.48
38.96
Not elected
October 2024
Valenciano
68.42
35.88
Not elected
October 2024
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)[reply]
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. —Cryptic10:25, 12 September 2025 (UTC)[reply]
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)[reply]
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 curious12:45, 12 September 2025 (UTC)[reply]
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. TarnishedPathtalk13:02, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Support ratios at WP:AELECT plotted on a horizontal lineAfter doing some data analysis (using Raladic's data above), I'm more convinced by asilvering's argument that 70% is a natural pass ratio, so Option A works for me too. Chaotic Enby (talk · contribs) 23:45, 12 September 2025 (UTC)[reply]
Just clarifying to make whoever closes this's life easier - So is that a "C -> A", a "C or A", or a "now A" (in which case striking the C above will help). Thx Raladic (talk) 01:11, 13 September 2025 (UTC)[reply]
C or A equally (as both are supported by different methodologies and I'm still not sure which one gives the best insight), although I'm also open to B as a third choice if the closer wants to find a middle ground between the suggestions. Chaotic Enby (talk · contribs) 01:25, 13 September 2025 (UTC)[reply]
Thanks! It could be good to have finer-grained values in the 60–80 range, as that's where most candidates are concentrated and what we're looking at for the pass percentage. Chaotic Enby (talk · contribs) 20:23, 13 September 2025 (UTC)[reply]
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)[reply]
What isn't reversible is the experience a user could go through if they feel they've been unfairly treated by poor administrative judgement. That's one of the reasons why the current bar is set higher than 50% let alone 60%. 🌻A♭m(Ring!)(Notes)11:33, 15 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
0 evidence has been presented showing this figure needs adjusting downward (and of course, little upward so far, but de-adminship seems to be a decades-long followup when it happens for cloudy reasons). Such evidence would be something to the effect of a string of candidates running in EFA, failing to pass the arbitrary percentage designated we have today (70% is effectively a best guess), and then perhaps running in RFA within days to weeks, and passing (or doing the same in EFA within the same period, but current procedure disallows such it seems). (And just for good belt and suspenders measure, some string of candidates failing both in EFA and nearterm RFA.) I'm also pretty sympathetic to "this is seen to be a process to accept obvious candidates, and as such the bar should be high", but that's just feelgood sentiment based on personal opinion, much like the rest of this discussion. As such, status quo aka option A. Izno (talk) 23:38, 12 September 2025 (UTC)[reply]
Option A I do not want this to be seen as kicking the ladder out from behind me. Due to the lack of discussion involved in the AELECT process, I find a rigid 70% threshold sufficient for assessing a broad community consensus in lieu of discussion. Curbon7 (talk) 03:55, 13 September 2025 (UTC)[reply]
Option C Looking at the list of candidates that would have passed with 65% threshold, I see us losing out on some good potential administrators by having a higher pass requirement. It is clear that the no vote rate is higher in an election than an RfA for the same quality of candidate. — rsjaffe🗣️08:28, 13 September 2025 (UTC)[reply]
Option D>C>B>A. Even the most slam dunk candidates on RFA get no more than 85%, continuing my belief that all SecurePoll elections involve a drop of about 10%-15% compared to public voting. Therefore I am in favour of dropping the threshold by 10%, and will welcome any consensus in that direction. Soni (talk) 10:54, 13 September 2025 (UTC)[reply]
Option B > C. I think we've got it almost right, but are slightly too strict in the current set-up, and the effective bar seems higher than with traditional RfA, given the drop-off in voters. We're short on admins, and we should not move in the direction of becoming more picky rather than less. We need more admins, and recalibrating our standards is one way to help solve this. —Femke 🐦 (talk) 14:47, 13 September 2025 (UTC)[reply]
Option A, though B as a 2nd choice. Oppose higher or option D (60% just feels too low to me). People who were unsuccessful with 60-70% should be encourage to run again after a bit of reflection/feedback, whether it be AELECT or RfA. -Kj cheetham (talk) 17:19, 13 September 2025 (UTC)[reply]
Option B. 66.67% (But option A as a second choice). We definitely need more admins. I also think that we should find a way to encourage those on the bubble to run again. SMasonGarrison00:36, 14 September 2025 (UTC)[reply]
Option A, although actually it should be even higher (75%?). Admin elections don't have the scrutiny that comes with a formal RFA; as such they should be reserved for more slam-dunk clear cases. There's no shame at all in going through a full, formal RFA, and candidates who don't meet the election standard shouldn't be scared off from RFA. SnowFire (talk) 05:47, 16 September 2025 (UTC)[reply]
Option C (or B) per HouseBlaster. It's currently a significantly higher bar to pass admin elections than RfA – and few think that RfA is too easy to pass. Perhaps that's intentional, but it's a bit disheartening to see low-profile candidates who would probably have sailed through RfA fail in the election. J947 ‡ edits02:44, 17 September 2025 (UTC)[reply]
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)[reply]
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. —Cryptic10:42, 12 September 2025 (UTC)[reply]
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 and 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 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)[reply]
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.) —Cryptic11:07, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
I think people should try to attend the workshop phase if they have strong opinions of exclusion of specific questions. Given the split between people in favour of dropping the threshold, and not, it was clearly contentious enough that it needed inclusion after AELECT 2. Soni (talk) 10:54, 13 September 2025 (UTC)[reply]
For better or worse, my past experience with workshops/preparation for request for comment discussions across a wide set of topics is that the audience who shows up for the RfC is typically broader than that which participates in the preparation, even when the prep phase is widely advertised. I wish that initial discussions would transition smoothly into the consensus-building discussions, but the reality on English Wikipedia is that often the difference in participants leads to a difference in consensus viewpoints. isaacl (talk) 16:31, 13 September 2025 (UTC)[reply]
I am seeing arguments from some of those supporting option A that the pass percentage should be in the middle of the discretionary range of RfA. So as a hypothetical question then, if the discretionary range was to be adjusted alongside the pass percentage of AELECT so that it's range is always ±5% of the pass percentage, would you still support 70% as the pass percentage or would you support going lower with that adjustment in place? So for example, if the pass percentage was changed to 65% as in option C, then the discretionary range would be adjusted to 60% to 70%. Gramix13 (talk) 18:03, 13 September 2025 (UTC)[reply]
I would not recommend assuming that RFA pass percentages and AELECT pass percentages correspond 1:1, and for that reason I would not recommend pegging them to each other. Secret voting usually results in at least 15% opposes, even for candidates that would probably pass with 99% or 100% support at RFA. The data from WP:ACE, WP:AELECT1, and WP:AELECT2 shows this clearly since the top candidates always only get 80–85% support. –Novem Linguae (talk) 20:02, 13 September 2025 (UTC)[reply]
I do agree with your analysis there that these two pass criteria don't entirely match from the data shown due to the 15% opposes, however my question is moreso directed at those who disagree with that view, such as Amakuru whose !vote above direction mentions the pass criteria and how this may cause a discrepancy between the two pass criteria. If consensus emerges for option A due to participants wanting the pass criteria between ALELECT and RfA to be 1:1, then seeing if we could adjust the pass criteria for both processes might become one such avenue to address the penalty of secret votes, even if its a compromise solution. Gramix13 (talk) 00:53, 14 September 2025 (UTC)[reply]
In my view many editors above are making a logical error in their reasoning for supporting a lower pass percentage. A process with a binary outcome has a tradeoff between sensitivity and specificity. To lower the threshold, it is not enough to say that some suitable candidates failed to reach our current threshold: if that was the only consideration, there is no limit to how much lowering can be justified. One must also consider the possibility of unsuitable candidates meeting the passing percentage. Without calling any specific previous candidate unsuitable, the past results make it clear that candidates with what we have historically considered insufficient experience or poor judgement can still reach a considerable quantum of support. I believe 70% strikes the right balance. If you have considered the full picture and still feel the threshold ought to be lower, that's fine. But merely saying "some good candidates didn't reach 70%" is entirely insufficient. Vanamonde93 (talk) 18:17, 16 September 2025 (UTC)[reply]
It is insufficient to assert that 70% strikes the right balance. People point to good candidates that fail to make the cut. If 70% struck the correct balance, then there would also be at least one bad one that made it. This is not apparent, so your own criteria agues for a lower threshold. Hawkeye7(discuss)19:19, 16 September 2025 (UTC)[reply]
That assumes the risk of passing an unsuitable candidate and not passing a suitable one are equal, and the community has not historically treated them as equal. I would not personally consider the risks equivalent either. Vanamonde93 (talk) 18:46, 17 September 2025 (UTC)[reply]
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.
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
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Option A Per Bunnypranav, when I have served as a real-world poll worker, I still got to vote because of the oversight of my oversight. Similarly, the scrutineers watch for clerk impropriety. ViridianPenguin🐧 (💬) 04:30, 13 September 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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
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)[reply]
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)[reply]
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. — xaosfluxTalk13:24, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Option B I understand the reasoning behinf this more than for the one above. Scrutineers are still members of the community and should still be able to vote, but I think a restriction on public displays of support/opposition is fair. Curbon7 (talk) 04:02, 13 September 2025 (UTC)[reply]
Option A Similar to my Q2 response, New Jersey has two pollworkers run each booth to have poll worker each watch the other. Here, we get the benefit of three-way vigilance between scrutineers. ViridianPenguin🐧 (💬) 04:33, 13 September 2025 (UTC)[reply]
Option A, what I said for the arbcom election, the threat model here does not make any sense. In practise it is mathematically impossible to influence the election without idk, deleting all votes except your one (and at that point, somebody might notice something?) -- Sohom (talk) 16:47, 13 September 2025 (UTC)[reply]
Option A though I would think it odd if a scrutineer publicly stated an opinion about a candidate, but nothing else on that list bothers me. Perfect4th (talk) 22:23, 15 September 2025 (UTC)[reply]
Option B - to me this is just a normal instance of being wp:involved while in an admin role. It would look odd, for instance, if a nominator for a candidate also was also striking votes of those who commented negatively about that candidate. For the purposes of removing the appearance of impropriety, I think scroots should have the same restrictions as monitors. BugGhost🦗👻17:33, 16 September 2025 (UTC)[reply]
Option A. If we can't trust them then they shouldn't have the right to perform checks using CheckUser tools. I also think that the scrutineers don't know who voted for whom. Fade258 (talk) 11:44, 19 September 2025 (UTC)[reply]
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.
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
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Option B Unlike clerks and scrutineers, the monitors are each watching the tone of discussion with the risk of prejudice to removing comments critical of candidates they nominate. Even if one monitor successfully challenges another’s moderating decisions as biased, the quick nature of admin elections means that readded candidate criticism will have a severely dampened impact. ViridianPenguin🐧 (💬) 04:35, 13 September 2025 (UTC)[reply]
B They’re wading into the action as part of their role. It would be a conflict to also participate outside of their role, and potentially confusing to boot. — rsjaffe🗣️08:31, 13 September 2025 (UTC)[reply]
I disagree. Snow closing this at some point is likely if the present pattern holds, but it's only been open about 36 hours at this point so a snow close now would be premature. Thryduulf (talk) 19:33, 13 September 2025 (UTC)[reply]
Ah so definitely too soon, I would agree with keeping over for a couple more days to ensure the consensus holds in the event of a flip. Gramix13 (talk) 00:54, 14 September 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. TarnishedPathtalk13:12, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Option A with no other choice unless we are RFCing to create parity between RFA and AELECT. I echo what others have said about having different standards for the same technical outcome; +Sysop or not +Sysop. Sennecaster (Chat) 01:42, 13 September 2025 (UTC)[reply]
Option A Same as RfA. I do not think we should have two different edit count requirements. We either raise them both together or do not raise them at all. Curbon7 (talk) 04:06, 13 September 2025 (UTC)[reply]
Option A One of our guiding principles in creating AELECT has been alignment with RFA rules to the greatest extent possible. Per Sirdog, if folks believe that 2.5K or 5K edits is the absolute minimum edits for an admin candidate, that should be simultaneously proposed for both AELECT and RFA. ViridianPenguin🐧 (💬) 04:36, 13 September 2025 (UTC)[reply]
A, though I understand why some want a higher threshold. But this concern is the same for RfAs, so if we don’t want newbies to get hurt by prematurely running, we should do it for both. — rsjaffe🗣️08:35, 13 September 2025 (UTC)[reply]
Option A I would like to welcome more "Highly skilled user with technical skill/other community experience" type editors, which a threshold will be a barrier against. Furthermore, I see the concept of thresholds as insufficiently protecting against the inexperienced editor this question seeks to protect. Soni (talk) 10:54, 13 September 2025 (UTC)[reply]
Option B since people are not voted at the 500 edit edit confirmed point anyway. Option B also has some wiggle room for the community to vote a person with less than the 2,385 edits which is the current low record edits of an elected admin.--Snævar (talk) 11:36, 13 September 2025 (UTC)[reply]
Option A. In reality, nobody with 500 edits will ever be voted in, unless we have some exceptionally unique & special candidate. Why not keep the door open for them? + No reason to have seperate restrictions to RfA. ULPS(talk • contribs)20:18, 13 September 2025 (UTC)[reply]
Option A before this RFC, I was ready to support C as a necessary evil for filtering out candidates who aren't ready, but after seeing the other votes here, I no longer feel that it's necessary. I think organizers have already done a good job of filtering out those who are unready, and voters can always vote against a candidate they feel doesn't meet the threshold to be an admin. Gramix13 (talk) 01:32, 14 September 2025 (UTC)[reply]
Option C for reasons explained well above. Second choice B or D, third A. Oppose E. I think elections is turning out to appeal to different users than RfA does, and appears also to attract a few WP:NOTYETs. In RFA we close the NOTNOWs, but because you don't always get a lot of feedback that would lead a candidate to realize they might be at the NOTYET point before the results come in, I think that setting a smallish threshold could help lessen those situations. Perfect4th (talk) 22:25, 15 September 2025 (UTC)[reply]
Option A: Voters are already capable of assessing if a candidate has the requisite experience, there is no need for a technical blocker which may filter out otherwise suitable candidates (as unlikely as that may be) or encourage edit count gaming (more likely). fifteen thousand two hundred twenty four (talk) 04:35, 16 September 2025 (UTC)[reply]
B or C, oppose anything higher. I agree with Thryduulf about not wanting to restrict people via codified editcountitis, but we've seen several self-noms from well meaning editors who have no chance of succeeding, and this rule may make it less likely to happen again. But I don't want to encourage gaming or blocking slower editors, so I oppose any limit higher than 2500. BugGhost🦗👻17:49, 16 September 2025 (UTC)[reply]
Option D, it's perfectly acceptable to expect admins to have a significant amount of experience, so while I respect the arguments for having no requirements similar to RfA, this requirement does no real harm for editors still wanting to request adminship via traditional routes. I also think that there is a benefit of restricting number of candidates for elections in such an organic manner, so as to reduce the voter time to review participants will potentially expand over time (already it's enough for me and imo a likely reason for low turnouts in such elections as well as abstain votes). CNC (talk) 20:32, 16 September 2025 (UTC)[reply]
Option A edit count can be utterly misleading; I would not want to create an incentive for someone to inflate their account just to be eligible. Regards, --Goldsztajn (talk) 10:27, 17 September 2025 (UTC)[reply]
Option A There is many people who are highly capable when they arrive on Wikipedia. They tend to be professionals, worked on large teams in projects in industry, understand team dynamics, how consensus works, have the ideal temperament, understand how the system works essentially from the beginning with no prompting. We would be precluding that group from potentially making a valuable contribution early on. scope_creepTalk10:23, 18 September 2025 (UTC)[reply]
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)[reply]
General note: If we RFC this again in the future, we should phrase it so that it changes the minimum requirements of RFA at the same time. It is clear that many respondents want to keep these corresponding 1:1 with each other, whatever the outcome. –Novem Linguae (talk) 20:11, 13 September 2025 (UTC)[reply]
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)[reply]
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, imperatrix13:01, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Option B we should not have different requirements for fundamentally the same outcome. If we're going to apply new standards at ADE, we need to apply them to RFA simultaneously. Sennecaster (Chat) 01:45, 13 September 2025 (UTC)[reply]
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)[reply]
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 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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Weak B - While I think a option to waive the requirements is a good Idea, admins are just part of the community like everyone else is too and there are plenty of experienced users whose judgment I'd definitely trust too who just never ran for adminship. Squawk7700 (talk) 22:20, 16 September 2025 (UTC)[reply]
Option B. Any candidate that is somehow unable to fulfill Q5/Q6 (which is very attainable) but somehow able to convince 70% of editors that he/she is an admin material is a strange fellow. ✠ SunDawn ✠Contact me!06:56, 18 September 2025 (UTC)[reply]
Voter guides remain incompatible with having discussion close before the end of voting. They shouldn't be in the header. (Or anywhere else.) —Cryptic10:32, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Option A I love voter guides, and even when I disagree with one, I get to learn more about what its creator values in other editors. That being said, per ActivelyDisinterested, they should not be given official backing. ViridianPenguin🐧 (💬) 04:39, 13 September 2025 (UTC)[reply]
Option A People should decide on their own what they vote. Linking questions and answers is fine, but if people want a voter guide, they should just look for them without an easy link to it.--Snævar (talk) 11:45, 13 September 2025 (UTC)[reply]
Option A, per above, (minus Cryptic and Thryduulf). They are valuable and should not be done away with, buut, yeah should, be officially recognized tbh. -- Sohom (talk) 16:41, 13 September 2025 (UTC)[reply]
Option A The voter guides are a combination of an individuals' opinions of what statistics they think are important and/or more subjective views, not officially compiled. -Kj cheetham (talk) 17:06, 13 September 2025 (UTC)[reply]
B I'd see the officiality concerns if there were an official list or something, but here we're just linking to a cat which already exists and guides are useful for forming opinions IMO. (I made a guide for Jul25, for disclosure.) charlotte👸♥22:39, 13 September 2025 (UTC)[reply]
Also I think seeing the voter guides in WP:ACE made me also expect them to be displayed in AELECT, so I was actually surprised to not see them be that visible when I was voting, I was able to find the category itself but it would have been nice to see the voter guides be accessible from the header to be similar to ACE. Gramix13 (talk) 01:41, 14 September 2025 (UTC)[reply]
Option A - I like guides and find them useful, but they should always be regarded as unofficial personal opinions. Their current position on the page is where they should be - engaged voters will find them, but unengaged voters won't. There are downsides to making them too prominent. BugGhost🦗👻07:59, 17 September 2025 (UTC)[reply]
Voter guides for Arb elections are a lesser evil than they are for admin elections (because in the former candidates are actually competing against each other for a finite number of seats), but a lesser evil is still an evil and really they shouldn't be allowed, let alone promoted, for either. Thryduulf (talk) 23:27, 13 September 2025 (UTC)[reply]
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.
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)[reply]
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)[reply]
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. —Cryptic12:00, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Option A, Doing this is already against the documents that need to be signed for this kind of access and if somebody finds out, it will probably enforced with a WMF ban. That itself should be a good enough deterent. (Option B is not bad tbh and a closer can count me in support, C while technically better gets a "oppose" from me since there is a real shortage of people who have a good-enough understanding of SecurePoll's inner workings) -- Sohom (talk) 16:37, 13 September 2025 (UTC)[reply]
Option B per Chaotic Enby and Pppery. I trust Novem entirely, but the optics matter to me in this instance, and tomorrow it may be someone else in the role. That said, if this were to create genuine problems for our capacity to organize admin elections, I would be open to revisiting. Vanamonde93 (talk) 22:22, 13 September 2025 (UTC)[reply]
B. This should prevent votes being revealed before results are published. However, we cannot prohibit former election clerks from ever gaining database access in the future, so we cannot completely eliminate the potential for votes of past elections could be revealed. Toadspike[Talk]06:51, 15 September 2025 (UTC)[reply]
Option B first choice, option A second choice. I trust Novem, but I'd rather not have any issues if we have any non-Novems. Plus I like avoiding even the appearance of impropriety. Perfect4th (talk) 04:00, 16 September 2025 (UTC)[reply]
Option B per Chaotic Enby. I reject Sohom´s "shortage of people" argument, as it has been confirmed by multiple devs that extensions that do not have a listed maintainer have a shortage of people. SecurePoll, the extension in question not only has T&S listed as an maintainer but also several volunteers in adition to that.--Snævar (talk) 11:42, 16 September 2025 (UTC)[reply]
Option A, mainly because I don't think there's anything really at stake here. I trust the election clerks not to do it, and even if they did, they're not exactly getting blackmail fodder - they'll find out who voted for who, which has been public information at RFA for over 20 years. We don't need to treat this like Fort Knox and have really elaborate set-up instructions, there's nothing really valuable at stake anyway. I'd be fine with B or C, just don't think it's worth the effort. BugGhost🦗👻18:09, 16 September 2025 (UTC)[reply]
I believe it was pointed out in the pre-RfC phase that election clerks who have the decryption keys of past elections can see the votes of those elections if they gain database access at any point in the future, so for the last two elections the horse has already bolted. Toadspike[Talk]12:40, 13 September 2025 (UTC)[reply]
This is true. Hypothetically, Joe Sutherland from WMF would be able to decrypt votes from AELECT1, and I'd be able to decrypt votes from AELECT2 (but of course I would not do so). –Novem Linguae (talk) 22:59, 13 September 2025 (UTC)[reply]
@Sohom Datta: If such abuse was to happen, how likely would it be for no one else to find out about it? I'm confident that we would be able to deal with confirmed cases, but I'm more worried about situations where abuse is not discovered. Chaotic Enby (talk · contribs) 20:30, 13 September 2025 (UTC)[reply]
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)
Option C – Dec 2 – Dec 22 (Dec 2 Call for Candidates, Dec 11 Discussion, Dec 16 Voting)
If consensus for option B is found, I envision AELECT4 being in May 2026, 5 months after when AELECT3 was supposed to be. This would keep from shifting all future elections off schedule by 1 month, making AELECT3 be a one time deviation. –Novem Linguae (talk) 22:57, 13 September 2025 (UTC)[reply]
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)[reply]
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.) —Cryptic10:39, 12 September 2025 (UTC), 13:06, 12 September 2025 (UTC)[reply]
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)[reply]
If supporting C is the only way to get a consensus then I'll support it, but it's a distant second choice to A. There still isn't a reason to deviate from the 5-month schedule. Thryduulf (talk) 03:19, 16 September 2025 (UTC)[reply]
Option A or Option C 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)[reply]
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, 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. Option C is okay for me, as an second alternative. ~/Bunnypranav:<ping>13:25, 12 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
B, and if we should need a compromise for whatever reason, just move the one after up a month to match what would have been the 5 month repeating schedule i.e. May 2026. Izno (talk) 23:47, 12 September 2025 (UTC)[reply]
Option A: The five-month cycle should become firmly established as soon as possible, even tk the detriment of the Christmas spirit. ~ Pbritti (talk) 02:30, 13 September 2025 (UTC)[reply]
Option A per fanfanboy. Also, a reminder that holidays in the Global North is not the same as holidays everywhere. As a voter, I have no problem with missing individual RFAs if they happen on inconvenient days. The same should apply to everyone else. Soni (talk) 10:54, 13 September 2025 (UTC)[reply]
Option A. I believe the only part of AELECT that would overlap with ACE on this schedule is the call for candidates, which requires no voter action and would stretch beyond ACE regardless. I also vehemently oppose scheduling around any particular holidays. Toadspike[Talk]12:37, 13 September 2025 (UTC)[reply]
Option B: I don't want to schedule around holidays, but two very close consecutive elections to pay attention to will lead to voter fatigue. I also support scheduling AELECT4 five months after when AELECT3 would have been to avoid disrupting the schedule. Cremastra (talk·contribs) 19:02, 14 September 2025 (UTC)[reply]
Option A to keep it on the correct schedule and because I am very much against scheduling around holidays, with C as a second choice. Oppose B because the whole point of the 5-month rotation was that different times are better for different people, and bypassing it now just because the current time is inconvenient for some defeats the whole point IMO. QuicoleJR (talk) 11:27, 15 September 2025 (UTC)[reply]
Option C: Per having AELECT be every five months and for being the closest to the five month period. (Option A is ~4.5 months, Option CB is ~5.9 months.) --Super Goku V (talk) 12:21, 15 September 2025 (UTC)[reply]
Option C I don't understand, the last election began (call for candidates) on July 9, and five months after that is Dec 9, so Option C is closest to being five months? Leijurv (talk) 04:16, 16 September 2025 (UTC)[reply]
I feel as though the ideal solution is to define the criteria we want so that there is no ambiguity. Here's an example: Elections are every five months. The discussion phase shall begin on the 2nd Friday of that month at 12:01am UTC and continue through the following Tuesday at 11:59pm UTC. This defines the dates precisely. 2nd Friday so that the call for candidates doesn't go into the previous month. Leijurv (talk) 04:21, 16 September 2025 (UTC)[reply]
Personally, I don't agree with locking in specific dates. These aren't laws governing elections with paid staff managing them. The community volunteers who manage the administrator elections should have some degree of flexibility, particularly since the dates are by design intended to float throughout the year. (As a point of comparison, the arbitration committee election rules specify a specific day for the start of nominations, and durations for the nomination period, pause before the election, and voting period. The requirements add up to a earliest possible start date, but the start of voting could be delayed if there were some unforeseen obstacle.) isaacl (talk) 05:49, 16 September 2025 (UTC)[reply]
I hear that, but I actually don't think the flexibility is a good thing. Because no one can unilaterally change the date, it would take a mini RFC to achieve consensus each time. Given that, wouldn't it be easier, not harder, if there were a default date on which the election will occur? Deviations from that would need consensus, but that's actually better than the alternative which is that every election requires consensus for a date. Leijurv (talk) 07:25, 16 September 2025 (UTC)[reply]
As I stated, no, I don't think a default date makes things easier. I do not believe a new consensus needs to be established for each election date that is approximately within the intended recurrence interval. A fixed date would require a time-consuming discussion for even minor changes. isaacl (talk) 15:58, 16 September 2025 (UTC)[reply]
Option A preferred, Option C otherwise – a 5-month period in-between voting is what was agreed to, to allow for diversity of months instead of a 6-month cycle where it would always be in the same two months. 5 months after July is December, and I prefer Option A over Option C as it's further away from the Christmas/holiday period of late December. DimensionalFusion (talk · she/her) 09:16, 16 September 2025 (UTC)[reply]
Option A: there will be always be a holiday somewhere and potential candidates who are less busy at certain periods. A 5-month gap is a good way to address that. Valenciano (talk) 15:53, 16 September 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
We would have to wait until February 2040 (29 days) to get elections in months of all possible lengths, because 2040 is a leap year. GTrang (talk) 14:20, 16 September 2025 (UTC)[reply]
I don't think that above mentioned AELECT3 date proposal is suitable. I think, There is a chance of overlapping with the Arbitration Committee Election which was already scheduled to be held from 2 November to 1 December 2025. So by considering it and As per the RFC held in early 2025, administrator elections are supposed to be held in every 5 months. Since last administrator election was held in July 2025, the next election (AELECT3) should take place around December 2025 to maintain this schedule. As Novem said above, My proposed AELECT3 dates are given below:
Might want to add that as Option C, then vote for it :) Although the problem with that one is that it puts scrutineering during Christmas, which could be a burden on election clerks, scrutineers, and even candidates who have to be stressed about election results during Christmas. –Novem Linguae (talk) 20:03, 14 September 2025 (UTC)[reply]
I again remind people that holidays in the world are not necessarily universal. Probably a third of the world observes Christmas or adjacent holidays in December, but that's not everyone. I'd like there to be not default assumptions that Christmas is a burden on everyone. Otherwise we risk aligning the schedule to the detriment of some others anyway, defeating the point of the 5 month window. Soni (talk) 21:13, 14 September 2025 (UTC)[reply]
Hi @Novem Linguae. Sure, I will do that. I agree with you on this but, If voting phase ends on 22 December then we have 2 days time before Christmas i.e 23 and 24 December for the scrutineers to check. If it is not enough then we need to add extra 3 days after the Christmas for scrutineers to publish results. Fade258 (talk) 02:46, 15 September 2025 (UTC)[reply]
As someone who proposed an option like this in the pre-RfC phase, but deliberately did not push harder for it to be added as an option. Option B does not overlap with ACE except for AELECT candidates and nominators, who will hopefully be preparing a few weeks ahead of time regardless and thus would still see some overlap in Option C. Toadspike[Talk]07:21, 15 September 2025 (UTC)[reply]
Hi @Toadspike. Yes you're right on that and agree with you but If we consider Option B then we're on the edge to violate 5 month schedule. Since ACE voting phase ends on 1 Nov and see some overlap with AELECT3 but that doesn't harm too much. Fade258 (talk) 08:20, 15 September 2025 (UTC)[reply]
Thanks for the clarification. Obviously it does but If it coincide in every 5 years with ACE then we need to do some adjustments in ACE dates also from next onwards – IMO. Fade258 (talk) 11:17, 19 September 2025 (UTC)[reply]
If both elections are on fixed 12 and 5 month schedules then they will inevitably coincide at some point. However, we don't need to avoid any overlap at all, only having the same phase of both elections (e.g. voting) happen at the same time. This can be achieved by adjusting one or the other by 1-2 weeks at most, which is entirely compatible with the 5 month interval in the RFC, and also not something we need to worry about for several cycles. Thryduulf (talk) 12:20, 19 September 2025 (UTC)[reply]
