Misplaced Pages

Latest revision as of 18:58, 9 January 2025

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 fewer 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: Misplaced Pages proposals 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)
  • I like to think we can make better decisions than the general electorate. If not the UK's, than at least the US's. —Cryptic 11:54, 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)

  Any value less than D. Buffs (talk) 20:48, 8 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 (block_talk) 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 > B 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)

  @Novem Linguae: The maximum support at AELECT is likely to always be lower than at RFA, because there is no social cost to opposing; but that doesn't necessarily scale to the passing threshold. Of the candidates in the first AELECT who did not pass but did receive more than 65% or 60%, I believe many would make fine admins, but none are editors who I would assume would sail through a regular RFA. Conversely, I know for a fact that many of those who passed had previously been told they would do great at RFA. If we want to change the passing threshold, I really think we ought to be convinced that the passing threshold is calibrated differently, and I don't see evidence of that. Vanamonde93 (talk) 16:47, 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)
• Option B. Because it was a trial, and the first-ever round of admin elections, the previous elections had some quirks that may not be reflective of the "stable" functioning of admin elections. For instance, it's currently too early to tell whether we will continue to have 30+ candidates for each election; I also have vague recollections that some people blanket-opposed out of concern that the large number of candidates or short discussion period prevented candidates from being evaluated thoroughly enough. Since we can't yet tell whether voter behavior thus far is typical, I think that—unless obvious problems arise with the current pass threshold—we should keep it stable for now. Think of it like a science experiment: we'll get the best data about what does or doesn't work by being conservative about how many variables we change at once, and I don't think the results thus far suggest that this variable urgently needs changing. ModernDayTrilobite (talk • contribs) 15:40, 8 January 2025 (UTC)
• Option B The current threshold worked well, and support levels will likely trend upward as the process becomes more familiar. Worst case scenario, consensus can change and we can revisit this after a couple more elections if we need to. If B fails, I weakly support C as the other decent option. I oppose D as too low and A as too high. QuicoleJR (talk) 16:03, 8 January 2025 (UTC)
• B, on the grounds of as currently expected, with no demonstrated need to change yet. Give it another cycle or two. --SarekOfVulcan (talk) 16:08, 8 January 2025 (UTC)
• C>B>D, oppose A. theleekycauldron (talk • she/her) 16:24, 8 January 2025 (UTC)
• B. Threshold C and below might make the process easier (and actually appoint more admins), but there has to be a feeling of confidence that unpopular or controversial candidates are not sailing through this process with the very low levels of scrutiny associated with a low threshold. While I am sure that Thresholds C or even D would not make an enormous difference, 70% is a fine cutoff and should not be lowered. arcticocean ■ 17:57, 8 January 2025 (UTC)
• C - The necessity of a landslide constrains the field unnecessarily and discourages any but the most vanilla candidates from runing. Carrite (talk) 19:38, 8 January 2025 (UTC)
• C>B>D. There is a significant drop in support compared to publicly disclosed votes. A lower passing percentage makes sense. Eluchil404 (talk) 22:13, 8 January 2025 (UTC)
• D>E ; oppose A - I think the current percentage is too high, since visibly with secret voting people are not afraid to oppose, so I strongly support decreasing it. While I'd like 66.7% (my option E) as a threshold since it is akin to a super-majority with the way votes are tallied, looking at the results I think all the candidates above 60% were excellent and also suited for adminship, so my preference is for D. Choucas Bleu 🐦‍⬛ 23:15, 8 January 2025 (UTC)
• B the current standard seems reasonable. Can be reevaluated later as needed, but I believe the bar for adminship should be high. LEPRICAVARK (talk) 12:07, 9 January 2025 (UTC)
• B. Status quo for now.

Lowering the cutoff is pain free. It’s basically the community saying, “too many good candidates didn’t get elected.” Raising the cutoff is not pain free. It can be interpreted as the community saying “too many bad candidates got elected,” and could fuel resentment over what could appear to be gatekeeping and moving the goalposts.

This election was extraordinary in many ways, it may be an outlier, and many other aspects are going to be changing. So I think we need to be cautious for now about this aspect.

Admin elections are clearly viewed as being vastly lower risk to candidates than RfA. Candidates can decide whether the tradeoff is worth it to them. We don’t need to try to make elections exactly as likely to succeed as RfA. They’re different processes.

I was against even asking this question at this time for this reason, but others workshopping were concerned that the question was a concern for a large portion of the community and that not asking it would be ignoring that. Valereee (talk) 14:16, 9 January 2025 (UTC)

• C no need to justify vote and mass opposition lowers the success percentages, for candidates that would've gotten 90%+ at RfA. I think 65% is about right based on the most recent election. ProcrastinatingReader (talk) 18:06, 9 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)

• So far most opinions seem clustered around B or C. It might be worth considering finer gradations within that range. 66.7 or 67.5% might be worth testing as a level for a broader consensus. Eluchil404 (talk) 22:20, 8 January 2025 (UTC)

  Agreed, 66.7% is an option that would make a lot of sense with how the votes are tallied, and appears to be a good candidate for a consensus value. Choucas Bleu 🐦‍⬛ 23:21, 8 January 2025 (UTC)

  I disagree that we should split the difference or come up with some average. B is not just a vote for a percentage. It's also a vote for the status quo. We can't know how many of those who voted B would have voted "No change for now". We can't know how many of them, if forced to support some change, would have voted A. Valereee (talk) 14:36, 9 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. (Note: I am heartened by the significant support for no cap on candidates. This will hopefully make several other questions about candidate priority moot. I am thus striking my !vote and expressing my support for no cap (A). If a cap is implemented, the higher the better.) 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 (block_talk) 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)
• Option A per Novem Linguae and Vanamonde. If we must have a limit, my preference would be E. ModernDayTrilobite (talk • contribs) 15:44, 8 January 2025 (UTC)
• Option A. This issue will likely work itself out, and I think adding a restrictive limit now would be problematic. If A fails, I support E as a second choice and weakly support D as a third choice for the same reasons. Oppose C and especially B as way too strict. QuicoleJR (talk) 16:09, 8 January 2025 (UTC)
• A per NL, with E being my next choice. --SarekOfVulcan (talk) 16:10, 8 January 2025 (UTC)
• A, failing which D or E. The capacity will be self-correcting, as others have said. A large number of appointments should be considered an objective of the process, not a failing. arcticocean ■ 18:01, 8 January 2025 (UTC)
• C>B>D. My personal preference would probably be 12 at a time with elections every 1-2 months. Even with a slower cadence I don't think the community can reasonably evaluate more than 15 candidates at a single time. Eluchil404 (talk) 22:22, 8 January 2025 (UTC)
• A ; oppose the rest - Any other option would be unfair, and the rest of the concerns I understand are solely based on calendar considerations, which is not the question here. Choucas Bleu 🐦‍⬛ 23:24, 8 January 2025 (UTC)
• C>D>A>E. I am not convinced this will be an ongoing problem, as it's quite likely there was tremendous pent-up demand. But I also don't think there's any harm in ensuring voters aren't overwhelmed by the number of candidates. Valereee (talk) 14:41, 9 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)

  I understand those votes. I suspect it won't be an issue, but if it is again, we again are overwhelming voters' ability to feel they can vet candidates, and we again end up with people voting Oppose for anyone they didn't have time to vet. Which in turn affects our pass/fail rate. I think the costs of a 35-person field are much, much higher than the costs of limiting the field to make sure we don't end up with 35 again. Valereee (talk) 14:48, 9 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 #)

• Option A - Simple. Fair. Close the call for candidates phase as soon as the numerical limit is reached. –Novem Linguae (talk) 10:28, 7 January 2025 (UTC)
• B is fairer, the additional complexity is manageable, and none of that complexity falls on the candidates' shoulders. Especially if the maximum number of candidates we decide on is low - say, the 8 or 10 options above - we shouldn't be devoting four or five slots to people who've tried and failed before, maybe a couple elections in a row, in preference to people who've never run, or who've been waiting longer for a second chance. —Cryptic 10:37, 7 January 2025 (UTC)
• B per Cryptic. Personally I think AELECT should be a one-shot deal, but at a minimum we shouldn't have perennial candidates crowding out others. Extraordinary Writ (talk) 10:46, 7 January 2025 (UTC)
• A is fairest in my opinion. Everything else has been too much workshopping to make effective policy. Soni (talk) 11:21, 7 January 2025 (UTC)
• Option B is most fair. I share the concerns about perennial candidates and generally agree with Cryptic and Writ. Toadspike 11:26, 7 January 2025 (UTC)
• B is fairest, but I'd really prefer if we made this question moot by having no limit in the question above. Tazerdadog (talk) 11:32, 7 January 2025 (UTC)
• B > C > A. I agree with Cryptic that this is the fairest. I don't think AELECT should be a one-shot deal, but equally I do agree that perennial candidates should be discouraged. Separately, I explicitly oppose E, how many friends you have who are willing and able to write a co-nomination statement should not be at all relevant to whether you get to stand - indeed I'd be in favour of limiting it to a maximum of just one co-nominator, both to stop it getting out of hand and to not discourage self-nominations. Thryduulf (talk) 12:00, 7 January 2025 (UTC)
• B is the fairest. Those who have not had a chance to be evaluated should be given priority. Z1720 (talk) 13:05, 7 January 2025 (UTC)
• Bper Tazerdadog · · · Peter Southwood :
• B, the simple chronology of A while perhaps encouraging some space between repeat noms, which every WP:NOTNOW RfA responder always encourages. CMD (talk) 15:17, 7 January 2025 (UTC)
• D Having it be time-based, like in options A and B, disenfranchises those with editing schedules (due to timezones, jobs, etc.) that don't allow them to be online right when the call for candidates opens. Option D allows for some compensation for those not chosen to run.--Ahecht (TALK
  PAGE) 15:35, 7 January 2025 (UTC)
