I moved this from the main page to declutter it ProcrastinatingReader (talk) 09:47, 8 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241108094700","author":"ProcrastinatingReader","type":"comment","level":2,"id":"c-ProcrastinatingReader-20241108094700-Espresso_Addict-20241106075200","replies":[]}}-->

A few general points:

• Maybe we should not overwhelm the community with absolutely tons of options. We'll get poor participation that way. I think some of them mentioned here are not essential to knock down, at least not at an RFC level (eg "Voting instruction in the interface"). Others have way too many options presented (eg "Election frequency"), which is going to make it hard for closers in the event of a split vote, and will lead to no consensus outcomes. Fewer options please?
• I feel guilty for starting the "multiple subquestions under one heading" trend, but when I first did this, it was just to illustrate a proposal to Thryduulf. I think in the actual RfC, perhaps each sub-question should be a level 3 heading or something? I guess actual formatting can be figured out later though, perhaps by Novem/leeky or some-such.
• At some point, let's move a snapshot of this page with threaded discussion onto talk, so we can see the 'final RfC' without comments here, for final thoughts? I feel like it's getting a bit cluttered. (I also take some responsibility for this lol - I think it's much easier to bash out changes with inline discussion, but works best when it's also easy to delete the comments afterwards IMO)

ProcrastinatingReader (talk) 09:49, 8 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241108094900","author":"ProcrastinatingReader","type":"comment","level":1,"id":"c-ProcrastinatingReader-20241108094900-General_discussion","replies":["c-Thryduulf-20241108112000-ProcrastinatingReader-20241108094900","c-Isaacl-20241108220900-ProcrastinatingReader-20241108094900","c-Leijurv-20241112233400-ProcrastinatingReader-20241108094900"]}}-->

• Yes, at some point we're going to need to decide which questions are worth asking. If any of them don't require an RFC then we should just wait until after the RFC to decide them. In some cases that might be getting a yes/no answer in the RFC and deciding details later if the answer is yes, but for others (e.g. number of candidates) the options do need to be in the RFC.
• Deciding which options should be presented for each question is a matter of fine tuning and we aren't at that stage yet with the election timing question, but it will come.
• It's too early to get bogged down in formatting, that's something to think about after we've decided what questions we're going to ask. We should consider what order we ask them in at that time too though.
• I expect that when things are pretty much agreed that the page on which the actual RFC will happen will be created with a draft and comments sought on that draft. If discussion is complete on any question though maybe collapsing the discussion will help? Thryduulf (talk) 11:20, 8 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241108112000","author":"Thryduulf","type":"comment","level":2,"id":"c-Thryduulf-20241108112000-ProcrastinatingReader-20241108094900","replies":[]}}-->
• I wondering if there is a way to take a straw poll to find the most popular options, so the final RfC can just include those? The more questions and choices there are, the more fatigue there'll be, and many editors will lose focus and let the RfC drop off their to-do list, until the next election, when they'll raise their concerns again. isaacl (talk) 22:09, 8 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241108220900","author":"Isaacl","type":"comment","level":2,"id":"c-Isaacl-20241108220900-ProcrastinatingReader-20241108094900","replies":[]}}-->

It looks like the questions and answers are settling down. How shall we prioritize which ones to put to the community? All? Leijurv (talk) 23:34, 12 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241112233400","author":"Leijurv","type":"comment","level":2,"id":"c-Leijurv-20241112233400-ProcrastinatingReader-20241108094900","replies":[]}}-->

Should we standardise on presenting numerical/duration options in either increasing or decreasing order, if so which? The argument for is consistency of presentation and is arguably less confusing for voters, the argument against is that it allows for the current option to be at the top regardless of whether increases or decreases are proposed. Thryduulf (talk) 23:11, 7 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241107231100","author":"Thryduulf","type":"comment","level":1,"id":"c-Thryduulf-20241107231100-Option_ordering","replies":["c-Isaacl-20241108003600-Thryduulf-20241107231100"]}}-->

