Wikipedia

Wikipedia talk:Administrator elections

(Redirected from Wikipedia talk:Administrator elections/October 2024/Voting phase)
Latest comment: 21 hours ago by Novem Linguae in topic Advertising the upcoming RFC
Learn more about this page

Results commentary

edit
Latest comment: 5 days ago23 comments17 people in discussion

My overall impression of the field of candidates was very positive, and I'm somewhat surprised that so many of them fell short of the support cutoff. Despite it not being a competition, I imagine that many voters may have felt pressure to avoid supporting more than half of the candidates. I think that even those who were unsuccessful should still feel proud to have been a part of such a strong field of candidates. signed, Rosguill talk 16:02, 31 July 2025 (UTC)Reply

Agree. That said, 9 out of 16 = 56% got elected, whereas in the previous (Oct-24) one 11 out of 32 = only 34% did. Of course, any number of factors could account for that difference. -- DoubleGrazing (talk) 16:10, 31 July 2025 (UTC)Reply
This is the second election in a row where the 65%-69.9% range of candidates was strong. We should look into RFCing a lowering of the pass threshold to 65% during the upcoming RFC phase. –Novem Linguae (talk) 16:37, 31 July 2025 (UTC)Reply
I don't know, if you're looking for breakpoints in the data there's +2.2%/-3.4% around 70% but only +0.8%/-0.4% around 65%. Unless you're willing to go all the way down to 60%, 70% seems like a natural break in the distribution. --Ahecht (TALK
PAGE) 17:02, 31 July 2025 (UTC)Reply
I think either fa should be raised from 65% or AE should be lowered to 65% Thanks,L3X1 ◊distænt write◊ 20:46, 31 July 2025 (UTC)Reply
What if we looked at both elections combined to see about a break point? SMasonGarrison 21:03, 31 July 2025 (UTC)Reply
If you include the last election, there's +1.66%/-1.09% around 70% and +0.79%/-0.25% around 65%. The largest breaks between 60% and 80% are 4.7% around 62%, 3.7% around 80%, and 2.7% around 70%. --Ahecht (TALK
PAGE) 17:12, 25 August 2025 (UTC)Reply
I'm glad that this time (unlike last time) there were enough questions/conversations that everyone who didn't pass has at least some understanding of why people opposed and where they can improve. I actually think these results are evidence that the 70% threshold is working exactly as it should, and I'll continue to oppose lowering it if another RfC on the topic is started. Extraordinary Writ (talk) 19:32, 31 July 2025 (UTC)Reply
Honestly speaking, I'm not sure why I got so many opposes. With RfA it would have been clear. —usernamekiran (talk) 21:42, 31 July 2025 (UTC)Reply
I feel similar. I wasn't really expecting to pass based on how things went in the discussion phase and what I observed off-Wiki, but I wasn't expecting it to be so low. A real downside to this method. If I stand again, it'll definitely be as an RfA. ~Darth StabroTalk • Contribs 22:40, 31 July 2025 (UTC)Reply
Yeah, several people I gave my wholehearted support to fell short for reasons I really can’t identify. EF5 22:46, 31 July 2025 (UTC)Reply
I share the perception that there were some well-qualified candidates who did not make it, and I want to encourage anyone who wants to, to run again, in either format. I feel that there were also some things that went very well this time, and that are worth noting. First, the results were compiled and made public very rapidly, and I want to thank everyone who worked on that. Also, I think that the process was reasonably successful in preventing obvious not-yet candidates from staying in before the start of voting. --Tryptofish (talk) 22:56, 31 July 2025 (UTC)Reply
this is like a solution to non-existent problem. With RfAs there is no need for scrutiny/compilation. The result are instantaneous. Same goes for not-yet candidates. RfAs can handle that pretty well. —usernamekiran (talk) 23:33, 31 July 2025 (UTC)Reply
Maybe there could be an optional short "Feedback from voters" phase where all candidates (whether successful or unsuccessful) can choose to receive feedback from voters after results are revealed. fanfanboy (blocktalk) 23:08, 31 July 2025 (UTC)Reply
That's an interesting idea, @Fanfanboy. Schazjmd (talk) 23:15, 31 July 2025 (UTC)Reply
I like that, too, so long as it's optional. --Tryptofish (talk) 23:26, 31 July 2025 (UTC)Reply
there is Wikipedia:Administrator elections/October 2024/Debrief. —usernamekiran (talk) 23:33, 31 July 2025 (UTC)Reply
The debrief for the October 2024 election was not intended to be place for candidates to receive feedback from voters, rather, it was a place for both candidates and voters to express what they thought went well/didn't go well with the process. The reason for the debrief was because the first AELECT was a trail election to see how it would work out, and we needed a place to discuss areas of the process that potentially needed changes so they could be included in the Phase II RFC. What I'm suggesting is an entirely different idea from the debrief. fanfanboy (blocktalk) 01:30, 1 August 2025 (UTC)Reply
Yes, optional as to not negate the reason AELECT exists in the first place. fanfanboy (blocktalk) 01:34, 1 August 2025 (UTC)Reply
I think there's a very strong case to be made by lowering the bar 7.5 points to a 62.5% pass rate. Looking at the top end of admin candidates, it's very common for a strong RFA candidate to sail through with 99/100% of the vote. At Aelect, there is a soft ceiling at 80% with only 3/48 candidates exceeding it, and a hard ceiling at 85% which nobody has yet exceeded. At the high end, AELECT is 15-20% harsher than RFA. Looking at the lower end, we have EggRoll97, who received 39.89% in the October 2024 election, kept his head up, and ran a RFA that ended with a no-consensus crat chat in April 2025 at 65.8% support. He certainly improved as a candidate in the interim, but it's likely that RFA was the kinder venue there as well by a substantial amount. There is a natural break in the data just below 65%, with 10 out of our 48 candidates scoring between 69.9% and 64.5%. Given that AELECT is harsher than RFA, those candidates probably should pass in the future. On the other hand, there was only 1 candidate between 65% and 56%, so that's a good natural gap to put the bar between "easily passes at RFA scrutiny: and "close call" Given that Aelect is a newer process, I'd be conservative, and put the bar near the top of that natural break at 62.5, which is a round fraction (5/8ths). Tazerdadog (talk) 00:08, 1 August 2025 (UTC)Reply