• A: Option A is the fairest from my perspective. I don't see it as necessarily relevant if a user has requested adminship in the past. Hey man im josh (talk) 15:42, 7 January 2025 (UTC)
• A is fairest in my opinion.Pharaoh of the Wizards (talk) 15:54, 7 January 2025 (UTC)
• B also as per Cryptic, but don't object to most of the others. Definitely not "E" though. -Kj cheetham (talk) 16:06, 7 January 2025 (UTC)
• A. I appreciate the spirit of B, but it is far too complex to legislate: an editor who created an RFA, but didn't transclude? A TOOSOON RFA? A candidate who withdrew from a previous ALECT? Too many edge cases that would waste community time. Vanamonde93 (talk) 17:28, 7 January 2025 (UTC)
• B as it biases the system towards those most likely to pass, which is a good thing. Please not Option E because that concentrates power in the hands of the already-powerful who make these nominations. JuxtaposedJacob (talk) | :) | he/him | 17:43, 7 January 2025 (UTC)
• Option A > B I had a hard time choosing between the two, but Option A is simpler to implement. We should worry about overflowing if the numerical max ends up being a low number like 8 or 10. fanfanboy (block_talk) 17:48, 7 January 2025 (UTC)
• B is fairest, any is fine. ~ ToBeFree (talk) 18:35, 7 January 2025 (UTC)
• A per Vanamonde, although the rest are also fine. (I was elected in AELECT, for disclosure.) charlotte 21:16, 7 January 2025 (UTC)
• D. I think D is really the fairest, although it might not be clear to everyone what it means (see discussion below). If someone attempts to run in the next election, but all the ballot positions are already filled by the time they make the attempt, that should allow them to get a chance in the election following that one. If we make the process like buying tickets for a popular concert, with contenders sitting with their finger on the keyboard in the minutes leading up to when the process opens, and all the slots filled within seconds, then we are always going to have some well-qualified candidates who never get the opportunity to run. --Tryptofish (talk) 22:44, 7 January 2025 (UTC)
• Options B, C, D all seem ok. I oppose E. Espresso Addict (talk) 22:50, 7 January 2025 (UTC)
• B is the best, D and A are fine, C and E are terrible. --JBL (talk) 00:56, 8 January 2025 (UTC)
• D prevents any concerted effort to deny opportunities or waste the communities time. L3X1 ◊distænt write◊ 01:18, 8 January 2025 (UTC)
• D > B seems to be the fairest way to allow candidates not miss out on an opportunity. cyberdog958 01:57, 8 January 2025 (UTC)
• Per Thryduulf, could we combine D and B, with both "randomly"s replaced by the procedure within B? It seems to be the fairest per most of the above. Aaron Liu (talk) 02:15, 8 January 2025 (UTC)
• B, second choice C, third choice A, oppose D, oppose E Leijurv (talk) 05:42, 8 January 2025 (UTC)
• B but okay with A. Callanecc (talk • contribs • logs) 06:23, 8 January 2025 (UTC)
• B ~ C ~ D > A >> E. (E could lead to a rather silly arms race for more co-noms at the last minute if the max has been reached.) SilverLocust 💬 06:40, 8 January 2025 (UTC)
• B or C, largely for the reasons given by Cryptic. D would be my third choice. Caeciliusinhorto-public (talk) 15:00, 8 January 2025 (UTC)
• B ~ A ~ D ~ C ~ E B is the fairest choice, and better than A; it might be comparitively difficult to manage but manageable in the end. And choosing randomly is better than allowing silly numbers of co-nom The AP (talk) 15:16, 8 January 2025 (UTC)
• B, with D as a second choice. This seems fairest and prevents perennial candidates from taking up too many slots. Oppose E as extremely unfair. QuicoleJR (talk) 16:11, 8 January 2025 (UTC)
• D > A per time zone concerns raised above. --SarekOfVulcan (talk) 16:12, 8 January 2025 (UTC)
• B, which failing C or D. I'm opposed to A: our best candidates might be those deciding to run only at the last moment. I'm suspicious of E: number of co-nominators has not always correlated with trustworthiness or suitability… arcticocean ■ 18:04, 8 January 2025 (UTC)
• A. Fairest way. Past adminship runs and experience should be judged by voters not procedures. Eluchil404 (talk) 22:24, 8 January 2025 (UTC)
• A>C>B .— xaosflux 11:39, 9 January 2025 (UTC)
• A due to simplicity to understand and administer. ProcrastinatingReader (talk) 18:08, 9 January 2025 (UTC)

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)

• Option A. Yes. This is the norm for SecurePoll elections. The idea behind scrutineering is to prevent sockpuppetry from influencing an election. Election integrity is important. –Novem Linguae (talk) 10:32, 7 January 2025 (UTC)
• Option A. Yes, duh. As long as we have willing scrutineers I do not see the downside (I don't think of PII exposure has been an issue), while improving voter confidence in the outcome is a significant benefit. Toadspike 10:47, 7 January 2025 (UTC)
• A. During reworkshop phase of AELECT, I believe editors said this question was not necessary in an already crowded RFC. I continue to believe this is obvious enough that it should not need an explicit re-affirmation question. Soni (talk) 11:23, 7 January 2025 (UTC)
• A per above Tazerdadog (talk) 11:34, 7 January 2025 (UTC)
• A The reasons for this seems obvious. -- LCU ActivelyDisinterested «@» °∆t° 12:29, 7 January 2025 (UTC)

  Just as a point about no socks being found, that may have something to do with being aware that checks were going to be made. At least the smarter ones aren't going to take part in a process that will uncover their socking -- LCU ActivelyDisinterested «@» °∆t° 14:00, 8 January 2025 (UTC)

• A per above. · · · Peter Southwood : 13:09, 7 January 2025 (UTC)
• A; because why would we think it's not important to check the votes? ~ Lindsay 14:27, 7 January 2025 (UTC)
• I lean towards A, but I also feel the current restrictions on checkuser are a bit tight. Given that, there may be similar reasons to nuance the scrutineering here, and this feels like it may be a LOCALCON of the wider checkuser policy. CMD (talk) 15:20, 7 January 2025 (UTC)
• A per above. --Ahecht (TALK
  PAGE) 15:37, 7 January 2025 (UTC)
• A without such review, I guarantee there will be rampant abuse. RoySmith (talk) 15:41, 7 January 2025 (UTC)

  Just like at RfA, the voter list is public. At RfA, "per other opposing user X" is a valid oppose argument. The vote content itself probably rarely leads to checkuser action. I'm fine with scrutineering, but as Pppery pointed out below, no votes were struck by the scrutineers in the first admin election, and the "guarantee there will be rampant abuse" when option B still logs the same data and RfA voters aren't regularly checkusered is close to having been proven incorrect. ~ ToBeFree (talk) 18:39, 7 January 2025 (UTC)

• A per above.Pharaoh of the Wizards (talk) 15:55, 7 January 2025 (UTC)
• A, can't think of a good reason why not to. -Kj cheetham (talk) 16:07, 7 January 2025 (UTC)
• A: Makes sense. Hey man im josh (talk) 16:38, 7 January 2025 (UTC)
• B The scrutineering process struck zero votes in the 2024 admin elections. I think that clearly shows the effort exceeds the value. * Pppery * _{it has begun...} 17:00, 7 January 2025 (UTC)

  There were no votes struck in the last RfA either, but socks are going to come up from time to time, I think. Especially since this is the first ADE, which potential sockmasters may have not even caught wind of yet, like how there's nearly no viruses on Linux. Aaron Liu (talk) 02:16, 8 January 2025 (UTC)

• A Secure elections = better. Just because it isn't a problem right now doesn't mean we shouldn't take prudent means to keep elections fair. Buffs (talk) 17:08, 7 January 2025 (UTC)
• A to quote Ruth Bader Ginsburg, this is "like throwing away your umbrella in a rainstorm because you are not getting wet" – Shelby County v. Holder, 570 U.S. 529 (2013). — Preceding unsigned comment added by HouseBlaster (talk • contribs)
• A Gaming has historically been a concern people have expressed with admin elections; one datapoint isn't enough to decide it's not a concern. Vanamonde93 (talk) 17:28, 7 January 2025 (UTC)
• A I have never heard someone being opposed to scrutineering of their votes. JuxtaposedJacob (talk) | :) | he/him | 17:44, 7 January 2025 (UTC)

  I think one or the other user would be opposed to getting checkusered every time they vote in an RfA. Or perhaps we could extend it to large deletion discussions too. Why the same is not an issue when using SecurePoll is not 100% obviously clear. ~ ToBeFree (talk) 18:44, 7 January 2025 (UTC)

• Option A Per almost everyone above fanfanboy (block_talk) 17:50, 7 January 2025 (UTC)
• A is fine, B is fine too. ~ ToBeFree (talk) 18:40, 7 January 2025 (UTC)
• B per Pppery and the fact that we don't scrutineer RfA voters. (I was elected in AELECT, for disclosure; I promise I only voted once!) charlotte 21:18, 7 January 2025 (UTC)
• A. No point in risking it. --Tryptofish (talk) 22:45, 7 January 2025 (UTC)
• A. Otherwise extremely abusable. The damage that could be done by a corrupt admin outweighs the burden on scrutineers. Espresso Addict (talk) 22:53, 7 January 2025 (UTC)
• A. --JBL (talk) 00:56, 8 January 2025 (UTC)
• A' largely performative. but just because don't CU RfA voters doesn't mean we shouldn't. L3X1 ◊distænt write◊ 01:19, 8 January 2025 (UTC)
• Option A. If the information is already available, there is no reason not to use it. cyberdog958 01:59, 8 January 2025 (UTC)
• A this is part of election integrity. TiggerJay (talk) 05:32, 8 January 2025 (UTC)
• A per above. Callanecc (talk • contribs • logs) 06:24, 8 January 2025 (UTC)
• A. SilverLocust 💬 06:40, 8 January 2025 (UTC)
• A Obviously The AP (talk) 15:18, 8 January 2025 (UTC)
• A It's the default for a reason. --SarekOfVulcan (talk) 16:14, 8 January 2025 (UTC)
• A: arcticocean ■ 18:05, 8 January 2025 (UTC)
• A - No-brainer. Choucas Bleu 🐦‍⬛ 23:31, 8 January 2025 (UTC)
• A bit upset the phrasing of this was changed because I think the new phrasing is quite misleading. Option B is the status quo at RfA currently. Accounts at RfA can be checked if they're suspicious; they're just not checked by default, and only the usernames are visible. The way it's worded currently makes it seem insane to not check the PII, as if elections lack integrity without this PII checking. That's aside from the fact that, in ACE, according to the stewards, only one vote was struck - not enough to tilt an election at all. With stewards doing the checking I don't think it really matters, but if local CUs are doing it, then I don't really think this balances the invasion to peoples privacy with the need to prevent abuse, as the facts stand. ProcrastinatingReader (talk) 17:46, 9 January 2025 (UTC)

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)

• Option B. The stewards have stated If the test is successful and enwiki decides to hold admin elections more frequently, I'm not sure Stewards have the capacity to support them. Archive link. I think it'd be fine to have English Misplaced Pages checkusers fulfill this function. These folks are already vetted and trusted to view IP addresses and other sensitive data. –Novem Linguae (talk) 10:35, 7 January 2025 (UTC)
• Option B, we trust CUs to do this for pretty much everyone on the project; I can't think of a single reason why we couldn't trust them to do it in elections. Assuming they're happy to do so, of course? --DoubleGrazing (talk) 10:48, 7 January 2025 (UTC)
• Option C. I think it would be acceptable to have local checkusers do it, but if stewards are able and willing I think that'd be preferable, as has been the consensus for many years of ArbCom elections. Extraordinary Writ (talk) 10:51, 7 January 2025 (UTC)
• B, there is no reason to involve Stewards. It makes sense to have them involved for Arbcom given the need for more independence in those elections but not admins (note re. potential COI, I am a Steward) MarcGarver (talk) 11:25, 7 January 2025 (UTC)
• I have a slight preference for C, since stewards from other homewikis are likely more impartial than our CUs, but I also have no issues with B. Toadspike 11:29, 7 January 2025 (UTC)
• C per Extraordinary Writ, while noting that this is a minor issue. Tazerdadog (talk) 11:35, 7 January 2025 (UTC)
• B. During the workshop phase I said using stewards as scrutineers for abcom elections is correct because en.wp checkusers are appointed directly by and work closely with arbcom, therefore there is a clear potential for a conflict of interest. The same is not true for admin elections. My opinion on this has not changed. Thryduulf (talk) 12:05, 7 January 2025 (UTC)
• Option B. CheckUsers already keep an eye on RfA and there is no reason why they can't be the group to do the same here. Giraffer (talk) 12:06, 7 January 2025 (UTC)
• Option B CheckUsers are already trusted to carry out such work, there is no reason they should +not+(see replies) also do so in admin elections. -- LCU ActivelyDisinterested «@» °∆t° 12:31, 7 January 2025 (UTC)

  Is your comment missing a "not"? –Novem Linguae (talk) 12:35, 7 January 2025 (UTC)

  Thanks for spotting that. -- LCU ActivelyDisinterested «@» °∆t° 13:08, 7 January 2025 (UTC)

  CheckUsers are trusted to check editors for whom they have legitimate cause to initiate a check, and in line with the WP:CHECKUSER policy and all of the restrictions it places on CUs (for instance, WP:NOTFISHING). They've never been authorised to see the PII of editors en masse. For instance, there's a good chance the PII of most people voting in this poll hasn't been viewed by a local CU. (at least, you'd hope this is the case.) ProcrastinatingReader (talk) 18:01, 9 January 2025 (UTC)

• B stewards do not need to do this. Z1720 (talk) 13:07, 7 January 2025 (UTC)
• B or C If a steward is available and volunteers, fine. · · · Peter Southwood : 13:13, 7 January 2025 (UTC)
• B per Thryduulf ~ Lindsay 14:30, 7 January 2025 (UTC)
• C, but not strongly as I don't think any of the options are bad. CMD (talk) 15:21, 7 January 2025 (UTC)
• B per Thryduulf. I also concur with CMD. Aaron Liu (talk) 15:33, 7 January 2025 (UTC)
• C per Extraordinary Writ. --Ahecht (TALK
  PAGE) 15:38, 7 January 2025 (UTC)
