Wikipedia

Wikipedia:Administrator elections/July 2025/RFC workshop

< Wikipedia:Administrator elections | July 2025
Latest comment: 1 hour ago by Super Goku V in topic Q10. Next election date

Current status

December 2025 →


This page is for drafting mini RFCs to change the administrator elections process.

  • Please do not vote. This will come in a later phase on a different page.
  • Feel free to modify RFC text on this page. For example, to include additional options.
  • Each RFC should have Option A, Option B, Option C, etc. Prefer letters over numbers.
  • Option A should usually be the status quo. Put "(current)" in parentheses after it.

Anyone should feel free to add mini RFCs. Through discussion, we may decide not to advance some proposals to the RFC phase.

Q1. Pass percentage

edit
Latest comment: 17 hours ago19 comments8 people in discussion

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

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

I will make a comment with this suggestion for the closer: This should probably be a two part close. Part A is whether there's consensus to lower the pass percentage at all. Part B is what to lower the pass percentage to. –Novem Linguae (talk) 08:15, 21 August 2025 (UTC)Reply

Let's put in options that reflect the debrief discussions. That is: 70%, 67%, 65% and possibly 60%. I don't see the 55% option having any chance of success. —Femke 🐦 (talk) 10:29, 21 August 2025 (UTC)Reply
Agreed. fanfanboy (blocktalk) 12:24, 21 August 2025 (UTC)Reply
  Done –Novem Linguae (talk) 15:59, 21 August 2025 (UTC)Reply
Did 67% come up during discussions? That's not a very round number. –Novem Linguae (talk) 15:56, 21 August 2025 (UTC)Reply
Apparently, I was the only who mentioned 67%, but two thirds was also suggested. —Femke 🐦 (talk) 16:20, 21 August 2025 (UTC)Reply
I have a question about the two part close idea. As long as the current practice, 70%, is part of the question, is it really necessary to ask a separate question about whether or not to change it? It seems to me that editors who would answer that they oppose changing it will !vote for 70%, and editors who support changing it will !vote for their preferred value. --Tryptofish (talk) 19:10, 21 August 2025 (UTC)Reply
Agreed. That's why I was thinking one question, but I just want to make a comment to suggest to the closer that they make sure to cover both these aspects. If the results of the RFC ended up being 20% option A, 20% B, 20% C, 20% D, and 20% E, and it was closed as no consensus, that would be ignoring the WP:BARTENDER part of this and would in my opinion be an incorrect close. –Novem Linguae (talk) 19:22, 21 August 2025 (UTC)Reply
Oh, you are absolutely correct, and I agree. I misunderstood your earlier comment to mean two questions, but I agree with you about the two-aspects close. Thanks. --Tryptofish (talk) 19:57, 21 August 2025 (UTC)Reply
I might write "66.67%" instead of "67%" to make it clear it is intended to be >⅔ Leijurv (talk) 01:39, 25 August 2025 (UTC)Reply
Or just write 2/3. --Ahecht (TALK
PAGE) 13:45, 25 August 2025 (UTC)Reply
I would not recommend 2/3. That would be confusing for candidates and for bureaucrats to get a results page containing decimals and then have to compare them to a fraction, and then wonder exactly how rounding works in the event of being close to the threshold. –Novem Linguae (talk) 15:46, 25 August 2025 (UTC)Reply
The recent petition has just reminded me that the threshold for a RRfA AELECT (ReAE?) is 55%. If the pass percentage for a normal election is lowered, then should the percentage for a ReAE(?) also be lowered? fanfanboy (blocktalk) 22:04, 28 August 2025 (UTC)Reply
It's probably simplest to ask this as a supplementary question:
If the threshold for candidates who are not currently administrators is changed (see Q1), should the threshold for current administrators seeking reconfirmation (currently 55%) be changed?
  • No (remain at 55%)
  • Yes, to 53%
  • Yes, to 51%
  • Yes, to 50%
  • Yes, to some other amount (specify)
