v t e 2021 Arbitration Committee Elections Voter log Contact the coordinators Discuss the elections Quick guide Candidates: Candidate guide Candidate statements Questions for the candidates Discuss the candidates Personal voter guides These guides represent the thoughts of their authors. All individually written voter guides are eligible for inclusion. Kudpung Epiphyllumlover Moneytrees TRM Atsme Tryptofish Elonka Pythoncoder Nick Giraffer Ealdgyth

ArbCom confirmation of scrutineers

Currently, scrutineers are confirmed by ArbCom in order to be granted local CheckUser permissions. Should the process be changed so that scrutineers are granted CU perms by community consensus rather than the Arbitration Committee? @ Swarm: Feel free to edit this to better reflect your suggestion. — Wug· a·po·des​ 00:38, 24 October 2020 (UTC) reply

• Just spitballing here, I would write something like:

Proposal to standardize the process of appointing scrutineers: The scrutineers are to be recruited and formally appointed by the Electoral Commission via the Stewards' noticeboard, in line with the existing membership requirements for Scrutineers. Once appointed, they are authorized to use their existing CU permission on English Wikipedia, within the scope of the Scrutineer role, as has already been articulated by the community.

Rationale: Currently, there is no formal process for appointing Scrutineers. The current de facto process is that Steward volunteers are informally recruited by the Electoral Commission, then formally authorized by Arbcom, in line with Arbcom's role as the body that authorizes local CU access. However, the Stewards are already global CUs, and they are already authorized to act as CUs within the scope of the Scrutineer position by the community. Nothing in the local or global CU policy dictates that our local community does not have the authority to grant Stewards local CU access for a specific purpose, and that such a decision must be approved by Arbcom. The Arbcom Elections are meant to be independent from Arbcom, so naturally Arbcom should not have a role in appointing Election officials, even if it is mainly procedural. This proposal would not change anything in practice, it would merely formally place the appointment of the Scrutineers in the hands of the Electoral Commission (who are directly appointed by the community), and would thus remove Arbcom's role in appointing these important election officials. ~Swarm~ ^{sting} 01:23, 24 October 2020 (UTC) reply

• So there are some problems to overcome on this, the checkuser policies allow for elected arbcoms, comprised of members that have at least 25 supporters, may directly appoint anyone as a CU -- the only other process is to have a community CU election. I don't think it is worth trying to work around the global policy for this once-a-year thing; I can't see arbcom ever denying a steward selected as a scrutineer by the Ecomm. — xaosflux ^Talk 14:54, 21 November 2020 (UTC) reply

A few remaining guides questions

I think my 2020 Guides 1c might be worth revisiting as a separate question from this year's 1. I think also Guides q8 would be worth revisiting with the obvious consensus but apparently no-consensus "nix the specific guides, add the category" on the template. (These are ones I'd like to see.)

Browsing through the rest, these others might be interesting to sort out:

• Suffrage 3 regarding increasing minimum "live" edit count, which a set of !voters were discussing.
• Sorting of candidates doesn't look, er, sorted, based on the discussion that occurred at VPT following RFC2020.
• Voting system looks to be reasonably settled but I generally agree it's not the best voting system. I do agree that active opposition/support, and passive neutrality, are good qualities to retain in a future system. Where before RFC2020 was this question last discussed?

-- Izno ( talk) 03:31, 1 November 2020 (UTC) reply

For ease of reference:

• Guides 1c: "A candidate who writes a guide must declare that they are a candidate in that guide."
  • This received a lot of support and little opposition but didn't pass due to interaction of first and second choice votes with 1a/1b (whether candidates may or may not write guides)
• Guides8a/ 8b "User guides to the candidates wiil/will not be advertised on the ACE banner."
  • No consensus between them, 8b (will be advertised) passed by default as the status quo.
• Suffrage 3a/ 3b whether the requirement for 10 live edits should be dropped.
  • Very clear support for retaining 10 edits, many commenters said or implied they would prefer a higher number.
• Candidate order 1c "Candidate order should be randomized by viewer but not change between refreshes."
  • Technical implementation was left to subsequent discussion. See Wikipedia:Village pump (technical)/Archive 184#Technical volunteer needed for Arbitration Committee Elections.

From memory voting systems have been discussed at several recent ACERFCs with suggestions that it should be looked at a different time of year so that all technical implementation questions about alternatives are sorted before the main RfC. I have no recollection that these discussions ever happened. Thryduulf ( talk) 14:40, 1 November 2020 (UTC) reply

As a note re candidate order, the commissioners dropped the change for this year. -- Izno ( talk) 17:32, 16 November 2020 (UTC) reply

2021 follow up, as far as I know - noone has stepped up to invent the magic sorting hat for this year either. — xaosflux ^Talk 01:37, 10 September 2021 (UTC) reply

I didn't have the mental bandwidth to take care following up this year. It looks like the two guides questions were asked again. :thumbsup: I'm not personally interested in chasing candidate order.

