Administrator elections

This is the talk page for discussing improvements to the Administrator elections page.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives: 1, 2, 3, 4, 5: 30 days

Discussion at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections

You are invited to join the discussion at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections. –Novem Linguae (talk) 10:16, 7 January 2025 (UTC)[reply]

Next steps

Now that the RfCs at WP:Requests for adminship/2024 review/Phase II/Administrator elections have been closed, the next step would be to hold the Renewal RfC per WT:Administrator elections#Planning for post debrief above. Before we do that, the new rules decided in Phase II should be collected somewhere, so that folks commenting in the Renewal RfC can see them in full. We should probably move the current content of this page, WP:AELECT, to a subpage for the October 2024 election. Then, we can rewrite this page as a general summary of the revised AELECT process. Toadspike [Talk] 05:23, 7 February 2025 (UTC)[reply]

Completely agree. I plan to do all that unless somebody gets to it first. I'm leaning towards a copy paste move to the subpage, keeping all the history at Wikipedia:Administrator elections rather than the subpage. –Novem Linguae (talk) 05:42, 7 February 2025 (UTC)[reply]

Apologies Novem, I got there first ;) I've added a pretty brief summary of the RFC results to the page, and I've updated Wikipedia:Administrator elections/October 2024 to be about the trial election (it previously was just a redirect to WP:AELECT) - I did a simple copy/paste move like you suggested, and am now editing it down to size. I'll continue tidying up Wikipedia:Administrator elections/October 2024, but the main admin election page should now be free to be just about the process itself, rather than the trial election. BugGhost 🦗👻 19:00, 10 February 2025 (UTC)[reply]

Wikipedia:Administrator elections/October 2024 is now in ok shape, and so I've removed details about the trial election from WP:AELECT (such as the schedule, results page, the list of scrutineers, etc) and placed an {{about}} template at the top to direct anyone who wants info on the trial election, rather than the AELECT process generally. The wording on the rules and implementation needs updating for the proposal. I'm probably going to leave this for tonight, but might pick this up again tomorrow. BugGhost 🦗👻 20:37, 10 February 2025 (UTC)[reply]

This all looks great. Thanks for your help! –Novem Linguae (talk) 09:54, 11 February 2025 (UTC)[reply]

Next cycle

If we're going to try to do the next election 5 months after the previous one, are we basically at the point pretty much right now where we should be announcing when the signup period starts? Valereee (talk) 02:07, 11 February 2025 (UTC)[reply]

I believe we have to do the full process reauthorization RFC first. Not sure where that would leave the schedule, though. Perfect4th (talk) 02:13, 11 February 2025 (UTC)[reply]

@Perfect4th, sorry, I'm clearly missing something...full process reauthorization RfC? Valereee (talk) 02:18, 11 February 2025 (UTC)[reply]

Valereee, I don't see anything explicitly stated on WP:AELECT at the moment, but the recent RFC for workshopping election details says 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. Seems to have also been discussed in #Planning for post debrief above (which of course I saw only after I chased more obscure revisions). Happy editing, Perfect4th (talk) 02:23, 11 February 2025 (UTC)[reply]

Hm...not actually sure what that even means. @Novem Linguae, can you translate? Valereee (talk) 02:51, 11 February 2025 (UTC)[reply]

The 2024 RfA review proposal only resulted in admin elections being approved for a one-time trial run. We need the community to approve it again to make it a permanent feature. Toadspike [Talk] 03:02, 11 February 2025 (UTC)[reply]

Good grief. Valereee (talk) 03:09, 11 February 2025 (UTC)[reply]

I've got a feeling it will snow-yes, based on the community feedback. Hopefully it won't be much of a timesink BugGhost 🦗👻 07:51, 11 February 2025 (UTC)[reply]

I also think the RFC will pass easily. Hopefully an infinite renewal, not just an additional trial. There's probably multiple blockers for the next election though:

renewal RFC
WMF needs to make a couple changes to the SecurePoll software, then permit it to be used locally on enwiki (phab:T378287, phab:T384302). WMF recently hired contractors to work on SecurePoll, so I think this will move forward shortly.

Once those are cleared, it should be easy to turn this into a recurring process.

I purposely put the word "ideally" into the RFC question about how often to have admin elections. I think the next election will happen whenever all the blockers are solved, then after that we can try to hit the 5 month cadence a little more strictly. –Novem Linguae (talk) 10:06, 11 February 2025 (UTC)[reply]

Renewal RFC planning

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.

I think the main administrator election page has now been updated to incorporate the results of the mini RFCs. I'll pause for a day or two to let people copy edit / tweak the page, then I think we should be all set to launch an RFC authorizing future administrator elections.

We can make it a simple yes/no question: "Now that the one time trial is complete, are Wikipedia:Administrator elections authorized to continue indefinitely?" This wording sound OK?

Do folks have any preference on if we should hold the RFC on this talk page, on an AELECT subpage, or on a WP:Requests for adminship/2024 review/Phase II/ subpage? cc @Theleekycauldron. –Novem Linguae (talk) 10:52, 11 February 2025 (UTC)[reply]

RFC location

I believe we agreed that Phase II was the best page for the reauthorization RfC, @Novem Linguae :) theleekycauldron (talk • she/her) 11:25, 11 February 2025 (UTC)[reply]

@Theleekycauldron. I don't recall agreeing to having both RFCs be in phase 2, but I dont mind since no one so far has objected. Would you like to create the sub page now and link to it here? Can you please put a notice that says that the RFC is a draft and is not open yet? Thanks in advance. –Novem Linguae (talk) 19:25, 11 February 2025 (UTC)[reply]

@Novem Linguae: I'm so sorry, you're totally right! Forgot that the mini-RfCs already went there. Happy to create it there, but if you have a different preference, that works for me too. theleekycauldron (talk • she/her) 21:47, 11 February 2025 (UTC)[reply]

@Theleekycauldron. No worries. Maybe a different (fresh, blank) phase 2 or phase 3 subpage than the mini-RFCs? –Novem Linguae (talk) 22:06, 11 February 2025 (UTC)[reply]

Phase 3 subpage seems simple and clearest. Soni (talk) 13:38, 12 February 2025 (UTC)[reply]

As soon as Leeky gets a minute to create the page and post a link to it here, I'll fill it in with a draft of the RFC and we can iterate a bit, then launch. –Novem Linguae (talk) 02:01, 14 February 2025 (UTC)[reply]

Like Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections ? Soni (talk) 04:11, 14 February 2025 (UTC)[reply]

I defer to @Theleekycauldron for the page title. Would be great to get it created soon though. –Novem Linguae (talk) 05:10, 14 February 2025 (UTC)[reply]