• If the current option is flagged, I don't personally feel it needs to be first. Thus my preference would be to sort numerical options for simplicity of browsing through them. isaacl (talk) 00:36, 8 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241108003600","author":"Isaacl","type":"comment","level":2,"id":"c-Isaacl-20241108003600-Thryduulf-20241107231100","replies":[]}}-->

I see several proposals in the RFC workshop that would push administrator elections to be more like RFA. In particular, the things that increase candidate scrutiny: maximum # of candidates in each election, discussion phase length, and Community Chat. The current way these 3 things are done minimizes candidate stress and reduces candidate scrutiny, and I daresay that the original architect(s) of AELECT probably did these things this way on purpose. This is just a general warning that we should be careful of changing them. They may be the "secret sauce" that makes AELECT work so well. –Novem Linguae (talk) 16:47, 8 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241108164700","author":"Novem Linguae","type":"comment","level":1,"id":"c-Novem_Linguae-20241108164700-Careful_of_slowly_just_turning_AELECT_into_RFA","replies":["c-Isaacl-20241108220000-Novem_Linguae-20241108164700","c-Valereee-20241118131000-Novem_Linguae-20241108164700"]}}-->

While I agree that several proposals run counter to the consensus previously established, for better or worse, one of English Wikipedia's decision-making traditions is that consensus can change any time, and so no one is compelled to have patience to evaluate previous decisions over some period of time. Ultimately, many of the editors who like to participate in these matters like talking about whatever matter is under consideration, many editors in general like the simplicity of voting, and many of those who like voting like seeing what others think. So it's not surprising that's how many people want to proceed. isaacl (talk) 22:00, 8 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241108220000","author":"Isaacl","type":"comment","level":2,"id":"c-Isaacl-20241108220000-Novem_Linguae-20241108164700","replies":["c-Femke-20241109093900-Isaacl-20241108220000"]}}-->

Consensus will likely change here to allow for a bit more scrutiny. I do share the worries of Novem however that if we don't design the Workshop well, we may go too far into correction mode. That is: people might like to either restrict the number of candidates significantly or make the discussion phase much longer, and if we do these two questions in paralell, it's difficult to make a good decision here. —Femke 🐦 (talk) 09:39, 9 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241109093900","author":"Femke","type":"comment","level":3,"id":"c-Femke-20241109093900-Isaacl-20241108220000","replies":["c-Soni-20241109095200-Femke-20241109093900"],"displayName":"\u2014Femke \ud83d\udc26"}}-->

I concur with Novem and Femke in this. My central worry about AELECT workshop has been to skip the mistakes done at RECALL's Phase 2 (Give too many indepenedent options, and people will choose the uniquely favourable ones in vacuum than a system that works). So I'd rather have much smaller tweaks for AELECT now that we know it works, presented more wholesale. Tweaking every aspect of the proposal one by one is way more likely to spoil the "secret sauce" that worked so far. Soni (talk) 09:52, 9 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241109095200","author":"Soni","type":"comment","level":4,"id":"c-Soni-20241109095200-Femke-20241109093900","replies":["c-Isaacl-20241118032400-Soni-20241109095200"]}}-->

Yeah, and who warned about the problems with trying to discuss each aspect of the recall process as if they were independent? ;-) I think that some of the aspects that have been raised are fairly independent, within the existing election process. As I discussed above, I think it's sufficient to have a discussion on how to prioritize potential candidates, and thus drop discussion on when potential candidates can sign up and how frequently, as the priortization will take care of it. Other aspects are a bit harder to decide to drop or merge, though, without those really interested in those aspects later complaining the RfC was really badly planned (as has already been said about the development of the election and recall processes). While personally I agree with not necessarily having to tackle everything at once, I appreciate though that there's no established consensus on what to tackle first. And for better or worse, processes only work when people are willing to go along with them, and feeling like their concerns have been worked on (even if not resolved) helps with buy-in. isaacl (talk) 03:24, 18 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241118032400","author":"Isaacl","type":"comment","level":5,"id":"c-Isaacl-20241118032400-Soni-20241109095200","replies":[]}}-->