Increasing the suffrage requirement might still be worth asking (now probably will have to wait to next year since it's been two weeks of ACERFC being open). Izno ( talk) 05:04, 14 September 2021 (UTC) reply

Candidate question period

Currently, candidates may receive questions as soon as they nominate. This disincentivizes early nominations as early nominees face more questions and scrutiny than others. Late nominations make it hard for the community to judge whether we will have enough nominees and leads to needless stress. Should the nomination period be separated from the question period? Should the timing of nominations and election be modified to accommodate this new question period? — Wug· a·po·des​ 19:33, 17 November 2020 (UTC) reply

Alt Accounts

Do we really need to require a list of "alt accounts" - problem : "I have some sekret alt's arbcom knows about" -- but then to ensure the candidate is valid someone has to go ask arbcom if they are telling the truth - and if they aren't : problem, if they are not barring something that arbcom is going to step in and enforce a secret topic ban from running for arbcom - then what? — xaosflux ^Talk 16:53, 16 November 2020 (UTC) reply

Perhaps from a workflow perspective - we wait until the nomination period is over and just ask arbcom 1 question. — xaosflux ^Talk 01:39, 10 September 2021 (UTC) reply

Reverse the question limit

This year a limit was imposed for number of questions. This was a solution looking for a problem, imo, and has caused messy limits on question asking. Some candidates have more to be asked of than others. The rationale in statement 1c is totally correct imo: "This is the status-quo, candidates are not obligated to answer editor questions". The rationale of people pushing vendettas wasn't fixed by this, yet it limited legitimate question-asking. Besides, if someone is asking an unreasonable amount of optional questions I'm sure others editors understand that time isn't infinite and they won't be answered. I think this should be reversed for 2021. ProcrastinatingReader ( talk) 20:20, 20 November 2020 (UTC) reply

Voting start date

In 2018 there was an issue with secure poll that could not be resolved without action from WMF staff in San Francisco. UTC midnight on Monday is 4pm Sunday in San Francisco so staff were not available and the election was postponed by 1 day. In 2019 and 2020 the Tuesday start date was carried over without formal discussion. We should rectify this and formalise the start date as 00:00 UTC on a Tuesday (i.e. 16:00 Monday PST) so that in the event of securepoll or other similar issues WMF staff will be able to fix it without significant delay to the election. Thryduulf ( talk) 14:12, 21 November 2020 (UTC) reply

blocked / pblocked users

• How to deal with p-blocked users for eligibility? — xaosflux ^Talk 02:34, 26 November 2020 (UTC) reply
• See also Wikipedia talk:Arbitration Committee Elections December 2020‎ and phab:T268800. The options are:
  1. Allow all partially blocked users to vote
  2. Disallow all partially blocked users.
  3. Allow some partially blocked users. (e.g. fawiki apparently disallows editors blocked from editing in the project namespace, but allows other partially blocked users to vote)

  There is no current community consensus either way, but option 1 is the option chosen by the commissioners for 2020 so is sort of the status quo.

  Option 2 is the simplest in terms of the voting software (securepoll does not currently distinguish between block types), with partially blocked users being added to the manual override list. It is hoped that Options 1 and 2 will be equally easy by the time of the 2021 election (but see phab:T268800 nearer the time). Option 3 seems unlikely to be supported by securepoll any time soon (but again, check Phabricator when this RFC starts) and so will require the most work. Thryduulf ( talk) 02:28, 27 November 2020 (UTC) reply

Commission selection

• Currently uses "collect approvals" method and the "winners" are generally the top 3 with the most approvals. Opposes are not collected, and implied opposes are not really assumed. The ambiguous area is what is the cut-off for "reserve" members when using this process. — xaosflux ^Talk 12:01, 1 December 2020 (UTC) reply

Candidates withdrawing in the voting period

Codify how these will be or not be "counted"

How to deal with candidates who withdraw in the voting period with respect to the final tally. Options are:

1. Withdrawn candidates are excluded in the tally of the votes
2. Withdrawn candidates are included in the tally of the votes but cannot be elected. Withdrawn candidates who would otherwise be elected if they were not withdrawn, leave an empty seat on the committee.

Previous times his has happened, the candidate has been excluded. However, if a number of stronger candidates withdraw it could lead to no seats being filled if they are included or candidates with less support elected if they are excluded. Having this explicitly defined seems reasonable. Dreamy Jazz ^{talk to me | my contributions} 23:54, 29 November 2020 (UTC) reply

This has come up due to the withdrawal by TonyBallioni from this years elections. My understanding is that they had a good chance of being elected if they hadn't withdrawn, so their position in the final tally of the votes may be in the top 7. The election commissioners all have a preference for number 1 (removing them from the final tally) and also the status quo has been to do this, so I expect that number 1 will be the one which is followed this year. Having this posed to the community seems a good idea, so future situations like this have established rules to follow (especially as its directly about who would be elected from the final tally). Dreamy Jazz ^{talk to me | my contributions} 00:03, 30 November 2020 (UTC) reply

Should voters be notified if candidates w/d ?

Came up at Wikipedia_talk:Arbitration_Committee_Elections_December_2020/Coordination#Withdrawal. Possible impact: strategic voters that oppose candidates they actually approve of. — xaosflux ^Talk 15:28, 30 November 2020 (UTC) reply

The topic here is a little misleading (I don't think intentionally - maybe just a tad oversimplified?).

The concern is: "Should voters be notified if a candidate withdraws days after voting has started, and a significant amount of votes have been cast?" SQL ^{Query me!} 05:04, 1 December 2020 (UTC) reply

Actually I think it would be clearest to ask a series of questions -

1. Should voters be notified if a candidate withdraws before voting? (yes/no)
2. Should voters be notified if a candidate withdraws after voting has opened? (yes, at any time/yes, but only after the half way point/yes, but only after a significant* number of votes have been cast/yes, but only after some other point/no)

*I'd suggest that if this option gets consensus but there is no consensus about what (approximate) number "Significant" means that it be explicitly left to the discretion of the commissioners. Thryduulf ( talk) 15:17, 2 December 2020 (UTC) reply

CentralNotice banner

Accepted in 2015 & reaffirmed in 2016. But it seems like we have no CentralNotice this year, nor a MediaWiki:Sitenotice. I gather the impression (from IRC talk) that it phased out into a watchlist notice and talk page banner. Roughly 2000 votes per year, it seems, with 40,000 eligible voters this year. I wonder if a CentralNotice banner will increase # of voters? Figured worth dropping here so I don't forget next year. ProcrastinatingReader ( talk) 17:40, 30 November 2020 (UTC) reply

@ ProcrastinatingReader: certainly can re-visit; this mostly evolved to the current practice of using a WLNotice and also sending out the 50-60 thousand individual talk page notifications that was used this year. — xaosflux ^Talk 17:49, 30 November 2020 (UTC) reply

@ ProcrastinatingReader: FYI, I've posted this for discussion. — xaosflux ^Talk 13:53, 3 September 2021 (UTC) reply

making the template more clear

This is a really minor suggestion, but on future versions of the {{ ACE2020}} template, I suggest that instead of the link to vote being labeled as "Vote", let's change it to "Cast your vote here." That would be in line with what the {{ Arbitration Committee candidate}} says, and I think it's much more clear. It is the most important link in the template, after all. Best, KevinL (aka L235 · t · c) 23:13, 6 December 2020 (UTC) reply

I don't think that needs an RFC... -- Izno ( talk) 23:16, 6 December 2020 (UTC) reply

@ Izno: I'd change it myself but I'm currently in a tricky position vis-à-vis directly editing official ACE templates KevinL (aka L235 · t · c) 23:19, 6 December 2020 (UTC) reply

@ L235: Just suggest it to the coordinators at Wikipedia talk:Arbitration Committee Elections December 2020/Coordination for this year. For next year I agree with Izno that it doesn't require an RfC, just a normal discussion if anyone objects (which for the record I don't). Thryduulf ( talk) 23:32, 6 December 2020 (UTC) reply

@ 2020 ACE Commissioners: Any thoughts on this? KevinL (aka L235 · t · c) 01:36, 7 December 2020 (UTC) reply

L235, speaking for myself only, I agree this seems uncontroversial enough that any editor can feel free to make the change WP:BOLDly before the start of next year's election. Seeing as we have just over two hours remaining, not sure we need to make the change for the current election. Mz7 ( talk) 21:40, 7 December 2020 (UTC) reply

 Done @ L235: I think this may be done now via Module:Arbcom election banner. Agree, this doesn't need an RfC; BRD is fine! — xaosflux ^Talk 13:59, 3 September 2021 (UTC) reply

bot accounts

• bookeeping: rfc to codify that "bot" flagged accounts are ineligible to vote. — xaosflux ^Talk 16:54, 16 November 2020 (UTC) reply
• update: should "all known bots" be prevented from voting as well? — xaosflux ^Talk 16:54, 16 November 2020 (UTC) reply
  • Is there a definition of "bot" other than "has the bot flag"? If not one will be needed. Thryduulf ( talk) 19:02, 16 November 2020 (UTC) reply

    • @ Thryduulf: for this case, it would be an account that has passed a BRFA (even if the BRFA concludes that it should operate without a bot flag), however I'd more generalize it to accounts contained within Category:All Wikipedia bots. — xaosflux ^Talk 20:26, 16 November 2020 (UTC) reply

      • That would also include now-retired/deauthorized bots (neither of which should really be used for voting IMHO). — xaosflux ^Talk 20:27, 16 November 2020 (UTC) reply

@ Wugapodes, ProcrastinatingReader, Swarm, Xaosflux, Izno, KevinL, and Dreamy Jazz: you made proposals or suggestions above regarding topics to review for the next election. The RfC for that election is now live, so you may wish to review your comments and/or make proposals. Thryduulf ( talk) 22:28, 1 September 2021 (UTC) reply

Thank you for the reminder. Dreamy Jazz ^{talk to me | my contributions} 07:41, 2 September 2021 (UTC) reply

Given the inordinate number of questions raised this year, I think it would beneficial to have a checkpoint in the first half of 2021 where the pending questions can be sorted and we can figure out what timeline would be most suitable. Perhaps some issues that are completely independent from others can be dealt with earlier, while others can be grouped and dealt with in phases. Also, if some questions will potentially affect the election schedule (such as extending the period between nominations and the election to allow for a full examination of last-minute nominations), we should ensure they are resolved sufficiently ahead of time. isaacl ( talk) 02:45, 23 December 2020 (UTC) reply

I think this is reasonable (especially the second facet), but we could probably move the deadline a bit later - a week's discussion should suffice if all we're doing is evaluating the timeline of the pre-election RfC and leaving enough space in case it mandates a timing change. [I know this isn't a discussion page, but since this would necessitate an action change, rather than a question, it seemed reasonable to comment] Nosebagbear ( talk) 11:04, 23 December 2020 (UTC) reply

The timeframe I suggested is kind of arbitrary; I was originally thinking of August, but then thought why wait if there are a lot of questions already to sort through. I agree just changing the schedule of the overall process shouldn't take too long, but if there is a desire to group questions into multiple phases in order to make the RfC process more manageable, more time may be required to reach an agreement. isaacl ( talk) 20:23, 24 December 2020 (UTC) reply

I started the RfC off using the same format as previous years' pre-election RfCs, but right now, in the opening hours of the RfC, I don't think it's too late to switch over to an alternative format if desired. I was thinking we could alternatively do a series of proposals with support/oppose sections for each, not unlike Wikipedia:Requests for adminship/2021 review/Issues. In other words, we could use the following format:

=== Proposal name ===
Neutral description of proposal. ~~~~

==== Support (proposal name) ====
# Additional comments here ~~~~

==== Oppose (proposal name) ====
# 

==== Comments (proposal name) ====
*

This could make the discussion format more readable and less archaic. Last year's RfC was a bit unwieldy because of its format: see WP:ACERFC2020. Thoughts? Mz7 ( talk) 01:15, 1 September 2021 (UTC) reply

• I decided to be bold and switch to this format. As I said, I think the previous format is a little archaic—a remnant from the earlier days when we weren't as fluent with what works and what doesn't. I hope no one minds. Mz7 ( talk) 02:13, 1 September 2021 (UTC) reply

  @ Mz7: I am glad you were bold enough to make a change! So far, I do like how it looks simpler. It made it easier for me to participate. Somerandomuser ( talk) 03:10, 11 September 2021 (UTC) reply

• This seems simpler, more aligned with other RfC's. — xaosflux ^Talk 02:23, 1 September 2021 (UTC) reply

  @ Mz7: I already broke it a little bit with the prop I added - but it is really seeking a 1-of-3 choice so I think I melded it well with this style without resorting to the messier old style. — xaosflux ^Talk 02:39, 1 September 2021 (UTC) reply

• Can we make the proposals lvl2 headers instead of lvl3 (same as Wikipedia:Requests for adminship/2021 review/Issues's format) to make the page easier to use on mobile? Thanks, Levivich 03:16, 1 September 2021 (UTC) reply
• I prefer the old format. Personally, I liked that the format made it clear that this is not a vote. On a more practical level, formatting proposals as statements makes it far more clear what editors are (or are not) agreeing to. Consider the partially blocked voter proposal. It has three support sections all relating to different proposals that are essentially statements already, but obscured by the multi-part proposal and parenthetical disambiguation of the generic "support" sections. The last of the three also make a developing consensus harder to observe. In the old format, someone could just make a new statement on how to handle a middle-path option and it could be endorsed and show consensus when compared to all the other options. In this format, each editor is essentially required to make their own statement or endorse one already presented in the numbered comments. This duplicates the previous structure but with the added issue that alternatives are obscured and given lower billing when compared to the first two. I'm fine trying something new, but we should consider whether a straw poll is the best way to draft election procedures. If we do proceed with this format, there is additional overhead that needs to be considered: the instructions still refer to the old format and {{ subst:ACERFC statement}} needs updated to use the new one. — Wug· a·po·des​ 04:22, 1 September 2021 (UTC) reply

  @ Wugapodes: I refactored those headings a bit, they are really all mutually exclusive options for that item though - but would like to encourage more discussing and less "voting"! — xaosflux ^Talk 09:59, 1 September 2021 (UTC) reply

  I think this is a workable compromise, and new proposals seem to be picking the format that makes most sense given the context. That seems like a positive change. I'm willing to see how this goes and reflect afterwards. — Wug· a·po·des​ 20:22, 1 September 2021 (UTC) reply

Sections such as Wikipedia_talk:Requests_for_comment/Arbitration_Committee_Elections_December_2020#ACERFC_decisions_to_date are generally very helpful, perhaps that should be maintained at Wikipedia:Requests_for_comment/Arbitration_Committee_Elections/ACERFC_decisions_to_date or another central page that can be just transcluded? — xaosflux ^Talk 02:27, 1 September 2021 (UTC) reply

I think this is an excellent idea. Worm^TT( talk) 08:09, 2 September 2021 (UTC) reply

I've copied the list to that link, and changed it as well as I could to match the results of the 2020 RFC. However, I haven't yet implemented points 9, 10, and 11 from there, as I wasn't sure how to merge Cyberpower678's RFC close with the current wording. Maybe one of you could take a look at that? -- rchard2scout ( talk) 09:59, 2 September 2021 (UTC) reply

@ Cyberpower678: would you please check on this if you have the time? — xaosflux ^Talk 14:12, 3 September 2021 (UTC) reply

Added a linked summary. — xaosflux ^Talk 02:42, 6 September 2021 (UTC) reply

As had been discussed last year, can we set a deadline for proposals to be added to the RfC? (An "ignore all rules" exception can be invoked if something urgent comes up after the deadline.) The number of proposals last year was somewhat unwieldy. isaacl ( talk) 05:59, 1 September 2021 (UTC) reply

• This runs for about a month, perhaps "no new proposals during the last week"? — xaosflux ^Talk 00:29, 2 September 2021 (UTC) reply

  One week seems like a reasonable minimum time to allot for discussion for a proposal, in order to accommodate editors who edit at different times in the week. I'd even support an earlier limit, such as the last two weeks. isaacl ( talk) 00:43, 2 September 2021 (UTC) reply

  With the latest proposal having a couple of responses remarking on the timing of the proposal, although there is over a week left, perhaps for next year a deadline can be set of at least two weeks before the end of the discussion period. isaacl ( talk) 14:39, 22 September 2021 (UTC) reply

  Certainly major changes should be given at least two weeks, smaller changes would be fine with a week imo. Thryduulf ( talk) 15:05, 22 September 2021 (UTC) reply

  @ Thryduulf: as far as the timing, another factor is participation - some editors may think they are done, have dismissed the WLN, or the WLN may already expire. While not a show-stopper itself - it may lead to a situation where the closer will find there is insufficient participation to actually have a consensus and we're not going to hold open the RfC due to scheduling issues. — xaosflux ^Talk 15:13, 22 September 2021 (UTC) reply

  I think it will be easier to have a single deadline, rather than two. isaacl ( talk) 15:20, 22 September 2021 (UTC) reply

We need an RFC about how this RFC is handled every year. For one thing, there's the timing of proposals issue raised here. Personally, I don't want to have to follow this page for a month to keep tabs on developments. I'd rather there was one set of proposals that I could read once and !vote on once (and then I have the option of engaging in discussion if I want to before or after !voting). So I'd prefer a system where all the proposals for the year were fixed ahead of time, and no new proposals were added once the !voting was open. Additionally, I don't like that just anyone can add a new proposal. Not every proposal is worth my time to read and think about and discuss, IMO. I think there should be some kind of filter system for deciding that we only have proposals if those proposals have some level of initial support. Finally, that leads us to the question of quorum, which was one of the proposals this year (and next?). Overall, I'm concerned about a situation where a late proposal (after most editors have !voted and moved on to other things) with only a few supports might end up making a major change that doesn't actually have global consensus. I'd suggest a sort of open-ended RFC about this annual ACERFC process to address these meta-issues. I know, NOTBURO, and this is already pretty procedurally heavy, but... ¯\_(ツ)_/¯ Levivich 15:18, 22 September 2021 (UTC) reply

If all proposals can be put forth at once, with none added later (with the usual ignore-all-rules exception for urgent issues), then I think that can help consolidate proposals. I had suggested last year that there be a checkpoint to determine the best schedule for soliciting feedback on the various proposal. Perhaps more simply we could call for proposals for a week, with no support or oppose viewpoints, and then have a consensus discussion, for three weeks. Because the schedule can be laid out way in advance, everyone has ample time to prepare proposals whenever they want ahead of time. There could be a working page for proposals to facilitate collaboration. isaacl ( talk) 15:31, 22 September 2021 (UTC) reply

Perhaps, throughout the year, we should be encouraging people to leave ideas/suggestions/proposals at the talk page of the 2022 RFC. Then sometime about say the third week of August we go through and consolidate the ideas, ping everyone who made a proposal, clean out any that have clearly been resolved during the year and/or which nobody wants to go through, workshop some others, so we're starting with something other than a blank slate on 1 September?

Another idea that may or may not be combinable with the above is to have a sort of two round system. Proposals that have fewer than 5 support votes and/or more than say 3 times as many oppose votes as support votes after a week get closed as unsuccessful at that point. Thryduulf ( talk) 18:23, 22 September 2021 (UTC) reply

Personally I don't feel an early-closure trigger is necessary. Interested parties can determine which proposals would benefit the most from their time and comments. I do think it is a good idea for proposers to work on their ideas ahead of time (I had proposed this for voting systems a few years ago), thus my suggestion for a working page. As always, the challenge is getting interested people to engage for a sustained period. isaacl ( talk) 20:20, 22 September 2021 (UTC) reply

While I know this new style is adopted to try and stress the "discussion not vote" setup, I assume that hasn't just deprecated the formally agreed rule from last year that necessitates at least 15 participants for a change to ACE rules? Nosebagbear ( talk) 12:55, 1 September 2021 (UTC) reply

@ Nosebagbear: Wikipedia:Requests_for_comment/Arbitration_Committee_Elections_December_2020#Meta1a closed as There will be no set minimum number of people who must support a proposal for there to be consensus.. — xaosflux ^Talk 13:13, 1 September 2021 (UTC) reply

@ Xaosflux: Ah, I was not aware the close had been reassessed, well that's one gordian knot cut. Nosebagbear ( talk) 13:32, 1 September 2021 (UTC) reply

I don't think the format change (which given the work I did at WP:RFA2021 is a format I'm comfortable with) makes it more a discussion and less a vote. I think structures it in a way that makes it easier to close. That is a big difference, and my concerns, expressed below remain. Best, Barkeep49 ( talk) 22:38, 1 September 2021 (UTC) reply

I remain convinced that our lack of safeguards on participation at ACERFC is a major issue. ACE itself is the single most participated process enwiki has every year and yet the process could be subjected to major changes through a late run (per the proposal above this about a lack of proposal deadline) of a very small number of people in a process that has historically had a single closer. I was glad to see roughly 65% of people agree on this last year and wonder if there is a way that safeguards imposed that could assuage people with concerns about this last year. Courtesy ping Vanamonde93 as the person who caused the close to be overturned. Best, Barkeep49 ( talk) 22:36, 1 September 2021 (UTC) reply

@ Barkeep49: I think the "deadline for proposals" section is better than a arbitrary participant count for that concern. — xaosflux ^Talk 23:01, 1 September 2021 (UTC) reply

I agree with xaosflux that a proposal deadline is better than a quorum. For my opinions on why a quorum is not a good idea, see my comment last year in opposition to the idea. If anything should asuage those with concerns last year, it ought to be the results of last year. Many said that having so many proposals risked low turn out and a finding of consensus for statements which only a few people supported, but that didn't happen. The only example brought up last year was from nearly a decade ago, and the rationale outright said the number was chosen based on the previous 3 years so the proposed rule wouldn't have had any meaningful effect in the recent past. If the concern now is late proposals being gamed, a deadline for proposals would be better than a quorum, but I'm not particularly convinced we should guard against a sequence of events (late proposal, lots of support, bad closer) that we've never had before and have no reason to believe will occur now. — Wug· a·po·des​ 23:40, 1 September 2021 (UTC) reply

I think there are relatively simple ways to guard against the low probability high impact event we've talked about and that's precisely why we should; I'm on board with isaac's idea above for that reason. But also the idea that it's ok for a small number of self-selected people to be able to control all sorts of material things - including the number of ArbCom seats up for election and the qualifications it takes to be a voter - is itself something that should be thought through carefully. To that end I'd be fine making it so the minimum number would be 1% of the previous year's electorate (we can even round it down) so this year that would be 18 people. And I know I'm not crazy because 28/43 people (again enough to pass the 1% threshold I'm talking about) agreed with the concept last year. I get you, xaos, and Thryduulf (it was he not Vanamonde who'd challenged it) have concerns. Trying to find a way to address those concerns are why I've not already re-proposed it but conceptually I continue to think this is important. Best, Barkeep49 ( talk) 00:18, 2 September 2021 (UTC) reply

As I and others argued last year, this isn't a problem that needs solving because it is already solved: RFC closers can, should and (in my experience) do consider the significance of the change and the amount of participation both absolute and relative to the time available when determining whether there is consensus. For the same reason I'm wary of a hard deadline - the possibility of controversial major changes getting limited consideration should not hamstring late proposals for clearly supported uncontroversial minor changes. Thryduulf ( talk) 00:57, 2 September 2021 (UTC) reply

• This has been added to the RFC, please reply there. — xaosflux ^Talk 18:29, 2 September 2021 (UTC) reply

Why do all the proposals have to be under a level 2 section heading called "Proposals" anyways? It makes the whole page harder to read (on mobile especially). – MJL  ‐Talk‐ ^☖ 00:10, 4 September 2021 (UTC) reply

The decisions to date relating to mass messaging state "Mass Message - eligible voters, have edited last 12 months before nominations, but excluding blocked users where the block duration extends past the the elections, globally b/locked accounts, bots, and accounts in Category:All Wikipedia bots, Category:Wikipedia alternative accounts, Category:Wikipedia doppelganger accounts, and Category:Deceased Wikipedians." however, the message will also not be delivered to accounts in Category:Users who do not wish to receive ACE messages and (I believe) Category:Wikipedians who opt out of message delivery. Do we need to state this, and if so does it need an RFC decision? Thryduulf ( talk) 22:29, 5 September 2021 (UTC) reply

Personally, I don't think an RfC question is needed. Users in these categories remain eligible to receive mass message notifications, but have opted out. isaacl ( talk) 23:37, 5 September 2021 (UTC) reply

And for the later, while we could attempt to send them - the system won't deliver them (and would flood the log with non-delivery attempts). — xaosflux ^Talk 02:14, 6 September 2021 (UTC) reply

Who’s closing this monstrosity this year. It should be done by multiple uninvolved admins, not just one like last year. Any volunteers?— CYBERPOWER ( Message) 04:19, 11 September 2021 (UTC) reply

• Dropped an ask at Wikipedia:Administrators'_noticeboard#WP:ACERFC_closers. — xaosflux ^Talk 14:10, 21 September 2021 (UTC) reply

Noting that there are still a few proposals that have not been closed yet. – FlyingAce ^✈hello 19:15, 9 October 2021 (UTC) reply

@ FlyingAce: maybe list at ANRFC, one challenge is that a lot of people that close things participated. It doesn't have to be an admin. — xaosflux ^Talk 21:06, 9 October 2021 (UTC) reply

• Listed at Wikipedia:Closure_requests#Requests_for_comment - currently there are 6 sections pending closure. — xaosflux ^Talk 11:04, 11 October 2021 (UTC) reply
• I've closed the last 2 remaining sections. I'm not familiar with Wikipedia:Closure_requests#Requests_for_comment, I don't know if something needs to be done there to take this off the list. Nor do I know if the fact that it's all closed needs to be "announced" somewhere, or pointed out to the EC, or... something. -- Floquenbeam ( talk) 16:59, 12 October 2021 (UTC) reply
  • Thank you! There are a small group of us working to coordinate the activities prior to eleccom being empaneled, Wikipedia:Arbitration Committee Elections December 2021/Coordination the TODO list has been updated and it looks like we are right on plan again. Best regards, — xaosflux ^Talk 17:19, 12 October 2021 (UTC) reply

Given that there is a predetermined fixed period for discussion, can I suggest that editors allow for the discussion period to end before evaluating consensus on any proposals? Unless there is some particular pitfall that is urgent to avoid, I don't personally see a need to close discussion on any proposals early. isaacl ( talk) 04:35, 11 September 2021 (UTC) reply

Agreed. Unless there is some specific problem being caused by edits to a particular proposal I don't think there is any need or benefit to SNOW closing proposals here - especially not NACs, especially when the "snow" is only teens to one and especially when we're less than halfway through the advertised period. I would encourage Tol and Sdkb to revert their closures and let the discussions run their course. Thryduulf ( talk) 16:37, 11 September 2021 (UTC) reply

Thanks for the ping, Thryduulf. I'm aware that my threshold for snow closes is lower than some other editors, and if the community wants to undo it, I won't particularly mind. That said, I think it was a solid close and stand by it.

When considering a snow close, the metric I use is whether or not I could envision any possible way of the discussion turning around and reaching a different result, and in this case, I could not. The three main factors were that this has been watchlist and CENT listed, meaning that there's no concern about local consensus; that the count was a unanimous 19 to 0 (discarding the joke !vote); and that the question of whether bots should be allowed to vote is prima facie obvious. The main serious discussion was a week ago about alternate accounts more generally, and I think closing will help that out by pushing it to a space in which it is the actual focus rather than out of scope. My view is that letting the discussion remain open for a full 30 days would be needless bureaucracy that would waste editors' time piling on and clutter/distract from the actual controversial issues in other sections. Regards, {{u| Sdkb}}  ^talk 17:25, 11 September 2021 (UTC) reply

I feel editors should be able to gauge for themselves that no further comments for a given viewpoint are needed, and so don't personally think a lot of focus will be spent on these proposals, particularly given that there is a known deadline in place so no one has to be concerned about an unexpected turnaround at some uncertain future date. Also, when the closing date is known, editors may deliberately defer commenting on a proposal, and thus feel excluded by an early closure. isaacl ( talk) 20:08, 11 September 2021 (UTC) reply

Thanks for the ping. I'd echo most of what Sdkb said, so I won't repeat it, but I also believe that if anyone disagrees with a snow-close, it shouldn't have been snow-closed. I've reverted my closure. Tol ( talk | contribs) @ 18:42, 11 September 2021 (UTC) reply

Unless there is unanimous opposition to a proposal (e.g. many opposes, no supports, and the nominator wishes to withdraw the proposal) I agree there shouldn't be any SNOW closes. I don't think it matters whether these are NACs or not. User:力 (power~enwiki, π, ν) 17:14, 11 September 2021 (UTC) reply

Please jot down any thing that may need revisiting for 2022's RfC. — xaosflux ^Talk 09:55, 14 September 2021 (UTC) reply

As per earlier suggestion, should a workshop page be started? It could just be the talk page for the 2022 RfC, or it could be a separate page. For instance, perhaps the proposal on how electoral commissioners are selected could have benefited from some discussion to make it more specific. isaacl ( talk) 04:11, 7 October 2021 (UTC) reply

@ Isaacl: well there is certainly plenty of time! Some of these topics probably need extensive workshopping (I'm looking at you change to voting system xxx) while others may just need some more thought. — xaosflux ^Talk 10:30, 7 October 2021 (UTC) reply

Just a reminder: if anyone is interested in working on a proposal that needs preparation, it may be a good time to get started. isaacl ( talk) 04:13, 28 March 2022 (UTC) reply

Shall we start a placeholder page for the 2022 RfC now, in order to allow for discussions to be held on its talk page to refine proposals? isaacl ( talk) 22:47, 13 June 2022 (UTC) reply

@ Isaacl sure go for it. — xaosflux ^Talk 22:58, 13 June 2022 (UTC) reply

OK, I created placeholder pages for the elections and the elections RfC. Should this section be copied to Wikipedia talk:Requests for comment/Arbitration Committee Elections December 2022? isaacl ( talk) 02:06, 14 June 2022 (UTC) reply

Magic candidate order

Was approved in the 2020 RfC, if there is no development - should this be retained? — xaosflux ^Talk 09:57, 14 September 2021 (UTC) reply

Different voting systems

This is sort of perennial, I think one challenge is that this is a hard topic and would need to have a lot of thought and examples ready to go before just says "lets use x system". It seems useful to keep exploring this, but if someone wants to tackle it they should probably start many months early workshopping it. — xaosflux ^Talk 10:00, 14 September 2021 (UTC) reply

As I commented somewhere (last year's RFC?), workshopping details and demonstrating technical feasibility, etc in advance of the RFC has been a perennial suggestion but it hasn't ever happened afaik. I wouldn't object to a prohibition on proposing any voting system in next year's RFC that isn't already technically supported. Do note though that I'm one of those people who has never been convinced that the current system needs changing. Thryduulf ( talk) 10:52, 14 September 2021 (UTC) reply

Terms and %

This section doesn't seem to be heading towards any consensus this year, but some ideas were floated that could bear revisting:

• Should 1-year terms be abolished? *Should the minimum % to be seated be adjusted? — xaosflux ^Talk 11:37, 19 September 2021 (UTC) reply

  @ Jc37: thank you for opening this, in the event it is a no-consensus I think it may be worth revisiting next year and could be work shopped in advance. — xaosflux ^Talk 10:27, 22 September 2021 (UTC) reply

ELECCOM format

Is it worth it to specifically ask for non-endorsements as well? This was somewhat muddled in with 1.9 this year that no-consensus'd. — xaosflux ^Talk 01:02, 7 October 2021 (UTC) reply

Nonpublic access agreement

Ideally candidates would sign it before voting and be disqualified if they haven't done it by then. Especially important due to the recent rule changes where individuals from certain countries are being denied access. -- Rs chen 7754 01:29, 7 October 2021 (UTC) reply

Sitting Arb eligibility for ELECTCOM

Should sitting arbitrators be allowed to serve on Electcom? This could take one of several outcomes including yes, only arbs whose terms are not up, only arbs whose terms are up (meaning they would not be eligible to run for re-election), or not at all. Best, Barkeep49 ( talk) 01:46, 7 October 2021 (UTC) reply

Traditionally arbitrators have declined to be involved with the organization of the arbitration election committee process. And while personally I think this is a good idea, I'm not convinced it needs to be raised in an RfC to be codified, since the community can have their say during the electoral commission selection process. The RfC is sufficiently long that I think we should try to avoid adding questions when possible. <cranky rant>And what's up with the Soviet-style (or military style, for the various "commands" out there) abbreviations people seem drawn to using? Pixels are free ;-)</cranky rant> isaacl ( talk) 04:02, 7 October 2021 (UTC) reply

Criteria for electoral commissioners

Consider setting aside one spot for first-time commissioners, if there are any suitable candidates who receive sufficient consensus support. (If not, fill the spot from the other candidates who receive sufficient support.) isaacl ( talk) 21:51, 13 October 2021 (UTC) reply

Nomination period and questions

Heard a couple folks mention this: should questions be permitted during the nomination period? There have been concerns about whether allowing questions disincentivizes early self-nomination (in order to avoid spending an extra few days getting asked questions). GeneralNotability ( talk) 22:35, 15 November 2021 (UTC) reply

Candidate order on all pages and on ballot is the order they self-nominate

If we want to discourage last-minute candidacies - which I think we should - I believe this would help. Also, no more complicated randomizing templates, no more bots purging anything, no more old people (like me) losing track of who's pages they've already read and who's they haven't. Just simplicity. -- Floquenbeam ( talk) 02:00, 16 November 2021 (UTC) reply

@ Floquenbeam: probably should merge along with "Magic candidate order" above. That was supposed to solve the later half of your problem, but not the former. I'm good to drop all of this on-wiki and just keep the securepoll randomizer (on the argument that voters may change their votes based on candidate order) - but I'm not married to that either - perhaps we keep all those points for disucssion bundled up. — xaosflux ^Talk 16:07, 16 November 2021 (UTC) reply

If there is a consensus about a problem with late nominations, then I think it is better to address more directly: reduce the length of the nomination period. Everyone knows when it's coming, so it doesn't have to be very long. If someone is going to be away during that time, they can ask an electoral commissioner to add their statement on their behalf. isaacl ( talk) 16:37, 16 November 2021 (UTC) reply

I would support making the nominations period shorter - my preference would be 7 days - and to perhaps not start the question period until the nominations period ends. I have floated the idea of providing an incentive to run early myself - in fact this very one that Floq suggests - but actually don't think this is a good idea. However if there were some other nudge towards running early that I'm not thinking of I would want to at least consider it. Best, Barkeep49 ( talk) 16:49, 16 November 2021 (UTC) reply

The key question is why do we want candidates to announce early? If it's to ensure equal amounts of time to consider and discuss the candidates, we could have candidates prepare their nominations out of view (perhaps on a subpage in their user space), privately notify the electoral commission, and then have the commissioners release all nominations at the same time. If it's to mitigate the possibility of the community panicking at the low number of candidates, a shorter nomination period may be enough (it could be even shorter than a week, since they nominations can be prepared ahead of time, but a week is probably a reasonable length). If it's to help people decide if they want to run based on the other candidates, encourage them to file a nomination anyway since they can withdraw after the nominations close. (I'm not convinced that late nominations is a significant problem, but some of these objectives might be an improvement anyway.) isaacl ( talk) 01:13, 17 November 2021 (UTC) reply

What actual evidence is there that people are nominating near the end of the period to "avoid scrutiny?" -- Euryalus ( talk) 01:54, 17 November 2021 (UTC) reply

I don't think it's possible to know unless they tell us. But as was mentioned at Wikipedia:Administrators' noticeboard § ACE2021 election spam, editors trying to avoid scrutiny are unlikely to run, as candidates are inevitably going to be scrutinized, no matter when they submit their nomination. (Note I didn't mention avoiding scrutiny.) isaacl ( talk) 02:40, 17 November 2021 (UTC) reply

Thanks for the reply, and yes agree with that. Absent any actual evidence we can probably dispense with the random conspiracy theories. Do agree with the idea of a shorter nominating period: may as well streamline what is already a very long process. -- Euryalus ( talk) 02:55, 17 November 2021 (UTC) reply

No more randomising: Good idea
Shorter nomination period e.g. 7 days: Good idea
Allowing questions only after the nomination period has closed: Good idea
Have candidates prepare their nominations out of view (perhaps on a subpage in their user space), privately notify the electoral commission, and then have the commissioners release all nominations at the same time: Good idea.
Kudpung กุดผึ้ง ( talk) 15:26, 18 November 2021 (UTC) reply

Striking of votes

The scrutineer team has two concerns that should probably be resolved for next year:

• Votes by socks: Should both sock and master be stricken, or only the sock?
• Votes on proxies: Should they be stricken or not?

— Thanks for the fish! ^{talk• contribs} 19:52, 2 December 2021 (UTC) reply

To clarify, by "votes on proxies", do you mean a vote coming from a proxy server, or something else? isaacl ( talk) 21:18, 2 December 2021 (UTC) reply

Yes, that's precisely it. Thanks for clarifying it for me :P Best, — Thanks for the fish! ^{talk• contribs} 23:44, 2 December 2021 (UTC) reply

My personal opinion is that votes on proxies shouldn't be stricken - a) we don't have any rules specifically disallowing editors from using proxies (we will block proxies on sight due to abuse, of course, but that doesn't mean that everyone on a proxy is an abuser), b) IPBE exists for a reason, some people can only edit via proxy, c) depending on the type of proxy we're dealing with (hello residential proxies) an IP may flag as hosting a proxy or proxies because multiple people are behind the same IP, and determining whether someone is actually using the proxy is a time-consuming process for our already overworked scrutineers. GeneralNotability ( talk) 00:00, 3 December 2021 (UTC) reply

I should have said open proxy servers, which I presume is your concern. I don't see why this makes a difference for the voters who are all logged in, though. isaacl ( talk) 00:26, 3 December 2021 (UTC) reply

Regarding sock accounts for this year: if the master account remains unblocked, then I do not believe there is a policy-based reason or an established consensus to remove them the master account from the electoral roll. isaacl ( talk) 00:32, 3 December 2021 (UTC) reply

From memory of previous years, I think if the scruitineers observed something they believe might be socking they passed the details to the local CU team for investigation. I don't recall what was done about votes made by newly-discovered masters, but those cast in violation of a previously existing ban were struck I believe. Thryduulf ( talk) 02:33, 3 December 2021 (UTC) reply

@ Isaacl: my clarification was in case both are blocked. We had that happen this year, but we're not sure if the master should be struck too as they were not blocked at the time they cast their vote.
@ Thryduulf: we do exactly that when we find a suspicious user, and that happened this year with a new master, so no previous blocks to say "hey, this should be struck too". Best, — Thanks for the fish! ^{talk• contribs} 17:43, 7 December 2021 (UTC) reply

My understanding from Wikipedia:Arbitration Committee Elections December 2021/Coordination/Instructions for scrutineers is that the user must not be blocked at the time of voting. Perhaps scrutineers from previous years can weigh in? isaacl ( talk) 19:05, 7 December 2021 (UTC) reply

My first read is that a truly newly discovered sockmaster that is otherwise eligible to vote would not be stricken, though their socks would be. This would be similar to another editor that voted, and then is subsequently banned or blocked for non-socking reasons. How to deal with new sockmasters can be added for the RfC to revisit for the next year. — xaosflux ^Talk 19:35, 7 December 2021 (UTC) reply

If the consensus is to strike all but one vote, it should probably be decided whether the unstricken one should be the first, most recent or the one cast by the master account wherever in the sequence that comes. Thryduulf ( talk) 00:01, 8 December 2021 (UTC) reply

I have started a discussion at Wikipedia talk:Requests for comment/Arbitration Committee Elections December 2022#Election timeline on the tentative start of the 2022 arbitration committee nomination period. Feedback is appreciated! isaacl ( talk) 05:23, 14 June 2022 (UTC) reply

Just a reminder: Wikipedia:Requests for comment/Arbitration Committee Elections December 2022 and its talk page are ready for proposals and discussion. With the RfC scheduled to start on September 1, it's a good time to start thinking about what proposals you may want to make. Happy editing! isaacl ( talk) 01:24, 3 August 2022 (UTC) reply

@ Xaosflux, Isaacl, Rschen7754, Barkeep49, GeneralNotability, Floquenbeam, Euryalus, Kudpung, and Tks4Fish: you made or commented on one of the suggestions for topics to review in 2022. Per the above, now is a good time to think about whether you want to make proposals for 2022. You can add them to Wikipedia:Requests for comment/Arbitration Committee Elections December 2022 whenever you wish (between now and the end of the RfC) but cannot vote on proposals until the RfC opens in September. Thryduulf ( talk) 10:23, 3 August 2022 (UTC) reply