Looks good to me! I'll draft some language for the RfC :) theleekycauldron (talk • she/her) 05:15, 14 February 2025 (UTC)[reply]

RFC question wording

I wouldn't have a place to !vote on such a survey. I would be forced to vote no, and I would make a stink about it. P2 has made adjustments, but I'm a firm beta test believer. We clearly didn't get recall petitions right the first time. We haven't tested these major changes in real time, and IMHO we haven't sufficiently foreseen how the system will be gamed over time. Adding an election tempo introduces an election season, for example. Political elements, as another. Ignore this at our peril. I agree that consensuses have been reached, but I do not think we've given sufficient thought to stress testing our changes at this moment in human history. I suggest a third option should be further testing, say, three election cycles before final approval. I'm sure my comment is out of process, but I believe you'll find I'm not the only one who'll object to a yes/no option. If you remember, the advent of political parties in the US was not foreseen by the framers. Further, all this prior process discussion assumed a current US government which acted predictably and within the bounds of law. This is clearly no longer the case. BusterD (talk) 12:19, 11 February 2025 (UTC)[reply]

At the very least we should consider the tempo of changes relative to current events. Sustainability. That's my reasonable concern. BusterD (talk) 12:28, 11 February 2025 (UTC)[reply]

@BusterD What are your specific concerns about how the current US government or other current events would impact the Wikipedia administrator election process? --Ahecht (TALK
PAGE) 14:02, 11 February 2025 (UTC)[reply]

My concern is about the inevitable politicization of the admin request process once this becomes a regularly scheduled !voting process (precisely in a context of incredible external chaos). For my part, I very much enjoyed the outcome of the last admin elections; I think we promoted outstanding new sysops who seem serious and open to feedback. That's great for all of us. But I don't believe we have sufficient data to indefinitely promote this process to elections every 5 months regardless of the need for moppers. My reservation is about the irrevocable nature of the change once we've made it, towards what I view as chosen polarization. I'll work harder to make my case when the question is asked formally. BusterD (talk) 15:03, 11 February 2025 (UTC)[reply]

I think bringing US politics into discussions about Wikipedia administrator elections is a bit odd. I wonder if the same arguments can be made in a different way. –Novem Linguae (talk) 19:33, 11 February 2025 (UTC)[reply]

I believe I intended to make a point about the dangers of majoritarianism, in the context of what has been happening in the US. I was also referencing very real live threats against our movement. The world's richest man, a man with a competing communications structure, has targeted this project directly. He now has been given virtually unfettered access to Americans' personal data, including many of ours'. By changing wikipedians' societal structure to be more in line with one country's particular political structure (regular elections), we risk weakening our culture of vigorous disagreement. Doing so indefinitely at this precise moment seems the height of folly. BusterD (talk) 13:09, 12 February 2025 (UTC)[reply]

The word "indefinitely" in the proposed wording might spook some; it's also quite... ambitious, in purely design engineering sense. (And I'm not arguing about the choice of word here, but rather the concept.) How about proposing as the next stage of the roll-out a finite (and not very large) number of elections, after which another review will be carried out? There are many moving parts in all this, and many factors which have so far only been probed once, with a particular set of parameters. Another, say, 2-3 elections with revised parameters could tell us a lot that we don't yet know about how this thing behaves when released into the wild. -- DoubleGrazing (talk) 14:11, 11 February 2025 (UTC)[reply]

I think that would be exercising too much caution - we've already had 2 RFC's about holding a trial (both of which had strong support, the first being declined only on technical grounds), the pre-trial planning and discussion, the trial itself, the debrief, the RFC workshops, and the fleet of post-trial RFC's themselves. In general I think we're already dragging this process out too long, and further trials and discussions could become naval gazing. Tens (if not hundreds) of thousands of words have already been written about AELECT - I think the time has come to just ask whether to accept it or reject it. We can repeal or refine it by RFC later on if there's a need to do so.