I'd also say that trying to set the cutoff support for a successful election so that it mimics that of RfA is another. So our best candidate got 83% in a secret ballot and would possibly have gotten 99% in an RfA. Admin elections are clearly viewed as being vastly lower risk/stress to candidates than RfA, but turns out they're also possibly less likely to rack up high numbers of support, and possibly less likely to succeed. Candidates can decide whether the tradeoff is worth it to them. We don’t need to try to make election results mimic RfA results. They’re different processes. I don't think we should be assuming we need to lower the cutoff, even if that was the kneejerk reaction of the average person watching the elections. Valereee (talk) 13:10, 18 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241118131000","author":"Valereee","type":"comment","level":2,"id":"c-Valereee-20241118131000-Novem_Linguae-20241108164700","replies":[]}}-->

I believe we should be explicitly framing this RfC as using ranked-choice voting. Given that we have >2 choices in every case, we run the risk of ending up with no consensus, or marginal consensus, on many questions, and consequently defaulting to the status quo even though that may have limited support. It creates more work for a closer, but it would help establish clear consensus and avoid the possibility of a runoff. Vanamonde93 (talk) 01:08, 18 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241118010800","author":"Vanamonde93","type":"comment","level":1,"id":"c-Vanamonde93-20241118010800-Ranked_choice","replies":["c-Espresso_Addict-20241118011400-Vanamonde93-20241118010800","c-Isaacl-20241118030600-Vanamonde93-20241118010800","c-Novem_Linguae-20241118031800-Vanamonde93-20241118010800"]}}-->

Yes, definitely. Espresso Addict (talk) 01:14, 18 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241118011400","author":"Espresso Addict","type":"comment","level":2,"id":"c-Espresso_Addict-20241118011400-Vanamonde93-20241118010800","replies":[]}}-->

Assuming you just mean providing an ordered list of preferred choices, and not instant runoff voting or single transferrable vote, sure. isaacl (talk) 03:06, 18 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241118030600","author":"Isaacl","type":"comment","level":2,"id":"c-Isaacl-20241118030600-Vanamonde93-20241118010800","replies":[]}}-->

Ranked choice voting for Wikipedia RFCs sounds uncommon and I suspect it'd make it hard to close. Does anyone have an example of a recent RFC that used rank choice voting? No consensus outcomes defaulting to the status quo wouldn't be a problem for most of the mini RFCs in the workshop, in my opinion, because the first administrator election went fairly well, so sticking with those "settings" would be reasonable in cases of no consensus. –Novem Linguae (talk) 03:18, 18 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241118031800","author":"Novem Linguae","type":"comment","level":2,"id":"c-Novem_Linguae-20241118031800-Vanamonde93-20241118010800","replies":["c-Isaacl-20241118032600-Novem_Linguae-20241118031800"]}}-->

People saying they prefer A over C over D isn't that uncommon. isaacl (talk) 03:26, 18 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241118032600","author":"Isaacl","type":"comment","level":3,"id":"c-Isaacl-20241118032600-Novem_Linguae-20241118031800","replies":["c-Femke-20241119074800-Isaacl-20241118032600"]}}-->

It wouldn't be quite ranked voice, but it makes it easier to find consensus when people give multiple preferences. If there are 70% of people happy with option C, but option B is the more popular (30% first choice), it makes sense to say there is consensus for option B. If people just indicate their first choice, a closer will have to guess which compromise is acceptable. —Femke 🐦 (talk) 07:48, 19 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241119074800","author":"Femke","type":"comment","level":4,"id":"c-Femke-20241119074800-Isaacl-20241118032600","replies":["c-Isaacl-20241119185800-Femke-20241119074800"],"displayName":"\u2014Femke \ud83d\udc26"}}-->

Although there can be specific cases where one option encompasses another, generally evaluators of consensus on English Wikipedia don't guess on the best compromise, as it's injecting their own personal opinion rather than determining the result of the discussion. And if the first choice is scattered amongst many options, while C is supported by 70% of participants, C seems to be a more suitable consensus result (based solely on this hypothetical, absent any further details). isaacl (talk) 18:58, 19 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241119185800","author":"Isaacl","type":"comment","level":5,"id":"c-Isaacl-20241119185800-Femke-20241119074800","replies":[]}}-->