• A or C. As a checkuser on enwiki, I really don't want to be in the business of running routine checks on my fellow editors unless there's a really good reason. RoySmith (talk) 15:45, 7 January 2025 (UTC)
• B or C If a steward is available and offers to volunteer fine otherwise Checkusers.Pharaoh of the Wizards (talk) 15:59, 7 January 2025 (UTC)
• C, as should be the job of a steward (if there is capacity), but not terrible to delegate. -Kj cheetham (talk) 16:09, 7 January 2025 (UTC)
• B: We should be able to trust our own CUs for this purpose. Hey man im josh (talk) 16:39, 7 January 2025 (UTC)
• B Assuming we do scrutineering at all. * Pppery * _{it has begun...} 17:00, 7 January 2025 (UTC)
• Any All options should be open. No real preference. Buffs (talk) 17:09, 7 January 2025 (UTC)
• C. I'm torn here. I'd prefer the stewards do it, for the sake of impartiality; but I don't want to set us up for failure in the future if the stewards are telling us they lack the capacity. Also: would CUs be expected not to vote, if they are scrutineering? Vanamonde93 (talk) 17:28, 7 January 2025 (UTC)
• B per NL. JuxtaposedJacob (talk) | :) | he/him | 17:44, 7 January 2025 (UTC)
• Option B Better to be able to do our own thing rather than rely on already fairly busy people. Also per Novem. fanfanboy (block_talk) 17:53, 7 January 2025 (UTC)
• Not stewards, unless there are individual ones who really want to and volunteer for this per election. Perhaps checkusers who voted for "A" above should be preferred as scrutineers. ~ ToBeFree (talk) 18:50, 7 January 2025 (UTC)
• B is fine. C would work too. Perfect4th (talk) 20:45, 7 January 2025 (UTC)
• B to leave the stews alone, although I oppose scrutineering in the first place. (I was elected in AELECT, for disclosure.) charlotte 21:20, 7 January 2025 (UTC)
• B. The Stewards apparently don't have the availability for this, and the Checkusers are entirely capable. --Tryptofish (talk) 22:47, 7 January 2025 (UTC)
• Option C. Prefer nonlocal scrutineering but it should not prevent elections from happening if they are unable to help out. Espresso Addict (talk) 22:56, 7 January 2025 (UTC)
• D, and apologies that I am adding an option. Steward time is very valuable, and is best spent helping projects which need additional help, not projects which are perfectly able to do so. However, I like the fact that stewards are "independent" and "uninvolved", so I am proposing an option to make that happen. For the closer: D > B >> C >>> A. HouseBlaster (talk • he/they) 23:27, 7 January 2025 (UTC)
• B. I see no reason not to use existing community resources. L3X1 ◊distænt write◊ 01:29, 8 January 2025 (UTC)
• Option D ideally but if not then option B is fine too. cyberdog958 02:02, 8 January 2025 (UTC)
• B or D, with B preferred. The limit on voting might be a little harsh. While I'm fine with CheckUsers taking part, I think it's reasonable to ask they not be partisan. Not a dealbreaker, however. —Ganesha811 (talk) 02:20, 8 January 2025 (UTC)
• B Those who regularly use the CU tools are the most appropriate to use those tools for this purpose as well, versus those who don't normally have that bit and don't actively use it otherwise. TiggerJay (talk) 05:33, 8 January 2025 (UTC)
• B and okay with D. ArbCom elections are different in that ArbCom apppoints CUs and there's generally a strong crossover in the ArbCom corps and CUs. Callanecc (talk • contribs • logs) 06:27, 8 January 2025 (UTC)
• A I believe that the scrutineers for administrator elections should be as impartial as is reasonably possible. Alternatively, I would also support a combination of C and D, which would be three stewards, and if unavailable, CheckUsers who don't nominate, discuss, or vote. JJP_Master (she/they) 12:44, 8 January 2025 (UTC)
• C > B I think the stewards are a better choice, but no reason not to have local CU in reserve. --SarekOfVulcan (talk) 16:16, 8 January 2025 (UTC)
• C but with the neutrality requirements of D applied to the local checkusers. I consider election integrity to have great importance and this process won't be fully trusted if there is a real possibility of an involved person using their checkuser access to strike results. arcticocean ■ 18:10, 8 January 2025 (UTC)
• B. I could libe with C or D. A is overkill. Eluchil404 (talk) 22:26, 8 January 2025 (UTC)
• D>B ; oppose A and C, per HouseBlaster. Choucas Bleu 🐦‍⬛ 23:36, 8 January 2025 (UTC)
• A The issue with local CUs is you've got people who are integrated within this community checking the PII of users they know (noting that most active editors will vote in elections, making their PII visible), indeed may well be wiki-friends with. That stewards are not from this wiki makes it non-problematic. It's the same principle as with any other PII. You wouldn't expect your friend working at a bank to view your PII to serve your support requests, while it's fine for a stranger to do so. Aside from that, it makes WP:NOTFISHING entirely redundant - there's no need to do fishing checks, because you can just wait for an admin election and see the PII anyway. From what I recall, local CUs have been admonished in the past for (perceived) unjustified RFA checks in the past. Those standards all kinda go out of the window with this. (To be clear, I have no opposition to stewards doing the checking, or, principally speaking, any non-enwiki CUs doing it. I'm also happy with local CUs doing it if they're discretionary checks, initiated for cause, rather than en masse.) ProcrastinatingReader (talk) 17:57, 9 January 2025 (UTC)

Q5 Discussion (Who will scrutineer)

• Didn't the stewards say they weren't willing to do it again? —Cryptic 11:16, 7 January 2025 (UTC)

  I think the issue was the short notice rather than a lack of willingness, but equally I see no reason why local CUs can't do it. MarcGarver (talk) 11:23, 7 January 2025 (UTC)

  Not unwilling, but. It depends on how frequent these are going to be. If this was annual, I'm sure we could muster the resources, if it is going to me monthly - that's not going to work. — xaosflux 11:38, 7 January 2025 (UTC)

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

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

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

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)

  @Vanamonde93 No right of reply? Though I haven't seen this tested, I assume anyone could go to the guide-maker's user talk page if they were concerned about misrepresentation. Heck, if it's a factual error, they could just correct it themselves. This is a wiki, after all. Toadspike 19:24, 8 January 2025 (UTC)

  @Toadspike: It's not basic factual errors I am concerned about, it's the matters of interpretation that typically lead to disputes at RFA. "I'm opposing Vanamonde93 because their CSD log is full of errors". At RFA there would be ample opportunity for me to offer a rebuttal to such a statement: for a voting guide, not so much. Vanamonde93 (talk) 22:46, 8 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 (block_talk) 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)
• B per SL above. --SarekOfVulcan (talk) 16:17, 8 January 2025 (UTC)
• B - I published a guide to the first election on Wikipediocracy and would be happy to have a link to future versions of that on-Wiki. Carrite (talk) 19:40, 8 January 2025 (UTC)
• A. Strong preference. Guides are unofficial and should not be encouraged since they discourage people from doing their own research. Eluchil404 (talk) 22:27, 8 January 2025 (UTC)
• B, oppose A and C — per Novem Linguae. Choucas Bleu 🐦‍⬛ 23:42, 8 January 2025 (UTC)
• B Some participants on the last election were dumping statistics and routine information on each candidate's discussion sections. While they are certainly helpful, they clutter the space and may not be relevant to everybody's criteria for admin. Allowing personal guides allow one to post details that they view to be relevant without clutter. Ca 15:08, 9 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)

• B. Exactly the same question and issues as Q6. —Cryptic 10:42, 7 January 2025 (UTC)
• Option A. Seems fine to link to voter guides. If someone wants to ask a question of the candidate during the discussion phase such as I noticed in this voter guide that it says X. Can you clarify if that is true / what your thoughts are on that?, I think that's reasonable. Same thing if a voter wants to say in a comment that I read in this voter guide that candidate did Y, and I am concerned about it.. –Novem Linguae (talk) 10:44, 7 January 2025 (UTC)
• Weak A. As I said above, banning all mention of voter guides is ridiculous and futile. However, I don't want folks linking their own voter guides everywhere as advertisement, so I'd like to see a good reason for any linking. Toadspike 11:35, 7 January 2025 (UTC)
• Weak A per Toadspike. Definitely no advertising beyond whatever is allowed in Q6. Tazerdadog (talk) 11:39, 7 January 2025 (UTC)
• B per my comments on Q6. Voter guides should be banned, not endorsed. Thryduulf (talk) 12:11, 7 January 2025 (UTC)
• B, While I would not bother to try to ban voter guides, I would also not endorse them. Let people vote based on their own experience and knowledge, and maybe a list of relevant statistics, if we ever agree on what statistics are relevant. · · · Peter Southwood : 13:24, 7 January 2025 (UTC)
• B if Q6 results in A, A otherwise. Ban them or don't. It's silly to have them but ban talking about them. -- asilvering (talk) 13:54, 7 January 2025 (UTC)
• Weak A. I support making info available to voters but I can see that if people start linking, say as part of a signature, it could serve as advertising. However, that is not yet a problem.--Wehwalt (talk) 14:50, 7 January 2025 (UTC)
• Weak A, having a hard time balancing transparency about their potential existence with concerns about overreliance/advertising. CMD (talk) 15:27, 7 January 2025 (UTC)
• B As per Q6 there is no of seats fill and the candidates aren't running against each other like arbcom.Pharaoh of the Wizards (talk) 16:07, 7 January 2025 (UTC)
• A: Personally I would see it as fine to link from a discussion on the admin elections talk page. Hey man im josh (talk) 16:42, 7 January 2025 (UTC)
• A but with note against promoting. Aaron Liu (talk) 17:18, 7 January 2025 (UTC)
• A B. exactly as above. Vanamonde93 (talk) 17:39, 7 January 2025 (UTC)

  I think you meant B. ~~ Jessintime (talk) 18:28, 7 January 2025 (UTC)

  I do indeed. Thank you. Vanamonde93 (talk) 18:43, 7 January 2025 (UTC)

• Weak A per CMD. JuxtaposedJacob (talk) | :) | he/him | 17:52, 7 January 2025 (UTC)
• Option A I don't see a big problem. fanfanboy (block_talk) 18:01, 7 January 2025 (UTC)
• Option B per my answer to Q6 above. ~~ Jessintime (talk) 18:28, 7 January 2025 (UTC)
• B as explained for Q6. ~ ToBeFree (talk) 19:01, 7 January 2025 (UTC)
• A as I mentioned in Q6 – trying to balance the needs of voters and candidates both is not easy, and this at least strikes some balance. Perfect4th (talk) 20:51, 7 January 2025 (UTC)
• A per Novem. (I was elected in AELECT, for disclosure.) charlotte 21:23, 7 January 2025 (UTC)
• Weak B. I want to discourage voter guides for the reasons I gave in Q6, but I think it may be harder to say no to any mention in a discussion on a talk page. --Tryptofish (talk) 22:54, 7 January 2025 (UTC)
• Option A. If guides are to be useful, they need to be visible. Espresso Addict (talk) 23:02, 7 January 2025 (UTC)
• Weak B. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A per NL. cyberdog958 02:09, 8 January 2025 (UTC)
• Not in favor of placing undue restrictions on talk pages. L3X1 ◊distænt write◊ 03:19, 8 January 2025 (UTC)
• A because of how it would cover talk pages. It would be an arbitrary restriction upon the exact places where we're meant to discuss the candidates anyway? Leijurv (talk) 05:51, 8 January 2025 (UTC)
• A. 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)

  If people just put their views in the discussion section in the first place, then no regurgitation is required. 100.36.106.199 (talk) 20:10, 8 January 2025 (UTC)

