Misplaced Pages

:Requests for adminship/2024 review/Phase II/Administrator elections - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages:Requests for adminship | 2024 review | Phase II

This is an old revision of this page, as edited by TheAstorPastor (talk | contribs) at 15:16, 8 January 2025 (→Q3 Survey (Selecting candidates for max #)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 15:16, 8 January 2025 by TheAstorPastor (talk | contribs) (→Q3 Survey (Selecting candidates for max #))(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Welcome back! The October 2024 trial of the administrator elections process has concluded, electing 11 out of 35 candidates. Administrator elections, in which candidates are voted on privately via SecurePoll, are an alternative path to the requests for adminship process. The process began on October 8 with a week-long nomination period, followed by a quiet period while the SecurePoll software was set up. Then a three-day discussion period began on October 22, followed by a week-long voting phase from October 25 to October 31. The election was approved as a trial run in a discussion at phase I of RFA2024. Some discussion of the process is available at Misplaced Pages talk:Administrator elections, and feedback from candidates and voters was collected on the debrief page. Following that, we now return to vote on a series of proposals to refine the process, decided at the AELECT workshop.

This RfC will not discuss reauthorization of administrator elections; that will be decided on in a follow up RFC after the RFCs on this page are all closed. The idea is to improve the process as much as possible first, then later have a straight up and down vote about renewal.

This is a lot of questions. Some questions will snow close fairly quickly, so feel free to wait until then if you would like less questions to evaluate.

Consider responding to each survey one at a time, to avoid edit conflicts.

RFC tag

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following list: When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Please opine on the below questions related to the English Misplaced Pages administrator elections process. –Novem Linguae (talk) 10:09, 7 January 2025 (UTC)

Q1: Pass percentage

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

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

Q1 Survey (Pass percentage)

  • Option C - I supported most of the candidates in the 65–70% range of the previous administrator election. These were really solid candidates and I think Misplaced Pages would have been better off had they succeeded. Additionally, having the pass threshold be identical between WP:RFA (65–75%) and WP:AELECT (70%) is questionable, because in secret elections such as WP:ACE and AELECT, voters tend to vote oppose more often. The top candidates in ACE and AELECT only tend to get around 80% instead of 100%. This suggests that the pass threshold for AELECT should be lower than for RFA. –Novem Linguae (talk) 10:20, 7 January 2025 (UTC)
  • Option C If people can elect a national leader on about 33% support, we can elect an admin for double that. Ritchie333 10:27, 7 January 2025 (UTC)
  • At least option A, if not higher. That's the threshold to pass RFA, and the proposal to lower the RFA threshold in the rfc that enabled the trial election failed. It is not appropriate for there to be a laxer numerical threshold in a process with demonstrably less scrutiny. —Cryptic 10:32, 7 January 2025 (UTC)
  • Option B (or A). Partly this is for the reason I gave in phase I: the elections process is a great way to streamline the process for uncontroversial candidates, but serious opposing arguments deserve to be hashed out through the consensus process. (I think the trial bore this out.) Partly it's because the percentages we saw in the trial are basically the low-water mark; as the process becomes more familiar and fewer people blanket-oppose, reaching 70% will become easier all on its own, whereas lowering it even further could have more drastic consequences than anticipated. And partly it's just because I think 70% worked well in the trial. This question is the big one, and I'd encourage people who are excited about AELECT to err on the side of caution here: if the threshold goes down, I think it'd lead to a lot more opposes in the re-authorization RfC, including mine. Extraordinary Writ (talk) 10:42, 7 January 2025 (UTC)
  • Option C, or perhaps even D. I oppose raising this higher than the current level. I believe the "lack of scrutiny" challenge will go away when we have more frequent elections and a better procedure in future – the trial election showed that deserving candidates didn't pass, not that undeserving candidates did. Toadspike 10:44, 7 January 2025 (UTC)
  • Option C > D > B. I believe 65% was sufficient, and the opposes on every candidate clearly showed having a secret voting does cause a significant percentage drop for candidates. Soni (talk) 11:15, 7 January 2025 (UTC)
  • B. As it seems to have worked okay. I also think there's a link between the number of candidates and the pass percentage threshold. If there are less candidates, then there is more opportunity for scrutiny which means that potentially the pass threshold can be raised. E.g., 20 candidates / 70%, 10 candidates / 75%, five candidates / 80% MarcGarver (talk) 11:20, 7 January 2025 (UTC)
  • D>C>B. The support percentages in the election were significantly lower than the support percentages I'd expect at RFA, and we should compensate by about 10%. Right now we're turning away good admins, while even 10% lower we will b e able to screen out candidates who don't have the community's trust with comfortable margins. Tazerdadog (talk) 11:29, 7 January 2025 (UTC)
  • Option (> D < C). Is it anyhow going to replace the standard RFA? --C1K98V 11:36, 7 January 2025 (UTC)
    The normal RfA process will remain an option (absent some future consensus to get rid of it); administrator elections are an alternative process, not a replacement. 137.22.90.76 (talk) 13:18, 7 January 2025 (UTC)
  • Option B > C > A > D. The current threshold worked well. Thryduulf (talk) 11:48, 7 January 2025 (UTC)
  • Option B. I think the current threshold worked well, and Writ's argument is also compelling. Giraffer (talk) 12:08, 7 January 2025 (UTC)
  • Between B and C. I felt 70% was too high a pass percentage, and some people I thought should pass didn't. However, 65% may be too low. I'd personally set it at 67%. We can always lower it further later, but it would be good to see what happens with a more moderate change in a smaller next election. —Femke 🐦 (talk) 12:15, 7 January 2025 (UTC)
  • Option B There nothing I can see in the previous election that shows that this needs to change. RFAs pass with such low levels of opposes because no-one wants to oppose an obviously passing candidate. In secret ballots that pressure is absent. So any comparison to normal RFAs isn't a valid comparison, and doesn't show any need to make any change. Looking at the data from the last election abstains tracked downward as support votes increased, the same isn't true with opposes. With opposes high levels of support could also be seen with high levels of oppose votes. -- LCU ActivelyDisinterested «@» °∆t° 12:24, 7 January 2025 (UTC)
    The idea of lower the requirement because a particular candidate failed is rather flawed. It dismisses oppose votes as unreasoned when opposition could have been for reasons unknown. Not knowing is the nature of secret ballots. Whether they would have made it in a normal RFA is also an unknown unless it's attempted. -- LCU ActivelyDisinterested «@» °∆t° 14:06, 8 January 2025 (UTC)
  • C>B as data has shown that there are candidates who should obviously pass. The candidate above and closest to the proposed 65% threshold was Lindsay, and there was no opposition registered on her page! I couldn't think of any either, except that I haven't seen her around, which is super flimsy reasoning. There's no opposition to scrutinize here, and there is nearly no benefit IMO in going the "safer" way here. Aaron Liu (talk) 13:22, 7 January 2025 (UTC)
    Plus, there's always Recall. Aaron Liu (talk) 00:30, 8 January 2025 (UTC)
  • B, the test election led to a number of new admins, so it seems the current threshold is functional. While the secret ballot process is different to the normal open ballot process, I don't think this is a reason to devalue opposition/over(?)value support in this process to try and create some supposed match in outcomes. Some above are getting into fine distinctions, 60%, 65%, 67%, 70%. Getting into those weeds is conceptually messy, with unclear justification. Keeping the thresholds the same (I suppose it is technically keeping the secret ballot threshold in the middle of the open ballot crat chat range) is easy to understand, and provides a less unnecessarily mathematically loaded decision for a prospective applicant. CMD (talk) 15:05, 7 January 2025 (UTC)
  • D > C. In situations where you're determining a cutoff, it's helpful to look at where there are natural gaps in the data. In the October elections, the largest gaps were 11.7% between 27.6% and 39.3%, 4.7% between 59.8% and 64.5%, 4.6% between 44.1% and 48.7%, and 4.1% between 55.7% and 59.8%. Of those, putting a cutoff in the 30s doesn't make sense, so the next logical place is between 59.8% and 64.5%. Ideally the cuttoff would be rounds to 65%, but that wasn't one of the options, so my preference would be somewhere between C and D. --Ahecht (TALK
    PAGE    ) 15:22, 7 January 2025 (UTC)
  • C per Novem Lingua and the same lower cutoff as RFA 65%.Pharaoh of the Wizards (talk) 15:43, 7 January 2025 (UTC)
  • C or B, with a view to reconsider after a few more cycles of elections. I do think there is a higher chance people vote negatively in secret ballots than would do publically. -Kj cheetham (talk) 15:59, 7 January 2025 (UTC)
  • B I'm not convinced the support percentage was a problem in the previous election. * Pppery * it has begun... 16:58, 7 January 2025 (UTC)
  • D or E (EC) To be blunt, if you voice a political opinion of any kind, you will get at least 30% pushback requiring perfect support from everyone else. This is a reflection of current politics, not any individual. Failing D or E, lower = better. We need Admins. We shouldn't be discouraging them through onerous processes. Buffs (talk) 17:00, 7 January 2025 (UTC)
    What's your option E? Aaron Liu (talk) 17:10, 7 January 2025 (UTC)
  • I want to support D. But I agree that it might lead to opposes in the reauthorization RfC. Therefore, I support B as leaving well enough alone. I wouldn't oppose C, however. And apologies in advance to the closer! HouseBlaster (talk • he/they) 17:10, 7 January 2025 (UTC)
  • B, as the middle of the RFA discretionary range. I don't believe we should be changing that without also changing the range for regular RFAs: that has been our standard for required community support for a long time. If we lower the threshold just for ALELECT, we may obviate regular RFA without any consensus for doing so. A 60% threshold in particular strikes me as far too low. I would accept C as a distant second choice. Vanamonde93 (talk) 17:28, 7 January 2025 (UTC)
  • Option C > D > B, Oppose A. Raising the threshold is a terrible idea. 70% was chosen in the first place because it's a good balance between 65% and 75% for crat discussion. The few candidates who were below between 65% and 70% were good and should have passed IMO. fanfanboy (blocktalk) 17:36, 7 January 2025 (UTC)
  • B is fine. Any is fine. ~ ToBeFree (talk) 18:33, 7 January 2025 (UTC)
  • B>A. — xaosflux 18:46, 7 January 2025 (UTC)
  • Option C, second choice option B, per Aaron Liu. Perfect4th (talk) 20:41, 7 January 2025 (UTC)
  • CBDA per Toadspike. (I was elected in AELECT, for disclosure.) charlotte 21:10, 7 January 2025 (UTC)
  • B. I am disinclined to change it after a single run, because it's difficult to know how this will work out in the future. If we continue to see significant numbers of editors opposing all candidates on the basis that there are too many candidates to evaluate carefully, then I might support lowering the number in the future. But that might not happen, and I don't want unqualified candidates to slip through because we overreacted to the results of the first try. --Tryptofish (talk) 22:34, 7 January 2025 (UTC)
  • Option A to match existing RfA threshold. As Cryptic writes above, it is absurd to reduce the threshold under circumstances where less scrutiny is likely to occur. I believe it is more important to have thoughtful, competent admins than just more admins. I strongly oppose lowering the threshold further; to be blunt, I don't agree that all those participants in the last election whose votes fell in the range 65% to 70% would have been likely to pass an RfA. Espresso Addict (talk) 22:39, 7 January 2025 (UTC)
  • Everyone who got about 60% in the first run would have been an excellent admin. I am comfortable with C, D, and B. --JBL (talk) 00:56, 8 January 2025 (UTC)
  • C its good enough. L3X1 ◊distænt write◊ 01:15, 8 January 2025 (UTC)
  • Option C. There seemed to be a built-in implicit bias against AELECT as the the user with the highest support percentage only got 82%. Thus the passing percentage should be lowered to compensate. cyberdog958 01:43, 8 January 2025 (UTC)
  • Option B which is the current standard. When we are looking at positions of trust where you can !vote discretely for each candidate, there is no reason why someone should not receive a significant majority of support. I initially considered a much lower percentage thinking about conventional elections, but the difference here is that we don't choose one RfA at the determined of another, we can support both equally with no consequence. TiggerJay (talk) 05:25, 8 January 2025 (UTC)
  • C, second choice B Leijurv (talk) 05:44, 8 January 2025 (UTC)
  • B or higher: should reflect RfA percentages also per Extraordinary Writ . Callanecc (talk • contribs • logs) 06:16, 8 January 2025 (UTC)
    It concerns me that one process routinely has candidates achieve 99% or 100%, and another process only has candidates achieve a maximum of around 80%, yet the pass percentage is the same for both of them. In my mind, they are not equivalent in that way. –Novem Linguae (talk) 06:57, 8 January 2025 (UTC)
    Given that the relative frequency of high support percentages has increased with the decrease in numbers of successful candidates, the most straightforward explanation is that candidates who in the past would have made a request and passed with a lower percentage are now declining to request administrative privileges. Shy voter effects have been hypothesized to lower expected support percentages in elections, but the attractiveness of voting could push support percentages up, so I don't think one election has provided enough data to determine a net effect. isaacl (talk) 07:34, 8 January 2025 (UTC)
    I'm also basing this on multiple WP:ACE elections, which has its top candidates achieve around 80% support maximum too. My theory is that any time SecurePoll is used, the top candidates max out at 80% instead of 100%. –Novem Linguae (talk) 07:46, 8 January 2025 (UTC)
    There are many people who choose to support no more candidates than the number of seats available in arbitration committee elections (although as I've previous written, unless you're confident about which candidates won't reach the required threshold, the best approach is to support everyone who you wouldn't mind passing). Administrator elections don't have a limited number of seats so this effect, which drives down support percentages, doesn't come into play. Voters may also have higher standards for arbitrators, which would reduce support percentages. isaacl (talk) 08:28, 8 January 2025 (UTC)
  • B ~ C > A > D, to avoid people opposing re-approval based on the threshold not being high enough, and with the hope that the top end of supports increases from around 80% next time. I would likely support slowly adjusting it downward in the future if people aren't getting above about 80%. SilverLocust 💬 06:40, 8 January 2025 (UTC)

Q1 Discussion (Pass percentage)

  • As a failing candidate in the trial elections i shan't "vote" in case it looks like i'm doing so out of sour grapes or some such; i shall offer the opinion, however, that the idea that making elections harder to pass than RfA is just plain silly. Though it's just a single series of data points, the election seems to show that the extremely high support rates that successful Requests have been gaining in the fairly recent past do not transfer processes: The candidate with the highest number of support votes ended up with less than a 79% rate, and only one had higher than 80%, whereas judging by RfAs over the past couple of years, at RfA likely three or four would have been over 90%. If elections are permanently implemented and we see the average success percentage creeping up, that would be the time to think about raising the bar ~ Lindsay 14:22, 7 January 2025 (UTC)
  • Since it looks like this question has a bit of split, if this question is closed as consensus for option C, should we make add an option in the reauthorization RfC to oppose reauthorization as-is but support reauthorization with option B? Aaron Liu (talk) 00:30, 8 January 2025 (UTC)
    I would be against this. I want the reauthorization RFC to be as uncomplicated as possible. This phase 2 RFC will result in the most popular changes achieving consensus and being made to AELECT, which will give the renewal RFC the most chance of succeeding. –Novem Linguae (talk) 02:15, 8 January 2025 (UTC)
    I guess we'd need to wait and see how much opposition to C really there is. Aaron Liu (talk) 02:24, 8 January 2025 (UTC)

Q2: Maximum # of candidates in each election (numerical limit)

Should there be a maximum number of candidates in each administrator election? What should it be?

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

Q2 Survey (Maximum # of candidates)

  • Option A. I might end up in the minority on this one, but I think having a high number of candidates is one of the many ways that administrator elections reduced scrutiny and stress for candidates. I would argue that these ways of reducing scrutiny and stress for candidates is the "secret sauce" that makes AELECT work so well, making it a much less stressful/toxic process than RFA. If we start making changes that shine more of a spotlight on candidates, we'll be moving the slider back in the direction of RFA and messing with the "secret sauce". Voters that don't have time to research candidates can always abstain on just those candidates. In the last election, the lowest number of support+oppose votes that any individual candidate received was 318, demonstrating that even if there are a lot of candidates, there are still plenty of voters willing to do research on the candidate and vote support or oppose. Finally, it is likely that future elections will have less candidates, so this may not be an issue for much longer. –Novem Linguae (talk) 10:25, 7 January 2025 (UTC)
  • Weak support for Option D. I'm not confident that future elections will have as many candidates as the first one did, especially if we get to hold them regularly, so I don't know if a limit is necessary. However, I oppose any limit lower than 15 as too restrictive. Toadspike 10:49, 7 January 2025 (UTC)
  • A or if we really want a limit something like 50. — xaosflux 10:54, 7 January 2025 (UTC)
  • E. As some limit is needed to make the process manageable. For me there's a link between the number of candidates and the pass percentage threshold. If there are less candidates, then there is more opportunity for scrutiny which means that potentially the pass threshold can be raised. E.g., 20 candidates / 70%, 10 candidates / 75%, five candidates / 80%. MarcGarver (talk) 11:19, 7 January 2025 (UTC)
  • Option A Per NL. I believe there are a significant number of RFA candidates who have enough imposter syndrome to be convinced to stand for elections. A process that reduces the number of "available slots" will almost certainly be not used by them; candidates will become way more hesitant to self-nom for fear of "wasting a seat". I think the right choice for ##Q16:_Discussion_phase_length_(length_in_days) can make the elections more rigorous than any tweaks with number of candidates. Soni (talk) 11:20, 7 January 2025 (UTC)
  • A per NL, who said it well. Tazerdadog (talk) 11:29, 7 January 2025 (UTC)
  • E. There does need to be some limit to make the process workable, however that limit should not be set too low and about 20 feels a good upper limit that combines this with minimising the "wasted seat" thinking mentioned by Soni. Thryduulf (talk) 11:52, 7 January 2025 (UTC)
  • A per NL. Chaotic Enby (talk · contribs) 11:54, 7 January 2025 (UTC)
  • A My guess is that this is a self-correcting issue, and that by the 3rd election, we'll get a steady 10-15 candidates. I'm not opposed to option E; the disadvantage I see there is that we have to make some arbitrary choices about who gets to be in the election. I imagine that a formal limit of 20 means a lower de facto limit, given that people withdraw before the voting starts. —Femke 🐦 (talk) 12:11, 7 January 2025 (UTC)
  • A Although the first election was barely manageable that was likely (hopefully) due to pent up demand. Hopefully once this has passed their will be less abstain votes in the election. -- LCU ActivelyDisinterested «@» °∆t° 12:26, 7 January 2025 (UTC)
  • A until there is evidence that it is problem.· · · Peter Southwood : 13:03, 7 January 2025 (UTC)
  • A This should not have limits or whatsover. Rationale mostly based on Novem Linguae's comment. Vanderwaalforces (talk) 13:10, 7 January 2025 (UTC)
  • A Let them run. A sufficient percentage passed on the first run that I am confident in the community to be able to sort out suitable candidates. Also per NL.--Wehwalt (talk) 14:26, 7 January 2025 (UTC)
  • C-E. The initial run of 35 was very high, and the securepoll software meant that it was not possible to vote in a staggered manner. Reviewing that many candidates is a significant burden for voters, and is likely to feel more so if such elections become routine rather than novel. There were 11 passing candidates out of 35 so perhaps 10 is more than would usually get elected, and 10 seems arbitrarily fine in line with our base 10 numerical system. However, perhaps you always get >10 passing candidates, hard to say, so going towards 20 might account for that while preventing the process getting away as it did with 35. CMD (talk) 15:14, 7 January 2025 (UTC)
  • A: I don't see a reason why we should limit the number of questions. Hey man im josh (talk) 15:17, 7 January 2025 (UTC)
    Did you mean to say "candidates" instead of "questions"? –Novem Linguae (talk) 15:32, 7 January 2025 (UTC)
  • B > C > Anything but A The number of candidates in this last election was untenable, as shown by the fact that the abstain rate for all but three candidates was above 30%, several candidates had abstain rates that approached 50%, and two elected candidates had abstain rates approaching 40%. I was lucky to get elected, but the fact that more than 1/3 of voters abstained rather than vote one way or the other on me really speaks to the lack of engagement and discussion on each candidacy. Other candidates that maybe should've been elected failed simply because there wasn't time or manpower for discussion and voters instead went on undiscussed and potentially misleading statistics. --Ahecht (TALK
    PAGE    ) 15:32, 7 January 2025 (UTC)
    In the most recent arb elections, there were only 12 candidates. In that election the abstention rate was >30% for all but one candidate, and >40% for four candidates including two of those who were elected. Given that there were fewer candidates in that election, and ArbCom candidates are presumably more familiar to voters than AElect candidates, and yet the abstention rates were comparable, I don't see either that this abstention rate is indicative of a problem or that having a smaller pool of candidates will necessarily lead to a lower abstention rate. (And this year's ACE was not unusual: in WP:ACE2023 there were only 10 candidates, and yet the lowest abstention rate was 32% and four of the eight elected candidates had an abstention rate >40%) Caeciliusinhorto-public (talk) 14:54, 8 January 2025 (UTC)
  • A. Too many candidates is a good problem to have, and I suspect in the future there won't be as many anyway. RoySmith (talk) 15:39, 7 January 2025 (UTC)
  • A per Novem Lingua the lowest number of support+oppose votes that any individual candidate received was 318 which is higher than most RFA.Pharaoh of the Wizards (talk) 15:48, 7 January 2025 (UTC)
  • A or E. 8 is too low. As others have said, the first run is probably going to get a higher number than ones going forward as it becomes more business as usual (assuming it does). Don't want a silly number, but if setting a maximum I'd also consider higher than 20, say 25. -Kj cheetham (talk) 16:02, 7 January 2025 (UTC)
  • A Not convinced this was a problem. * Pppery * it has begun... 16:58, 7 January 2025 (UTC)
  • A no need for a limit Buffs (talk) 17:01, 7 January 2025 (UTC)
  • A we seem to have managed well in analyzing 30+ candidates, and I can't imagine there will be more candidates in a non-trial run. HouseBlaster (talk • he/they) 17:11, 7 January 2025 (UTC)
  • A per NL and to avoid any number of cascading complexities coming from limiting the number of candidates. I know we had a lot of complaints during and after, but the numbers bely them to some extent. Also, I fully expect the first run to be an outlier. Vanamonde93 (talk) 17:28, 7 January 2025 (UTC)
  • C I support there being 10 candidates, as kind of a goldilocks zone of not overwhelming voters with too many candidates/allowing relatively un-scrutinized candidates to pass and making the process similar to RFA. I felt overwhelmed with the past number of candidates, and I can imagine there were definitely some who decided to not vote because of the high number, so a limit is definitely better. JuxtaposedJacob (talk) | :) | he/him | 17:39, 7 January 2025 (UTC)
  • Option E > D > A. Oppose B & C. 20 and 15 are reasonable, but 10 and 8 are too little. Option A should be on the table because Novem is right, the more candidates, the less scrutiny. fanfanboy (blocktalk) 17:41, 7 January 2025 (UTC)
  • Option E followed by Option A. Having more than 30 candidates run is unwieldy for voters to sort through. I think 20 is a fair number, assuming elections aren't too infrequent, and would strongly oppose a lower limit than 20. ~~ Jessintime (talk) 17:56, 7 January 2025 (UTC)
  • A is fine. Any is fine. ~ ToBeFree (talk) 18:34, 7 January 2025 (UTC)
  • Option D or E, second(/third) choice A. It would be easier to evaluate less candidates than last time, but I don't think it would be helpful to limit it too much. Perfect4th (talk) 20:43, 7 January 2025 (UTC)
  • DEACB per Fanfanboy and Jessintime. (I was elected in AELECT, for disclosure.) charlotte 21:14, 7 January 2025 (UTC)
  • A. I think that it's probable (albeit not certain) that we will have fewer candidates in future elections than we had in the first one, so I don't want to put a limit in now, especially given the need for new admins, along with the fact that the process still worked quite well, even with so many candidates. If, in the future, we keep getting such large numbers of candidates, I might change my mind and support an upper limit of maybe 15 (D). --Tryptofish (talk) 22:39, 7 January 2025 (UTC)
  • Option B. Eight is plenty to be evaluating simultaneously, and also plenty to take the heat off individual candidates. Espresso Addict (talk) 22:44, 7 January 2025 (UTC)
  • Option A. I came into this RfC expecting to support a limit, but ultimately it's just so difficult to administer fairly that I don't think it's worth the trouble. If we're consistently getting an unmanageably high number of candidates (which I think is unlikely), then the answer is to increase the frequency of elections. Extraordinary Writ (talk) 00:38, 8 January 2025 (UTC)
  • A or E; B and C are much too small. --JBL (talk) 00:56, 8 January 2025 (UTC)
  • A I fail to see any material gains to the community by limiting it. Limiting it puts in the same debacle as other arbitrary restrictions, wandering around in the dark. L3X1 ◊distænt write◊ 01:16, 8 January 2025 (UTC)
  • Option E should be the ceiling just in case there are random spikes during one election. This will make it not too overwhelming for voters to evaluate all the candidates. cyberdog958 01:50, 8 January 2025 (UTC)
  • A, hypothetically, a limit might be an improvement, but practically, it would cause a number of headaches that just aren't worth it. If the number of candidates becomes a consistent problem, we can raise the threshold to stand for elections or hold them more frequently. —Ganesha811 (talk) 02:17, 8 January 2025 (UTC)
  • A while I am inclined to have some sort of limit, this has never seemed to be a problem that has needed fixing in the past. TiggerJay (talk) 05:27, 8 January 2025 (UTC)
  • E, second choice A Leijurv (talk) 05:41, 8 January 2025 (UTC)
  • D but also okay with B or C. It needs to be achievable for voters to have time to look through the information about each candidate. If there are too many candidates this is no longer doable. Callanecc (talk • contribs • logs) 06:21, 8 January 2025 (UTC)
  • E ~ D. It was rather too high in the trial, but I'd like to leave room for, say, withdrawn candidacies during the discussion period. SilverLocust 💬 06:40, 8 January 2025 (UTC)
  • Option A per NL The AP (talk) 15:11, 8 January 2025 (UTC)

Q2 Discussion (Maximum # of candidates)

  • I agree with Novem's comments in the survey section, but don't want to vote since I was neither a voter (as such) nor one of the organisers, so the large number of candidates didn't pose any problems for me as a candidate, therefore I don't feel I'm in a position to comment.
I will mention a concern I brought up earlier, that the larger the number of candidates, the more influential voter guides become, which could concentrate power in the hands of those few who bother to compile a guide. But as NL says, if these elections become a regular feature, then candidate numbers in any given election are likely to stay relatively low, although cumulatively there could still be 'voter fatigue' which could emphasise the role of voter guides. Although whether that's a good thing or bad, I'm not sure. --DoubleGrazing (talk) 10:45, 7 January 2025 (UTC)
I expect there will be a decline in candidates if this becomes a regular "thing". If not, well, I'm told we need the admins. Is there any evidence that the 11 new admins are messing up?--Wehwalt (talk) 14:45, 7 January 2025 (UTC)
  • I don't fully understand the votes above saying A and it likely won't be an issue anyway. It's an issue or it isn't. On the potential issue, increasing the size of individual elections is not the only potential mechanism to address it, more frequent elections would have a similar effect while spreading the voter time commitment out. CMD (talk) 15:43, 7 January 2025 (UTC)

Q3: Maximum # of candidates in each election (selection criteria)

If there's a maximum number determined in Q2, which candidates can stand in the elections?

  • Option A - The first candidates who sign up chronologically (oldest first)
  • Option B - Those who have never requested adminship before in sign-up order (oldest first), followed by time since most recent adminship request (longest ago first)
  • Option C - By number of previous requests for adminship (fewest first), then by sign-up order (oldest first)
  • Option D - Any candidates who applied but weren't selected to run in the previous election (randomly) then all other candidates (randomly)
  • Option E - By number of co-nominators (greatest first)

Q3 Survey (Selecting candidates for max #)

Q3 Discussion (Selecting candidates for max #)

What does option D mean? Aaron Liu (talk) 15:30, 7 January 2025 (UTC)
If there is a limit to the number of candidates that is lower than the number who sign up then we need some method of picking which people get to stand this time. Option D proposes that we allocate the places randomly for the first election. For the second and subsequent elections the candidate pool would be split into two groups, one (call it group A) for those who wanted to stand in a previous election but were unlucky, and another (group B) for everyone else. If there are more people in group A than the maximum number of candidates then we randomly select just from that group. If there are fewer people in group A than the maximum then they all get allocated spots and the difference is filled by a random selection of people from group B. Thryduulf (talk) 16:42, 7 January 2025 (UTC)
  • These sorts of limits make no sense. If we do it by "Who hasn't had a chance?" you'd rather evaluate someone who has been here for 3 months rather than someone who has been here for 15+ years, but failed an RfA 12 years ago. Put a time limit on it if you're going that route. For first come, first serve, we're going to end up evaluating the same quick people over and over or force people in some regions to get up overnight just to have a shot. This is NOT the way... Buffs (talk) 17:06, 7 January 2025 (UTC)
    Question 12 attempts to address your final sentence (among other possible issues). Thryduulf (talk) 17:13, 7 January 2025 (UTC)

Q4: Scrutineering (yes/no)

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

  • Option A - Scrutineered. Personal data of voters is visible en-masse to electionadmins, similar to ACE elections (current)
  • Option B - Not scrutineered. Personal data of voters is visible en-masse to electionadmins because there is no way to turn it off in SecurePoll, but it will not be methodically checked.

Q4 Survey (Scrutineering)

Q4 Discussion (Scrutineering)

Q5: Scrutineering (who will scrutineer)

If Q4 achieves consensus for Option A (doing scrutineering), who should the scrutineers be in future administrator elections?

  • Option A - 3 stewards who are given local CheckUser access solely for scrutineering the election (current)
  • Option B - 3 English Misplaced Pages CheckUsers
  • Option C - 3 stewards who are given local CheckUser access solely for scrutineering the election; if not enough Stewards are available, English Misplaced Pages Checkusers may volunteer
  • Option D - 3 English Misplaced Pages CheckUsers who do not otherwise participate in the election process (including no nominating candidate(s), no discussing candidate(s), and no voting)

Q5 Survey (Who will scrutineer)

Q5 Discussion (Who will scrutineer)

Q6: Voter guides (main election page linking to unofficial guides)

For future administrator elections, should Misplaced Pages:Administrator elections link to unofficial voter guides?

Q6 Survey (listing unofficial guides)

  • Option B. Especially in large elections such as the 32-candidate election we just had, voter guides are very useful for helping to gather information on the candidates. Obfuscating a good tool doesn't seem necessary to me. Linking to the category should be sufficient -- we don't need to advertise voter guides more heavily by listing or transcluding them on the actual page. –Novem Linguae (talk) 10:38, 7 January 2025 (UTC)
  • A. Unlike arbitrator elections, the candidates aren't running against each other, there's no set amount of seats to fill, and voting for or against a particular candidate doesn't hurt or help the others. There is no legitimate reason to make voters' scrutiny more difficult by directing them to pages besides the main discussion page, and no reason at all except to game the discussion limits, or perhaps self-aggrandizement on the parts of guide writers. Put your discussion on the candidacy pages where it belongs. —Cryptic 10:41, 7 January 2025 (UTC)
    ACE is actually a 2-prong decision, the first being "is THIS candidate" acceptable for this position at all (just like RFA) -- the secondary component is to fill the limited committee slots with those that have been found to be the most acceptable to others. — xaosflux 12:11, 7 January 2025 (UTC)
    I'd buy that if we had ever, even once, not filled an arbitrator slot. —Cryptic 12:45, 7 January 2025 (UTC)
    @Cryptic, I believe what @Xaosflux is saying is that 2 decisions have to be made in ArbCom Elections; whether you support the candidate and whether the candidate is supportable over the other candidates, because there are a limited number of seats; this is dissimilar to admin elections, where you can theoretically support every candidate. Thus, your statement is somewhat in agreement with his, because you acknowledge how the limited number of seats in Arbitrator elections requires a second decision to be made. JuxtaposedJacob (talk) | :) | he/him | 17:49, 7 January 2025 (UTC)
    That second part is what isn't relevant here because there are unlimited seats, in admin elections, and in ace elections - the first part is the same, "is this person acceptable for this position". — xaosflux 18:29, 7 January 2025 (UTC)
  • Option B. As a voter, getting input on candidates in a neat summary is very helpful. Direct questions/comments/concerns should be on candidate discussion pages, but last time this led to folks dumping all sorts of statistics onto the discussion pages (like AfD stats and declined CSDs), which cluttered things. I don't understand the obsession with suppressing voter guides expressed in previous discussions. Toadspike 11:33, 7 January 2025 (UTC)
  • B - let the community post nice tabulated information for each other and make it easy to find. This also reduces the amount of work duplication I'd have to do to vote intelligently. Tazerdadog (talk) 11:37, 7 January 2025 (UTC)
  • B, and not really a problem if there is a list on a template similar to ACE. Transcluding them all - hard no. — xaosflux 11:40, 7 January 2025 (UTC)
  • A per Cryptic. Voter guides are just about justifiable for ArbCom elections, but they are absolutely not for admin elections. The best guides are neutral, factual and aid doing one's own research about the candidates however the utility of these can be replaced by a standard set of statistics agreed in advance as relevant and compiled for every candidate and so the harm caused by guides that try to influence the way someone votes. Ideally voter guides should be be banned completely but at the very least we should not be promoting or endorsing them in way shape or form. Thryduulf (talk) 12:10, 7 January 2025 (UTC)
  • A per Thryduulf · · · Peter Southwood : 13:17, 7 January 2025 (UTC)
  • B. We shouldn't be making information harder to access for voters who aren't so plugged-in to the whole process that they know of all the voter guides already. But outright oppose C. That's bananas. -- asilvering (talk) 13:52, 7 January 2025 (UTC)
  • B Isn't this website about making info available to people who want it?--Wehwalt (talk) 14:47, 7 January 2025 (UTC)
  • A, the guides are personal opinions. Linking to them, even to a category, gives the air of officialdom and elevates those above the discussions on the actual candidacy pages. CMD (talk) 15:25, 7 January 2025 (UTC)
  • B. Otherwise, we socially force the otherwise-guidemakers into the bureaucracy of laboriously commenting on every single candidate page. I believe it's clear enough that these guides are unofficial, or have the same officiality as those who comment something on every single candidate page. Those who wouldn't do any scrutinizing after reading a voter guide would not scrutinize the candidates in the first place. Aaron Liu (talk) 15:37, 7 January 2025 (UTC)
  • A per Cryptic there is no of seats fill and the candidates aren't running against each other like arbcom.Pharaoh of the Wizards (talk) 16:05, 7 January 2025 (UTC)
  • B: Most elections for any Misplaced Pages position that's voted on as a group contain voter guides. If someone wants to follow the opinion of another, or use that as a starting point, I have no issue with it. Hey man im josh (talk) 16:40, 7 January 2025 (UTC)
  • All/none no preference Buffs (talk) 17:10, 7 January 2025 (UTC)
    You don't have to answer "abstain" to any question. Aaron Liu (talk) 17:14, 7 January 2025 (UTC)
    I practically do too. For me, it means "I want a consensus to be found". When there are 5 people for option A and 6 people for option B, I'd rather see option B implemented than "no consensus" to be found. ~ ToBeFree (talk) 18:55, 7 January 2025 (UTC)
    Hmm, that's interesting. I wonder if that's gonna result in option A here, since it both has quite a bit of votes and is the status quo. Aaron Liu (talk) 02:29, 8 January 2025 (UTC)
  • A. I suspect I am in the minority here, but I don't like us platforming editors' opinions of each other in the way we do. Most authors of most AELECT/ACE guides that I have read have been respectful, but not all have been. The intent of AELECT was to reduce the stress on candidates, and I don't think aggregating guides that offer candidates no right of reply is the way to do that. I have opposed guides for ACE for the same reasons: the stakes are lower here, and the reasons to centralize guides even weaker. If you want to learn the opinions of an editor you respect, just ask them. Vanamonde93 (talk) 17:39, 7 January 2025 (UTC)
  • B per NL. JuxtaposedJacob (talk) | :) | he/him | 17:49, 7 January 2025 (UTC)
  • Option A > B Both are good, I like A better though. fanfanboy (blocktalk) 17:59, 7 January 2025 (UTC)
  • Option A per Vanamode. Platforming unofficial voter guides goes against the spirit of secret balloting. ~~ Jessintime (talk) 18:27, 7 January 2025 (UTC)
    The spirit of a secret ballot is that your vote is unprovable, not that you can't speak about your opinion. — xaosflux 18:30, 7 January 2025 (UTC)
    Misplaced Pages:Administrator_elections#Rationale and Misplaced Pages:Requests_for_adminship/2024_review/Phase_I#Proposal_13:_Admin_elections both suggest that secret balloting was intended to "reduce the opportunity for contentious discussion amongst participants." Platforming election guides undermines that principle. ~~ Jessintime (talk) 18:41, 7 January 2025 (UTC)
  • A per Vanamonde93: If you want to learn the opinions of an editor you respect, just ask them. ~ ToBeFree (talk) 18:58, 7 January 2025 (UTC)
  • B It may just be me, but i often find locating things in the back office, so to speak, of the Project quite difficult; any kind of wlink or pointer to help me find such guides and information as i seek to make a decision is to my benefit, and most likely to others', too ~ Lindsay 20:12, 7 January 2025 (UTC)
  • (Weak) A: there is arguably benefit to the candidates in not doing so, and arguably benefit to the voters in doing so. AELECT is designed to be easier on the candidates, so I think no – but do support no ban on linking from other election pages below. Perfect4th (talk) 20:51, 7 January 2025 (UTC)
  • B to properly educate the voters; C is unnecessary and hard to maintain. (I was elected in AELECT, for disclosure.) charlotte 21:23, 7 January 2025 (UTC)
  • A. And I feel strongly about this one. The idea behind the first trial was that there would be candidates who would prefer not to be publicly dissected, and the results of that trial bore that out. This isn't the same thing as ArbCom elections, and AELECT should be something where it doesn't feel so much like being under a microscope. This process looks like it is a real success, and let's not water it down simply because we might have had a one-off the first time, with so many candidates. --Tryptofish (talk) 22:51, 7 January 2025 (UTC)
  • Option B. If candidates don't want to be scrutinised in public then they should not stand for adminship. Espresso Addict (talk) 22:59, 7 January 2025 (UTC)
  • A. Voter guides are ArbCom elections are extremely difficult to use, centralizing discussion is much better. --JBL (talk) 00:56, 8 January 2025 (UTC)
  • B. this page is hard enough to find itself L3X1 ◊distænt write◊ 01:32, 8 January 2025 (UTC)
  • Option B. I used a number of guides last election and having them in a localized place easily accessed from the page would be the best for convenience. cyberdog958 02:07, 8 January 2025 (UTC)
  • B, oppose A and C Leijurv (talk) 05:46, 8 January 2025 (UTC)
  • Prefer B, okay with A and oppose C. Callanecc (talk • contribs • logs) 06:30, 8 January 2025 (UTC)
  • B. Don't try to hide the guides from people or require them to regurgitate their views in the discussion section. SilverLocust 💬 06:40, 8 January 2025 (UTC)

Q6 Discussion (listing unofficial guides)

Q7: Voter guides (non-main election page linking to unofficial guides)

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

  • Option A - May be linked from any election-related page (such as talk pages, discussion phase pages, etc.)
  • Option B - May not be linked from any election-related page (such as talk pages, discussion phase pages, etc.)

Q7 Survey (linking to unofficial guides)

Q7 Discussion (linking to unofficial guides)

Q8: Voter guides (official guides)

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

  • Option A - No official voter guide shall be produced (current)
  • Option B - An official voter guide shall be produced, containing only a pre-agreed set of factual statistics

Q8 Survey (official guides)

Q8 Discussion (official guides)

  • Meh, either is fine. In the election we've run, i found both the statistics on the candidates' pages useful and the guides a helpful...guide ~ especially the two or three tables of statistics which the creators felt were important; some i agreed with, some i didn't, but still useful in my decision-making process; such things are helpful but not essential ~ Lindsay 20:23, 7 January 2025 (UTC)

Q9: Suffrage requirements

Who may vote in future administrator elections?

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

Q9 Survey (Suffrage requirements)

Q9 Discussion (Suffrage requirements)

I have no strong preference here - both methods seem similarly trivial to game, if that's what we're trying to avoid - but there's plenty of people able and willing to generate the list of eligible voters. I'm one of them. The idea that there's sort of insurmountable technical problem and that we won't ever be able to have elections again if Cyberpower678 stops wanting to do it shouldn't be a factor. —Cryptic 11:01, 7 January 2025 (UTC)

"both methods seem similarly trivial to game" – you might be right, but generally admins are looking for gaming of XCON far more closely than they are looking for gaming of...150 edits in one month. Consistency can be valuable. Toadspike 11:39, 7 January 2025 (UTC)

Q10: Minimum vote requirement (minimum supports)

Should there be a minimum vote requirement to elect a candidate?

  • Option A - no requirement. (current)
  • Option B - require 20 supports minimum to pass
  • Option C - require 50 supports minimum to pass
  • Option D - require 100 supports minimum to pass

Q10 Survey (minimum support requirement)

  • Option A - We had absolutely no problem achieving a reasonable quorum in the last election (the average number of support+opposes per candidate was 385, and the lowest any candidate received was 318). Hypothetically, let's say we had an election where only 20 people participated. Even then, I still think that the support percentage required to pass (currently 70%) would prevent unqualified candidates from getting elected. Therefore I think any quorum requirement just adds unnecessary complexity to the process. –Novem Linguae (talk) 10:53, 7 January 2025 (UTC)
  • Option B There were concerns expressed in the first election of a hypothetical candidate getting through with very few support votes, on the basis of absence of against votes. Personally I think that's unfounded, but to address these concerns a (low) minimum number could be required. --DoubleGrazing (talk) 10:57, 7 January 2025 (UTC)
  • Option D or C, I guess, as a failsafe to ensure genuine consensus; it doesn't add complexity when it's not an issue. (No RfA candidate has passed with fewer than 100 supports since the WP:RFA2015 reforms, and the last one with fewer than 50 was in 2011.) But I agree this will probably never be a problem. Extraordinary Writ (talk) 10:59, 7 January 2025 (UTC)
  • Option D or C - Just because it is very unlikely happen to allow someone to become an admin on a technicality if for some reason it did every happen. As it should never happen, the sensible thing is to make sure it it did we have a safety guard. As a programmer I can say that I have seen a lot of bugs caused by 'that should never happen' logic. KylieTastic (talk) 11:22, 7 January 2025 (UTC)
  • Option A I believe the hypothetical concerns are unfounded and it's exactly the kind of "just in case" policy carve outs that lead to extreme bureaucracy and scope creep. Every single additional clause to complicated processes make things marginally worse, and I am strongly against the kind of precedent that assuages every "this will never happen" concern with changing our policies. In the 0.1% of universes this happens, we still have a process to deal with it, it's called WP:IAR. Soni (talk) 11:28, 7 January 2025 (UTC)
  • Option C or D per KylieTastic. I hate bureaucracy as much as the next guy, but I don't see IAR as a good failsafe. 100 is a fairly high bar, though, so I prefer a lower one. Toadspike 11:43, 7 January 2025 (UTC)
  • B>C>D>A. There should be some requirement. — xaosflux 11:47, 7 January 2025 (UTC)
  • A per NL - poor attendance of an election shouldn't affect pass rate. B second choice. Tazerdadog (talk) 11:50, 7 January 2025 (UTC)
  • Option A No need to create rules when there is not a problem. Misplaced Pages is overly complicated as is. —Femke 🐦 (talk) 12:07, 7 January 2025 (UTC)
  • A > B > C > D. If you think a candidate should not be an administrator, oppose them, if it looks like there will be few votes then get people to vote. There is no support threshold at RFA and candidates becoming admins with very few supports has never been an issue (and what counts as "very few" has changed considerably across the lifetime of the project) so it isn't going to be an issue at AELECT. If we do have to have a bar, it should be as low as possible. Thryduulf (talk) 12:21, 7 January 2025 (UTC)
  • A At this time it's not needed. At some future point election become so mundane that fewer and fewer editors take part, and the something like this could be needed, but at this time I don't think it's needed. -- LCU ActivelyDisinterested «@» °∆t° 12:40, 7 January 2025 (UTC)
  • B per Xaosflux. Potentially getting in with a single support and nothing else seems a bit sub-optimum. · · · Peter Southwood : 13:33, 7 January 2025 (UTC)
  • A. Er, do we really want to sysop someone who only had 20 supports? What problem would this threshold actually solve? If there's grumbling about an elected candidate not having received enough support, let's grumble about it in the future, with whatever future standards we want to apply, rather than saying "well, back in 2025, we decided on this number, and so..." -- asilvering (talk) 14:05, 7 January 2025 (UTC)
  • A If voting interest drops off then reconsider.--Wehwalt (talk) 14:53, 7 January 2025 (UTC)
  • Weak A, we just don't have data to evaluate this, and it is hard to pinpoint which plausible hypotheticals this might be based around. CMD (talk) 15:33, 7 January 2025 (UTC)
  • A per Novem Linguae average support+opposes per candidate was 385, and the lowest any candidate received was 318 .So far no issue with participation.Pharaoh of the Wizards (talk) 16:22, 7 January 2025 (UTC)
  • A: Realistically all of these will be passed, and I found it rather silly that folks suggested the option B threshold wouldn't be met at any point during the original elections. Hey man im josh (talk) 16:44, 7 January 2025 (UTC)
  • A * Pppery * it has begun... 17:01, 7 January 2025 (UTC)
  • A. On the face of it I'd support 50 or even a 100, but until quorum is shown to be a problem we don't need more rules - and if quorum is a problem, there are going to be deeper issues occurring that this won't fix. Vanamonde93 (talk) 17:39, 7 January 2025 (UTC) After further thought, C or D. I don't foresee this being a problem, but unlike several other forward-looking proposals here, I see no cost to implementing this now and it could prove to be a useful backstop. Many of us reasonably believe the first AELECT is likely to be an outlier. An election with 200 voters is easily imaginable, and if there's a high abstention rate we could easily get down to numbers below what we are comfortable with. Vanamonde93 (talk) 19:10, 7 January 2025 (UTC)
  • B Let's plan for the future. I don't think voting interest will drop off too terribly much, but even if it does, 20 is still very achievable. I also don't want an admin winning on 2 support votes out of 3 votes. JuxtaposedJacob (talk) | :) | he/him | 17:58, 7 January 2025 (UTC)
  • Option A No need to complicate things further. fanfanboy (blocktalk) 18:09, 7 January 2025 (UTC)
  • A is fine, the other options are fine too. ~ ToBeFree (talk) 19:07, 7 January 2025 (UTC)
  • Doubt this will be an issue but was raised as a concern by several people, so C. Not really opposed to anything else though. Perfect4th (talk) 20:52, 7 January 2025 (UTC)
  • A per Novem. (I was elected in AELECT, for disclosure.) charlotte 21:26, 7 January 2025 (UTC)
  • C. On other questions, I'm reluctant to change anything based on what happened the first time, but here, I'm a little reluctant to assume that we will continue to get as many voters in the future. And, in either case, it should be an easy thing to get at least 50 supports. --Tryptofish (talk) 23:02, 7 January 2025 (UTC)
  • C > D > B, oppose A. I don't think we should assume that voters will come in their droves once this is happening frequently. Espresso Addict (talk) 23:14, 7 January 2025 (UTC)
  • A: all the others are solving a problem that we don't have and probably never will have. --JBL (talk) 00:56, 8 January 2025 (UTC)
  • Option B. Its unlikely to even matter as it wasn't even close last time, but this should be just the bare minimum of supporters. cyberdog958 02:18, 8 January 2025 (UTC)
  • A - if this becomes a real problem in the future, it can be dealt with then. For now, no artificial threshold. —Ganesha811 (talk) 02:23, 8 January 2025 (UTC)
  • B or C - I can see the value in having some sort of minimum safeguard against some sort of gaming of the system whereby someone otherwise slips through the cracks (ie say there are non-official voting guides), and everybody has no consensus on this person (eg nothing good nor bad to say), and so people !vote an abstain. We did see a spread of 122 to 293 abtains depending on the individual. This would be cheap insurance. I would propose that the result would then be no-consensus and they would be able to run this or the traditional RfA without prejudice. TiggerJay (talk) 05:46, 8 January 2025 (UTC)
  • A (or as low as possible). No need to add an additional consideration Leijurv (talk) 05:52, 8 January 2025 (UTC)
  • C then B. While I agree that this is unlikely to be an issue there's no cost to having a minimum just in case. A 50 minimum would require around 72 editors (assuming the 70% support percentage stays) to participate in the election which seems to be a reasonable number. Callanecc (talk • contribs • logs) 06:40, 8 January 2025 (UTC)
  • A Solution in search of a problem. JJPMaster (she/they) 12:50, 8 January 2025 (UTC)

Q10 Discussion (minimum support requirement)

  • I'd be interested to hear from any passing bureaucrats whether they'd +sysop someone who got (let's make this concrete) five support votes and no opposes, if we don't decide on an explicit threshold here. —Cryptic 13:39, 7 January 2025 (UTC)
    Now you mention that, I recollect that the WMF have a policy about who can hold certain user rights, which requires some community discussing in which a minimum number of people (20?) need to have participated (not necessarily that many supporters, that may participants). However I can't remember whether this is about adminship (it would be the wp:viewdeleted right if so) or checkuser/oversight access and I've completely failed to find it when searching. Thryduulf (talk) 14:12, 7 January 2025 (UTC)
  • We can't predict voter turnout. Last time we had 600-ish, but what if a future election only gets, say, 120? Option D would then impose an additional pass threshold, in addition to the required %. (And if there were only 87 voters, then under option D no candidate would pass, even with 100% support!) --DoubleGrazing (talk) 14:08, 7 January 2025 (UTC)

Q11: Minimum vote requirement (minimum supports and abstentions)

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

  • Option A: No (current)
  • Option B: Yes

Q11 Survey (minimum support/abstention requirement)

Q11 Discussion (minimum support/abstention requirement)

Q12: Call for Candidates phase duration (when signups open)

When should candidates sign up to stand in an election?

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

Q12 Survey (when signups open)

  • Option A - Worked fine in the last election. The advantage of a sign up window over option B is that 1) it prevents folks from signing up and then being inactive at the time of the election, and 2) it reduces the amount of time the candidacy is public (reducing candidate stress). If one of the RFCs above about only having X candidates per election passes, and if we get into a situation where there are too many candidates, it will be especially important to not have inactive candidates on the list. –Novem Linguae (talk) 11:01, 7 January 2025 (UTC)
  • B seems harmless. Option A is manifestly unfair if any of the choices involving sign-up order in Q3 are selected - who gets to run would depend on when the sign-up period starts. Even changing the start of the candidacy phase as in Q14C doesn't fix this; if the one or two times in a year it opens at a reasonable time in your time zone happens to be during your busiest season at work, you're still out of luck. —Cryptic 11:08, 7 January 2025 (UTC)
    While mostly true, I think an argument could be made like "it's not unfair, it just favors those who really want it". Which includes signing up during a lunch break, staying up late for signing up or whatever. And if it increases the perceived value of making it, that could be positive too. ~ ToBeFree (talk) 19:12, 7 January 2025 (UTC)
  • A or no consensus. I think A is reasonable and worked fine. Alternatively, I'm happy if we bunt this entire question to a future "NON RFC" discussion. Cryptic raises valid points, but I would rather also not hedge my !vote against every outcome this mega-RFC might cause. If we choose something where timing is important, I think a simple discussion is sufficient to change the status quo. Soni (talk) 11:31, 7 January 2025 (UTC)
  • Weak A. I agree with Cryptic that a fixed sign-up time with limited spots could be unfair, but if places are scarce we should add more elections or more spots regardless of the sign-up system. — Preceding unsigned comment added by Toadspike (talk • contribs)
  • Procedural A as a formal deadline, to ensure candidates are actually active during the process. That said, I don't think this is a prohibition on informal expressions of interest earlier, and might flex as the process develops anyway. CMD (talk) 15:38, 7 January 2025 (UTC)
  • Option A worked fine last time.Pharaoh of the Wizards (talk) 16:26, 7 January 2025 (UTC)
  • A I know that some now-RFA'd candidates missed the window for signups, but I think the arguments made by NL outweigh these concerns. JuxtaposedJacob (talk) | :) | he/him | 18:03, 7 January 2025 (UTC)
  • Option A The simplest option. Worked just fine. fanfanboy (blocktalk) 18:13, 7 January 2025 (UTC)
  • Option B: open signup is the simplest approach for potential candidates, thus reducing barriers to running. Not having a nomination period also avoids a landrush phase at the start. I feel this is worth some additional co-ordination effort to confirm with candidates that they are going through with their candidacy. isaacl (talk) 18:23, 7 January 2025 (UTC)
  • A is fine, B is fine too. ~ ToBeFree (talk) 19:09, 7 January 2025 (UTC)
  • A per Novem. (I was elected in AELECT, for disclosure.) charlotte 21:27, 7 January 2025 (UTC)
  • I'm neutral between A and B. If B, candidates who sign up early should reconfirm their availability. A reduces the prolonged scrutiny, which is good, but B is more flexible, which is also good. I also think this issue depends on whether or not we limit the number of candidates allowed: if there's a numerical limit, then A would be better. --Tryptofish (talk) 23:08, 7 January 2025 (UTC)
  • Option A, weakly, to ensure candidates are available during the election period. Not opposed to B, as long as candidates are contacted to reiterate their interest. Espresso Addict (talk) 23:22, 7 January 2025 (UTC)
  • Per Soni and Cryptic, the right answer to this question depends on the answers to other questions. --JBL (talk) 00:56, 8 January 2025 (UTC)
  • Option A. Having a open call for candidates can mean those who apply early are put under more scrutinity than someone who comes in just before the bell just due to being exposed for a longer period of time. Having it be within a standard window will reduce this as much as possible. cyberdog958 02:27, 8 January 2025 (UTC)
  • A I think that any active editor should be able to monitor and sign up at the appropriate time. Furthermore, if we permitted B, then it would certainly setup a system where we might have too many people up for election making it unweidly, which then would change my answers to a few questions above.
  • A per Novem Linguae and Toadspike. Callanecc (talk • contribs • logs) 06:43, 8 January 2025 (UTC)

Q12 Discussion (when signups open)

Q13: Call for Candidates phase duration (what future elections can be signed up for)

If Q12 option B (open sign up) is chosen, for which elections should nominations be accepted?

  • Option A: Only the next scheduled election (current)
  • Option B: The next scheduled election and the election after that
  • Option C: The next scheduled election and the following two elections
  • Option D: For any future election.

Q13 Survey (what future elections can be signed up for)

Q13 Discussion (what future elections can be signed up for)

Q14: Call for Candidates phase duration (time of day to open)

If Q12 option A (a nomination window) is chosen, at what time of day should it open?

  • Option A: Not important. Pick a time for that particular election in advance, and stick to it. (current)
  • Option B: The window should always open at the same time (e.g. 00:00 UTC)
  • Option C: The window should open at a different time of day each election (e.g. move forward 6 hours).

Q14 Survey (when call for candidates open)

Q14 Discussion (when call for candidates open)

Q15: Candidate ordering

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

  • Option A: Chronological by signup date on call for candidates page, random in SecurePoll (current)
  • Option B: Chronological by signup date
  • Option C: Random
  • Option D: Alphabetical

Q15 Survey (candidate ordering)

Q15 Discussion (candidate ordering)

Q16: Discussion phase length (length in days)

How long should the discussion phase be?

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

Q16 Survey (Discussion phase length)

  • E2, F, or G. Ending "official" discussion while voting is still open is stupid, thinking discussion ends just because we say it's officially ended is gullible, and making it harder for other voters to find that discussion means we're making worse choices. —Cryptic 11:11, 7 January 2025 (UTC)
  • Option A - I might end up in the minority on this one, but I think having a short discussion phase is one of the many ways that administrator elections reduced scrutiny and stress for candidates. I would argue that these ways of reducing scrutiny and stress for candidates is the "secret sauce" that makes AELECT work so well, making it a much less stressful/toxic process than RFA. If we start making changes that shine more of a spotlight on candidates, we'll be moving the slider back in the direction of RFA and messing with the "secret sauce". The last election was regarded as very successful, so in this case, I think it'd be safe to say "if it ain't broke, don't fix it". We should be careful of making changes to AELECT that just slowly turns AELECT into RFA. RFA has major flaws, and AELECT's uniqueness fixes a lot of these RFA flaws. –Novem Linguae (talk) 11:13, 7 January 2025 (UTC)
  • Option A per NL. We should be attempting to make RFA more like AELECT, not the other way round. I think having it concurrent to voting has some benefits so also okay with Option E2. But generally prefer shorter discussion periods over longer. Soni (talk) 11:36, 7 January 2025 (UTC)
  • Option A or E2 per Novem Linguae and Soni. I would prefer a longer discussion phase, but I realize that this is extremely discouraging to candidates and could defeat the purpose of admin elections. Keeping discussion open during voting seems sensible, though, so maybe that's a good compromise? Toadspike 11:56, 7 January 2025 (UTC)
  • E>E2 ; there is massively more time spent on this by voters than candidates, they should be afforded enough time to engage. — xaosflux 12:01, 7 January 2025 (UTC)
  • Option A --C1K98V 12:07, 7 January 2025 (UTC)
  • Strongly oppose A and C. I'm not really bothered about the exact length, provided it isn't fewer than seven days long. I understand the desire to make AELECT less stressful, but it should never come at the expense of candidate scrutiny. Having a smaller discussion period to relieve pressure on candidates is the wrong approach. Giraffer (talk) 12:34, 7 January 2025 (UTC)
  • C > A > E. I think there are significant benefits to having discussion before voting, as this makes it more likely for WP:NOTNOW candidates to realise this applies to them and gives them time to withdraw before they get disheartened by a huge no vote. I do agree that we should keep the discussion period short to avoid the elections becoming more like RFA, but there does need to be a balance between this and scrutiny and I think 5 days will be a better balance than 3, but 3 days is better than 7. Thryduulf (talk) 12:43, 7 January 2025 (UTC)
  • C> A > ughhhh fine E2. Oppose all others. The elections process is already long. People have all the time between candidates officially choosing to run and the discussion window opening to do additional scrutiny. -- asilvering (talk) 14:12, 7 January 2025 (UTC)
  • This is a bit of a messy set of options, muddling up questions about whether to end discussions, whether discussions and voting should be concurrent, the time limit of discussions, and the time limit of voting. E2, F, or G, I suppose, per Cryptic, but I don't think this is a clear enough question to produce a strong result here. CMD (talk) 15:53, 7 January 2025 (UTC)
  • F > E2 The current system's incredible short discussion phase combined with the lack of activity on most candidate pages due to the number of candidates meant that someone could drop a bunch of misleading statistics (assuming good faith) or false accusations (assuming bad faith) on a discussion page at the last minute and there would be no way to rebut it or provide context that most editors would see. It also just pushes discussions to talk pages and other places where, again, most voters won't see it. There's no reason to artificially close off discussion during the voting phase, but 14 days total of discussion is way too long. Slight preference for F over E2 as some time before voting begins would help with WP:NOTNOW cases. --Ahecht (TALK
    PAGE    ) 16:15, 7 January 2025 (UTC)
  • Option A per Novem Linguae "if it ain't broke, don't fix it".Further long periods of discussion will make it stressful like RFA. Pharaoh of the Wizards (talk) 16:44, 7 January 2025 (UTC)
  • Option C: 3 days felt too short last time, but 7 days also feels too long. C is a good middle ground. Hey man im josh (talk) 16:46, 7 January 2025 (UTC)
  • F, second choice E2 I don't see any good reason to shut down discussion during voting, and at the same time see some value in having some discussion before the voting period so early voters have something to base their opinions off of. * Pppery * it has begun... 17:08, 7 January 2025 (UTC)
  • Option C > E > A. Oppose other options. I don't like the idea of overlaps. fanfanboy (blocktalk) 18:18, 7 January 2025 (UTC)
  • As short as possible. The longer the "discussion" (read: people voting publicly while avoiding making the impression of doing so) is, the more it becomes like RfA. ~ ToBeFree (talk) 19:19, 7 January 2025 (UTC)
  • Option C or option A, opposed to E2, F, & G as they could create more stress for candidates. Perfect4th (talk) 21:03, 7 January 2025 (UTC)
  • A per Novem. (I was elected in AELECT, for disclosure.) charlotte 21:35, 7 January 2025 (UTC)
  • C per Hey man im josh. The discussion period last time really rushed by, and with multiple candidates at once, I do think it damages our ability to do proper scrutiny. Cremastra (u — c) 21:39, 7 January 2025 (UTC)
  • C. 3 days was too short in the first run, and 5 should be enough. I'm against having it continue once the voting phase begins, because the selling point of this new system is that candidates can "tune out" once the process moves from discussion to voting, and that's a good thing that I want to preserve. --Tryptofish (talk) 23:16, 7 January 2025 (UTC)
  • F. I think there are significant advantages to discussion continuing during voting. Oppose A, C: there needs to be at least a week's discussion phase to allow calendar-limited editors to participate (there are plenty who only edit at weekends, or only during the week). Espresso Addict (talk) 23:41, 7 January 2025 (UTC)
  • Option C per Hey man im josh. cyberdog958 02:47, 8 January 2025 (UTC)
  • A I think there is a benefit to having discussions wrapped up in a timely manner before anyone can actually vote, helping ensure that people have the chance to vote with a more comprehensive discussion, versus voting and then discussion continuing, and then striking, etc. TiggerJay (talk) 05:58, 8 January 2025 (UTC)
  • A ~ C > E2. I'm fine with modestly extending it, but I'd like to keep a shortened intrusion upon candidates' tranquility. SilverLocust 💬 06:40, 8 January 2025 (UTC)
  • F then C. 7 days of discussion seems excessive if it's not overlapping with the voting but 3 days without overlap seems too short. Callanecc (talk • contribs • logs) 06:50, 8 January 2025 (UTC)