There's a big danger of crazy stuff happening whenever there are 3 or more choices. IMO the best method to handle this and to move this great idea forward (vs. dying under it's own weight) is to workshop a single new proposal and present it in an RFC for approval. Ranked choice is cool but involves creating a whole new system in Wikipedia. Another way is to simply ask everybody to comment on every choice and then do a close based on that. North8000 (talk) 19:44, 22 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241122194400","author":"North8000","type":"comment","level":1,"id":"c-North8000-20241122194400-Ranked_choice","replies":[]}}-->

We've noted quite a few times that all of the options relate to each other in complex ways, for instance:

• The election frequency and a potential maximum of candidates
• The election frequency and scrutineering
• Discussion period, voter guides and pass percentage (I imagine that with more scrutiny, we'd have fewer blanket opposes, but more skeletons discovered).

Would it be an idea to do this RfC set in two stages? For instance, first decide on ideal election frequency, then on the maximum number of candidates? And first decide the discussion period length, before making changes to pass percentages? To speed things up, we can ask for closers to be lined up before, as ask the easier questions first (numerical questions are a bit easier to close, so we could start with those).

Longer term, I imagine we will want to tweak some of the rules again after the next election. I don't want to do another "trial" in the sense that we need a second confirmatory RfC about whether elections are a green light, but it may be good to bake this in into the RfC of the first confirmatory RfC. That way, we can also experiment with smaller tweaks first and then adjust where necessary, ensuring we keep the strenghts of EFA alive. —Femke 🐦 (talk) 07:46, 19 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241119074600","author":"Femke","type":"comment","level":1,"id":"c-Femke-20241119074600-Sequencing_questions","replies":["c-Bugghost-20241126085200-Femke-20241119074600","c-Novem_Linguae-20241128091300-Femke-20241119074600"],"displayName":"\u2014Femke \ud83d\udc26"}}-->

I would support two stages - I agree that the outcomes of the candidate quantity limits and election frequency questions are likely going to be linked, so deciding one then the other makes sense to me. This might make the RFC process as a whole longer, but I think consensus would be easier to get to if we do it this way. BugGhost🦗👻 08:52, 26 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241126085200","author":"Bugghost","type":"comment","level":2,"id":"c-Bugghost-20241126085200-Femke-20241119074600","replies":["c-Risker-20241127160300-Bugghost-20241126085200"]}}-->

Bluntly, I think that instead of all of these questions and all of these RFCs on this and other RFC-on-RFA based issues, it is better to present a single version for RFC, with all of these questions answered. The community has already had a minimum of 5 RFCs on this general topic in the last 18 months. The next RFC should be on a policy that, just like any other policy on our project, can and will be modified as needed based on the overall community experience. Nobody wants two or more further RFCs on this topic. Just make a single proposal. Risker (talk) 16:03, 27 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241127160300","author":"Risker","type":"comment","level":3,"id":"c-Risker-20241127160300-Bugghost-20241126085200","replies":["c-Femke-20241127212300-Risker-20241127160300"]}}-->

Given we found consensus for the first set of EFA rules, perhaps we could do this again with tweaked rules. The advantage of individual mini RfCs is that we can ensure we get a more thought-out process than before. That said, I hope we can find consensus to not field at least half of the questions now being workshopped. It should be straightforward that if there is a maximum, those that can't stand can decide themselves what to do next rather than that it is pre-ordained. No need to use community time there. —Femke 🐦 (talk) 21:23, 27 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241127212300","author":"Femke","type":"comment","level":4,"id":"c-Femke-20241127212300-Risker-20241127160300","replies":[],"displayName":"\u2014Femke \ud83d\udc26"}}-->

I think the 2nd, 3rd, 4th, etc. questions in multi-question sections are excellent candidates for dropping completely from the RFC. A lot of those are details that can be hashed out on the fly and may not need an RFC. "Maximum # of candidates in each election" is the worst offender, but other multi-part questions also fall into this pattern of having less important or unimportant follow up questions, in my opinion. –Novem Linguae (talk) 09:13, 28 November 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241128091300","author":"Novem Linguae","type":"comment","level":2,"id":"c-Novem_Linguae-20241128091300-Femke-20241119074600","replies":[]}}-->

I've started a discussion that may perhaps interest editors here, at WP:AN#Elections, recall, and backlogs. --Tryptofish (talk) 01:09, 5 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241205010900","author":"Tryptofish","type":"comment","level":1,"id":"c-Tryptofish-20241205010900-Related_discussion","replies":[]}}-->

Is there anytime we can expect the RFC to start, or when it will at least start to be put together? We seem to have a lot of the information we need to get started. fanfanboy (block_talk) 20:35, 9 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241209203500","author":"Fanfanboy","type":"comment","level":1,"id":"c-Fanfanboy-20241209203500-Timeline_for_RFC","replies":["c-Femke-20241209204200-Fanfanboy-20241209203500","c-Novem_Linguae-20241210023800-Fanfanboy-20241209203500"]}}-->

I think the key remaining issue is that we need to agree if and which subquestions to not field, so that the RfC is more respectful of people's time. And a decision on whether we want to sequence the questions, as a way to deal with dependencies. —Femke 🐦 (talk) 20:42, 9 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241209204200","author":"Femke","type":"comment","level":2,"id":"c-Femke-20241209204200-Fanfanboy-20241209203500","replies":[],"displayName":"\u2014Femke \ud83d\udc26"}}-->

I think this is ready to go. I'd rather get it published with imperfections than get too bogged down in details.

I think having a lot of questions is probably OK. The alternative is to skip asking the questions at all, or have a part 2 which will double the length of the process. I think any meh questions that we didn't eliminate in the workshop will snow close fairly quickly.

I propose the following: 1) copy paste everything to a different page. 2) delete all the comments and anything with a strikethrough, leaving just the questions/options. 3) split multi question sections into one section per question. it will be really hard for the closer if we try to mix questions in the same section. 4) consult with @Theleekycauldron to see how she wants to integrate this into WP:RFA2024 phase 2. Maybe just let me know the title of the page you want me to create the RFC at? –Novem Linguae (talk) 02:38, 10 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241210023800","author":"Novem Linguae","type":"comment","level":2,"id":"c-Novem_Linguae-20241210023800-Fanfanboy-20241209203500","replies":["c-Fanfanboy-20241210165500-Novem_Linguae-20241210023800","c-Theleekycauldron-20241211054100-Novem_Linguae-20241210023800"]}}-->