• A — per Novem Linguae. Choucas Bleu 🐦‍⬛ 23:44, 8 January 2025 (UTC)
• A. Just like any ordinary talk page discussion linking to other discussions or to essays. You can write directly in discussion pages, or you can write on a "guide" and link to it. Adumbrativus (talk) 11:30, 9 January 2025 (UTC)

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)

• If official stats are to be provided, provide them on the candidacy pages where they're most likely to be seen. —Cryptic 10:43, 7 January 2025 (UTC)
• Option A. I don't think an official voter guide is necessary. It could become a maintenance burden for election administrators to have to publish this. Perhaps best to crowd-source it to the folks that do unofficial voter guides. –Novem Linguae (talk) 10:45, 7 January 2025 (UTC)

  No reason such a guide would only be able to updated by election admins, if it can only contain statistics anyone could update it. (compare to ACEGUIDE - the election team normally updates it, but there are no restrictions on others making productive edits as well). — xaosflux 11:43, 7 January 2025 (UTC)

  I'll add that I am not completely opposed to Option B. I do think it'd be fairly easy to make an objective voter guide. You could just take something like User:Novem Linguae/Essays/2024 administrator election voter guide, and strip the subjective parts out of it. The subjective parts are the green and red check marks (replace them with pure numbers), and delete the "user talk archiving and transparency" column. –Novem Linguae (talk) 00:49, 8 January 2025 (UTC)

• Option B. During the trial elections, a lot of statistics were dumped onto candidate pages, which cluttered the discussion. (ex.) This was done in good faith by well-meaning editors to improve transparency, but a discussion area is not the best place for that. An official voter guide, on the other hand, is a great place. Toadspike 11:37, 7 January 2025 (UTC)

  Note: If consensus for unofficial guides is found, then I don't care if there is an official one. I simply don't want more statistics than discussion on the discussion pages. Toadspike 19:27, 8 January 2025 (UTC)

• Option A to avoid the appearance of bias, which can be seen as simply as which statistics are displayed and how prominently. Tazerdadog (talk) 11:41, 7 January 2025 (UTC)
• B sure seems fine. — xaosflux 11:43, 7 January 2025 (UTC)
• A, it would be very easy for an "official" guide to be biased, for instance by choosing which statistics to show. I don't think we should guide voters by telling them which statistics would be more or less relevant to consider. Chaotic Enby (talk · contribs) 11:59, 7 January 2025 (UTC)
• B, to avoid giving a justification for spamming random and irrelevant statistics (which is most of them) on discussion pages and discourage people thinking individual voter guides are somehow a good thing because they contain statistics. Thryduulf (talk) 12:15, 7 January 2025 (UTC)
• A What editors consider to be relevant experience for an admin will vary. Whatbis important for one may not be important for another. "Official" guides are only ever going to give a certain perspective on whatbis required. -- LCU ActivelyDisinterested «@» °∆t° 12:35, 7 January 2025 (UTC)
• B · · · Peter Southwood : 13:26, 7 January 2025 (UTC)
• A. I don't think statistics should be given without any additional discussion, and I don't think it's possible to add useful discussion while remaining fully neutral. -- asilvering (talk) 13:59, 7 January 2025 (UTC)
• A Leave it to the private guides.--Wehwalt (talk) 14:51, 7 January 2025 (UTC)
• Lean B, but not strongly. This would prevent them ending up on every page, but on the other hand they end up on every page as it is, so it might not make too much of a difference. That said, the more candidates, the trickier it is to evaluate everything for the single securepoll, so strong B if Q2 results in an unlimited candidate pool. CMD (talk) 15:30, 7 January 2025 (UTC)
• Option B official stats can be provided.Pharaoh of the Wizards (talk) 16:13, 7 January 2025 (UTC)
• A, very firmly. I dislike the "official" guide to ACE, and I think it's even worse here: we're giving license to a handful of volunteers to centralize information the candidate may or may not want to make public. Vanamonde93 (talk) 17:39, 7 January 2025 (UTC) Addendum: even if we reach a community consensus on which statistics should be displayed, I'm inclined to believe this will result in groupthink and stat-padding, and a considerable bias against candidates in niche areas. So I oppose per ChaoticEnby as well. Vanamonde93 (talk) 19:06, 7 January 2025 (UTC)
• Option B. While the details to be covered in such a guide need to be hashed out, I think it's important to at a minimum identify which candidates have run for adminship (either through an RFA or an election) in the past. ~~ Jessintime (talk) 17:50, 7 January 2025 (UTC)
• A per Chaotic Enby. JuxtaposedJacob (talk) | :) | he/him | 17:53, 7 January 2025 (UTC)
• Option B not convinced by the other arguments. fanfanboy (block_talk) 17:57, 7 January 2025 (UTC)
• A is fine, B is fine. Neither is a megaphone to a single user's opinion. ~ ToBeFree (talk) 19:02, 7 January 2025 (UTC)
• Either is fine (but agree with Toadspike that dumping statistics on candidates' pages made them a bit unwieldy and would prefer to avoid that in the future). Perfect4th (talk) 20:51, 7 January 2025 (UTC)
• A per Novem, although I don't feel strongly here. (I was elected in AELECT, for disclosure.) charlotte 21:24, 7 January 2025 (UTC)
• A, because a pre-agreed set of stats is in invitation for a long, costly, and utterly silly argument. Cremastra (u — c) 21:35, 7 January 2025 (UTC)
• A, definitely. Any general consensus of what to ask "officially" will be useless information. The first trial went much too far in emphasizing trivial statistics about certain kinds of audited content, without giving adequate attention to the qualities that really matter. --Tryptofish (talk) 22:57, 7 January 2025 (UTC)
• Option A. The bald numbers can be very deceptive, agreeing what to include would be a nightmare, and I agree with Tryptofish that the important qualities are not easily quantified. Espresso Addict (talk) 23:05, 7 January 2025 (UTC)
• Option A, precisely per Cremastra. I will reprint their rationale, because it bears repeating: a 'pre-agreed set' of stats is in invitation for a long, costly, and utterly silly argument. Who decides what is Officially Important? HouseBlaster (talk • he/they) 23:32, 7 January 2025 (UTC)
• A per Cremastra. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A per HouseBlaster. Developing a pre-agreed set of factual statistics sounds like it would just devolve into contention and disagreement of what to include. Also, would probably just be redundant to the unofficial guides that will surely be created. cyberdog958 02:15, 8 January 2025 (UTC)
• A unless the official guide contains very limited stats. L3X1 ◊distænt write◊ 03:20, 8 January 2025 (UTC)
• A the information that would be in an offical guide would be fairly easily accessible anyway and will lead to disagreements about what is to be included. Callanecc (talk • contribs • logs) 06:33, 8 January 2025 (UTC)
• Option A. Having an official guide could create potential Goodhart's law issues, where voters (or prospective candidates) may become unduly focused on easily trackable metrics. Leaving guides in the unofficial-material realm strikes a better balance of making information available to the electorate without portraying specific quantifiable stats as the intended "deciding factors" of an election. ModernDayTrilobite (talk • contribs) 15:53, 8 January 2025 (UTC)
• A. If people want known stats, they can look them up. --SarekOfVulcan (talk) 16:18, 8 January 2025 (UTC)
• A per ModernDayTrilobite. QuicoleJR (talk) 16:51, 8 January 2025 (UTC)
• B. The equivalent Arb election guide is an extremely useful list of candidates with convenient link to past runs and such. While a comparable page would be pretty sparse, having links to edit counts, etc from a single page would be very helpful. Eluchil404 (talk) 22:31, 8 January 2025 (UTC)
• A an official voter guide would be far more trouble than it's worth. Unofficial ones are fine. —Ganesha811 (talk) 22:35, 8 January 2025 (UTC)
• B — I do not think it is necessary to have one, but I believe it could be useful. Choucas Bleu 🐦‍⬛ 23:48, 8 January 2025 (UTC)

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)

• Option B - Originally I think the AELECT proposal just copied WP:ACE to copy an existing process. But we have discovered that the ACE suffrage criteria is complicated, and requires a specialized user to spend hours running a script, and then the data from that script has to be imported into SecurePoll. This process is inefficient and creates a bus factor. It would be much easier on the back end to switch to Option B and just require voters to be extended confirmed. This also aligns the suffrage criteria with RFA. –Novem Linguae (talk) 10:49, 7 January 2025 (UTC)

  I thought of something else. For A, an allowlist is generated off-wiki and then imported into SecurePoll. It's a snapshot. Anyone that didn't meet the requirements before the import date and then met the requirements after the import date can't vote. B is generated more on-the-fly. Your perms are checked when your SecurePoll session is created. To sum up, option B solves the problem of the voter list being a week or two old by the time someone tries to vote. –Novem Linguae (talk) 00:46, 8 January 2025 (UTC)

• B. I prefer this in principle, but in light of Novem's comments it's a no-brainer. Extraordinary Writ (talk) 10:52, 7 January 2025 (UTC)
• Option B. Consistency is a good idea, and if the ACE requirements are harder to implement then there's no reason to make an exception here. Toadspike 11:40, 7 January 2025 (UTC)
• Both are acceptable, pick whichever is easiest to implement and maintain. Tazerdadog (talk) 11:43, 7 January 2025 (UTC)
• B do not require anything requiring a manual whitelist to be built by volunteers for each election. — xaosflux 11:45, 7 January 2025 (UTC)
• B Easier to maintain and in line with consensus on RfA. —Femke 🐦 (talk) 12:08, 7 January 2025 (UTC)
• B there is no reason for different adminship request processes to have different suffrage requirements. Thryduulf (talk) 12:16, 7 January 2025 (UTC)
• B The method of standing for being an admin shouldn't change who can participate. -- LCU ActivelyDisinterested «@» °∆t° 12:37, 7 January 2025 (UTC)
• B, Should be the same as for RFA.· · · Peter Southwood : 13:27, 7 January 2025 (UTC)
• B, keep it simple. CMD (talk) 15:31, 7 January 2025 (UTC)
• B As somebody who has been on WP:ELECTCOM for two years, I agree with Novem Linguae about the bus number aspect. The ACE criteria adds complexity for no good reason. RoySmith (talk) 15:49, 7 January 2025 (UTC)
• B KISS (as long as there is scrutineering). -Kj cheetham (talk) 16:12, 7 January 2025 (UTC)
• B in line with consensus on RfA.Pharaoh of the Wizards (talk) 16:17, 7 January 2025 (UTC)
• B: RfA suffrage requirements make sense for requests for adminship. Hey man im josh (talk) 16:42, 7 January 2025 (UTC)
• B * Pppery * _{it has begun...} 17:01, 7 January 2025 (UTC)
• B per NL. Ideally I'd give scrutineers the ability to strike votes that are based on gaming EC rights, but perhaps that's too complicate. Vanamonde93 (talk) 17:39, 7 January 2025 (UTC)
• B on principle (simplicity), plus because of interesting comments by NL. JuxtaposedJacob (talk) | :) | he/him | 17:56, 7 January 2025 (UTC)
• Option B RFA and AELECT should be equal when it comes to who can participate. fanfanboy (block_talk) 18:04, 7 January 2025 (UTC)
• A is fine, B is fine too. Perhaps the process for A can be automated more centrally than it currently is, especially if both options require programming anyway. And if A is really problematic, we should change it for ArbCom elections as well. ~ ToBeFree (talk) 19:04, 7 January 2025 (UTC)

  B is super easy. You just tick some boxes such as "must be extendedconfirmed" and "must not be banned". A is complicated. Cyberpower678 generates an allowlist of usernames off-wiki using a custom written script, it takes hours, then it must be imported into SecurePoll. –Novem Linguae (talk) 00:43, 8 January 2025 (UTC)