Regarding wording, I agree maybe we could soften it - "Should Admin elections be adopted as a recurring process?" or something (I don't feel very strongly about this though). BugGhost 🦗👻 14:41, 11 February 2025 (UTC)[reply]

By convention, all Wikipedia processes are in place until they're modified, so I agree that "indefinitely" isn't required in any question. isaacl (talk) 17:19, 11 February 2025

Agreed, indefinitely is a scary word, and it's implied anyway. My suggested wording: Should Wikipedia:Administrator elections continue as a recurring process now that the trial election is complete? Leijurv (talk) 17:30, 11 February 2025 (UTC)[reply]

Requests for comments on broad matters consume a lot of community time in aggregate, so it's a bit of a judgement call on what approach seems more likely to be more streamlined. Does the community feel the process has general acceptance and so is likely to persist, even if needs further modifications; does it think that there may be significant problems that might not be resolved, and so a full re-approval of the process would be more time-effective; or something else? It's difficult to tell, but given that an election process has been sought for many years now, and English Wikipedia editors just seem to like voting in any discussion, my suspicion is that it may be more efficient to follow the usual Wikipedia approach of enacting a process rather than a trial (in this case, extending a trial), and reviewing its effectiveness while it is operational. With the five-month gap between elections, there will be sufficient time for the community to discuss stopping the process if it feels it is desirable. isaacl (talk) 17:32, 11 February 2025 (UTC)[reply]

Good idea on the revised wordings. When the subpage is created, we can place one of those wordings in there, and then iterate a little bit more, if needed. –Novem Linguae (talk) 19:36, 11 February 2025 (UTC)[reply]

I'm going to make some unsupported assertions. These are my opinions, based on my experience here. I believe the scheduled nature of these elections makes our community more vulnerable. Many nations replace their representatives in free and fair elections which occur when needed. These sorts of electoral processes are inarguably less resource-consuming than those in countries in which set dates are scheduled. These sorts of elections see less grandstanding and less corporate manipulation. Scheduled election dates by definition create election seasons. We shouldn't ignore the risks of giving disrupters advance notice of moments the wikipedia community's attention might be inward facing (as I believe it was during October 2024 elections) instead of outward facing (as we are when we have disasters to cover). Again, all of this is my opinion, based on 20 years of watching this stuff, both here and in RL. BusterD (talk) 13:32, 12 February 2025 (UTC)[reply]

BusterD, I've read all of your comments here thus far and I do not know what you're on about. Bringing all kinds of politics into this seems irrelevant and unhelpful – I'm sorry if that sounds harsh. I realize that Wikipedia faces many external threats, but I do not see how this particular method of selecting administrators makes us significantly more vulnerable to these threats. I understand if you are deliberately obfuscating your worries, but it is not clear if you are.

Perhaps I can clear some things up. The elections will not be regularly scheduled years in advance. Individual editors will do their best to hold elections "approximately every 5 months" – if there is no interest in doing so, they simply will not be held. If the elections turn out to be a disaster, anyone may open an RfC to end them. Elections do not "dispose of our disagreement-based culture" – their goal is to make it easier to disagree with candidates (vote against them) without hurting their feelings or being badgered about it. If you would still like to disagree in public, there are discussion pages for that, and the discussion time has been lengthened since the trial. I don't understand where your concerns about polarization, majoritarianism, or dominance are coming from, in a non-competitive process with a passing threshold (70%) far beyond a simple majority, to elect administrators who do not vote like parliamentarians. And since RfA will still be around, I disagree that elections are a "total change in wikiculture" – it will be at most a partial change. On the other hand, there has long been a consensus (at least since 2015) that change to the RfA culture is needed.

I hope this was in some way helpful – if you are still concerned, I would be happy to see you voice your concerns more clearly in the RfC, as you have promised. I hope it is clear that I have no hard feelings against you; I am simply having trouble understanding what you want to say. Toadspike [Talk] 19:49, 12 February 2025 (UTC)[reply]

I echo the same thooughts as Toadspike, I don't understand your points here. US politics shouldn't have any bearing on WP elections BugGhost 🦗👻 01:35, 14 February 2025 (UTC)[reply]

I understand, but from a different angle. What is probably a concern would be an eventual encouragement of gamification (of sorts) of the elections, where unlike the RfA format, the regularly scheduled elections offer a clearer or easier goal to work towards promoting their "own kind" of editors as admins. In the RfA format, like it or not, the voracity in responses from the the rest is an effective guardrail in this case, making people think twice on supporting or oppose the nominated person because their !votes are public. The only guardrails for the elections are the questions and answers, and nothing is stopping adversarial hijacks of the process if they have a large number of active editors voting silently. In the real world, it can happen, and it had happened before. e.g. Association of Women for Action and Research#Attempted takeover by conservative Christian group (if anyone wants more details, there is a detailed record at fandom). On here, the only few recourse to prevent or defrock the troublesome admins would be through Bureaucrats, Arbcom, and/or the various functions in WMF (T&S, UCOC, etc), and each option will definitely take increasingly longer reaction time as compared to the one before, time which the community may not have if the admin(s) go(es) rogue in the eyes of the community. – robertsky (talk) 07:13, 14 February 2025 (UTC)[reply]

And WP:RECALL, which has (for better or worse) an pretty short reaction time. Thanks for clarifying the main worry though. Since admins, unlike legislators or executive committee members, do not "vote" anywhere or make content decisions, I still believe fears of hijacking to be inapplicable, but I can understand how you may disagree. Toadspike [Talk] 18:07, 14 February 2025 (UTC)[reply]

Do we think a lot of people will want a time limited renewal? If so, I suppose we should do an option a option b option c type rfc, and make a time limited renewal one of the options. Thoughts? –Novem Linguae (talk) 19:40, 11 February 2025 (UTC)[reply]

What we can do is say that people can specify a number of elections they'd like to reauthorize for (up to indefinite), and the closer can authorize as many new elections as have consensus (assuming that someone who wants 3 new elections would also support having 2 new elections). theleekycauldron (talk • she/her) 21:48, 11 February 2025 (UTC)[reply]

I think it would also be advisable to delete "Now that the one time trial is complete," from the RfC question, and instead, include the fact of that trial having happened in some introductory material on the RfC page. Some editors might be sensitive to the question being non-neutral (even though that would be a stretch), so it's better to avoid any obstacles. I think it would be best to write the RfC question as: "Are Wikipedia:Administrator elections authorized to continue?" – plain and simple. And again, the invitation to specify, if one wants to, how many elections to authorize, can be stated in the introductory material (with the understanding that if there is no consensus to limit the number, then the elections continue until they don't). --Tryptofish (talk) 22:56, 11 February 2025 (UTC)[reply]

I could go along the language "Are Wikipedia:Administrator elections authorized to continue?" yes or no. I could go along with a preliminary schedule of test votes. I cannot go along with a total change in wikiculture with insufficient playtesting. For my part, I want us to find dedicated and qualified new admins as much as anybody. I don't want (in exchange) for the en.wiki community to dispose of our disagreement-based culture in favor of a more political voting one. Our movement represents a different cultural approach to mere dominance. There are moving parts here, and they will never stop moving. We should game this ourselves, and benefit from the experience.

Ahem. Thanks, whoever sub-sectioned this. I feel I have unjustly disrupted a simple technical exchange between two wikipedians I trust implicitly. I am being pointy. I am not normally known for such disruptions. BusterD (talk) 12:56, 12 February 2025 (UTC)[reply]

Personally, I don't think the new election process signifies a total change yet, and I think there are ways to safeguard against problems that may arise. The open viewpoint request for administrative privileges process remains in place. Wikipedia's consensus-can-change tradition is also still here and can rein in any abuses, even if they're in progress. English Wikipedia guidance isn't a set of binding laws; the community can agree to cancel an election or put the entire process on hold whenever it wants. isaacl (talk) 16:36, 12 February 2025 (UTC)[reply]

RFC draft

Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections

Took a whack at a first draft :) feel free to wikify it into something better! theleekycauldron (talk • she/her) 05:27, 14 February 2025 (UTC)[reply]

Looks good. I just went through and made my suggested changes. I think it's looking pretty good. Any thoughts or concerns before we launch the RFC?

Also, do we want to take this opportunity to promote AELECT to a guideline or a policy? Would be pretty easy to insert this wording into the RFC, if we think it's a good idea. Considering we just RFC'd 22 little details of the AELECT page, I think it's safe to say that the AELECT page has a PAG-level of consensus. Although if we skip making it a PAG, that should be fine too. Lots of procedural pages such as WP:RFA and WP:AFD are not PAGs. –Novem Linguae (talk) 07:08, 14 February 2025 (UTC)[reply]

Just a thought: I'm leery of the or any other limitations phrase. It seems to invite participants to suggest arbitrary "tweaks". What I'm imagining is a bunch of Option Bs that create a giant mess - contradicting each other. "Authorized to continue for 2 more elections assuming at least X people vote in each" or things of that nature, that would make the RfC impossible to close. I think it is duplicative of the phase II RfCs. If I were writing the RfC, I would put: Option A - No. Option B - Yes, more trial(s) are authorized (please specify how many). Option C - Yes, administrator elections are authorized to occur approximately every 5 months. Leijurv (talk) 19:30, 14 February 2025 (UTC)[reply]

Sure, that seems fine to remove. Done. –Novem Linguae (talk) 19:59, 14 February 2025 (UTC)[reply]

The draft as it currently stands looks good to me. No edits here. —Ganesha811 (talk) 06:59, 15 February 2025 (UTC)[reply]