Yeah this sounds good to me. fanfanboy (block_talk) 16:55, 10 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241210165500","author":"Fanfanboy","type":"comment","level":3,"id":"c-Fanfanboy-20241210165500-Novem_Linguae-20241210023800","replies":["c-Femke-20241210175900-Fanfanboy-20241210165500"]}}-->

I've closed one that was unlikely to gain consensus, and have removed a non-sensical option from another. Happy to go now, even though sequencing is still my preference. —Femke 🐦 (talk) 17:59, 10 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241210175900","author":"Femke","type":"comment","level":4,"id":"c-Femke-20241210175900-Fanfanboy-20241210165500","replies":[],"displayName":"\u2014Femke \ud83d\udc26"}}-->

@Novem Linguae: I've gone ahead and quickly mocked up something at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections. I haven't split out the questions or added discussion sections – for such a large RfC, I strongly suggest we move the discussion sections to the talk page, with a small section for meta discussion at the top. Feel free to monkey around with the formatting :) theleekycauldron (talk • she/her) 05:41, 11 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241211054100","author":"Theleekycauldron","type":"comment","level":3,"id":"c-Theleekycauldron-20241211054100-Novem_Linguae-20241210023800","replies":["c-Soni-20241211062100-Theleekycauldron-20241211054100","c-Isaacl-20241211072000-Theleekycauldron-20241211054100"]}}-->