• B KISS (I was elected in AELECT, for disclosure.) charlotte 21:25, 7 January 2025 (UTC)
• B. It's an RfA, either way. --Tryptofish (talk) 22:58, 7 January 2025 (UTC)
• Option B. Match RfA requirements. Espresso Addict (talk) 23:07, 7 January 2025 (UTC)
• B per everyone else. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option B. This is an RfA afterall. cyberdog958 02:17, 8 January 2025 (UTC)
• b L3X1 ◊distænt write◊ 03:21, 8 January 2025 (UTC)
• B it makes sense to be consistent between RfA and Elections. TiggerJay (talk) 05:37, 8 January 2025 (UTC)
• B to match RfA requirements plus the point Novem Linguae makes. Callanecc (talk • contribs • logs) 06:34, 8 January 2025 (UTC)
• B. Parity, simple. SilverLocust 💬 06:40, 8 January 2025 (UTC)
• B Same as the RFAs The AP (talk) 15:20, 8 January 2025 (UTC)
• B Someone's ability to vote on a candidate should not be affected by what process the candidate chooses. That would be injustice. QuicoleJR (talk) 16:17, 8 January 2025 (UTC)
• B is for blizzard. --SarekOfVulcan (talk) 16:20, 8 January 2025 (UTC)
• B for the reasons given by others. arcticocean ■ 18:11, 8 January 2025 (UTC)
• B — Fully support uniformization around the EC criterion, and per above arguments. Choucas Bleu 🐦‍⬛ 23:52, 8 January 2025 (UTC)

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 (block_talk) 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. JJP_Master (she/they) 12:50, 8 January 2025 (UTC)
• A or B this shouldn't be an issue L3X1 ◊distænt write◊ 15:24, 8 January 2025 (UTC)
• Option B. I think it makes sense to have some failsafe in play, in case some freak accident causes us to have an election with vanishingly low participation. However, the minimum number of support votes should be low enough that candidates in an "average" election shouldn't need to worry about it. My reasoning is essentially similar to that of Toadspike or Callanecc (even if my opinion differs from theirs on precisely where to lay the threshold). ModernDayTrilobite (talk • contribs) 15:58, 8 January 2025 (UTC)
• B > A to avoid freak accidents as above. --SarekOfVulcan (talk) 16:23, 8 January 2025 (UTC)
• Option B or C, with a slight preference for B. There should be a failsafe so that we don't have someone getting elected admin by 10 people. I oppose A because we need a failsafe, and I oppose D as too extreme. QuicoleJR (talk) 16:25, 8 January 2025 (UTC)
• A. There is no quorum for RFAs and no need for one here either. arcticocean ■ 18:13, 8 January 2025 (UTC)
• C>B>A. Some minimal quorum makes sense in the absence of interactive discussion but is shouldn't be too high. Eluchil404 (talk) 22:33, 8 January 2025 (UTC)
• D>C>>>B, oppose A — A fail-safe clause is absolutely necessary here. It is not because it would not have been useful during this trial that we should design a process with clear, open vulnerabilities like this one. Choucas Bleu 🐦‍⬛ 23:57, 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)

• 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:54, 7 January 2025 (UTC)
• Option A. This is a bridge too far: it would hobble genuinely uncontroversial candidates (just look at the numbers in previous ArbCom elections), and it could even create perverse incentives to abstain rather than oppose. Extraordinary Writ (talk) 11:03, 7 January 2025 (UTC)
• A. B makes abstentions not be abstentions anymore - we go from having options of "yes", "don't care", and "no" to "yes", "no", and "no way". —Cryptic 11:04, 7 January 2025 (UTC)
• Option A, "abstain" should truly mean "abstain" and an additional quorum is needless bureaucracy. Toadspike 11:27, 7 January 2025 (UTC)
• A there should be no regard to voters that don't want to express an opinion on you. — xaosflux 11:48, 7 January 2025 (UTC)
• A per all above Tazerdadog (talk) 11:51, 7 January 2025 (UTC)
• A, making abstentions count is equivalent to forcing users to vote on everyone without realizing it. Chaotic Enby (talk · contribs) 12:00, 7 January 2025 (UTC)
• A I don't see much logic behind this requirement. —Femke 🐦 (talk) 12:06, 7 January 2025 (UTC)
• A per everyone above. Thryduulf (talk) 12:21, 7 January 2025 (UTC)
• A. Abstaining generally means the person does not have an opinion either way, so there should be no consequence either way. · · · Peter Southwood : 12:35, 7 January 2025 (UTC)
• A As with all secret ballots abstaining is to effectively agree with the outcome. Editors abstaining are not opposed or supportive now the candidate, and so shouldn't effect the outcome. -- LCU ActivelyDisinterested «@» °∆t° 12:42, 7 January 2025 (UTC)
• A. It's an abstention, not an oppose. -- asilvering (talk) 14:07, 7 January 2025 (UTC)
• A, this is just trying to wiggle around problems caused by overlong candidate lists. CMD (talk) 15:35, 7 January 2025 (UTC)
• A strongly, as others have said. -Kj cheetham (talk) 16:15, 7 January 2025 (UTC)
• Option A We had absolutely no problem achieving a reasonable quorum in the last election and participation is not an issue.Pharaoh of the Wizards (talk) 16:24, 7 January 2025 (UTC)
• A: A passing percentage is a passing percentage, leave it at that. Hey man im josh (talk) 16:44, 7 January 2025 (UTC)
• A * Pppery * _{it has begun...} 17:05, 7 January 2025 (UTC)
• A, as above. Vanamonde93 (talk) 17:39, 7 January 2025 (UTC)
• A Changed my mind after reading the above arguments. JuxtaposedJacob (talk) | :) | he/him | 18:01, 7 January 2025 (UTC)
• Option A No. fanfanboy (block_talk) 18:10, 7 January 2025 (UTC)
• Supporters who turn up only for specific candidates shouldn't affect how the levels of trust for other candidates are determined. Thus I support option A. isaacl (talk) 18:18, 7 January 2025 (UTC)
• A, per isaacl. ~ ToBeFree (talk) 19:08, 7 January 2025 (UTC)
• A in agreement with everyone above ~ Lindsay 20:30, 7 January 2025 (UTC)
• A per Femke. (I was elected in AELECT, for disclosure.) charlotte 21:26, 7 January 2025 (UTC)
• A. No need to make it more complicated. --Tryptofish (talk) 23:03, 7 January 2025 (UTC)
• Option A. The abstain option is useful to enable voters to evaluate only some of the candidates. Espresso Addict (talk) 23:16, 7 January 2025 (UTC)
• A per Cryptic. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A. Abstentions should have no bearing on whether a candidate passes. I abstained from voting on several of the candidates out of necessity of not having enough free time to adequately evaluate every candidate. cyberdog958 02:21, 8 January 2025 (UTC)
• A when it comes to this format, I think this is the best route, provided the prior Q10 passes with some sort of a minimum number of votes. TiggerJay (talk) 05:46, 8 January 2025 (UTC)
• A another unnecessary complication Leijurv (talk) 05:56, 8 January 2025 (UTC)
• A uncessary per Novem Linguae. Callanecc (talk • contribs • logs) 06:41, 8 January 2025 (UTC)
• A no. L3X1 ◊distænt write◊ 15:25, 8 January 2025 (UTC)
• Option A per Extraordinary Writ and cyberdog958. ModernDayTrilobite (talk • contribs) 16:12, 8 January 2025 (UTC)
• A Abstain should mean abstain, plain and simple. QuicoleJR (talk) 16:20, 8 January 2025 (UTC)
• A as per Quicole. --SarekOfVulcan (talk) 16:24, 8 January 2025 (UTC)
• A: anything else is unnecessary complexity. arcticocean ■ 18:14, 8 January 2025 (UTC)
• A — No-brainer. Choucas Bleu 🐦‍⬛ 23:59, 8 January 2025 (UTC)

Q11 Discussion (minimum support/abstention requirement)

• If this was the proposal I made, I think it got a bit mangled in transmission. I would definitely oppose this as written. theleekycauldron (talk • she/her) 16:13, 8 January 2025 (UTC)

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 (block_talk) 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)
• B I prefer open signup and don't think we'll have issues. if candidates are inactive at time of elections then no one will vote for them, problem solved. L3X1 ◊distænt write◊ 15:36, 8 January 2025 (UTC)
• A because I don't think it would be good for the system to have the slots fill up immediately after the previous election. A nomination window would allow people time to think before declaring their candidacy. I also would not oppose punting this question to a future RFC dependent on the answers to the other questions. QuicoleJR (talk) 16:28, 8 January 2025 (UTC)
• B because it minimises the cognitive load of volunteering for admin by standing for election – candidates can simply add their name as soon as they become willing to volunteer. arcticocean ■ 18:16, 8 January 2025 (UTC)
• B. Add your name when your ready and then answer questions when the time for your election comes up. Eluchil404 (talk) 22:35, 8 January 2025 (UTC)
• A — per Novem Linguae. Choucas Bleu 🐦‍⬛ 00:01, 9 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)

• Option A - Worked fine in the last election. The advantage of a sign up window over longer options 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:03, 7 January 2025 (UTC)
• I see nothing wrong with D, especially if our combinations of choices in the other questions generates a significant waiting list. Just require that candidates confirm they're active and still want to run when their name comes up. —Cryptic 11:29, 7 January 2025 (UTC)
• A - B/C/D is the same type of bureaucracy creep and policy overload I would personally prefer to avoid. This is another question that I think should have been skipped from Phase II altogether. Soni (talk) 11:33, 7 January 2025 (UTC)
• A. If we have a nomination window, then all nominations must be made in that window. Thryduulf (talk) 12:24, 7 January 2025 (UTC)
• A. As I said above, the solution to scarce candidate spots (which would be a great thing!) is more elections or more spots, not more bureaucracy to game. Toadspike 12:26, 7 January 2025 (UTC)
• A More elections and more frequent elections are the solution to any excess of candidates. -- LCU ActivelyDisinterested «@» °∆t° 12:45, 7 January 2025 (UTC)
• A. It should be easy enough to sign up at the time, and there should preferably not be a limit on numbers. · · · Peter Southwood : 13:42, 7 January 2025 (UTC)
• A, this isn't a process that needs extensive lead times. This would add complexity for little gain. CMD (talk) 15:40, 7 January 2025 (UTC)
• A KISS. -Kj cheetham (talk) 16:16, 7 January 2025 (UTC)
• Option A per Novem Linguae.Pharaoh of the Wizards (talk) 16:27, 7 January 2025 (UTC)
• B If the above RFA option B passes, then I think that the consensus should apply to all elections. Note that I voted A on Q12. JuxtaposedJacob (talk) | :) | he/him | 18:06, 7 January 2025 (UTC)
  • A I misread the question. JuxtaposedJacob (talk) | :) | he/him | 02:16, 8 January 2025 (UTC)
• Option A While I don't think Option B of Q12 is a good idea, if it passes this is my preferred option. fanfanboy (block_talk) 18:13, 7 January 2025 (UTC)
• Option D: any future election is the simplest approach for potential candidates, and avoids a landrush for the next scheduled election. isaacl (talk) 18:25, 7 January 2025 (UTC)
• A is fine, B and C are okay, I'm not sure how D would be implemented and if signing up for 2030's admin elections should really be an option. ~ ToBeFree (talk) 19:15, 7 January 2025 (UTC)

  I hereby announce my intention to run in 2075, I'd probably have done something desysop-worthy by then... charlotte 21:30, 7 January 2025 (UTC)

• A. I'm persuaded by the arguments that we should have more frequent elections instead of making it necessary to plan so far ahead. --Tryptofish (talk) 23:10, 7 January 2025 (UTC)
• A. Espresso Addict (talk) 23:23, 7 January 2025 (UTC)
• A. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A. Especially if elections are only held biannually, someone stating they want to run in two elections would be stating they will run in one years time. There is no campaigning to be done so there is no reason to predate your nomination for an election in the future. cyberdog958 02:34, 8 January 2025 (UTC)
• A p l e a s e KISS Leijurv (talk) 05:57, 8 January 2025 (UTC)
• A for simplicity. Callanecc (talk • contribs • logs) 06:44, 8 January 2025 (UTC)
• A' easier. L3X1 ◊distænt write◊ 15:44, 8 January 2025 (UTC)
• A You shouldn't have to sign up several elections in advance if you want to run. QuicoleJR (talk) 16:30, 8 January 2025 (UTC)
• A and I find the question a tad perplexing (although that could be my fault). If a candidate particularly wishes to avoid a specific election, it seems obviously their responsibility to delay signing up. arcticocean ■ 18:22, 8 January 2025 (UTC)
• D. Candidates add their name to a single queue and every month the top twelve get removed and voted on. Eluchil404 (talk) 22:36, 8 January 2025 (UTC)

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)