The wording "with no limitations" feels a bit off to me. I’m concerned it doesn’t fully reflect the considerable RFCs and consensus and time put into thinking out the process and trying to make it a secure, "safe" admin selection process. I’d prefer something like B – Authorize administrator elections to continue for an additional x number of trial elections (please specify x); C - Fully authorize administrator elections, or something of the sort. Perfect4th (talk) 07:14, 15 February 2025 (UTC)[reply]

I changed it to Yes, without needing further trials or renewals. Administrator elections are authorized to occur approximately every 5 months. Does that make some progress towards your concern? –Novem Linguae (talk) 08:07, 15 February 2025 (UTC)[reply]

Yes, that helps, thanks. Perfect4th (talk) 20:04, 15 February 2025 (UTC)[reply]

Mass message

When the RFC launches, any objections to sending a mass message to Wikipedia:Administrator elections/Newsletter list? Will probably use the {{Please see}} template for neutral wording. I do not believe this to be canvassing since the newsletter list is not partisan -- I believe it is all folks that are interested in administrator elections, not just "pro" AELECT or "anti" AELECT editors. –Novem Linguae (talk) 18:54, 14 February 2025 (UTC)[reply]

Yes, as advertised and described on the mailing list page, it is to get notifications about the process. Thus not notifying those on the mailing list would be breaking a promise. isaacl (talk) 22:35, 14 February 2025 (UTC)[reply]

I think that's fine. —Ganesha811 (talk) 07:00, 15 February 2025 (UTC)[reply]

Yep, sounds good to me. Surprised there wasn't one for the mini RFCs, I didn't realise they were happening until near the end BugGhost 🦗👻 17:27, 15 February 2025 (UTC)[reply]

Send it :) Leijurv (talk) 03:11, 20 February 2025 (UTC)[reply]

Renewal RFC is live

The renewal RFC is live at Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections. The MMS bot should be along soon to notify this talk page as well. –Novem Linguae (talk) 06:11, 21 February 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.

Discussion at Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections

Administrator Elections | Renewal RFC phase

You are invited to join the discussion at Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections.

You're receiving this message because you signed up for the mailing list. To opt-out of future mailings, please remove yourself from the list.

MediaWiki message delivery (talk) 06:21, 21 February 2025 (UTC)[reply]

Name of heading for voter eligibility

I know, what an important detail.^[Joke] Currently, the name of this heading is "Who can vote" in the present tense and "Who could vote" in the past tense, as seen on ADE and the October 2024 subpage. I don't think we should be changing the name of this heading every time an election finishes, so could we settle on a name with some more permanence? I suggest "Voter eligibility". Aaron Liu (talk) 17:14, 22 February 2025 (UTC)[reply]

In general, re-writing pages for past elections to be in the past tense should, in my view, not be done. With a clear indication of the status of the election at the top, there's no need to change the rest of the page as no one will be confused that the election is still ongoing. I think people coming to see the page in future would be more likely to want to see the state as it appeared during voting, and not a reworded page. isaacl (talk) 17:29, 22 February 2025 (UTC)[reply]

I was the person who split the Oct '24 details into the separate subpage and turned everything past-tense - just wanted to say that I don't really have much preference on this, it just felt like it made grammatical sense at the time seeing as the page was created after the election had ran (when it run running, details of the trial were just on the main WP:AELECT page). I've got no opinion on what happens in future elections' subpages, and wouldn't object if someone made the Oct 2024 subpage present tense (I don't think it would be worth doing, but I also won't attempt to stop anyone). "Voter eligibility" sounds like a good header to me. BugGhost 🦗👻 00:32, 23 February 2025 (UTC)[reply]

I'll just change it to that, then. My main concern was with link stability. (As for the tense of page content... I have no preference, since it is virtually impossible to be tense-neutral in English.) Aaron Liu (talk) 03:31, 23 February 2025 (UTC)[reply]

Do we really need to be this exclusionary? Let's keep it at a name everybody understands —Femke 🐦 (talk) 07:27, 23 February 2025 (UTC)[reply]

Do you have a tense-neutral suggestion? Aaron Liu (talk) 15:18, 23 February 2025 (UTC)[reply]

Present tense feels sufficiently neutral for this, right? —Femke 🐦 (talk) 15:20, 23 February 2025 (UTC)[reply]

No, because it is present tense and will be changed into the past tense, which breaks links. With ACE also changing content to the past tense I'm not sure if there's consensus to not rewrite into the past tense. This isn't any important enough for me to push it, though, so you're free to change it back if you wish. Aaron Liu (talk) 16:08, 23 February 2025 (UTC)[reply]

I don't agree that a verb "will be changed into the past tense", and I don't think this should be a consideration in choosing a heading. That being said, I don't have a problem with using "Voter eligibility". isaacl (talk) 16:38, 23 February 2025 (UTC)[reply]

The truth is, people are spontaneously changing verbs to the past tense, as seen at ACE. Aaron Liu (talk) 16:46, 23 February 2025 (UTC)[reply]

It happened in 2023 at the arbitration committee elections page, but not in 2024 (yet), and has not happened for all past elections (as of when I checked in 2023). It leads to very stilted language and doesn't bring any particular benefit. If a trend develops, I think determining a practice by consensus would be warranted, but I don't think it's necessary yet. (On a technical point, someone changing a heading could add an anchor to preserve older links. I didn't mention this before because I think the re-writing shouldn't be done anyway.) isaacl (talk) 17:11, 23 February 2025 (UTC)[reply]

special:Diff/1262010917. Nothing else was changed 2024 but that's more of an oversight. Anchors can be added, but the editors who spontaneously change the tense are unlikely to realize that. Aaron Liu (talk) 17:15, 23 February 2025 (UTC)[reply]

No, not an oversight. I didn't object to that brief change made in the lead sentence, but I will object if the rest of the page gets altered, after having posted my view on this matter in 2023. isaacl (talk) 17:22, 23 February 2025 (UTC)[reply]

I have the same position you have, then. (Though I think that all headings should just be tense-neutral.) Aaron Liu (talk) 20:03, 23 February 2025 (UTC)[reply]

With little copy edits like this, probably best to just make the change, and anyone that doesn't like it can revert it. Will save us 650 words of discussion :) –Novem Linguae (talk) 17:13, 23 February 2025 (UTC)[reply]

I think it was worthwhile to mention the broader issue. I feel what best serves future readers is to preserve the appearance of the page as it was during the vote. Perhaps it would be helpful to have a status banner at the top, similar as with the arbitration committee elections, so the current state of the election is clearly identified. isaacl (talk) 17:18, 23 February 2025 (UTC)[reply]