I'll leave a note about this at WT:RECALL. Thryduulf (talk) 22:25, 28 August 2025 (UTC)Reply
I agree that it would have to be a separate question. (I'm a little ambivalent about whether it's worth asking this time around.) --Tryptofish (talk) 22:28, 28 August 2025 (UTC)Reply
Probably also want an option like "5% 10% 15% lower than the result for non-admins". This option could also be the status quo because 70 - 15 is 55, but is dynamic to the pass percentage for non-admins, so if it's lowered to 67%, it would 52% for reconfirmation elections. fanfanboy (blocktalk) 22:43, 28 August 2025 (UTC)Reply
I don't think we'd want to reconfirm an admin who has anything less than 51% of votes in a hearing.
While Wikipedia isn't strictly a democracy, I think we can agree to stick to the democratic principles that an election requires a majority, whether that's a simple majority of 51% of votes, or a supermajority of some sorts. But we should not go down to plurality level. Raladic (talk) 01:51, 29 August 2025 (UTC)Reply
If a simple proposal was made asking "Should the status quo be changed to X?" and the result would be snow-closed as "no" then including X as an option in a list of options would be at best pointless (unless all the possible options comprise a list that is both short and finite, not the case here). Less than 50% would definitely be snow-opposed, but I'm not certain 50% would be. Maybe 50%+1 would be a better option though? Thryduulf (talk) 02:04, 29 August 2025 (UTC)Reply
Good question. If I'm remembering correctly, the WT:RECALL folks set that percentage themselves in an RFC last time around. So I think it should be up to them to change it this time around. In conclusion, I don't think we should RFC the RECALL threshold in the AELECT RFC, but rather let the WT:RECALL folks do it. –Novem Linguae (talk) 04:10, 29 August 2025 (UTC)Reply

Q2. Restrictions on election clerks

edit
Latest comment: 8 days ago1 comment1 person in discussion

Are election clerks restricted from certain election activities, to avoid an appearance of impropriety?

  • Option A – No restrictions (current)
  • Option B – Restrictions on public actions: Election clerks may not nominate candidates, publicly have an opinion about candidates, create a voter guide, or ask official questions on the discussion page
  • Option C – Restrictions on public and private actions: Election clerks may not nominate candidates, publicly have an opinion about candidates, create a voter guide, ask official questions on the discussion page, or vote

On the AELECT talk page, I don't think discussions about restricting election clerks achieved the same weight as discussions about restricting scrutineers and monitors. But this question was requested in the RFC workshop, so adding. –Novem Linguae (talk) 09:42, 21 August 2025 (UTC)Reply

Q3. Restrictions on scrutineers

edit
Latest comment: 8 days ago5 comments3 people in discussion

Are scrutineers restricted from certain election activities, to avoid an appearance of impropriety?

  • Option A – No restrictions (current)
  • Option B – Restrictions on public actions: Scrutineers may not nominate candidates, publicly have an opinion about candidates, create a voter guide, or ask official questions on the discussion page
  • Option C – Restrictions on public and private actions: Scrutineers may not nominate candidates, publicly have an opinion about candidates, create a voter guide, ask official questions on the discussion page, or vote

During the last election, Wikipedia_talk:Administrator_elections/Archive_7#Are_election_officials_allowed_to_vote? had a lot of words, suggesting the community has some feelings about this. Also Dbeef resigned as a scrutineer last election to avoid any potential appearance of impropriety related to both nominating a candidate and scrutineering in the same election, so these situations do come up. –Novem Linguae (talk) 08:26, 21 August 2025 (UTC)Reply

The same should be asked about election clerks as well. I have no preference on them being asked separately from scrutineer or in the same subquestion. Soni (talk) 09:19, 21 August 2025 (UTC)Reply
  Done –Novem Linguae (talk) 15:59, 21 August 2025 (UTC)Reply
  • I would suggest breaking Option C in two -- voting and asking questions are quite different things, since one is public and the other is not. To me, there is a material difference between public actions that might be taken as showing an opinion or influencing the election (nominating, discussing, asking questions, writing voter guides), and casting a secret vote where the community only knows that they have voted. Ditto for below. UndercoverClassicist T·C 13:20, 21 August 2025 (UTC)Reply
      Partly done. I moved "asking questions" to option B in all 3 questions. –Novem Linguae (talk) 15:59, 21 August 2025 (UTC)Reply

Q4. Restrictions on monitors

edit
Latest comment: 8 days ago1 comment1 person in discussion