• Option A - Seems like a non-issue. The call for candidates phase is currently a week long, so the time of day that it opens and closes shouldn't be an obstacle for anyone. Even if they work 5 days a week, they will still have 2 days out of the 7 days to submit their candidacy. It is unlikely the time of day would be a factor. –Novem Linguae (talk) 11:06, 7 January 2025 (UTC)
• I highly doubt that this will become relevant, since I don't think we'll have enough candidates again for this to be an issue, but if I had to choose Option C seems most fair. Toadspike 11:51, 7 January 2025 (UTC)
• A. We can revisit this if candidates in some timezones are being disadvantaged, but we will have actual knowledge of who is being disadvantaged and in what way so we can make sure whatever we change it to actually helps that rather than accidentally making it worse. Thryduulf (talk) 12:28, 7 January 2025 (UTC)
• A. It is simple and less likely to confuse anyone, also per Thryduulf. · · · Peter Southwood : 13:45, 7 January 2025 (UTC)
• A, this is a question premised on a number of assumptions, which may or may not be true. Again there is a lack of data, and this issue can be revisited later, per Thryduulf. CMD (talk) 15:45, 7 January 2025 (UTC)
• C if we limit the number of candidates or list the candidates in an order that in any way that rewards early sign-ups. Otherwise A. --Ahecht (TALK
  PAGE) 16:03, 7 January 2025 (UTC)
• A per Novem Linguae.Pharaoh of the Wizards (talk) 16:32, 7 January 2025 (UTC)
• A per NL, CMD, and Thryduulf. JuxtaposedJacob (talk) | :) | he/him | 18:08, 7 January 2025 (UTC)
• Option A Simple fanfanboy (block_talk) 18:14, 7 January 2025 (UTC)
• A is fine, C makes sense too per Ahecht. ~ ToBeFree (talk) 19:16, 7 January 2025 (UTC)
• A per Novem. (I was elected in AELECT, for disclosure.) charlotte 21:32, 7 January 2025 (UTC)
• A a petty detail for a week-long period. Cremastra (u — c) 21:37, 7 January 2025 (UTC)
• A, as being the simplest. --Tryptofish (talk) 23:11, 7 January 2025 (UTC)
• A, though open to revisiting if there is a lot of demand and editors are missing out because of timezone issues. Espresso Addict (talk) 23:26, 7 January 2025 (UTC)
• Option A. I doubt there would be such a mad rush to run that this would be an issue. cyberdog958 02:36, 8 January 2025 (UTC)
• A provided that there is no limit to the total number of people. However, if we end up with a scenario where we cap the number of applicants and then implement some sort of "first ones who register", then it might be important to implement some sort of random or advancing start time, such as every 4 to 6 hours advancing each call, so that it doesn't unfairly disadvantage some people who are nearer or further to that timezone that is used globally. — Preceding unsigned comment added by Tiggerjay (talk • contribs)
• A or B keep it simple. Callanecc (talk • contribs • logs) 06:45, 8 January 2025 (UTC)
• B same time every day is good. L3X1 ◊distænt write◊ 16:07, 8 January 2025 (UTC)
• C > A per Ahect. --SarekOfVulcan (talk) 16:25, 8 January 2025 (UTC)
• I'm fine with any of these, with a slight preference for option C. I think this would be a good one to revisit down the line after we figure out whether it is a problem. QuicoleJR (talk) 16:32, 8 January 2025 (UTC)

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)

• Option D - Alphabetical. This is the most convenient for voters. It allows easy cross-referencing to an offline list that the voter might have made of how they plan to vote, easy cross-referencing to voter guides, etc. The current system of randomizing voters in SecurePoll is inconvenient to voters, and makes it easier to make mistakes transferring one's offline ballot into SecurePoll. –Novem Linguae (talk) 11:10, 7 January 2025 (UTC)
• D. Per Novem Linguae it is much more convenient in the actual voting process, especially if there are lots of candidates. MarcGarver (talk) 11:27, 7 January 2025 (UTC)
• Any of B, C, or D are fine so long as the order doesn't change. (That is, if C means we pick a random order and stick to it, not that the order is random each view, and especially if it's a different random order than in SecurePoll.) —Cryptic 11:30, 7 January 2025 (UTC)
• Not A, no preference between the rest (agree with Cryptic). Toadspike 11:52, 7 January 2025 (UTC)
• D , reevaluate after the next election, the datapoint would be if candidates lower on the list get significantly less total non-abstain votes. — xaosflux 11:59, 7 January 2025 (UTC)
• Option D: Alphabetical --C1K98V 12:05, 7 January 2025 (UTC)
• D, Alphabetical is what most people are used to and it makes things easier if one wants to go back and double check.· · · Peter Southwood : 12:44, 7 January 2025 (UTC)
• Weak D I don't see this as being majorly important, but if the candidate were alphabetised it would be easier when doing double checks. -- LCU ActivelyDisinterested «@» °∆t° 12:47, 7 January 2025 (UTC)
• D is fine. They're not running against each other.--Wehwalt (talk) 14:55, 7 January 2025 (UTC)
• C, random order is a good system. The issue with it is partially due to the SecurePoll software, as raised by those above, but is also a function of the sheer number of candidates we had. We know randomness helps mitigate against psychological nudges, and I'm surprised to see so many opinions sacrificing this instead of looking at other methods we have to mitigate the technical issues (eg, not running 35 candidates). CMD (talk) 15:49, 7 January 2025 (UTC)
• B. I agree that random is annoying because it makes it hard to transfer from my off-wiki notes to the ballot. Those of us who are old enough to remember paper phone books will remember when companies would routinely game the alphabetical ordering to get to the front of the listings: "AAAAAAAAAAA Plumbing Supply". We don't need that. RoySmith (talk) 15:56, 7 January 2025 (UTC)
• C per CMD. --Ahecht (TALK
  PAGE) 16:09, 7 January 2025 (UTC)
• D or C. We don't have too many "Aaron A. Aaronson"s. -Kj cheetham (talk) 16:18, 7 January 2025 (UTC)

  Aaron Liu (talk) 02:50, 8 January 2025 (UTC)

• C per CMD.Pharaoh of the Wizards (talk) 16:38, 7 January 2025 (UTC)
• C * Pppery * _{it has begun...} 17:06, 7 January 2025 (UTC)
• C Random, because although it is hard to transfer off-wiki notes to the voting software, it is much better than creating a perverse incentive for people named AAAA signing up on the first minute getting advantaged. JuxtaposedJacob (talk) | :) | he/him | 18:10, 7 January 2025 (UTC)
• Option D Easy for most people. fanfanboy (block_talk) 18:16, 7 January 2025 (UTC)
• C because, although it imposes a cost on voters, a level playing field is important, and there is real-world data showing that ordering matters in these circumstances. Vanamonde93 (talk) 19:11, 7 January 2025 (UTC)
• Prefer C, fine with D. ~ ToBeFree (talk) 19:18, 7 January 2025 (UTC)
• C per Vanamonde. (I was elected in AELECT, and probably got so many votes because I was the first to sign up, for disclosure.) charlotte 21:34, 7 January 2025 (UTC)
• C. I see no reason to give favor based on either the alphabet or on the order of sign-up. Random is the most neutral, and I don't think it really confuses anyone. --Tryptofish (talk) 23:13, 7 January 2025 (UTC)
• D is more convenient if there are lots of candidates. Opposed to randomising the nominations (C) which makes it hard to keep track of nominations and be sure one has assessed everyone. Espresso Addict (talk) 23:30, 7 January 2025 (UTC)
• C conditional on if the SecurePoll ballot can use the same order the candidates page is randomized in; e.g. if the candidates page randomizes five candidates (each of which I represent as a letter) as F Y C S O, the ballot should also list them as F Y C S O, not O Y F C S. If we somehow can't do that, then I think we should do B per Roy. Aaron Liu (talk) 02:50, 8 January 2025 (UTC)

  Nearly no one is going to vote based on the randomized ballot listing on the SecurePoll page, IMO. They'll probably read the candidate pages list first in whatever order that has. Aaron Liu (talk) 12:57, 8 January 2025 (UTC)

• Option C. Alphabetical order bias is a real thing and this would be the most fair way to present the candidates unless phab:T378313 ever makes any headway. cyberdog958 02:43, 8 January 2025 (UTC)
• D for voting only, and C for everywhere else official as alphabetical is easier for the voter as Novem said above. If this was the case of winner-take-all like many political elections then there is plenty of research to support a random order is best, but since you can vote for more than one person I think this bias is eliminated. However, this same sort of bias can be introduced in the initial proposal/research stage, were it is likely those higher up on the list will receive more votes because more people will begin the research and as the votes progress, the number of people looking into the editors might decrease, so a random order would be best -- perhaps better still if it was somehow random for everyone, or daily. TiggerJay (talk) 05:55, 8 January 2025 (UTC)
• D per Novem Linguae. Callanecc (talk • contribs • logs) 06:46, 8 January 2025 (UTC)
• C per JuxtaposedJacob. We should not sacrifice fairness for the sake of convenience. JJP_Master (she/they) 12:53, 8 January 2025 (UTC)
• D > C I like randomization, but I also like easy cross-checking. --SarekOfVulcan (talk) 16:26, 8 January 2025 (UTC)
• D for voting, C for the rest per TiggerJay. QuicoleJR (talk) 16:36, 8 January 2025 (UTC)
• A' all polls should be randomly ordered L3X1 ◊distænt write◊ 16:57, 8 January 2025 (UTC)
• D. I have long been unconvinced that alphabetical order advantages particular candidates in Misplaced Pages elections. The phenomenon is known to affect English elections, but I find Wikipedians a more fastidious sort than the average British voter… arcticocean ■ 18:24, 8 January 2025 (UTC)

  If chronological does (which it did, see how much participation QoH got), then I don't see why alphabetical won't. Aaron Liu (talk) 19:22, 8 January 2025 (UTC)

  Chronological effect actually had little effect on the last election, overall. The candidate listed immediately after QOH finished nearly last. Alphabetical order would have little effect either, because there is simply no evidence that voters are blindly supporting the first n candidates, or that sequence of candidates creates an unfair advantage for anyone. arcticocean ■ 11:28, 9 January 2025 (UTC)

  I guess that's fair. I meant more participation and scrutiny, not more support, though. Aaron Liu (talk) 17:59, 9 January 2025 (UTC)

• D - Poli Sci people know that the first name on a ballot has an advantage over names lower on the list, but these candidates are each running Yes/No on their merits with no limit of "winners"... Carrite (talk) 19:42, 8 January 2025 (UTC)
• C, oppose all else — per CMC and Vanamonde, everything else is just demonstratively unfair. Choucas Bleu 🐦‍⬛ 00:08, 9 January 2025 (UTC)

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)

  I oppose Options F and G, which would make the AELECT discussion phase longer than RFA, and therefore more stressful for the candidates. That would be counter-productive to the goal of AELECT (to create a process LESS stressful than RFA). –Novem Linguae (talk) 21:40, 8 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 (block_talk) 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)