Q16 Discussion (Discussion phase length)

Q17: Discussion phase length (overlap with voting phase)

If Q16 options F or G are chosen, shall formal questions and answers on candidate pages continue during the voting phase?

  • Option A – No (current)
  • Option B – Yes, additional formal questions and answers are permitted.
  • Option C – Further questions may be permitted but candidates are not obliged to answer them.

Q17 Survey (Discussion phase overlap)

Q17 Discussion (Discussion phase overlap)

Q18: Supervising the election

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

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

Q18 Survey (Supervising the election)

Q18 Discussion (Supervising the election)

  • Electoral commission currently links to Hyperlink. It would be better if the proposal specified how the commission would be chosen. Extraordinary Writ (talk) 11:07, 7 January 2025 (UTC)
    I assume that was deliberate, since there currently is no electoral commission. But if not, @Novem Linguae, you wanna fix that? Toadspike 12:01, 7 January 2025 (UTC)
    Thanks for checking. Yes, it was intentional. Just now I went ahead and changed it to a red link so it's less confusing. –Novem Linguae (talk) 12:11, 7 January 2025 (UTC)
  • I probably won't post in the survey section of this question since my name is in it. When the AELECT proposal by Worm That Turned was created, he envisioned the bureaucrats being heavily involved in the process, since bureaucrats are heavily involved in the RFA process. Seems like their wheelhouse. However, in practice, the bureaucrats were not really involved, and I ended up doing most of the AELECT backend work. This question was added by me as a way of asking the community what direction we should go in with listing who administrates the AELECT process and how they administrate it. The idea of an "electoral commission" comes from the WP:ACE process and is one possible term we could use to call the folks that do the backend work of AELECT. –Novem Linguae (talk) 11:19, 7 January 2025 (UTC)
    Note the arbitration committee electoral commission was not created to do the backend work: it was created to make expedient decisions that, given the deadlines of the process, couldn't wait to be resolved by community consensus. There isn't a pressing deadline with admin elections, though, since even if an election can't be held as scheduled, there are many current admins who can continue to do the day-to-day work on Misplaced Pages. isaacl (talk) 18:41, 7 January 2025 (UTC)

