Wikipedia:Administrator elections/July 2025/RFCs: Difference between revisions

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]]) &#124; 🙂 &#124; he/him &#124; </small> 21:59, 12 September 2025 (UTC)

*”’B”’ No per @[[User:Eggroll97]]. [[User:JuxtaposedJacob|JuxtaposedJacob]] <small>([[User talk:JuxtaposedJacob|talk]]) &#124; 🙂 &#124; he/him &#124; </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.

Please opine on the below questions related to the English Wikipedia administrator elections process. –Novem Linguae (talk) 08:48, 12 September 2025 (UTC)[reply]

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)[reply]
Can we collapse the table in this response? It’s taking up a lot of room. fanfanboy (blocktalk) 12:28, 12 September 2025 (UTC)[reply]
I agree, so I did it. (Just click to see what’s inside.) —Tryptofish (talk) 21:34, 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. —Cryptic 10: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]
  • 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)[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 curious 12:45, 12 September 2025 (UTC)[reply]
  • Option A (current), per Cryptic. Fortuna, imperatrix 12:54, 12 September 2025 (UTC)[reply]
  • Option A – shouldn’t allow for any lower without discussion to explain why. —SarekOfVulcan (talk) 13:01, 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. TarnishedPathtalk 13:02, 12 September 2025 (UTC)[reply]
  • Option A, seems to be working fine. — xaosflux Talk 13:21, 12 September 2025 (UTC)[reply]
  • Option A (current). I don’t see any reason to change it. Kudpung กุดผึ้ง (talk) 13:26, 12 September 2025 (UTC)[reply]
  • Option A Nothing has changed since the last time this question was asked. — LCU ActivelyDisinterested «@» °∆t° 13:34, 12 September 2025 (UTC)[reply]
    Just in case of a bartender close, I directly oppose any other option. — LCU ActivelyDisinterested «@» °∆t° 13:59, 12 September 2025 (UTC)[reply]
    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)[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]
    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)[reply]
    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)[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. This seems to work fine. No reason to lower it. Intothatdarkness 14:49, 12 September 2025 (UTC)[reply]
  • Option A * Pppery * it has begun… 15:18, 12 September 2025 (UTC)[reply]
  • Option A, reflects the RfA discretionary range. CMD (talk) 15:42, 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]
    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)[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]
  • 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]
  • 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]
  • 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)[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?
Novem Linguae (talk) 09:18, 12 September 2025 (UTC)[reply]

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]

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]

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]

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)[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 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)[reply]
  • A per Thryduulf–Plutus 💬 mess Fortune favors the curious 12:50, 12 September 2025 (UTC)[reply]
  • 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)[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 E as, really, reflecting the actualité. Fortuna, imperatrix 12:59, 12 September 2025 (UTC)[reply]
  • D – if you want to make a case sooner, make it at RFA. —SarekOfVulcan (talk) 13:06, 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. TarnishedPathtalk 13: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]
  • 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)[reply]
  • 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)[reply]
  • Option A – per Xaosflux. The results of the elections will reflect what the voters think. Kudpung กุดผึ้ง (talk) 13:43, 12 September 2025 (UTC)[reply]
  • 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)[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]
  • 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)[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 Why would we make it higher for AELECT than for RfA? EggRoll97 (talk) 21:03, 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]
  • Option D Per Novem JuxtaposedJacob (talk) | 🙂 | he/him | 21:55, 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]

Comments (Q5. Candidate edit count requirement)

[edit]

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]

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)[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 A – Yes
  • Option B – No

Survey (Q7. Candidate admin nominations)

[edit]

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

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)[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. —Cryptic 12:00, 12 September 2025 (UTC)[reply]
  • Option B > A I trust that nobody will do anything crazy. fanfanboy (blocktalk) 12:57, 12 September 2025 (UTC)[reply]
  • Option B/C per Cryptic. Separation of powers is both harmless and useful. Fortuna, imperatrix 13:06, 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. 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)[reply]
  • B, (C as second choice) per others. Ophyrius (he/him
    T • C • G
    ) 16: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]
  • C I trust people, but let’s prevent accidents. JuxtaposedJacob (talk) | 🙂 | he/him | 22:03, 12 September 2025 (UTC)[reply]
  • 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)[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)

Survey (Q10. Next election date)

[edit]

  • 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]
    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)[reply]

Leave a Comment

Your email address will not be published. Required fields are marked *

Exit mobile version