Are monitors restricted from certain election activities, to avoid an appearance of impropriety?

  • Option A – No restrictions (current)
  • Option B – Restrictions on public actions: Monitors may not nominate candidates, publicly have an opinion about candidates, create a voter guide, or ask official questions on the discussion page
  • Option C – Restrictions on public and private actions: Monitors may not nominate candidates, publicly have an opinion about candidates, create a voter guide, ask official questions on the discussion page, or vote

During the last election, Wikipedia_talk:Administrator_elections/Archive_7#Are_election_officials_allowed_to_vote? had a lot of words, suggesting the community has some feelings about this. Risker asked about this on the talk page. RFA monitors have restrictions, so some may wonder if AELECT monitors have the same or similar restrictions. –Novem Linguae (talk) 08:29, 21 August 2025 (UTC)Reply

Q5. Candidate edit count requirement

edit
Latest comment: 6 days ago14 comments8 people in discussion

What are the minimum requirements to become a candidate?

  • Option A – Be extended confirmed (current)
  • Option B – Have at least 1000 edits on English Wikipedia
  • Option C – Have at least 2500 edits on English Wikipedia
  • Option D – Have at least 5000 edits on English Wikipedia
  • Option E – Have at least 7000 edits on English Wikipedia and an account age of 1 year or greater
  • Option F – Have at least one nominator that is an administrator
  • Option F – Other (specify)

We got multiple WP:NOTNOW candidates in the most recent election. Raising the candidate requirements could help avoid WP:BITING these folks by setting clear expectations that they are too inexperienced to participate in this process. –Novem Linguae (talk) 08:40, 21 August 2025 (UTC)Reply

Suggest Option F - Have at least 7000 edits on English Wikipedia and an account age of 1 year or greater based on User:Novem Linguae/Essays/2025 administrator election voter guide references 1 & 2, the smallest edit count and youngest account age that resulted in a successful RfA. I'd expand on that to say that candidates who wished to put themselves forward but didn't meet those two requirements could do so at RfA - on the basis that a candidate and the community would have a good opportunity to delve into the apparent inexperience during that process - but not AELECT. Cheers, SunloungerFrog (talk) 09:29, 21 August 2025 (UTC)Reply
I would be okay with this replacing the option I added. --Super Goku V (talk) 09:45, 21 August 2025 (UTC)Reply
Which I have just done. (10k edits swapped out for 7k edits + 1 year) --Super Goku V (talk) 09:49, 21 August 2025 (UTC)Reply
I think it'd be a good idea to delete the 10,000 edit one. That one has no chance of passing. AELECT itself has promoted an admin with less than 10,000 edits before (Sohom Datta). –Novem Linguae (talk) 09:44, 21 August 2025 (UTC)Reply
I will just make it official then and replace the option. Also, I didn't know that anyone has become an admin since 2020 with less than 10,000 edits. Happy to learn that.  :) --Super Goku V (talk) 09:48, 21 August 2025 (UTC)Reply
Should we consider adding an option requiring that the editor obtain an endorsement from an admin to be a candidate? This seems like to me the most direct way for the community to know that this candidate should meet the minimum requirements to run, because having an endorsement bestows confidence in that candidate and signals to voters that they should hear out this candidate. I also specify admin because everyone who had such an endorsement won their election (Darth Stabro was the only other nomination, and was nominated by a fellow candidate in the election). Gramix13 (talk) 04:59, 22 August 2025 (UTC)Reply
  Done –Novem Linguae (talk) 05:35, 22 August 2025 (UTC)Reply
We should make it so you can select multiple options to valid. You can have Option A, Option D, and Option F and they won't contradict or overlap each other (Options B-E excepted). fanfanboy (blocktalk) 13:42, 22 August 2025 (UTC)Reply

Any interest in considering a safety valve where a candidate under these totals can run if they have an admin nominator? I can construct hypothetical candidates under some of these tenure milestones that should be successful or worthy of real consideration. This lets notnow candidates be quietly directed towards an admin that can give them advice on how things work, while also allowing any unicorn candidates who are under the threshold to run. Tazerdadog (talk) 22:13, 21 August 2025 (UTC)Reply

I think we might want to try wordsmithing this one a bit. Right now D or (A and F) is a logically sensible !vote that means something very different from D or C. I'd suggest some language along the lines of "candidates without the tenure from this question should be able to run with the nomination of an administrator), or else splitting the question, or some poor closer may be cursing our names in 8 weeks when they unravel this. Tazerdadog (talk) 21:57, 22 August 2025 (UTC)Reply

I agree about splitting the question. I've been trying to think about how to do it in a single question, and I've come up empty-handed. I'm seeing three independent parameters, beyond the status quo ec: how many edits, whether to have a 1-year-+ account, and the admin nominator. --Tryptofish (talk) 22:02, 22 August 2025 (UTC)Reply
An additional problem is that having a nominator (of any sort) could logically be both an AND or and OR to the tenure questions. i.e. all the following are logical positions to hold (for the sake of brevity: "Age" = minimum account age, "edits" = minimum edit count, "nom" = nominator)
  1. Age
  2. Age and edits
  3. Age or edits
  4. Age and edits and nom
  5. Age or nom
  6. Age and nom
  7. (Age or edits) and nom
  8. (Age and nom) or (edits and nom)
  9. (Age and edits) or nom
  10. Age or edits or nom
  11. Age or (edits and nom)
  12. (Age or nom) and edits
  13. (Age and nom) or edits or nom
  14. (Age and nom) or edits
  15. Edits
  16. Edits and nom
  17. Edits or nom
  18. Edits or (nom and age)
  19. Nom
  20. No change
It's not just as simple as asking which of these you prefer in one question and what the minimum edits/time should be in another as views like "2000 edits without a nominator or 1000 edits with a nominator" and "(1000 edits and 2 years) or (2000 edits and 1 year)" are logical.
You could I suppose ask questions like:
  • If a candidate is nominated by an administrator, what should the minimum edit count be?
  • If a candidate is nominated by someone who is not an administrator, what should the minimum edit count be?
  • If a candidate does not have a nominator, what should the minimum edit count be?
But that only captures two of the three dimensions and I wouldn't volunteer to close a discussion that complicated. Thryduulf (talk) 22:44, 22 August 2025 (UTC)Reply
As the one who proposed option F, I'll go split that off into its own RFC question to resolve the ambiguity it will cause the votes. Gramix13 (talk) 22:36, 22 August 2025 (UTC)Reply

Q6. Candidate account age requirement

edit
Latest comment: 21 hours ago4 comments2 people in discussion

If Q5 introduces a new requirement, should the Q5 new requirement be modified to also include "and an account age of 1 year or greater"?

  • Option A – Yes
  • Option B – No

My reasoning follows directly from the proposed question about admin noms, just above. I think that if we have three questions in this fashion, we can separate out the various issues about minimum candidate requirements in a workable way. In other words, the first question would be only about ec as Option A (current practice) versus B – E for the minimum number of edits (and F for other). Then the second question, the one above, would pair the previous answer with yes or no for an admin nom waiver, and the third question, this one, would pair the previous answers with yes or no for a one-year-plus account. I think that covers all the points. --Tryptofish (talk) 20:20, 23 August 2025 (UTC)Reply

Can we switch Q6 and Q7 so the admin nom waiver question can ask about both age and edits? I'd hate to be in a situation where admin noms can waive edit count but not account age, which doesn't feel particularly consistent to me. Tazerdadog (talk) 13:52, 28 August 2025 (UTC)Reply
Good point. I'd support that. --Tryptofish (talk) 22:29, 28 August 2025 (UTC)Reply
  Done. --Tryptofish (talk) 00:23, 29 August 2025 (UTC)Reply

Q7. Candidate admin nominations

edit
Latest comment: 6 days ago8 comments3 people in discussion

If Q5 and/or Q6 introduce a new requirement, should the Q5/Q6 new requirement be waived if the candidate has a nomination from a current administrator?

  • Option A – Yes
  • Option B – No

I original proposed an admin nomination requirement as part of the Minimum candidate requirements section, but two editors have pointed out how that might complicate closing the RFC, so I have gone ahead and split that question off to its own RFC. Gramix13 (talk) 22:40, 22 August 2025 (UTC)Reply

You can view my justification for this question here which links to my proposal in the original RFC question. Gramix13 (talk) 22:43, 22 August 2025 (UTC)Reply
This really isn't what I had in mind. I'd much prefer a question asking if an admin nominator exempts a candidate from the tenure requirements considered above. I think requiring all candidates to have an admin nom is probably a non-starter. Tazerdadog (talk) 00:20, 23 August 2025 (UTC)Reply
Appreciate the clarification, when I read D or (A and F) I saw that initially as two separate votes and not a conditional vote as you describe now. Like Thryduulf said, this is going to create a very complicated question to ask in an RFC with all the possible combinations of age, edits, and noms. I think the best approach would be to focus on solely asking about an edit requirement for this RFC round, and future RFC rounds can slowly add more criteria in response. Thoughts? Gramix13 (talk) 00:33, 23 August 2025 (UTC)Reply
We definitely need to restrict the options from Thryduulf's list, which is untenable. My preference was to ask 1 question for age+edits, and then a second question here for whether a nomination is good enough to waive the age+edit requirement. Ive tried to modify the RFC question in this section to reflect what I am meaning. Tazerdadog (talk) 00:40, 23 August 2025 (UTC)Reply
I agree in the need to trim Thryduulf's list and endorse your edit to the RFC question except for labeling "No" as "current" as when this RFC goes out we won't know ahead of time the consensus of the Minimum candidate requirements RFC, and it could so happen that an edit requirement fails from consensus against such a change. Gramix13 (talk) 00:46, 23 August 2025 (UTC)Reply
I went ahead and removed the current from the question. Tazerdadog (talk) 01:08, 23 August 2025 (UTC)Reply
I switched yes and no, so that option A is yes. I did that because it's what one would expect to see. --Tryptofish (talk) 20:08, 23 August 2025 (UTC)Reply

Q8. Voter guide category in the header

edit
Latest comment: 8 days ago2 comments2 people in discussion

Shall a link to the voter guide category (e.g. Category:Wikipedia administrator elections July 2025 voter guides) be added to the election's header template (e.g. Wikipedia:Administrator elections/July 2025/Header)?

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

I think this was asked about on the talk page last election but ended up being controversial, so it was not added at the time. But maybe with additional discussion there might be some interest. –Novem Linguae (talk) 08:43, 21 August 2025 (UTC)Reply

I'll put in a strong support for including a question like this one (not surprisingly!). --Tryptofish (talk) 19:13, 21 August 2025 (UTC)Reply

Q9. Election clerks with database access

edit
Latest comment: 16 hours ago18 comments6 people in discussion

There is a situation that may arise in the future where an election clerk has both decryption keys and database access. (Database access includes the ability to view the table of votes as a whole, while the keys are needed to decrypt individual votes.) This combination (decryption keys + database access) would give them enough access to read individual private votes (although it would take several steps to do so, and it would violate the Wikimedia Foundation Privacy Policy). Should changes be made to avoid this?

  • Option A – No. Election clerks are trusted enough not to do this. (current)
  • Option B – Yes. We will create a rule that a different election clerk must hold the decryption keys, and not share them with anyone with database access. Clerks with database access can still do the todo list and SecurePoll setup list, and be a poll administrator in the SecurePoll software. They just cannot know the decryption keys.
  • Option C – Yes. We will forbid people with database access from being poll administrators in the SecurePoll software. This means they could do the todo list, but cannot do SecurePoll setup.

I have been an election clerk for the last two elections. I'll probably apply for database access at some point to help with my technical work. Would rather RFC this now than do an RFC mid-season. This is kind of complicated to explain, so simplification of the above wording is welcome. For comparison, for WMF global elections, the election clerk does have database access. –Novem Linguae (talk) 00:31, 24 August 2025 (UTC)Reply

Can you clarify what is meant by "database access" in this question? What database is being gained access to exactly? Gramix13 (talk) 18:49, 24 August 2025 (UTC)Reply
Sure. The database that stores all information for this website. The part that would be important to AELECT is that the securepoll_votes MariaDB table that stores all the votes is included in this access. –Novem Linguae (talk) 19:19, 24 August 2025 (UTC)Reply
I think this question would work better with some kind of reference link to what it means to have database access. My first guess upon reading was that this is referring to WMF employees, but actually it seems like it's a more loosely defined group. Is there somewhere I can see a list and/or the criteria? Leijurv (talk) 01:42, 25 August 2025 (UTC)Reply
There's several groups that have database access. They are mostly WMF employees, although some technical volunteers apply for and receive it. Some groups that come to mind are ops, deployment, and analytics-privatedata-users. –Novem Linguae (talk) 01:59, 25 August 2025 (UTC)Reply
Probably link to the privacy policy in the RFC! Sohom (talk) 16:43, 25 August 2025 (UTC)Reply
  Done –Novem Linguae (talk) 22:53, 26 August 2025 (UTC)Reply
Maybe I'm misunderstanding, but: wouldn't option C be more clearly phrased as "those with database access are never allowed to be election clerks"? Because it's not like database access would be revoked by the WMF if they became an election clerk. So I feel like this would be more accurate? Leijurv (talk) 22:30, 26 August 2025 (UTC)Reply
  Done –Novem Linguae (talk) 22:53, 26 August 2025 (UTC)Reply