Ability to customize Wikipedia:Administrator elections/July 2025/Header

edit
Latest comment: 30 days ago2 comments2 people in discussion

Howdy. Can someone good with templates take a stab at adding a parameter to Wikipedia:Administrator elections/July 2025/Header such as |custom_message=, where I can add a custom message? Now that results are posted, I'd like to be able to update that. And I might want to update it again during the debrief phase, RFC workshop, and RFC phase. Thanks. –Novem Linguae (talk) 16:35, 31 July 2025 (UTC)Reply

@Novem Linguae: You can just modify the |status= parameter to remove {{Administrator elections status}} like I've done so here [1]. Due to [2], you need to add an asterisk or colon at the beginning of the text to make it look nice, but I think that should do what you want, right? Mz7 (talk) 18:06, 31 July 2025 (UTC)Reply

Discussion at Wikipedia:Administrator elections/July 2025/Debrief

edit
Latest comment: 30 days ago1 comment1 person in discussion

  You are invited to join the discussion at Wikipedia:Administrator elections/July 2025/Debrief. –Novem Linguae (talk) 23:58, 31 July 2025 (UTC)Reply

Order of Support/Oppose/Abstain

edit
Latest comment: 28 days ago17 comments8 people in discussion

Currently the Wikipedia:Administrator elections/July 2025/Results page shows the results as Support/Abstain/Oppose instead of the historically used Support/Oppose/Abstain order that has been used for RFAs forever. I understand from @Novem Linguae that somewhere here there was a discussion to keep this AE results like it is on the ballot, but I think internal consistency within our pages should take precedent. Especially as we have some pages, like the Wikipedia:Successful adminship candidacies/2024 and Wikipedia:Unsuccessful adminship candidacies (Chronological)/2024 pages, where we show both RFA and AElect results and show the tally there in consistent order of Support/Oppose/Abstain.