Q19: Participating in administrator elections multiple times

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

  • Option A: Yes (current)
  • Option B: Yes, but not the immediately following one
  • Option C: Yes, but there should be a limit to the number of times a candidate can run
  • Option D: No, any future requests for adminship must go through standard RFA.
  • Option E: Yes, but not if they have run either in an election or in a standard RFA in the last 3 months.

Q19 Survey (Participating in multiple elections)

  • Option D, followed by B/C, per what I said on Q1: "the elections process is a great way to streamline the process for uncontroversial candidates, but serious opposing arguments deserve to be hashed out through the consensus process". If a candidate has been previously voted down, then there are serious opposing arguments that are best dealt with at RfA. Extraordinary Writ (talk) 11:09, 7 January 2025 (UTC)
    This vote seems to come from an inherent assumption that RFA is somehow more robust than AELECT, or that the process in it is sacrosanct for "serious arguments". I just want to say I reject that assertion. Soni (talk) 11:40, 7 January 2025 (UTC)
    RfA is far more robust than AELECT. The former has been tested, analyzed, and tweaked for over twenty years, while the latter was created a year ago, with the details largely hashed out by rough agreement (not formal consensus) among ~10 people, and has only been run once. Giraffer (talk) 12:27, 7 January 2025 (UTC)
  • Option A - There is likely to be a huge time gap between elections. Also, people repeatedly running isn't a problem at RFA, so I think it's unlikely to be a problem at AELECT. If it becomes a problem, we could look into having the community topic ban a person from AELECT via ANI, the same way we would probably handle someone making too many RFAs. –Novem Linguae (talk) 11:23, 7 January 2025 (UTC)
  • Option A per NL. It feels like a solution in search of a problem - There's no need to pre-emptively complicate the process chasing hypotheticals. Soni (talk) 11:39, 7 January 2025 (UTC)
  • Not B or E. Someone running twice in a row is already not going to pass, if for no other reason than "'Optional' question Q4: Dude, you just ran three months ago and got 19% of the vote. Why on earth do you think you're going to do better this time?" Putting a hard minimum time limit on recandidacy is going to falsely imply to the candidates that all is forgiven and they're welcome to rerun as soon as the time is up, and to the voters that any recandidacy remotely near that hard time limit - whether it's three months or three years - is obviously too soon. —Cryptic 11:40, 7 January 2025 (UTC)
  • Option E. --C1K98V 11:51, 7 January 2025 (UTC)
  • Option A per Novem Linguae and Cryptic. Toadspike 12:10, 7 January 2025 (UTC)
    In the last elections, some candidates only failed narrowly with no clear reason. They have appropriately been urged to run again. Point is, we shouldn't default to branding those who don't pass as incompetent fools and ban them from ever running again. Toadspike 12:14, 7 January 2025 (UTC)
  • A > B > E. Discouraging perennial candidates should be done socially or by specific individual editing restrictions in extreme cases. Q3 already reduces the impact these candidates will have on others. Thryduulf (talk) 12:51, 7 January 2025 (UTC)
  • A Seems fairest to me. I don't think people should be penalized for failed candidacies by having options closed off.--Wehwalt (talk) 14:58, 7 January 2025 (UTC)
  • Lean B or E, but fear Cryptic may have gone through the same thought process to come out with exactly the opposite conclusion with reasonable justification. CMD (talk) 16:00, 7 January 2025 (UTC)
  • Also lean B or E, but the more I think about it the more I think a 1 year "cooldown period" would be more helpful. What's the shortest time in recent memory that a candidate has gone from failing an RfA to passing? --Ahecht (TALK
    PAGE    ) 16:19, 7 January 2025 (UTC)
    @Ahecht: I didn't check RfA to be certain but the most recent I remember is Theleekycauldron at roughly 18 months (Jan '22, Aug '23). Perfect4th (talk) 21:08, 7 January 2025 (UTC)
  • A: I don't see a valid reason to say no. I also don't think we should be concerned that people are going to spam elections unless we start doing them with a very high level of regularity. Hey man im josh (talk) 16:47, 7 January 2025 (UTC)
  • Option A per Novem Linguae and Cryptic. Further there is no limit in RFA also.Pharaoh of the Wizards (talk) 16:53, 7 January 2025 (UTC)
  • A Unclear what problem this is solving. * Pppery * it has begun... 17:09, 7 January 2025 (UTC)
  • B. Assuming we're capping the number of candidates, it would be unfair if the same editors kept running again and again. ~~ Jessintime (talk) 17:52, 7 January 2025 (UTC)
  • D because I think any serious opposition should be able to be hashed out via RFA, while any abstract time requirements are unnecessary. JuxtaposedJacob (talk) | :) | he/him | 18:20, 7 January 2025 (UTC)
  • Option A > B > E. Oppose D Candidates should be allowed to choose what process they want to go through. fanfanboy (blocktalk) 18:27, 7 January 2025 (UTC)
  • Option A: Until more experience is gained from more elections, I don't think a formal maximum limit is needed. isaacl (talk) 18:46, 7 January 2025 (UTC)
  • Anything except C or D, which would make people afraid of running too early while they should be encouraged to run earlier than they thought they'd be elected. ~ ToBeFree (talk) 19:25, 7 January 2025 (UTC)
  • A, second choice B or E, per ToBeFree. Perfect4th (talk) 21:08, 7 January 2025 (UTC)
  • A per Novem and Soni. (I was elected in AELECT, for disclosure.) charlotte 21:38, 7 January 2025 (UTC)
  • E, without objection to the other choices, except that I strongly oppose D. Basically, I think unsuccessful candidates should be able to run again, after they have learned from the feedback, without being mandated to switch to traditional RfA. I also think it's reasonable to set some amount of time before a re-run, but it doesn't have to be a long time. E comes to closest to covering all those considerations. I also support the caveat by MarcGarver in the discussion section below. --Tryptofish (talk) 23:28, 7 January 2025 (UTC)
  • B, C, E. I don't think frequent repeated runs should be encouraged, especially if slots are limited, but I don't think a single unsuccessful run should mandate going through the RfA process. Espresso Addict (talk) 23:53, 7 January 2025 (UTC)
  • A or E. --JBL (talk) 00:56, 8 January 2025 (UTC)
  • A This one took some thought, but I think it's fine to let people run again right away for now. If it becomes a problem, it can be changed later. —Ganesha811 (talk) 02:26, 8 January 2025 (UTC)
  • Option B. Ideally, I think it should be a combination of options B, C, and D. A candidate should be able to run, but if they do not pass, they should have to wait at least one cycle to gain more experience. There should be an upper limit of how may elections they are able to go through, and if they pass that limit without being elected, they should have to go through a regular RfA. This could hold candidates accountable to gain enough experience before reapplying, and it would reduce the chances of perennial candidates. cyberdog958 03:11, 8 January 2025 (UTC)
  • A as we don't currently have a problem and do not expect their to be one. There will always be a few people who says hey, I'll give it a try, what's the worst that can happen and they'll get shot down and then if they're actual constructive contributors, know what they need to work on and should be given the opportunity at a second chance at it. There will also be those who run 5 times in a row, but my guess is those people are already NOTHERE, and will be blocked for other disruptive reasons before they get too many shots at more than 2 or 3 election processes. TiggerJay (talk) 06:06, 8 January 2025 (UTC)
  • A per Novem Linguae. Oppose options with timelimits per Cryptic. Callanecc (talk • contribs • logs) 07:02, 8 January 2025 (UTC)