• F > G > E2 > E >>> C >>> A. RFA should be a democratic process. For that to work, we need to give voters a reasonable opportunity to actually obtain the information necessary to make informed choices -- including those voters who occasionally spend 72 hours away from Misplaced Pages. Making the process more comfortable for candidates is a good thing, but reducing scrutiny to provide that is not. --Blablubbs (talk) 16:11, 8 January 2025 (UTC)
• G. All the other options end discussion once voting begins or have too short a time for discussion before voting begins. Both are deeply undesirable, as the trial election has partly demonstrated. There should be 7 days for discussion, nothing shorter, and the discussion should continue for another 7 days while voting happens. arcticocean ■ 18:27, 8 January 2025 (UTC)
• E - Three days is not enough time, I know that for sure. Carrite (talk) 19:43, 8 January 2025 (UTC)
• F > C > A. To me, the discussion phase seemed a bit too short, and I think on balance, it's better to have a bit of overlap with the voting phase. My ideal discussion phase would be 2 days before the voting starts until 3 days into voting. I've never been convinced of the individual right to participate. The elections are about choosing good volunteers for adminship, not about franchise in my opinion. Unlike normal RfAs, the names are well advertised in advance during the sign-up phase, so you can prepare questions in advance (I certainly did). —Femke 🐦 (talk) 20:58, 8 January 2025 (UTC)
• F>E2>E. Needs to be long enough for people who only log in during certain days or times to participate. Eluchil404 (talk) 22:39, 8 January 2025 (UTC)
• C The trial 3-day period did feel a little rushed, and while that may be improved by having fewer candidates in the future, there's no guarantee of that. However, I am opposed to having discussion open while voting, which makes the whole thing a long ordeal for candidates, or else may lead to needless controversies involving people changing their votes. —Ganesha811 (talk) 22:41, 8 January 2025 (UTC)
• C>E ; oppose all else — per Tryptofish. Choucas Bleu 🐦‍⬛ 00:13, 9 January 2025 (UTC)
• E some people don't check this website every day L3X1 ◊distænt write◊ 18:44, 9 January 2025 (UTC)

Q16 Discussion (Discussion phase length)

• I wish there was an option for 5 days, concurrent with the voting phase. JuxtaposedJacob (talk) | :) | he/him | 18:12, 7 January 2025 (UTC)

  You can add the option if you like. Although maybe balance that decision with if you think other folks will also choose that option. –Novem Linguae (talk) 01:01, 8 January 2025 (UTC)

  Ehh, no big deal; I am confident that your guys' work at the workshop has produced a broadly-acceptable set of options. If someone else particularly wants to, I would be unopposed. JuxtaposedJacob (talk) | :) | he/him | 02:25, 8 January 2025 (UTC)

• Is there a reason these options are not labeled a,b,c,d etc? L3X1 ◊distænt write◊ 17:02, 8 January 2025 (UTC)

  Options got added and removed during the workshop, and I forgot to re-letter them. –Novem Linguae (talk) 21:41, 8 January 2025 (UTC)

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)

• Option A - The less stress and scrutiny on candidates, the better. The first administrator election was very successful. If it ain't broke, don't fix it. Let's not turn AELECT into RFA. The point of AELECT is to be different than RFA so that we can fix RFA's problems. –Novem Linguae (talk) 11:16, 7 January 2025 (UTC)
• Option A per Novem. Saying that "candidates are not obliged to answer them" doesn't actually work. If our goal is to reduce stress, we need to actually ban questions during the no-questions period. Toadspike 11:59, 7 January 2025 (UTC)
• A per NL, we shouldn't turn AELECT into RFA. Chaotic Enby (talk · contribs) 12:03, 7 January 2025 (UTC)
• A' per NL and Chaotic Enby. Thryduulf (talk) 12:44, 7 January 2025 (UTC)
• A, while discussion can continue, let's not keep the candidates on the hook. C would be nice, but I suspect Toadspike is right on its practicality. CMD (talk) 15:55, 7 January 2025 (UTC)
• A Per the others here, while I feel centralized discussion during the voting phase is important, the burden of additional days of questions is unwarranted. --Ahecht (TALK
  PAGE) 16:16, 7 January 2025 (UTC)
• A seems less stress. -Kj cheetham (talk) 16:19, 7 January 2025 (UTC)
• Option A per Novem Linguae.Pharaoh of the Wizards (talk) 16:46, 7 January 2025 (UTC)
• B No reason to stifle discussion here. * Pppery * _{it has begun...} 17:08, 7 January 2025 (UTC)
• Option A Per Novem. fanfanboy (block_talk) 18:20, 7 January 2025 (UTC)
• A. ~ ToBeFree (talk) 19:22, 7 January 2025 (UTC)
• A per NL. Perfect4th (talk) 21:03, 7 January 2025 (UTC)
• A. This isn't an ArbCom election, so let's not make it too much of an ordeal. --Tryptofish (talk) 23:18, 7 January 2025 (UTC)
• A. I had supported C during discussions, but was persuaded that it would not work in practice. Espresso Addict (talk) 23:44, 7 January 2025 (UTC)
• The question is If Q16 options F or G are chosen, so I guess I'd say B/C; it wouldn't make sense to allow people to complain about the candidates but prohibit people from asking them questions. But it doesn't really matter since F or G aren't likely to get consensus in the first place. Extraordinary Writ (talk) 00:24, 8 January 2025 (UTC)
• A. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A. I was going to vote option C, but NL and others convinced me that this would be the least amount of stress for the candidates. cyberdog958 02:55, 8 January 2025 (UTC)
• A strongly so. I think discussions while voting on things like this are not helpful, but rather getting efficiently through the response phase is helpful. TiggerJay (talk) 05:59, 8 January 2025 (UTC)
• A, as above. SilverLocust 💬 06:40, 8 January 2025 (UTC)
• A per above. Callanecc (talk • contribs • logs) 06:53, 8 January 2025 (UTC)
• Option A per Novem Linguae and Toadspike. ModernDayTrilobite (talk • contribs) 16:13, 8 January 2025 (UTC)
• A See my comment in the section above, this would just lead to discussion in a different form and cause issues. —Ganesha811 (talk) 22:42, 8 January 2025 (UTC)
• A per novem L3X1 ◊distænt write◊ 18:45, 9 January 2025 (UTC)

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)

• All of these options are fine. C is the de facto situation, A is the "ideal", choosing D and letting any uninvolved editor do what they can to help out might be most practical (and also kinda the de facto situation). Toadspike 12:06, 7 January 2025 (UTC)
• A I guess, but generally agree with Toadspike. If the Novem Linguae dictatorship stops working that can be discussed at a later point too. CMD (talk) 15:57, 7 January 2025 (UTC)
• D * Pppery * _{it has begun...} 17:08, 7 January 2025 (UTC)
• A per CMD, but with less uncertainty. JuxtaposedJacob (talk) | :) | he/him | 18:16, 7 January 2025 (UTC)
• Option A We had no problems. Maybe B or C? Option B or C > D. Novem is right, bureaucrats didn't do much in this election. fanfanboy (block_talk) 18:22, 7 January 2025 (UTC)

  It is my impression that the bureaucrats did not participate in the last AELECT though. Is it accurate to say that they supervise the election? –Novem Linguae (talk) 05:15, 8 January 2025 (UTC)

  I was on the fence about this one tbh, but you're right, I'll change my vote to something else. fanfanboy (block_talk) 23:46, 8 January 2025 (UTC)

• Option D: similar to the arbitration committee election, I feel it's an important aspect that the community runs the election. (Note the arbitration committee electoral commissioners do not supervise the arbitration committee election. The whole process is run by community volunteers, though these days there is typically overlap with the commissioners.) There's no need to have an explicit statement assigning supervisory duties to any single group. isaacl (talk) 18:31, 7 January 2025 (UTC)
• Whatever. isaacl's arguments sound good to me. ~ ToBeFree (talk) 19:24, 7 January 2025 (UTC)
• A, but reword. Certainly the grunt work (what ACE calls coördinating) should be done by Novem or whoever volunteers. But we also need a way to "deal with any unforeseen problems that may arise" (WP:ELECTCOM), and while talk-page discussion should resolve most issues, it's easy to see a situation where a decisive answer one way or the other is needed. The bureaucrats are in a good position to do that; selecting a separate electoral commission wouldn't be worth the trouble. Extraordinary Writ (talk) 20:20, 7 January 2025 (UTC)

  Do the bureaucrats even want the job? If we posted an issue at WP:BN in the middle of an election and asked them to solve it, would they have enough knowledge about the election, and be able to come to a consensus, and be able to act in a timely manner? –Novem Linguae (talk) 05:14, 8 January 2025 (UTC)

• Option D – it doesn't really make much of a difference, and agree with isaacl. That gives us a leeway for whatever we need to end up doing. Fine with Extraordinary Writ's suggestion too. Perfect4th (talk) 21:03, 7 January 2025 (UTC)
• C because I support the Novem Linguae dictatorship. I agree with Toadspike. (I was elected in AELECT, for disclosure.) charlotte 21:38, 7 January 2025 (UTC)
• D, but I don't feel strongly. My reaction is actually similar to what ToBeFree said. --Tryptofish (talk) 23:22, 7 January 2025 (UTC)
• D, oppose C. Not sure what there is for bureaucrats to do here. Espresso Addict (talk) 23:46, 7 January 2025 (UTC)
• D. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A. It didn't see like there was any issues the last time. cyberdog958 02:58, 8 January 2025 (UTC)
• Reworded A per Extraordinary Writ but also okay with D. To be honest, regardless of whether the crats want the job it should be theirs given it's directly related to the appointment of administrators. Callanecc (talk • contribs • logs) 06:58, 8 January 2025 (UTC)
• A Bureaucrats should be encouraged to be more involved in the process. Eluchil404 (talk) 22:40, 8 January 2025 (UTC)
• D In general, we should avoid the temptation to add unnecessary bureaucracy. Misplaced Pages is full of volunteers and people who like making an impact. We can let supervision emerge organically, and if it becomes necessary later on to do something more formal, we can do that then. —Ganesha811 (talk) 22:44, 8 January 2025 (UTC)
• D — per isaacl. Choucas Bleu 🐦‍⬛ 00:22, 9 January 2025 (UTC)
• C L3X1 ◊distænt write◊ 18:55, 9 January 2025 (UTC)

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)

  Note to closer: Please see all the +1's in the discussion section and consider incorporating that into your close. –Novem Linguae (talk) 21:44, 8 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 (block_talk) 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)
• Option A. The lower-friction nature of elections (vs. RFAs) means that we may face an increased risk of perennial candidates, but I can't imagine that will become so widespread a phenomenon as to make these restrictions necessary. Editors who use the admin elections process disruptively can always face individual sanctions, and good-faith users who have an unsuccessful election should not be penalized for taking a risk that didn't pan out. ModernDayTrilobite (talk • contribs) 16:25, 8 January 2025 (UTC)
• E seems fair. --SarekOfVulcan (talk) 16:29, 8 January 2025 (UTC)
• Option A because this is the kind of thing that should be dealt with case-by-case. Oppose D as unfair to candidates. Neutral on the other three. QuicoleJR (talk) 16:42, 8 January 2025 (UTC)
• A. But I could love with E. Eluchil404 (talk) 22:42, 8 January 2025 (UTC)
• A ; oppose all else — Everything other option is unfair and trying to fix issues that either do not exist or would be created by introducing avoidable flaws in the process. Choucas Bleu 🐦‍⬛ 00:27, 9 January 2025 (UTC)
• A: arcticocean ■ 08:37, 9 January 2025 (UTC)
• A. I think there's nothing inherently wrong with people rerunning. If it turns out that people do it repeatedly and disruptively, we can revisit this question, but now is too soon. Adumbrativus (talk) 11:41, 9 January 2025 (UTC)
• A per Soni. Aaron Liu (talk) 18:05, 9 January 2025 (UTC)
• A if someone knows they are going to make it through RfA they won't run, and you would have to have some gall to run in another election if you got smoked. L3X1 ◊distænt write◊ 18:58, 9 January 2025 (UTC)

Q19 Discussion (Participating in multiple elections)