Support/Oppose/Abstain is also the general order that most votes are tallied/presented in government chambers (e.g. US Congress - which shows them as Yay / Nay / Present / Not Voting. Or WP:ARBCOM which also shows them as Support / Oppose / Abstain (e.g. latest Arbcom case.

So basically we use "Support/Oppose/Abstain" everywhere on wiki except here - so I'm gonna invoke Wikipedia:Consistency and would ask to reconsider so we can bring the results page here in line with other use on Wiki to avoid confusion :) Raladic (talk) 04:47, 1 August 2025 (UTC)Reply

The status quo ante was neither of the options presented here. The status quo ante was oppose/abstain/support, to match the order of the columns in SecurePoll. The order of those columns in SecurePoll was the result of previous discussion. I'd recommend reverting to that order on the results page while this discussion takes place. I'm also not a big fan of folks messing with these results too much. What if a typo or miscalculation is made during refactoring? Then it looks like the scrutineers certified something that they did not. –Novem Linguae (talk) 05:02, 1 August 2025 (UTC)Reply
I already reverted the column order (using the template).
I did also (as I noted in my edit summary) triplecheck the results to ensure that no typo or miscalculation was made (the % were helpful to crosscheck the support/abstains as I was replacing them one by one and had matching % in the preview to know it was right).
I just didn't realize the results page wasn't already using a row template since pretty much everything else around adminship stuff has some and I had created Template:AdErow last year for the October election already for the Wikipedia:Successful adminship candidacies/2024 page (which as I mentioned above, necessitates the columns being in sync with the status quo since 2003.
So, I get that the securepoll has some other order (and that was part of some discussion I missed), but it seems rather counter-intuitive, given that it is the opposite of pretty much every ballot sheet I've ever seen.
Support is always first, followed by Oppose and either you leave them blank, or there's a 3rd box thereafter for abstaining.
If you have the links handy, I'd love to see that old discussion as it does seem puzzling. Raladic (talk) 05:14, 1 August 2025 (UTC)Reply
I already reverted the column order (using the template). The column order is currently support-abstain-oppose. When I originally posted these results, the column order was oppose-abstain-support. My attempt to put it back in this order was reverted by you, I believe.
If you have the links handy, I'd love to see that old discussion as it does seem puzzling. Wikipedia talk:Administrator elections/Archive 6#Column order –Novem Linguae (talk) 05:23, 1 August 2025 (UTC)Reply
No, that order of Oppose-Abstain-Support was changed to Support-Abstain-Oppose by @Extraordinary Writ - here.
I made my template conform to that. I didn't realize you want to go and introduce a different 3rd different order for the results page.
I do understand the psychology for during the voting due to limitations of the voting software, but we do not need to limit our resulting outcome pages to that. No one cares about how the voting software was structured once we look at the results tally and I think we should show the results tally in the usual order of modern election tallies, aka Support/Oppose/Abstain. Raladic (talk) 05:29, 1 August 2025 (UTC)Reply
Personally, I don't think the column order on the results page has to match the order on the ballot. Some of the considerations for the ballot (matching the arbitration committee election ballot, layout limitations) don't apply to the results page. Thus I think matching how the results are displayed on the RfA page and arbitration committee election pages is reasonable. isaacl (talk) 05:29, 1 August 2025 (UTC)Reply
Yup - agree and just made the same point above.
I think it's fine that the secure poll is set up to have Oppose and Support be visually separated by the neutral abstention in the middle. But I don't think we should stick to that for the results page.
(Personally I do feel that on the voting page support should be first and Oppose at the end, but that's a separate discussion that doesn't need to happen here, though I take your comment I saw from that other discussion that that order for the voting software is consistent with how it's presented for Arbcom member vote, so maybe we'll just keep that one as it is). Raladic (talk) 05:31, 1 August 2025 (UTC)Reply
I don't really mind whether we use Support/Abstain/Oppose (like ArbCom election results) or Support/Oppose/Abstain (like everything else). But yeah, I found it very confusing to do Oppose/Abstain/Support: it's one thing to do it like that on the ballot, but the results don't need to be the same way (as in ArbCom elections, where the ballot is O/A/S but the results are S/A/O). I don't think there's anywhere else on Wikipedia where we report results starting with Oppose. Extraordinary Writ (talk) 05:37, 1 August 2025 (UTC)Reply
Reminder: Abstain (in the election) =/= Neutral (in an RFA). — xaosflux Talk 09:30, 1 August 2025 (UTC)Reply
Yay, Nay, Abstentions, is how it’s done. SmokeyJoe (talk) 09:34, 1 August 2025 (UTC)Reply
My point is that "Neutral" in an RFA is still someone actively taking point in the discussion. "Abstain" in the election is someone specifically not taking part in the decision for a candidate. — xaosflux Talk 09:57, 1 August 2025 (UTC)Reply
A secret vote is not active participation in a discussion. SmokeyJoe (talk) 01:42, 2 August 2025 (UTC)Reply
I don't care about the way the results are ordered. But I am wondering if, for future ballots, it might be worth changing the order from "oppose, abstain, support" to "support, abstain, oppose". Something that seems clear (at least to me) from the results is that voters trended towards opposing much more than what typically happens in traditional RfA. Perhaps, having "oppose" as the left-hand column has a psychological effect, and it might be worthwhile to reverse that. --Tryptofish (talk) 14:17, 1 August 2025 (UTC)Reply
I suspect it is more that those voting oppose in the election don't need to worry about having to defend their position later. In traditional RFA's while supporters are mostly ignored, a significant number of opposers spawn discussions about their individual stances. — xaosflux Talk 14:43, 1 August 2025 (UTC)Reply
Yeah, who would have thunk it? The way to make RfA less toxic is to allow badgering of opposes. But, seriously, I find it hard to believe that the number of editors who hold back from opposing in traditional RfA would be large enough to account for the voting numbers in the election. --Tryptofish (talk) 22:22, 1 August 2025 (UTC)Reply
There is a good argument that the election is by far "less toxic" for opposers, which far outnumber candidates. — xaosflux Talk 17:51, 2 August 2025 (UTC)Reply
I did almost vote oppose for all of the candidates I was intending to support until I did a double check of my ballot. signed, Rosguill talk 18:10, 2 August 2025 (UTC)Reply

Unlisted candidates

edit
Latest comment: 28 days ago6 comments5 people in discussion

There are still four unlisted candidates, namely Wikipedia:Administrator elections/July 2025/Candidates/A.FLOCK, Wikipedia:Administrator elections/July 2025/Candidates/Aaron-yabloko, Wikipedia:Administrator elections/July 2025/Candidates/Cloventt (already moved to userspace), and Wikipedia:Administrator elections/July 2025/Candidates/Lewis4482000. We still need to find out what we should do with those four pages. One suggestion would be to move three of those four pages to userspace (without leaving a redirect behind) like Cloventt already did and delete the redirect from Cloventt's subpage. Another suggestion would be to IAR delete the three pages that were not already userfied, together with the redirect from Cloventt's subpage. GTrang (talk) 17:09, 2 August 2025 (UTC)Reply

We could also just leave them there. They're not hurting anything. They're not listed on the main candidate page, so the only way someone could find them is through a subpage search. –Novem Linguae (talk) 18:22, 2 August 2025 (UTC)Reply
We should update Wikipedia:Administrator_elections/July_2025#Withdrawing though, because right now we're saying they should be WP:SPD'd since they withdrawn/removed prior to the discussion phase.
I do think GTrangs suggestion to userfy them by default without a redirect would be the easiest thing.
We do also need to remove the Category from the pages as the currently show up at Category:Wikipedia administrator elections July 2025 candidates (I'll go do that right now. Raladic (talk) 18:24, 2 August 2025 (UTC)Reply
I agree with Novem that the best solution is to do nothing (aside from removing those categories, which you have correctly done already). I think the current wording at Wikipedia:Administrator_elections/July_2025#Withdrawing is fine: we can still ask people to request WP:G7 (author-requested deletion) for their unlisted candidate subpages, but if they don't do that, then there's no harm in just leaving it there. Mz7 (talk) 23:54, 2 August 2025 (UTC)Reply
Would we maybe want to move them to a subpage structure though to make it clear they were not actually running in the election?
Like Wikipedia:Administrator elections/July 2025/Candidates/Withdrawn before Discussion Phase? Raladic (talk) 00:29, 3 August 2025 (UTC)Reply
Personally, I think people checking manually will generally look at the candidates page to see who ran. I think only categorizing actual candidate pages should suffice to support tools looking for a list of candidates. isaacl (talk) 03:26, 3 August 2025 (UTC)Reply

election guides

edit
Latest comment: 26 days ago11 comments7 people in discussion

The candidate discussion page said Please do not cast votes or issue any declarations of support/opposition here. Yet there were "guides" declaring support/oppose like this, and this. I am not opposed to actual guides that are neutral like by FemkeAsilvering, Novem, and others. But the two pages above are clear declarations of votes. Why is this this permitted? This is against the spirit of EFA. —usernamekiran (talk) 05:36, 3 August 2025 (UTC)Reply

Please see Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections#c-Barkeep49-20250206190800-Q6: Voter guides (main election page linking to unofficial guides) for context. There was a consensus found that unofficial voting guides are fine. What the sentence you’re referring to at the individual candidates pages means is that we don’t want endorsements on the candidate page discuss discussions. Raladic (talk) 07:07, 3 August 2025 (UTC)Reply
The sentence you're quoting is just guidance about the purpose of that specific part of the page (hence the "here"). It's mainly just to make sure people don't treat the discussion phase like RFA, and post stuff like "Support - I already thought they were an admin!" or whatever. People are still allowed to disclose who they are planning to vote for elsewhere. BugGhost 🦗👻 07:47, 3 August 2025 (UTC)Reply
you are missing the big picture. There was a reason why secret ballot was chosen. The discussion linked above discusses about voter guides. The pages I linked above can't be considered as voter guides. They are outright endorsements/support-oppose declarations. User:Novem Linguae/Essays/2025 administrator election voter guide, and User:Asilvering/AFD notes for July 2025 EFA are actual voter guides. —usernamekiran (talk) 09:07, 3 August 2025 (UTC)Reply
Secret ballot doesn't mean individuals are bound to secrecy as to their votes, it means that votes are by default secret. Every one of the linked examples you've provided is a valid voter guide. ThadeusOfNazereth(he/him)Talk to Me! 10:38, 3 August 2025 (UTC)Reply
you are missing the big picture - I don't think I am, I have been involved in AELECT since before the trial and this has been discussed multiple times, and I am not aware of any community consensus to require people to conceal their voting intentions. Based on previous discussions, I don't think a proposal to create that requirement would get much traction. BugGhost 🦗👻 14:12, 3 August 2025 (UTC)Reply
I know I keep saying this like a broken record, but the voter guides are a net negative. I realize that, with numerous candidates, many editors are eager to have ways to simplify the process of choosing, but I think the existing consensus should be reexamined before the next election. --Tryptofish (talk) 16:05, 3 August 2025 (UTC)Reply
It's going to happen, on-wiki or off-wiki. I appreciate the on-wiki guides even if they didn't recommend me because I got a feel for why someone might not choose to support me, and I'm able to look into that now if I choose to stand again later. The election process gives startlingly little feedback. ~Darth StabroTalk • Contribs 16:41, 3 August 2025 (UTC)Reply
@Bugghost: I did not mean to offend you. On side note, I have been active in RfA reform (generalised discussions to improve RfA) in 2017-18. I have been observing the AE related discussions as well, I haven't commented much there though. If the participants aren't allowed to display their vote on discussion page, then displaying it somewhere else (with or without rationale) before voting period is over, is swaying the election. It is similar to voting in RfA with only difference being commenting it on userpage instead of actual page. Then whats the point of going through all that trouble of AE (for candidates, scrutineers, participants, tech-team, and everybody). That's what I'm saying. —usernamekiran (talk) 16:41, 4 August 2025 (UTC)Reply
Don't worry, no offense taken, was just clarifying. As far as I am aware, participants are allowed to make their voting intentions obvious on discussion pages, and are also allowed to "sway" the election (what else is the purpose of nominators?), and it's pretty common thing to do (eg. comments like this are perfectly fine). The benefit of AELECT over RFA is that support/oppose comments aren't necessary, and so the discussion isn't a boolean two-tribes decision. These aspects lower the temperature a lot - but it doesn't bind anyone to secrecy. BugGhost 🦗👻 17:16, 4 August 2025 (UTC)Reply
The reason I made a "guide" this year round is cause my understanding was that the community had significantly softened its stance on "do not explicitly endorse candidates" (based on the consensus at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections#c-Barkeep49-20250206190800-Q6: Voter guides (main election page linking to unofficial guides). I typically rarely promote my voting guide, they serve as a place for me to point to when asked the question "how did/do you plan on voting in X election" and they are a way for me to reflect on my personal compass and how they stack against the community. For me, it's more for my personal documentation/archival than persuasion. Sohom (talk) 00:28, 4 August 2025 (UTC)Reply

CSRF and duplicates

edit
Latest comment: 12 days ago2 comments2 people in discussion

I'm just writing this FYI for the future scrutes (see also phab:T397819). The 'CSRF' and 'Duplicate' columns were empty while scrutineering the test election, and there was some speculation they may be something related to global elections. We had examples appearing in both columns for the July 2025 admin election. There were five CSRF failures labelled 'Failed'. The scrutineers did not strike these votes. A successful CSRF basically means you're logged in, and you return the edit token provided to you by the voting page. A failed CSRF could be caused by a few things, most of them bug-related. Timeout (taking too long to vote) could be one option, but I see that the token is valid for 30 days. The worst case scenario is probably some hacker tricking a user into voting from another site. This seems relatively unlikely, both generally and in these cases. The Duplicate column contained 'Dup cookies' for one user who had their account renamed during the election (and did not vote twice). You can see which account name has the other cookie by looking at the vote details. -- zzuuzz (talk) 21:45, 3 August 2025 (UTC)Reply

CSRF tokens are not valid for 30 days. The expiry is based on how long the php session remains active, which is mostly random. It is quite possible for it to become invalid if a user takes too long to vote (though not for all users who take too long to vote).
"Dup cookies" is shown in the duplicate column when two users visit the voting page from the same device (hence share the same cookie), which makes it quite likely they're socks. Renames can indeed cause false positives because names are used instead of ids to tell differentiate users (this is because in global elections, the same user can have multiple ids as they could vote from multiple wikis). – SD0001 (talk) 17:49, 18 August 2025 (UTC)Reply

Discussion at Wikipedia:Administrator elections/July 2025/RFC workshop

edit
Latest comment: 10 days ago1 comment1 person in discussion

  You are invited to join the discussion at Wikipedia:Administrator elections/July 2025/RFC workshop. –Novem Linguae (talk) 08:12, 21 August 2025 (UTC)Reply

AELECT3 proposed dates

edit
Latest comment: 5 days ago22 comments10 people in discussion
This has been added to the upcoming RFC. Best to centralize discussion there rather than debate it twice. –Novem Linguae (talk) 08:02, 26 August 2025 (UTC)Reply

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

AELECT3 is supposed to be in December (+5 months after AELECT2, per RFC). I propose the following dates to pencil in:

  • Tue Nov 25 - Call for Candidates
  • Tue Dec 2 - SecurePoll setup
  • Thu Dec 4 - Discussion phase
  • Tue Dec 9 - Voting phase
  • Tue Dec 16 - Scrutineering phase

This bleeds into November a bit, and the Call for Candidates is over the USA Thanksgiving holiday. But the alternative is to have the Scrutineering Phase overlap with Christmas a bit, which isn't great for our candidates or our scrutineers.

Do these dates look OK as a rough draft? Thanks. –Novem Linguae (talk) 00:44, 25 August 2025 (UTC)Reply

Although subject to change based on the arbitration committee election request for comments discussion, for reference the current projected timeline for the arbitration committee election is as follows:
  • Nomination period: November 2–11
  • Voting period: November 18–December 1
isaacl (talk) 00:53, 25 August 2025 (UTC)Reply
(edit conflict) The provisional dates for WP:ACE2025 have the voting period from 18 November to 1 December. I don't think that this overlapping with the AELECT call for candidates is a problem. It's worth noting that there is likely going to be a proposal in the RFC to shorten the voting period, if that passes then there may be no overlap at all (it's currently undiscussed whether it will be proposed to move the start or end of the elections) Thryduulf (talk) 00:56, 25 August 2025 (UTC)Reply
I think asking the community to participate in two high research high impact votes in such a short period of time is not ideal. Best, Barkeep49 (talk) 03:02, 25 August 2025 (UTC)Reply
Another option is to push AELECT3 to January. Would that be superior? That would avoid conflicts with ACE and with Christmas. –Novem Linguae (talk) 03:13, 25 August 2025 (UTC)Reply
Yes, I think pushing AELECT3 to Jan might be better in this case. That way, there's no risk of overlapping with ArbCom election and it also avoids the whole end of November and month of November time issue, given that there's the holidays around that time that a good chunk of people of the English-speaking world, which makes up a good chunk of the en-wiki editor base, might observe those and may have family obligations.
And that way, we could hold theoretically AELECT4 six months later in July 2026 thereafter (if we assume that the twice-a-year thing is going to stick) - so they'd be evenly spaced out by 6 months, which in theory we could then actually rinse-and-repeat assuming that the post-AELECT review and refinement of procedures will get less and less as it gets more routine with each instance. Thoughts? Raladic (talk) 07:48, 25 August 2025 (UTC)Reply
The rationale for 5 months was so that they wouldn't always happen on the same months. I think that logic still holds water. -- DoubleGrazing (talk) 07:58, 25 August 2025 (UTC)Reply
Yes, I think January would work better on this occasion. -- DoubleGrazing (talk) 07:59, 25 August 2025 (UTC)Reply
I don't think the overlap with American Thanksgiving is a problem. The whole point of the 5-month cycle is that some dates may be inconvenient for some editors, but the following year will avoid those inconveniences. --Ahecht (TALK
PAGE) 13:39, 25 August 2025 (UTC)Reply
I am good with the Nov-Dec dates as suggested initially.
No issues with having the elections over holidays of some. (heck, my RfA was over the Christmas/New Year week). Sooner or later, the elections will hit the major holidays of my country as well. – robertsky (talk) 07:53, 26 August 2025 (UTC)Reply

Revised date proposal:

  • Tue Jan 6 - Call for Candidates
  • Tue Jan 13 - SecurePoll setup
  • Thu Jan 15 - Discussion phase
  • Tue Jan 20 - Voting phase
  • Tue Jan 27 - Scrutineering phase

Comments welcome. –Novem Linguae (talk) 08:02, 25 August 2025 (UTC)Reply

I think that is too late per the RFC. Call for Candidates was started on July 9th, so a January 6th start would be 181 days afterwards. (Dumb question, but the only specific period is that discussion must lasts seven days (Apparently, I can't count the days from January 15th to January 20th...) and must be followed by voting, right?) --Super Goku V (talk) 08:56, 25 August 2025 (UTC)Reply
Sigh. Guess we'll have to RFC this then. Will add it to the RFC workshop. –Novem Linguae (talk) 08:58, 25 August 2025 (UTC)Reply
Wikipedia:Administrator elections/July 2025/RFC workshop#Q10. Next election date –Novem Linguae (talk) 09:03, 25 August 2025 (UTC)Reply
I went back to the RfC. The question as written was, "Ideally, how often should administrator elections be held?" Given the usage of ideally, it seems to be fine to have one that is a bit longer than five months. Sorry for all the trouble, Super Goku V (talk) 09:18, 25 August 2025 (UTC)Reply
the only specific period is that discussion must lasts seven days and must be followed by voting, right? The call for candidates is a week, SecurePoll setup is 2 days, discussion phase is 5 days, voting phase is 7 days, scrutineering phase was around 2 days for AELECT2. All in all, need around 3.5 weeks to do everything. –Novem Linguae (talk) 09:08, 25 August 2025 (UTC)Reply
Figured, but I was hoping that it wasn't set in stone to see if adding a few days here and there would still make it work. (Also, I don't know why I said seven instead of five.) --Super Goku V (talk) 09:18, 25 August 2025 (UTC)Reply
As I mentioned above, I think we should stick to the 5 month cycle. Yes, you avoid American Thanksgiving, but you're now hitting Epiphany and Eastern-Orthodox Christmas. --Ahecht (TALK
PAGE) 13:41, 25 August 2025 (UTC)Reply
We are giving people several months notice re these elections, if the call for candidates overlaps with a US holiday, surely candidates can just get their drafts prepared a day or more earlier. The discussion phase is different as candidates may want to respond, so that should avoid a clash with anything that would mean a significant proportion of candidates had days offline for a big real life event. To some extent the same is true of the voting phase, or rather it needs to include dates when everyone is available, even if there are a couple of days when members of various faith, sport or cultural groups will be offline. As for the scrutineers, would we have a problem if one year they said the scrutiny phase needs an extra weekend because we were all watching Wimbledon/off at Glastonbury/Involved in last weekend's alien invasion? We may actually find that some of them have some slack time around Christmas, especially if the team has more people than the minimum needed for one scrutiny. So I'd be inclined to go with the post Arbcom December dates suggested earlier. ϢereSpielChequers 16:24, 25 August 2025 (UTC)Reply
It's not so much the overlap with holidays, inasmuch as it is the overlap with the ArbCom election that will be right in the middle of the original schedule.
That's a lot of things to review in parallel. Raladic (talk) 17:25, 25 August 2025 (UTC)Reply
As per the top of the thread, an Arbcom Voting period of November 18–December 1 wouldn't overlap with the discussion phase of the RFA election. I don't see a problem if there is an overlap involving different people or software. For example the scrutiny of one and the nominations of another. I'm not disputing that the voting and discussion parts can't overlap. ϢereSpielChequers 07:39, 26 August 2025 (UTC)Reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Advertising the upcoming RFC

edit
Latest comment: 21 hours ago13 comments7 people in discussion

Howdy folks. The workshop has slowed down and can probably be closed soon. When the workshop is closed, we will launch the RFC phase. How widely do you think we should advertise the RFC phase?

Minimum:

Possible other places to advertise: (defaulting to no unless asked for in this talk page section):

  • watchlist notice
  • talk pages or noticeboards not mentioned above

I think this RFC is important to AELECT folks such as the watchers of this talk page, but may be less important to the wider wiki. So I'm actually leaning against advertising at all the above places, but am happy to be convinced. Thoughts? –Novem Linguae (talk) 22:27, 26 August 2025 (UTC)Reply

I'm puzzled by you listing WT:RFC, since the RfC tag is what is important. I think a watchlist notice or any kind of banner would be overkill. But listing it on CENT might be a good idea. --Tryptofish (talk) 22:31, 26 August 2025 (UTC)Reply
Typo. I meant WT:RFA. Thanks for catching. Fixed :) –Novem Linguae (talk) 22:48, 26 August 2025 (UTC)Reply
I would agree, for almost all of the RFC questions, except for one, which is so weighty that I think T:CENT or similar would be a good idea. Purely because one of the RFC questions is the pass percentage I think slightly wider advertisement is warranted. Leijurv (talk) 22:33, 26 August 2025 (UTC)Reply
Sounds good. Let's put it on T:CENT since folks are asking for it. I edited my post to reflect that. –Novem Linguae (talk) 22:49, 26 August 2025 (UTC)Reply
I think AELECT MMS might be a good idea, people wishing to comment probably have put their names on it, and might be benefited from the notice.
Maybe WT:ADMIN as well? (feel free to ignore if others say it's not needed) ~/Bunnypranav:<ping> 05:58, 27 August 2025 (UTC)Reply
  Done –Novem Linguae (talk) 17:06, 30 August 2025 (UTC)Reply
Yeah I agree, people signed up on the mailing list for a reason, so letting them know is probably a good idea. fanfanboy (blocktalk) 12:14, 27 August 2025 (UTC)Reply
Sounds good. Will do the MMS. –Novem Linguae (talk) 18:42, 27 August 2025 (UTC)Reply
I think a short invitation on the administrators’ noticeboard would make sense. Perfect4th (talk) 13:05, 27 August 2025 (UTC)Reply
  Done –Novem Linguae (talk) 17:06, 30 August 2025 (UTC)Reply
If there is a question about the pass percentage for reconfirmation elections (see new discussion about Q1) then WT:RECALL should be added to the notification list. Thryduulf (talk) 22:34, 28 August 2025 (UTC)Reply
Sure. Added. –Novem Linguae (talk) 04:06, 29 August 2025 (UTC)Reply
Add topic
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Administrator_elections&oldid=1308637666"