Q19 Discussion (Participating in multiple elections)

Q20: Election frequency (how often)

Ideally, how often should administrator elections be held?

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

Q20 Survey (Election frequency)

  • B sounds about right to me, but ultimately we just need to pick something and re-evaluate it down the line once we see how many candidates we're consistently getting. Extraordinary Writ (talk) 11:19, 7 January 2025 (UTC)
  • Option B sounds about right. Also fine with Option A or Option C. One month or two months is probably too often -- there's a lot of work on the back end that goes into each election. I purposely worded this question as "ideally", because we want to keep flexibility here. This will be very dependent on how many candidates we are consistently getting, who ends up scrutineering and what their bandwidth is, other bus factors such as the bandwidth of myself and Cyberpower678 (voter roll generation), and if WMF green lights local SecurePoll elections that aren't dependent on votewiki / WMF Trust & Safety. –Novem Linguae (talk) 11:28, 7 January 2025 (UTC)
  • Option C --C1K98V 11:55, 7 January 2025 (UTC)
  • B>A. Would consider C if we do away with traditional RFA. — xaosflux 12:03, 7 January 2025 (UTC)
  • C > B > A. These need to be frequent enough that we don't overload voters with too many candidates, and to produce more new admins. Toadspike 12:17, 7 January 2025 (UTC)
  • Option A. Elections take up a lot of editor time, and holding two per year seems excessive when we don't have an accurate judge of the long-term demand for the process yet. The global election calendar is already pretty saturated (ArbCom, Board of Trustees, Steward, U4C) and we are at real risk of election fatigue, so I don't think starting with every six months is the right way to go. Giraffer (talk) 12:20, 7 January 2025 (UTC)
  • C > B > A per Toadspike. More frequently would be too disruptive to the community, less frequently disadvantages candidates who have real life commitments at a given time of year (e.g. due to seasonality of their job) if that coincides with when the elections are held. Thryduulf (talk) 12:54, 7 January 2025 (UTC)
  • As frequently as possible If they could be monthly that would be a boon, and if possible at least every 3 months. This is so dependent on editors time and the amount of signups that I wonder if it should be irregular dependant on those factors, but to start with at least it should be as often as possible. That will allow any pent up demand to pass, boost admin numbers, and further shake out any potential issues with the process. -- LCU ActivelyDisinterested «@» °∆t° 12:58, 7 January 2025 (UTC)
  • C > B > A, without prejudice to future modifications. It looks like the proposal to add a maximum # of candidates is not going to pass. It seems like three months will keep the number of applications manageable while not creating excessive workload. But until future elections are ran, I cannot verify this assumption. Ca 14:13, 7 January 2025 (UTC)
  • B Yearly sounds a little too infrequent.--Wehwalt (talk) 14:59, 7 January 2025 (UTC)
  • C, but as an initial choice that could be reconsidered if it seems insufficient (or too frequent I suppose). CMD (talk) 16:02, 7 January 2025 (UTC)
  • B-D. Every year feels not enough, every month feels too much. B or C feels just right... -Kj cheetham (talk) 16:21, 7 January 2025 (UTC)
  • B > C > A The requires a bit of crystal-ball gazing as to the number of candidates we'd have in future elections, but somewhere between quarterly and semi-annually sounds about right. --Ahecht (TALK
    PAGE    ) 16:22, 7 January 2025 (UTC)
  • B: Yearly is too infrequent and every 3 months is too frequent. Every 6 months is the goldilocks options. Hey man im josh (talk) 16:51, 7 January 2025 (UTC)
  • Option Bper Hey man im josh. Yearly is too infrequent and every 3 months is too frequent.Pharaoh of the Wizards (talk) 16:55, 7 January 2025 (UTC)
  • Every 4 months (B/C > C > B). I think we can keep the strenght of numbers if we do it every 3 month or less frequently. Capacity to organise might be more of a constraining factor, so every 4 months is probably easier. At once every 6 months, I think we'll be missing candidates. For instance, assuming one doesn't want to go for old-school RfA, and is busy for two election cycles, that would mean we miss out on a potential admin for a year. By which time they may no longer be interested. —Femke 🐦 (talk) 17:22, 7 January 2025 (UTC)
  • B: every six months feels about right – not so frequent that it would cause voter fatigue, or put an excessive burden on those running the scheme (I'm assuming?); but frequent enough that no candidate would have to wait a year for the next election to come around. (That said, this question doesn't exist in isolation, it links to candidate numbers per election, and other factors, which are as-yet undecided.) --DoubleGrazing (talk) 18:02, 7 January 2025 (UTC)
  • B per NL, with his same openness to A and C. JuxtaposedJacob (talk) | :) | he/him | 18:21, 7 January 2025 (UTC)
  • Option B > C > A There shouldn't be a too short or too long time between elections fanfanboy (blocktalk) 18:29, 7 January 2025 (UTC)
  • Option E > D > C: I prefer running elections frequently on a regular cadence. This reduces their "special event" nature and makes them just another regular occurrence, which I think will encourage more people to help out in a sustainable manner, either as a candidate, a volunteer to support elections, or a voter. isaacl (talk) 18:55, 7 January 2025 (UTC)
  • A and B are fine, C is acceptable if no scrutineers are needed, D and E are impractical. ~ ToBeFree (talk) 19:28, 7 January 2025 (UTC)
  • B > A > C; D and E would be too frequent. Perfect4th (talk) 21:09, 7 January 2025 (UTC)
  • I agree with ActivelyDisinterested; as frequent as is practical. (I was elected in AELECT, for disclosure.) charlotte 21:40, 7 January 2025 (UTC)
  • B six monnths is the perfect time period for someone to watch one AELECT and then prepare for the next one. Cremastra (u — c) 21:43, 7 January 2025 (UTC)
  • B as first choice, C as second choice. I feel like having it every month would be too much, and only once a year not enough. --Tryptofish (talk) 23:31, 7 January 2025 (UTC)
  • B or C. Not opposed to A but would hope there would be more demand than that. Espresso Addict (talk) 23:57, 7 January 2025 (UTC)
  • C or B or some number in between like 4 or 5 months. --JBL (talk) 00:56, 8 January 2025 (UTC)
  • C, but B or something in between (4-5 months) would be perfectly acceptable. A 5-month schedule would also drift in terms of seasonality, which could be a benefit. — Preceding unsigned comment added by Ganesha811 (talk • contribs)
  • Option B > C. Once the process is streamlined, the set-up won't take as long as the first time. Every 3-6 months seems ideal to reduce voter fatigue. cyberdog958 03:15, 8 January 2025 (UTC)
  • C to start and then adjust as needed based on the backlogs and active admin counts. There is no reason why we need to be locked into a specific cycle here, but instead the election committee with direction from community consensus can determine several thresholds that are used to help gauge how we're doing with our admin recruiting efforts, and if we need more admins perhaps run an election sooner, but on the other hand if they backlogs were mostly cleared, and we have a healthy number of admins, perhaps we can wait 5-7 months until the next one. TiggerJay (talk) 06:09, 8 January 2025 (UTC)
  • C, but I'd prefer to make it vary based on how many ran last time. If there's a maximum number of candidates per election, and the max was reached, then there should be another election called 1-2 months later. If there's <50%, wait 4-6 months. SilverLocust 💬 06:40, 8 January 2025 (UTC)
  • C or B but this should be easy to change with a discussion if there's a maximum and a lot of candidates missed out. I'm also okay with doing it every 6/7 months or similar. Callanecc (talk • contribs • logs) 07:05, 8 January 2025 (UTC)