• Abstaining from a "vote" due to my COI as a candidate in the first election. If a restriction is placed on running again, I suggest that is not put in place until after the next election (because candidates in the first trial were not warned it was their "only chance" and might have waited until a later election had they known). MarcGarver (talk) 11:31, 7 January 2025 (UTC).

  +1 Toadspike 12:13, 7 January 2025 (UTC)

  +1. -- asilvering (talk) 14:15, 7 January 2025 (UTC)

  Agree. JuxtaposedJacob (talk) | :) | he/him | 18:20, 7 January 2025 (UTC)

  Agree. Espresso Addict (talk) 23:54, 7 January 2025 (UTC)

  +1. --JBL (talk) 00:56, 8 January 2025 (UTC)

  +1 -- TiggerJay (talk) 06:03, 8 January 2025 (UTC)

  +1 --SarekOfVulcan (talk) 16:30, 8 January 2025 (UTC)

  Agreed. fanfanboy (block_talk) 23:41, 8 January 2025 (UTC)

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)
  • I also like Pbsouthwood's suggestion of seven (or maybe five) months, which is a clever way of being fair to people unavailable at certain times of year. Extraordinary Writ (talk) 00:44, 8 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 (block_talk) 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)

  I agree that if there is a maximum number of candidates imposed, and that ceiling is regularly reached, election frequency should be increased (or if there are a ton of failing candidates, higher thresholds for candidacy imposed). —Ganesha811 (talk) 22:47, 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)
• Option B feels appropriate at a gut level, but I agree with the other users saying that—regardless of where consensus lands—we should make it easy to change this if needed. Some commenters have also suggested a period such as 5 or 7 months that would allow election times to "drift" between different parts of the year, and I think that would be a good idea as well. ModernDayTrilobite (talk • contribs) 16:29, 8 January 2025 (UTC)
• C > B, with ability to schedule earlier if candidates are limited. --SarekOfVulcan (talk) 16:31, 8 January 2025 (UTC)
• Gonna say B. C risks spreading out the candidates too much, we want a good amount of agglomeration. I'm not expecting future elections to have as many candidates as the trial run. theleekycauldron (talk • she/her) 16:32, 8 January 2025 (UTC)
• Leaning C or B as a starting point, but I agree with EW that the "right" answer is going to come down to the size of the candidate pool in future iterations. I'm not a huge fan of any of the hard limits proposed in Qs 2 and 21, but I think it would be sensible to pick a number, and then use future iterations of AELECT to refine it so we end up with cohorts of around 10-20 candidates per round. --Blablubbs (talk) 16:43, 8 January 2025 (UTC)
• B > A > C. B would be ideal as frequent enough to not have to wait too long, but also not have candidates so spread out that it defeats the point of the election. D and E are way too frequent. QuicoleJR (talk) 16:45, 8 January 2025 (UTC)
• Option B. Six months seems about right. ~~ Jessintime (talk) 16:46, 8 January 2025 (UTC)
• C - Quarterly is about right. Carrite (talk) 19:44, 8 January 2025 (UTC)
• E or D as second choice. I think we'll get too many candidates if we have longer time frames. Eluchil404 (talk) 22:43, 8 January 2025 (UTC)
• B — per DoubleGrazing, with the assumption that we put the two periods at intelligent places (like beginning of April and of October) to minimize the disruption of taking time away for the candidates. Choucas Bleu 🐦‍⬛ 00:38, 9 January 2025 (UTC)
• B because it strikes a good balance between election fatigue and utility of the process. arcticocean ■ 08:39, 9 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)

• Option A. It's not fair to leave candidates high and dry after they've taken the vulnerable step of placing their name into contention. If we're consistently getting too few candidates, the burden for solving that problem should be placed on the community (by rejiggering the frequency of elections). Extraordinary Writ (talk) 11:14, 7 January 2025 (UTC)
• Option A - Like RFA, the candidate should have control over when exactly they run. –Novem Linguae (talk) 11:34, 7 January 2025 (UTC)
• Option A --C1K98V 11:57, 7 January 2025 (UTC)
• Option A -- per above. —Femke 🐦 (talk) 11:59, 7 January 2025 (UTC)
• A the frequency of elections can be adjusted if the candidate pool is too small or large. — xaosflux 12:04, 7 January 2025 (UTC)
• Option A. I oppose B for being ridiculous, and oppose C only slightly less. If a candidate has prepared themselves to run, we shouldn't call it off for reasons out of their control. Toadspike 12:20, 7 January 2025 (UTC)
• A' per Extraordinary Writ, Novem Linguae and Xoasflux. Thryduulf (talk) 12:56, 7 January 2025 (UTC)
• A per all above.· · · Peter Southwood : 12:58, 7 January 2025 (UTC)
• A Although I don't think it should be an absolute rule. There is a cost to editors time in setting up and running the election. So the could be times that skipping an election makes sense. -- LCU ActivelyDisinterested «@» °∆t° 13:01, 7 January 2025 (UTC)
• A, in the question of the immediate upcoming election. It can't get worse than an individual RfA after all. Slightly ambiguous question, my A vote does not mean however that the overall frequency shouldn't be adjusted to try and facilitate a certain minimum number of candidates (on the assumption we are deliberately trying for it to not to be individual RfAs). CMD (talk) 16:05, 7 January 2025 (UTC)
• A is fairest. Need some predicability. Though I can imagine some people may only want to do it when in a group rather than effectively on their own, but can see who has already signed up I imagine first. -Kj cheetham (talk) 16:22, 7 January 2025 (UTC)
• A: Let's run 'em. Hey man im josh (talk) 16:49, 7 January 2025 (UTC)
• Option A per Extraordinary Writ, Novem Linguae and Xaosflux.the elections should be conducted if candidates are available.Pharaoh of the Wizards (talk) 17:03, 7 January 2025 (UTC)
• A per KJ Cheetham. JuxtaposedJacob (talk) | :) | he/him | 18:23, 7 January 2025 (UTC)
• Option A Simple to implement. fanfanboy (block_talk) 18:30, 7 January 2025 (UTC)
• A. B would and C could damage the process by throwing away good candidates. ~ ToBeFree (talk) 19:29, 7 January 2025 (UTC)
• A per Extraordinary Writ; although this all sounds like a hypothetical. (I was elected in AELECT, for disclosure.) charlotte 21:41, 7 January 2025 (UTC)
• A as the non-silly option. Cremastra (u — c) 21:44, 7 January 2025 (UTC)
• A, with the caveat that candidates can drop out if they feel like there are too few other candidates. --Tryptofish (talk) 23:33, 7 January 2025 (UTC)
• A. Agree that candidates should have the ability to withdraw if they feel too exposed. Espresso Addict (talk) 00:02, 8 January 2025 (UTC)
• A. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A. The other options don't really make any sense to implement. cyberdog958 03:17, 8 January 2025 (UTC)
• A with the provisions of some sort of minimum participation is required, so that two electors don't slip by without much notice... TiggerJay (talk) 06:10, 8 January 2025 (UTC)
• A per Extraordinary Writ, Novem Linguae and Xoasflux. Callanecc (talk • contribs • logs) 07:03, 8 January 2025 (UTC)
• A, of course. We'll always need more admins. --SarekOfVulcan (talk) 16:34, 8 January 2025 (UTC)
• A is the only sane option here, B is patently absurd and C is just B Lite. QuicoleJR (talk) 16:46, 8 January 2025 (UTC)
• A ; oppose B and C — anything else would be ridiculously unfair. Choucas Bleu 🐦‍⬛ 00:39, 9 January 2025 (UTC)

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)

• oppose kinda feel like that defeats the purpose. theleekycauldron (talk • she/her) 11:02, 7 January 2025 (UTC)
• Option A - The first administrator election was very successful. If it ain't broke, don't fix it. Let's not turn AELECT into RFA. The point of AELECT is to be different than RFA so that we can fix RFA's problems. –Novem Linguae (talk) 11:35, 7 January 2025 (UTC)
• Option A - the thing that gave me most nerves in my RfA was to be opposed by people I respected. By not saying oppose or support, I think it's much easier to raise concerns without it coming across as an attack. The RfA systems reminds me of the adversarial legal system, making people take up the role of supporter or opposer. The strenght of the election is that we move more towards investigative discussions. —Femke 🐦 (talk) 12:05, 7 January 2025 (UTC)
• Option A. But while I oppose explicit s/o "votes" on the discussion page, non-neutral comments (when based on evidence) should be encouraged. Toadspike 12:23, 7 January 2025 (UTC)
• A per NL and Toadspike. Thryduulf (talk) 12:56, 7 January 2025 (UTC)
• Weak A, but agree with those commenting below that discussion is reasonable outside of create support and oppose sections. CMD (talk) 16:08, 7 January 2025 (UTC)
• A, although between this and recall petitions, it's seems like Wikipedians have a really hard time commenting without turning it into an additional voting venue. --Ahecht (TALK
  PAGE) 16:23, 7 January 2025 (UTC)
• A: I think it makes perfect sense to allow for folks to voice their opinion on a candidate, instead of attempting to remain as neutral as possible for a discussion. Voters are allowed to draw their own conclusions from the statements made by others. Hey man im josh (talk) 16:48, 7 January 2025 (UTC)
• Option A per Novem Linguae.Pharaoh of the Wizards (talk) 17:07, 7 January 2025 (UTC)
• A This seems silly and redundant. Basically per Josh. * Pppery * _{it has begun...} 17:09, 7 January 2025 (UTC)
• A Ignoring all the other arguments (with which I agree), I don't know what the threshold would be for brief and reasonable; it would increase community effort and time to have to deal with that. JuxtaposedJacob (talk) | :) | he/him | 18:28, 7 January 2025 (UTC)
• Option A Defeats the purpose of this process. fanfanboy (block_talk) 18:31, 7 January 2025 (UTC)
• A. We have RfA for that. ~ ToBeFree (talk) 19:31, 7 January 2025 (UTC)
• A per Novem. (I was elected in AELECT, for disclosure.) charlotte 21:42, 7 January 2025 (UTC)
• A. We should try hard to make it a discussion and not a vote. We cannot prevent editors from tipping their hands in comments, but we definitely should not encourage "voting" before the voting. --Tryptofish (talk) 23:35, 7 January 2025 (UTC)
• Weak A, but I think commenters should feel less intimidated about expressing polite, nuanced views on the candidate's suitability. Espresso Addict (talk) 00:07, 8 January 2025 (UTC)
• A. --JBL (talk) 00:56, 8 January 2025 (UTC)
• Option A. Allowing for bolded (or unbolded) votes would just turn this into a normal RfA and all the potential vitriol that brings. That would defeat the purpose. cyberdog958 03:20, 8 January 2025 (UTC)
• A given the voting process that would be essentially hidden until after all of the results are known (or perhaps only to whoever is providing oversight). There might be value (but it might require a lot of work) that if we enabled such a comment, that some election admin would review those and provide some sort of consolidated report privately to the nom advising them of general consensus about the editor (ie things brought up that will likely cause them to fail again in the future, or things for an approved admin to be cautious of as they get started because of prior behavior, etc) But that sure sounds like a lot of work, and of questionable value. TiggerJay (talk) 06:13, 8 January 2025 (UTC)
• A Defeats the purpose. Callanecc (talk • contribs • logs) 07:07, 8 January 2025 (UTC)
• A per cyberdog, !RFA. --SarekOfVulcan (talk) 16:35, 8 January 2025 (UTC)
• A B would defeat the entire purpose of the process. QuicoleJR (talk) 16:47, 8 January 2025 (UTC)
• A — of course not, defeats the entire purpose by bringing back the worse part of the RFA process that we are trying to supplement (and ideally eventually replace but that is just my personal wish there). Choucas Bleu 🐦‍⬛ 00:45, 9 January 2025 (UTC)
• Based on past elections (e.g. the Discussion pages for ACE), almost no voters would use such a feature. Option A: arcticocean ■ 08:41, 9 January 2025 (UTC)
• A to do otherwise would defeat the purpose. LEPRICAVARK (talk) 12:05, 9 January 2025 (UTC)

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)

• Misplaced Pages requests for comment