I did some minor copyediting and moving the order around. I agree with @Femke on removing some of the questions for future resolution (whether RFC or general discussion). I'd personally choose to cut "Call for Candidates", "Candidate Ordering", "Support and Oppose Section" for that, leaving us with 10 sections. Probably still a lot, so might be worth considering the 4-5 "most important" questions to be answered in first sequence Soni (talk) 06:21, 11 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241211062100","author":"Soni","type":"comment","level":4,"id":"c-Soni-20241211062100-Theleekycauldron-20241211054100","replies":[]}}-->

I think for "Suffrage requirements', it's dangerous to have an option tied to changes to the SecurePoll software, without a backup plan. I wouldn't want elections to be blocked waiting for SecurePoll changes to be made, tested, reviewed, and deployed.

Regarding questions that I think can be deferred: I think question 2 under "Election frequency" can wait until the community actually sets a schedule and has some more elections. I'm guessing for an interim period they won't be run as frequently as the community might desire as per question 1, so I think it's easier to just run them whenever we can for now and revisit this question later.

I think question 2 under "Minimum vote requirement" can also be deferred. Candidates have no control over who turns up to vote for them; I don't know why their support level should be compared to voters who voted for other candidates but abstained for them. If one candidate attracts a lot of people interested only in voting for them, I don't think the other candidates should be penalized for it.

I think "Call for candidates duration" is a bit overly detailed until there's a history of elections running regularly. We can have the easiest approach for now: open signup, and adapt it based on the results to the maximum number of candidates question.

It feels to me like questions 1 and 2 for "Voter guides" can be combined, and question 3 dealt with by discussion with interested editors rather than a full community RfC. isaacl (talk) 07:20, 11 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241211072000","author":"Isaacl","type":"comment","level":4,"id":"c-Isaacl-20241211072000-Theleekycauldron-20241211054100","replies":["c-Fanfanboy-20241211131900-Isaacl-20241211072000","c-Novem_Linguae-20241211191200-Isaacl-20241211072000","c-Femke-20241212212700-Isaacl-20241211072000"]}}-->

I'm not sure what the danger is with SecurePoll. We just ran an election with option 1, and option 2 should be fairly easy to set up from what I read. fanfanboy (block_talk) 13:19, 11 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241211131900","author":"Fanfanboy","type":"comment","level":5,"id":"c-Fanfanboy-20241211131900-Isaacl-20241211072000","replies":["c-Isaacl-20241211175700-Fanfanboy-20241211131900"]}}-->

My understanding is that extended-confirmed is a specific user group on English Wikipedia, and that SecurePoll lacks the ability to check for membership in a specific user group to determine in real-time if a voter is eligible. If this is so, then new development is required. (I think the minimum edit and account age thresholds could be mimicked; this wouldn't cover anyone who had been sanctioned by being removed from the extended-confirmed group.) isaacl (talk) 17:57, 11 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241211175700","author":"Isaacl","type":"comment","level":6,"id":"c-Isaacl-20241211175700-Fanfanboy-20241211131900","replies":["c-Isaacl-20241211181500-Isaacl-20241211175700"]}}-->

Looking at the code some more, I see SecurePoll can be configured with a list of user groups that form the pool of voters. Thus I agree that option 2 can be implemented as-is. isaacl (talk) 18:15, 11 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241211181500","author":"Isaacl","type":"comment","level":7,"id":"c-Isaacl-20241211181500-Isaacl-20241211175700","replies":[]}}-->

Sounds like folks on this talk page went to eliminate a couple more questions. We can slow down a bit and see if consensus develops to eliminate some specific questions. –Novem Linguae (talk) 19:12, 11 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241211191200","author":"Novem Linguae","type":"comment","level":5,"id":"c-Novem_Linguae-20241211191200-Isaacl-20241211072000","replies":[]}}-->

Basically fully agree with isaacl:

• Agree that the "Call for candidates", "Candidate ordering" and "Support and oppose section" can be omitted, mostly per WP:BIKESHED.
• Regarding Suffrage options, option 1 (current option) isn't scalable. I don't think we need a mini-RfC to decide that. Option 2 is what we do for standard RfAs anyway.
• I agree that the election frequency question is difficult to pose now, as we don't know how much demand there is when this is a regular thing. That said, this is something that should be easy to change if it doesn't work.
• Would omit rather than defer Q2 from minimum vote requirement. Unlikely to gain consensus, as it doesn't really make sense to penalize people if there is a highly contentious or well-known editor in their EFA cohort.
• Agree we don't really need an RfC for voter guide Q3 (official voter guide). That can be decided by discussion, in which we'd talk about what to include and whether this is useful for voters.

Getting agreement here means that the mini-RfC stage is hopefully faster! —Femke 🐦 (talk) 21:27, 12 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241212212700","author":"Femke","type":"comment","level":5,"id":"c-Femke-20241212212700-Isaacl-20241211072000","replies":["c-Novem_Linguae-20241213024400-Femke-20241212212700"],"displayName":"\u2014Femke \ud83d\udc26"}}-->

I think voter guides are very contentious, and that it'd probably be helpful to get the RFC for that out of the way now. –Novem Linguae (talk) 02:44, 13 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241213024400","author":"Novem Linguae","type":"comment","level":6,"id":"c-Novem_Linguae-20241213024400-Femke-20241212212700","replies":["c-Isaacl-20241213171500-Novem_Linguae-20241213024400"]}}-->

I think linking to personal voter guides has been contentious. I don't think an overview of candidates similar to Wikipedia:Arbitration Committee Elections December 2024/Candidates/Guide, the topic of question 3, is very contentious. What to include in such an overview can be debated, but I think a set of facts that no one objects to can be used at first. I'd rather defer the question for additional info to include to a later RfC, if needed. isaacl (talk) 17:15, 13 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241213171500","author":"Isaacl","type":"comment","level":7,"id":"c-Isaacl-20241213171500-Novem_Linguae-20241213024400","replies":[]}}-->

This is the only new Admin idea that actually worked, and the only one that addressed the actual problem at RFA. Now it looks like the process to continue it is dying under it's own weight and complexity. My suggestion: Quickly float the main questions here and then quickly workshop a single proposal and go to an RFC with it within 2 weeks. A part of it would say we recognize that it will probably need further tweaking later on. Sincerely, North8000 (talk) 20:31, 12 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241212203100","author":"North8000","type":"comment","level":1,"id":"c-North8000-20241212203100-Let's_just_workshop_a_single_proposal_and_go_to_an_RFC_with_it","replies":["c-Fanfanboy-20241212205700-North8000-20241212203100","c-Isaacl-20241212230800-North8000-20241212203100"]}}-->

Things seem to be going pretty smoothly as far as I can tell. I know it's moving pretty slow (which is why I wanted to get things moving on to the next step as seen in the section above), but there's no need to rush this when there's no need to. fanfanboy (block_talk) 20:57, 12 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241212205700","author":"Fanfanboy","type":"comment","level":2,"id":"c-Fanfanboy-20241212205700-North8000-20241212203100","replies":[]}}-->

For better or worse, English Wikipedia decision-making tradition is to have community discussion if enough people want to discuss a decision, and a lot of people have expressed a desire to weigh in on different aspects of the administrator election process. I agree it's cumbersome to do everything this way, but the catch-22 is that the only way to do something else is to have a discussion that agrees upon it, and I don't think there's going to be agreement for that in this case. It's challenging trying to set up a request for comments by consensus discussion, because it's hard to keep enough people engaged and focused to reach a consensus, and that doesn't provide much incentive for participants to work towards compromise approaches. If everyone had quickly agreed to a single proposal, it would have been done and proposed already. Nonetheless, I think progress is being made in identifying the questions for the next RfC. isaacl (talk) 23:08, 12 December 2024 (UTC)[reply]__DTELLIPSISBUTTON__{"threadItem":{"timestamp":"20241212230800","author":"Isaacl","type":"comment","level":2,"id":"c-Isaacl-20241212230800-North8000-20241212203100","replies":[]}}-->