Q20 Discussion (Election frequency)

  • If it's to be only once or twice a year, could we please not have it be the same times every year? A lot of peoples' availability varies fairly consistently year-to-year; if the only times elections are held are when you're always the busiest, then you're locked out of them forever. —Cryptic 12:10, 7 January 2025 (UTC)
    Or they could be held in cycles not tied down to a year, like every nine months. Giraffer (talk) 12:21, 7 January 2025 (UTC)
    Or an interval that shifts to a different month and season every year, like 7 months. · · · Peter Southwood : 12:56, 7 January 2025 (UTC)

Q21: Election frequency (relationship with number of candidates)

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

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

Q21 Survey (Election frequency - when to run)

Q21 Discussion (Election frequency - when to run)

  • During the workshop phase it was brought about that some people may only wish to run as part of a large group. However, everybody's definition of "large" will vary and there is nothing stopping a candidate withdrawing if there are few others running at the same time. Thryduulf (talk) 13:12, 7 January 2025 (UTC)
    This! If someone turns out to be the only candidate in the election and is uncomfortable with this, they can withdraw. ~ ToBeFree (talk) 19:30, 7 January 2025 (UTC)

Q22: Support and oppose section

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

  • Option A: No (current)
  • Option B: Yes

Q22 Survey (Support and oppose section)