We did have a status banner at the top; it was only removed this month. There was rough consensus to make it just an ombox, and I did make what is now {{Administrator elections status}} based on the ACE status header, but I misconfigured it spectacularly during the trial election; while the misconfiguration has been fixed, I'm not sure if we'll get consensus to adopt that automatically-updating template instead of the manually-updated header template we had. Aaron Liu (talk) 20:08, 23 February 2025 (UTC)[reply]

I was referring to the individual election pages. When the next election page is created, it could have a status banner to highlight the current state of that specific election and eventually its results. It wouldn't be a lot different than the current lead sentence at Wikipedia:Administrator elections/October 2024, but some editors like to have that info given additional emphasis. isaacl (talk) 23:10, 23 February 2025 (UTC)[reply]

The header is the header for the election pages. Aaron Liu (talk) 00:21, 24 February 2025 (UTC)[reply]

That header currently solicits participation in the past RfCs. My suggestion is for a header that just describes the state of the election and which never gets modified again after the election is closed and the results are announced. isaacl (talk) 00:28, 24 February 2025 (UTC)[reply]

I'd got with Voter eligibility or Voter suffrage. — xaosflux ^Talk 23:21, 23 February 2025 (UTC)[reply]

It seems I read a viable solution: Change it to Voter eligibility and any objections, if any, could be handled at that time. -- Otr500 (talk) 15:30, 6 May 2025 (UTC)[reply]

This change has already been made fanfanboy (block_talk) 15:49, 6 May 2025 (UTC)[reply]

Next election date & list of blockers

Hello all. I got a question offwiki about when the next election date would be. Right now the next election is blocked on two things:

If the renewal RFC closes as option C, I think the date of the 2nd election will be a bit off the 5 month schedule (a bit random and depends on when the blockers are resolved, setup time, etc.), then elections after that will be on the 5 month schedule.

If the renewal RFC closes as option B, same thing, except the potential 3rd election will probably also be off the 5 month schedule.

Hope that helps with advising candidates on whether to wait for AELECT or choose RFA. Happy electing! –Novem Linguae (talk) 20:56, 3 April 2025 (UTC)[reply]

Update: The RFC is now closed. If there aren't any forthcoming close challenges, the remaining blocker is now phab:T384302 SecurePoll: Restrict creation of foreign and global elections. I have written two patches that should resolve this ticket. Might take a couple weeks to go through the code review and deployment process, and get signoff from WMF leadership. Getting SecurePoll approved for local use (what this ticket is about) isn't a total blocker, but it allows SecurePoll elections to be held without having to bug WMF Trust & Safety, who are busy. It makes the entire process quicker, more scalable, and able to handle the recommended 5 month cadence. –Novem Linguae (talk) 23:20, 9 April 2025 (UTC)[reply]

When those tickets are fully dealt with, we should probably wait a few weeks before having another election. I also think that after the next election is when we start counting the 5 month schedule. fanfanboy (block_talk) 01:38, 10 April 2025 (UTC)[reply]

Yeap. Agreed. I think the steps after securepoll local elections being ready on the technical side is picking some English Wikipedia election admins (scrutineers). This will be our first time doing that so may require some extra time. Then proposing a schedule on this talk page and getting it approved. Then doing a call for candidates. –Novem Linguae (talk) 04:08, 10 April 2025 (UTC)[reply]

Would eyeing something like June-July 2025 be feasible for AELECT 2? Or is it too soon to consider without more info on the other blockers? Soni (talk) 11:29, 10 April 2025 (UTC)[reply]

Sounds about right. If I had to guess, I think we can get the software stuff wrapped up in one month, then another month for picking scrutineers and planning. –Novem Linguae (talk) 11:35, 10 April 2025 (UTC)[reply]

I hope I'm not re-litigating an RfC outcome that took months of time and thousands of words but ... why five months, not six to make it twice a year? HJ Mitchell | Penny for your thoughts? 11:41, 10 April 2025 (UTC)[reply]

I think the idea behind the 5 month RFC close was to stagger the elections so that if someone is always busy during certain months, that eventually AELECT would occur in a month where they are not busy. –Novem Linguae (talk) 11:50, 10 April 2025 (UTC)[reply]

So that they will drift seasonally, rather than always being at the same times each year. —Ganesha811 (talk) 14:43, 10 April 2025 (UTC)[reply]

Fair enough. Thanks for the answers. HJ Mitchell | Penny for your thoughts? 15:55, 10 April 2025 (UTC)[reply]

We should probably have an FAQ or similar about the admin elections that prominently includes the answer to this question. Thryduulf (talk) 08:02, 12 April 2025 (UTC)[reply]

Thanks for all the work put in @Novem Linguae! Hey man im josh (talk) 13:39, 10 April 2025 (UTC)[reply]

+1 fanfanboy (block_talk) 14:34, 10 April 2025 (UTC)[reply]

absolutely ^Thanks,L3X1 ◊distænt write◊ 16:18, 10 April 2025 (UTC)[reply]

Yes, a huge thanks to Novem for all your work! Perfect4th (talk) 16:23, 10 April 2025 (UTC)[reply]

absolute +1 charlotte ^👸♥ 21:07, 10 April 2025 (UTC)[reply]

Update: My software patches in phab:T384302 were merged and deployed very quickly thanks to Dreamy Jazz. Thanks so much for the quick code reviews. Next step now will be to get sign off from the WMF TSP team (maybe via a post in phab:T301180), and WMF leadership. –Novem Linguae (talk) 00:01, 12 April 2025 (UTC)[reply]

Excellent, nice work team. —Ganesha811 (talk) 16:40, 13 April 2025 (UTC)[reply]

No problem on the code review. Good to see this moving along. Dreamy Jazz ^{talk to me | my contributions} 21:19, 15 April 2025 (UTC)[reply]

Congratulations, all AELECT supporters and commenters! Many users, especially User:Novem Linguae & User:theleekycauldron deserve wide praise for demonstrating how an engaged community may adapt to broad input and make informed AND complex decisions about its future. We went to the well of consensus over and over, and those who supported individual elements of the surveys became broader supporters of the entire movement. The model used for acquiring a neutral consensus moving the process forward was well founded and might be used for other longterm issues moving forward. Bravo! For my part, I fully believe in this election process and the steps made to enshrine elections as policy. I thank everyone who participated. BusterD (talk) 13:53, 21 April 2025 (UTC)[reply]

Have CheckUsers be in charge of creating/editing SecurePoll polls?

I've drafted an RFC at Wikipedia:Administrator elections/SecurePoll permissions RFC. It is not open yet. Please feel free to give feedback here. Basically we already had an RFC that approved creating an "Election Administrator" user group, but after thinking about it more I think it'd be less messy to just give all the SecurePoll create/edit/scrutinize permissions to the existing CheckUser group. Thoughts? –Novem Linguae (talk) 23:52, 11 April 2025 (UTC)[reply]

It feels to me that creating and editing should be one group, and scrutineering should be another. I'm not sure on the technical side of this, but can we not append scrutineering rights to checkusers, and allow the new electionadmin group to just create/edit (but not scrutineer) elections? BugGhost 🦗👻 00:11, 12 April 2025 (UTC)[reply]

When will these RFCs come to an end! But yeah I agree with BugGhost on this one. fanfanboy (block_talk) 00:21, 12 April 2025 (UTC)[reply]

When will these RFCs come to an end? Hopefully soon :) If this change is small enough, maybe I can just post at WP:VPPR with a "does anybody object?" type message. Will give this some more thought, and hopefully some others will chime in too. –Novem Linguae (talk) 00:49, 12 April 2025 (UTC)[reply]

We've had a quite a few RFCs, and as there may still be (a rather important) one to come about WP:RECALL, I think there's good merit in the simple message option instead. It still provides an opportunity to raise concerns or even request using an RFC after all if people do want that. Also agree with BugGhost on the scrutineer aspect but I'm really not bothered either way. Perfect4th (talk) 01:25, 12 April 2025 (UTC)[reply]

+1. It seems like a problem solvable by a simple well notified discussion than a full RFC. We're fairly deep in implementation land Soni (talk) 10:26, 12 April 2025 (UTC)[reply]

+2 agreed, I see no need for a full RfC. —Ganesha811 (talk) 16:40, 13 April 2025 (UTC)[reply]

Adding a new role would indeed create needless process / procedure. Bundling it into an existing position is probably the best option. But why checkuser? Checkuser makes perfect sense for scrutineering since they can already view that data. But the task here is more like admin election clerking. To me, it feels more intuitive to give this right to the bureaucrats? Leijurv (talk) 07:25, 12 April 2025 (UTC)[reply]

There are only 16 crats - assigning a role to them is likely to put a bottleneck on the process, and we don't have any indication that they want to take on this additional set of tasks, especially if it is working with something complex and niche like securepoll. I think a specialised self-nominating group would be best for setting up elections, even if it means more legwork right now to organise that group. BugGhost 🦗👻 10:04, 12 April 2025 (UTC)[reply]

That is a fair point.

Why not give the right to all sysops? Leijurv (talk) 13:40, 12 April 2025 (UTC)[reply]

Something that is complex and niche shouldn't be handed out broadly to people with no need for it and no guaranteed aptitude for it. Rights like this are the entire reason that small usergroups exist, and while there will of necessity be some process and procedure associated with the right, absolutely none of that will be needless and there is no reason it for it to be lightweight. The process and requirements for Wikipedia:Interface administrators seem like a good model for this, although I don't see a need to require 2FA or CSS/JS knowledge. Thryduulf (talk) 14:29, 12 April 2025 (UTC)[reply]

The previous RfC to which you linked found consensus to enable the electionadmin right, but did not specify that a specific user group had to be created (An RFC to determine how the new right should be distributed can be launched at any time...). I think there should be more discussion about the details of other potential processes for granting the right than just granting it to the checkusers group (the three basic ways being by consensus agreement on request, by appointment from some group, or by election). Also, given the resolution of Phabricator ticket T377531, there is the ability to separate poll administration tasks from scrutineering tasks, so that's something to consider when deciding how to manage the election admin role. isaacl (talk) 15:34, 12 April 2025 (UTC)[reply]

I don't think it would be controversial for CU's to get electionadmin rights in addition to the scrutineering right which was decided in the previous RfC.

I'd say this can be devised as similar to the edit filter manager group, which has rights not included in sysop group by default but can be self-granted by sysops. Reusing the IA requirements seems slightly too restrictive. 0xDeadbeef→∞ (talk to me) 13:10, 15 April 2025 (UTC)[reply]

Though upon further thought, config editing seems outside the job descriptions of CUs.. 0xDeadbeef→∞ (talk to me) 13:15, 15 April 2025 (UTC)[reply]

I think that the best choice is between the model of Wikipedia:Interface administrators and Wikipedia:Edit filter manager. A separate user group makes sense in the absence of explicit consensus to bundle it, but we don't need a heavy-weight process to assign membership. Eluchil404 (talk) 23:27, 21 April 2025 (UTC)[reply]

Second draft

Moved to Wikipedia talk:Administrator elections/SecurePoll permissions proposal § Second draft

– –Novem Linguae (talk) 17:56, 23 April 2025 (UTC)[reply]

The second draft is currently stuck. Wikipedia talk:Administrator elections/SecurePoll permissions proposal#Stuck. Help and new participants in the discussion would be appreciated. –Novem Linguae (talk) 14:20, 28 April 2025 (UTC)[reply]

Looks like it's getting unstuck! —Ganesha811 (talk) 18:34, 28 April 2025 (UTC)[reply]

We've made some changes and I think the current version is ready for final sign off. Please feel free to give your opinion at Wikipedia talk:Administrator elections/SecurePoll permissions proposal#Survey / Motion to close –Novem Linguae (talk) 15:30, 29 April 2025 (UTC)[reply]

SecurePoll notes

Hi all,

Based on the discussions over at Wikipedia talk:Administrator elections/SecurePoll permissions proposal, I realised that there's not a lot of certainty in the community about how SecurePoll's config really works, so I've done some local testing and tried to collate a basic summary of what I've found about it in the hopes to get a bit more community clarity on this. It's available at User:Bugghost/Securepoll notes. It is still a work-in-progress and I plan to add more to it over the coming days. Anyone is free to edit it if they've found anything incorrect, and please let me know if there's anything in particular you'd like me (or anyone else) to test and I'll try to add it to the page. BugGhost 🦗👻 20:17, 29 April 2025 (UTC)[reply]

Fantastic, thank you so much! Assuming we will use an encrypted poll, my question is about the period after the poll is over. Is it possible for a scrutineer who possesses the private key to see who voted for who? For instance, could they view the total tally, then strike someone's vote, then view the tally again to see whose count was decremented, thus learning who that user voted for? Leijurv (talk) 22:02, 29 April 2025 (UTC)[reply]

Very good question - from my testing it looks like yes an election clerk or scrutineer can look at the tally, then strike a particular user's vote, compare the tally to see who that user voted for, and then unstrike the vote again to cover their tracks. This can be done on an encrypted poll as long as the election clerk/scrutineer has the correct encryption keys to examine the tallies. There is a ~~public~~ log at Special:SecurePollLog (if logging is turned on), but it looks like it only tracks when tallies are requested (so in this scenario would be twice - before and after the vote strike) - but surprisingly this log doesn't show when a vote gets struck or unstruck. Election clerks/scrutineers can see if a particular vote has been struck/unstruck, but that information is not easily visible, and it is not accessible at all to the general public. Seems like a bit of an oversight here. BugGhost 🦗👻 17:28, 30 April 2025 (UTC)[reply]

That's probably a bug that should be reported on Phabricator, although I'm not sure what could be done about it and even without revealing whose vote was struck/unstruck the multiple unauthorized tallies will leave an audit trail a mile long.

Finally Special:SecurePollLog is not public - only election clerks can access it (it's gated on securepoll-create-poll which is strange). * Pppery * _{it has begun...} 17:49, 30 April 2025 (UTC)[reply]

Looks like you're right about SecurePollLog not being public - sorry about that, I've struck the above. I agree that it's not obvious what could/should be done to mitigate this. Maybe a new poll option to specifically only allow one tally to ever be generated? BugGhost 🦗👻 17:59, 30 April 2025 (UTC)[reply]

Or possibly a log entry for votes being struck or unstruck, so the log would read something like:

18:57 30 April 2025 (UTC) Example requested tally for poll #42
18:58 30 April 2025 (UTC) Example struck 1 vote on poll #42
18:58 30 April 2025 (UTC) Example requested tally for poll #42
18:59 30 April 2025 (UTC) Example unstruck 1 vote on poll #42

At the very least that would be cause to ask Example what they were doing and why. If it is possible to leave edit summaries when striking votes then they could be displayed in this log too (if the log is restricted to the same people who can strike and unstrike votes then I don't think that would have any security implications?). Thryduulf (talk) 18:59, 30 April 2025 (UTC)[reply]

In the meantime we could put a policy that no one shall click Tally until all scrutineers have publicly declared (ratified) that they are done scrutineering. This is verifiable, and if everyone can be seen to have followed this policy, it is certain none of them used this trick. Leijurv (talk) 19:47, 30 April 2025 (UTC)[reply]

Does it ever make sense to strike votes after tallying? Is there some reason SecurePoll couldn't prohibit that operation entirely? * Pppery * _{it has begun...} 21:12, 30 April 2025 (UTC)[reply]

I don't think striking votes after tallying should happen in usual course of action. I think that operation could be prohibited, but it would require changing the code. The only downside I could think of is accidentally or maliciously tallying early. If there was no way to strike votes after that, it would spoil the election and I guess everyone would have to re-vote (with new scrutineers). I guess a more ideal solution would be that all (or a majority?) of scrutineers must request a tally before the code actually does it? (Instead of just 1 scrutineer saying they're done, most, or all of them would have to). But this is overcomplicated and shouldn't be considered a blocker for AELECT, because we can just have the scrutineers agree not to tally until everyone has ratified. Leijurv (talk) 21:23, 30 April 2025 (UTC)[reply]

Filed phab:T393057. And I agree none of these are blockers for local elections - they're paranoid nice-to-haves. * Pppery * _{it has begun...} 21:35, 30 April 2025 (UTC)[reply]

Strikes are logged. The fact that they're logged in a different place than anything else is weird, and may make that sort of chichanery harder to find, but ultimately harmless. * Pppery * _{it has begun...} 21:48, 30 April 2025 (UTC)[reply]

Where are they logged at? –Novem Linguae (talk) 22:23, 30 April 2025 (UTC)[reply]

(from looking at the code, not tested locally) If you go to the details page for a specific vote it should show the log of any strike/unstrike actions affecting that vote. * Pppery * _{it has begun...} 22:36, 30 April 2025 (UTC)[reply]

This aligns with what I've been seeing. I've added a screenshot to the notes page to illustrate. BugGhost 🦗👻 08:36, 2 May 2025 (UTC)[reply]

This sounds like a reason for the encryption key not to be shared with the scrutineers, and thus to have a non-scrutineer electionadmin to be a backup to the electionadmin who created the poll. isaacl (talk) 22:30, 30 April 2025 (UTC)[reply]

Just to clarify: any election clerk is able to do the above, regardless of if they are scrutineers - any election clerk is able to request tallies and strike/unstrike votes. From my testing, the only difference between and election clerk and a scrutineer is that a scrutineer can see IP addresses and user agents (ie. browser versions) of voters and an election clerk cannot. BugGhost 🦗👻 18:45, 1 May 2025 (UTC)[reply]

Thanks for the clarification. This means that electionadmins must also be trusted to only strike votes in accordance with community guidance. isaacl (talk) 22:05, 1 May 2025 (UTC)[reply]

They have to be added to the election to do anything with it, though. Typically for past Arbcom elections the election comission has been removed from the election on votewiki when it starts, leaving only the scrutineers (and WMF staff) able to strike votes, and we could do the same for local elections * Pppery * _{it has begun...} 04:31, 2 May 2025 (UTC)[reply]

At least one electionadmin has to remain in order to tally the results, and for redundancy, there should be at least two. When the vote is run on the WMF voting server, it makes sense to add electionadmins from English Wikipedia in order to manage the poll until voting time, to avoid taking up the time of WMF staff. But when running the poll on the English Wikipedia server, I don't think additional electionadmins need to be added beyond those who must be there to do the tallying. isaacl (talk) 14:55, 2 May 2025 (UTC)[reply]

You could also revoke the right just during the election ? (Basically two people get the right, setup securepoll and then have their permissions revoked. The election then runs and once it is over the right is regranted, the votes and struck, counted and the rights are revoked again). It might be a fair bit of bureaucracy but it would sidestep the problem of peeps tallying the vote before the end. Sohom (talk) 15:13, 2 May 2025 (UTC)[reply]

The issue is with someone having the ability to strike votes and tally them after the poll ends. (I still don't see a need for extra electionadmins to be assigned who won't be part of the process to tally votes.) isaacl (talk) 15:33, 2 May 2025 (UTC)[reply]

Right, my personal opinion is that we should have only two folks with electionadmin at a time (one to actually do the sensitive work and one to perform a oversight/contingency role). We can always assign more folks if we see that there is a need for other contingency folks. Sohom (talk) 16:23, 2 May 2025 (UTC)[reply]

Personally I'm OK with users only holding the electionadmin right for the period when they are using it for a specific poll, and with the self-assignment process this is workable with minimal overhead. I appreciate, though, that others don't think it's necessary to be that strict with who currently holds the electionadmin right, as long as the number of users assigned to manage a given poll is tightly managed. isaacl (talk) 17:07, 2 May 2025 (UTC)[reply]

I think we don't need to worry too much about who actually has the election clerk rights and when. Personally I would like the election clerk role to be widely adopted so that Special:SecurePollLogs can be watched by a sizable number of people to see if there's any unnecessary tally-generations. I agree the more important issue is deciding who is actually added to a poll at a given time. BugGhost 🦗👻 18:07, 2 May 2025 (UTC)[reply]

This all sounds a bit complicated. Would recommend copying what WMF does and what we did for the first admin election, and have one electionclerk and three scrutineers. The three scrutineers have the same perms as electionclerks, so in theory this gives us four election clerks. –Novem Linguae (talk) 19:04, 2 May 2025 (UTC)[reply]

I think there should be at least one backup election clerk who is not a scrutineer with whom the encryption key is shared, so they can trigger a vote tally if necessary. isaacl (talk) 21:09, 2 May 2025 (UTC)[reply]

Admin election in June?

It looks as though the final technical changes to enable AELECT to run smoothly on English Wikipedia are moving forward and should be implemented soon. With that major task near-complete, it's time to think about scheduling our first non-trial elections. For simplicity's sake, we can wait out May to make sure everything is 100% ready, and aim for a June election. Proposed calendar:

June 3-10: Call for candidates, Tuesday to Tuesday to include a full weekend
June 11-15: Discussion phase, again including a full weekend
June 16-22: Voting phase, including a full weekend
June 23 to close - scrutineering and tallying, promote successful candidates.

With this schedule, we'd want to have a few election clerks volunteer in the first few days of June, though technically they wouldn't be needed until the voting phase begins on June 16th. Scrutineers could also be asked to volunteer ahead of time. Thoughts? —Ganesha811 (talk) 16:25, 2 May 2025 (UTC)[reply]

My only thought is that this would put the voting period for the following elections at the same time as the voting period for the ArbCom elections (based on it being similar to the 2024 dates). I think it would be ideal to avoid that until admin elections are more established to reduce potential confusion, etc. Moving it circa 2 weeks forwards or backwards would resolve this I think. Thryduulf (talk) 17:04, 2 May 2025 (UTC)[reply]

Personally, I'd rather adjust the dates for any election in November/December if desired, than the one happening five months earlier. The rotating through the year approach means that eventually the problem will be encountered again, so I think it's sufficient to be flexible for the dates of the actual election in conflict. (The arbitration committee election dates could shift, for all we know at this time.) isaacl (talk) 17:17, 2 May 2025 (UTC)[reply]

If the technical changes are resolved fairly promptly, we could have a May/June election that runs from May 20th to June 9th, which would enable a October/November election ahead of Arbcom elections this fall. We could also use the June 3-23rd dates and then hold the fall election October 20th-November 9th anyway. I don't think we need to be super strict on the 5-month period between elections (after all, each election takes a few weeks) as long as we're close. —Ganesha811 (talk) 17:21, 2 May 2025 (UTC)[reply]

A thought: if we design this election cycle to not conflict with the same month as ACE, it'll end up conflicting some time in the future because of the odd # of months. –Novem Linguae (talk) 19:13, 2 May 2025 (UTC)[reply]

Obviously, my thinking was just that it would be better to not conflict when AELECT is still a relatively new process. When it's established and routine, there should be fewer potential issues. If my maths is correct (and it might not be) if we delay this two weeks from the above suggested dates then the first clash will be the thirteenth election rather than the second and by that time any bugs in processes will likely have been ironed out, many unknown unknowns will have made themself known, we'll have experience of dealing with them and people will be familiar with both types of election. Thryduulf (talk) 19:25, 2 May 2025 (UTC)[reply]

Yes, that's what I said ("eventually the problem will be encountered again"). All I'm saying is we can defer worrying about this until the arbitration committee election RfC is over and the dates are known. There is enough flexibility in the administrator election process to allow for adjustments. isaacl (talk) 21:05, 2 May 2025 (UTC)[reply]

Election clerks will be needed before the start of the voting period in order to complete preparations and setup, particularly for the first time an election is run on the English Wikipedia server. Personally I think we'd want clerks and scrutineers in place before the call for candidates, and even the poll initially created (though not finalized for voting), so all resources are ready to run through the election process. isaacl (talk) 17:17, 2 May 2025 (UTC)[reply]

Whichever date we set, we could put out a request for election clerks and scrutineers say a week ahead of time. I agree it would be preferable to have volunteers and the poll in place ahead of the call for candidates, even if not strictly required. —Ganesha811 (talk) 18:27, 2 May 2025 (UTC)[reply]

Fine by me. I take it the secure poll setup phase was for the trail only? fanfanboy (block_talk) 18:22, 2 May 2025 (UTC)[reply]

Yes, it was more complicated then because it required the WMF to help set it up - in addition, because the suffrage requirements were complicated, a whitelist of eligible voters had to be manually generated and fed into SecurePoll. Neither should be true for future elections. —Ganesha811 (talk) 18:26, 2 May 2025 (UTC)[reply]

I would be in favor of doing some localhost and enwiki test elections. During that testing I will write a work instruction, and that will shorten the SecurePoll setup phase, but probably won't eliminate it. –Novem Linguae (talk) 19:14, 2 May 2025 (UTC)[reply]

I personally think this might be too early to schedule this. We do not have SecurePoll installed and working on en.wikipedia. Queuing up an election before we are 100% certain we can actually run it on that date is not a good idea, and puts undue pressure on us. We don't know if more software patches are required, and we haven't got a concrete decision on several key implementation details (eg. encryption) BugGhost 🦗👻 18:29, 2 May 2025 (UTC)[reply]

We certainly don't have to finalize any dates until those things have been taken care of, but it's good to start discussing it. From my understanding WMF has signed off and the technical changes will be implementable quite quickly. June is still a full month away. —Ganesha811 (talk) 19:10, 2 May 2025 (UTC)[reply]

True, but it's worth remembering that the last RFC about AELECT ended up taking nearly 2 months to run its course. I agree with Novem that a June election isn't completely unrealistic and hopefully we'll be able to get it all working by that point, I'm just worried that we have several unknowns to deal with before we can be certain. BugGhost 🦗👻 01:46, 3 May 2025 (UTC)[reply]

It might be a bit early to pick dates. I have a sequential todo list that is something like 1) deploy config patch, 2) create the 3 MediaWiki pages and update the 3 documentation pages mentioned in Wikipedia:Administrator elections/SecurePoll permissions proposal, 3) ask WT:AELECT who the electionclerk(s) should be, 4) do a test election on localhost wiki, 5) do a test election on enwiki, 6) recruit 3 scrutineer volunteers from among the CheckUsers. Once that is complete, I think that'd be a good time to set the exact dates for the next election (because at that point it will have no blockers remaining). I do think June is realistic but I am not sure we should commit to exact dates yet. Hope that makes sense. –Novem Linguae (talk) 19:11, 2 May 2025 (UTC)[reply]

Sounds reasonable. As mentioned above there's definitely no need to finalize anything until we're all set. —Ganesha811 (talk) 19:24, 2 May 2025 (UTC)[reply]

Wikipedia talk:Administrator elections