Question. If another election clerk handles decryption key, does that mean that you (DB+Election clerk) cannot view the private data even if you wanted to? If yes, explicitly clarifying it in B might be good. Soni (talk) 17:27, 28 August 2025 (UTC)Reply
Someone with database access can view encrypted private data but cannot decrypt it. The important thing here is the combination of decryption key + database access, not election clerk + database access. I went ahead and rewrote the question and options just now to hopefully be clearer. Feel free to tweak or provide feedback. –Novem Linguae (talk) 19:33, 28 August 2025 (UTC)Reply
What duties could the election clerk perform without access to the decryption key? (I'm guess voter-roll generation/general setup stuff?) Sohom (talk) 19:44, 28 August 2025 (UTC)Reply
SecurePoll: Everything I currently do, minus typing in the encryption keys upon poll creation, and typing in the decryption keys then hitting the tally button. More details at Wikipedia:Administrator elections/July 2025/SecurePoll setup#Instructions for election clerks.
Non-SecurePoll: If Option C were selected, we might have to create a new position that does clerical stuff but has no access to SecurePoll. There's a whole checklist for non-SecurePoll stuff that current election clerks also handle, i.e. Wikipedia:Administrator elections/July 2025/Todo list. –Novem Linguae (talk) 19:56, 28 August 2025 (UTC)Reply
Perhaps it can be worded something like the following:
SecurePoll encrypts individual votes when storing them into the database underlying the MediaWiki installation. Two election clerks (for redundancy) hold the necessary decryption keys to trigger SecurePoll to tally the votes. If they had access to the database, though, they would be able to read and decrypt individual votes from the database. (Note this would violate the Wikimedia Foundation Privacy Policy, to which everyone must agree before being granted database access.) Most people requiring access are WMF employees, though there are some volunteers who are given access to accomplish specific technical tasks. What should be the rules for this situation?
  • Option A: No restrictions; anyone with database access is trusted to follow the privacy policy.
  • Option B: Election clerks with database access cannot hold the election decryption keys. They can perform all tasks not involving the decryption keys.
  • Option C: Anyone with database access cannot serve as an election clerk.
isaacl (talk) 23:41, 28 August 2025 (UTC)Reply
An additional complicating factor is if someone had the decryption key for a past poll, and gained database access later before the voting records were deleted (which, if I recall correctly, happens after a fixed time?), then they would retroactively have access to the individual votes for the past poll. So if an option other than A passes, then we may want to have a rule about waiting until the voting data is no longer available before gaining database access. isaacl (talk) 23:50, 28 August 2025 (UTC)Reply
Does it matter if they have that access? Like they can't change the outcome of election. Sohom (talk) 23:53, 28 August 2025 (UTC)Reply
Yes, when privacy is promised. Breaking trust discourages candid voting (and theoretically enables vote buying, though on English Wikipedia, editor farms probably enable paid voting sufficiently already). isaacl (talk) 00:19, 29 August 2025 (UTC)Reply
Checkuser-ish voter data is deleted after 60 days. I think votes are kept indefinitely. Perhaps the reason for that is if a re-tally is needed due to discovering a sockfarm or something. –Novem Linguae (talk) 05:05, 29 August 2025 (UTC)Reply

Q10. Next election date

edit
Latest comment: 1 hour ago15 comments8 people in discussion

Keeping in mind that there was an RFC that stated that AELECT should be held every 5 months, when should AELECT3 be held? (It is possible that a November date might conflict with Thanksgiving and WP:ACE, and that a December date might conflict with Christmas and WP:ACE.)

  • Option A – November 2025, 4 months after AELECT2
  • Option B – December 2025, 5 months after AELECT2
  • Option C – January 2026, 6 months after AELECT2

There's too many different opinions over at Wikipedia talk:Administrator elections#AELECT3 proposed dates, so we should probably RFC this. –Novem Linguae (talk) 09:02, 25 August 2025 (UTC)Reply

I think it would be helpful to know the exact dates involved, stating only the month on the RFC compared to the day schedule on that page seems too vague to me, and that could lead to confusion about the specific dates after the RFC closes. Gramix13 (talk) 00:34, 27 August 2025 (UTC)Reply
Can I also suggest October 2025 as an option? That way we can do the election earlier before ACE, which avoiding a delay. I'm not sure if that sounds too soon or not, but it would mean avoiding ACE's election timeline without going beyond 5 months. In the future, maybe there needs to be coordination between the two elections to avoid this problem going forward. Gramix13 (talk) 00:37, 27 August 2025 (UTC)Reply
Given 5 months is approximately 152 days, the ideal start if we ignored holidays would be on or near December 8th. If we started at the end of October, it would only have been four months between elections. (Though, it seems that there will likely be some disadvantage no matter the option.) --Super Goku V (talk) 05:17, 27 August 2025 (UTC)Reply
8th December is a religious holiday in many countries. It should stay on the 5-month schedule. The whole point of it is there will always be times which are better and worse for some. Valenciano (talk) 08:18, 29 August 2025 (UTC)Reply
Then skipping a day would make it the 9th and be after said holiday, but I get the point that it is impossible to avoid them all. (Personally, I think it would be better to schedule the elections out farther in advance once we get through a few of them.) --Super Goku V (talk) 19:41, 29 August 2025 (UTC)Reply
The only other idea I have is that extra days can be added to the phases to reduce the impact of the holidays, but with all of those set in stone, we would need an RfC for that as well. (Plus, it would need support and I am not convinced that there is enough for this.) --Super Goku V (talk) 05:24, 27 August 2025 (UTC)Reply
I oppose delaying it to January. As some said on the WT: AELECT thread, the whole point of 5 months is to change the dates every year, for better accomodation of all people. I'd say to stick with Dec, because it only overlaps ACE voting and EFA call for condidates, which should not be a problem IMO. ~/Bunnypranav:<ping> 06:10, 27 August 2025 (UTC)Reply
Re “no known conflicts” in January: not sure if this was discussed already and I don’t know how big an issue it is for some, but an editor did raise concerns in the linked discussion that January causes issues with Epiphany and Orthodox Christmas. Perfect4th (talk) 18:52, 27 August 2025 (UTC)Reply
I had changed it by adding the word "known", but now that you point it out, I'm inclined to delete the entire phrase. I feel like it's a non-neutral question with that in there, as if telling respondents that this is the safe answer to give. Maybe better to leave it out? --Tryptofish (talk) 18:56, 27 August 2025 (UTC)Reply
That’s a fair point too, I’d agree with leaving it out. Perfect4th (talk) 19:11, 27 August 2025 (UTC)Reply
I think I would prefer that the initial paragraph list any potential conflicting dates, such as the relevant portion of the arbitration committee election timeline, leaving the options without any side commentary. isaacl (talk) 00:26, 29 August 2025 (UTC)Reply
That's a good point, and I implemented it. --Tryptofish (talk) 00:30, 29 August 2025 (UTC)Reply
Seems less organized this way. It seems to put relevant info farther away from the option it's associated with. –Novem Linguae (talk) 04:16, 29 August 2025 (UTC)Reply
The way I see it, it's not difficult for anyone to find the information this way, whereas putting the comments within each choice comes across as a non-neutral poll question. --Tryptofish (talk) 18:55, 29 August 2025 (UTC)Reply
Add topic
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_elections/July_2025/RFC_workshop&oldid=1308488181"