Q22 Discussion (Support and oppose section)

  • "Support" and "oppose" are not magic words in this process. We don't need to carve out a special section for them, but we don't need to be hostile to them either. It'd be nice to have a proposal along those lines. Extraordinary Writ (talk) 11:17, 7 January 2025 (UTC)
  • Don't think this needs some sort of ordered list, but no objection to people discussing their thoughts. — xaosflux 12:06, 7 January 2025 (UTC)
  • I'm curious as to how the users opposing this but supporting voter guides justify their position. —Cryptic 12:55, 7 January 2025 (UTC)
    Voter guides do not require one to state an oppose or support. Mine and NL's for instance did not include this information. I felt it was more important to write down strenghts and weaknesses I saw, also as a feedback mechanism, without stating openly who I supported and opposed. My guess is that it's less stressful for the candidates, but I might be wrong and have gotten some feedback from the candidates on how to do better next year. —Femke 🐦 (talk) 14:00, 7 January 2025 (UTC)
    Agree. Mine was basically "is this AfD record useful and if so what does it say". You could have used it to guess my voting intention, but you'd have come out with the wrong answer. -- asilvering (talk) 14:19, 7 January 2025 (UTC)
  • Based on the discussion on the talk page this is likely to be snow-closed, and I won't bother casting a !vote to avoid that, but I'd like to say to the people above that my experience was that not having any idea whether people were going to vote for you or not, or why people were supporting/opposing you, did not make the process less stressful. The main advantage that the process had, from my POV, was that you were running at the same time as others and so the impact of losing was likely to be less. FOARP (talk) 15:07, 8 January 2025 (UTC)
Category: