Wikipedia:Requests for comment/Arbitration Committee Elections December 2021

2021 Arbitration Committee Elections

Status as of 14:43 (UTC), Monday, 18 November 2024 ()

• Thank you for participating in the 2021 Arbitration Committee Elections. The certified results have been posted.
• You are invited to leave feedback on the election process.

---

The purpose of this request for comment is to provide an opportunity to amend the structure, rules, and procedures of the December 2021 English Wikipedia Arbitration Committee election and resolve any issues not covered by existing rules. 00:36, 1 September 2021 (UTC)

Background: In the case of proposals that change existing rules, or that seek to establish new ones, lack of consensus for a change will result in the rules from the prior elections remaining in force. Some issues are not covered by the existing rules but will need to be decided one way or another for the operation of the election, in those cases it will be up to the closer to figure out a result, even if there is no clear consensus, as they have had to in the past.

Structure: This RfC is divided into portions, each of which contains a discussion point for the community. The points will be listed in the table of contents below. Anyone is free to raise any new topics that they feel need to be addressed by filling out the format template below.

Duration: In order to preserve the timeline of the election (see above), we should aim to close this RfC as soon as 30 days have passed, i.e. on or after September 30, 2021. The results will determine the structure, rules, and procedures for the election.

Timeline: Per the consensus developed in previous requests for comment, the electoral commission timetable is as follows:

• Nominations: Saturday 00:00, 2 October – Friday 23:59, 8 October (7 days)
• Evaluation period: Saturday 00:00, 9 October – Friday 23:59, 15 October (7 days)
• Commission selection: completed by Friday 00:00, 22 October

Per the consensus developed in previous request for comments, the arbitration committee election timetable is as follows:

• Nominations: Sunday 00:00, 7 November – Tuesday 23:59, 16 November (10 days)
• Setup period: Wednesday 00:00, 17 November to Sunday 23:59, 22 November (5 days)
• Voting period: Tuesday 00:00, 23 November to Monday 23:59, 6 December (14 days)
• Scrutineering: Begins Tuesday 0:00, 3 December

---

Use the following format below; post a new proposal at the BOTTOM of the page.

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

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

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

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

Proposals

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

---

Withdrawn candidates

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

---

If a candidate withdraws from the election between the start of voting and the end of voting, then the final results will be calculated as if the withdrawn candidate never ran. For example, if there are eight vacant seats in the election, and the withdrawn candidate finishes in the top eight, then we would still fill all eight vacant seats, skipping over the withdrawn candidate and awarding their seat to the candidate with the ninth highest support percentage. Mz7 (talk) 00:30, 1 September 2021 (UTC)

Support (withdrawn candidates)

1. This is the way that the Electoral Commission in WP:ACE2020 decided it would be tallied in the event that TonyBallioni, who withdrew midway through the voting period, finished in the top 7 (he did not end up doing so). The alternative would be to treat it as if the withdrawn candidate had won a seat and promptly resigned, leaving one empty seat on the Committee to start the next year. Mz7 (talk) 00:30, 1 September 2021 (UTC)
2. Seems reasonable. {{u|Sdkb}} ^talk 00:53, 1 September 2021 (UTC)
3. * Pppery * _{it has begun...} 03:46, 1 September 2021 (UTC)
4. Why of course. GoodDay (talk) 03:53, 1 September 2021 (UTC)
5. Makes the most sense.  Mysterymanblue  04:37, 1 September 2021 (UTC)
6. No brainer. pandakekok9 (talk) 06:09, 1 September 2021 (UTC)

   Turns out, it is a brainer... See my comment below. pandakekok9 (talk) 10:52, 1 September 2021 (UTC)

7. Callanecc (talk • contribs • logs) 06:42, 1 September 2021 (UTC)
8. This seems sensible. HighInBC ^{Need help? Just ask.} 06:51, 1 September 2021 (UTC)
9. Obvious way to do it. Happy days, Lindsay^Hello 06:52, 1 September 2021 (UTC)
10. —Locke Cole • t • c 06:53, 1 September 2021 (UTC)
11. Bibeyjj (talk) 07:50, 1 September 2021 (UTC)
12. SoWhy 08:33, 1 September 2021 (UTC)
13. NW1223_{(Howl at me|My hunts)} 10:23, 1 September 2021 (UTC)
14. Gog the Mild (talk) 10:24, 1 September 2021 (UTC)
15. The idea seems logical. In response to the comment below, I would note that this theoretical unsuitable candidate would still need at least 50% to get in, so it remains far more likely that a better candidate than an empty seat gets in, to me eyes Nosebagbear (talk) 12:45, 1 September 2021 (UTC)
16. Generally seems sensible. Thanks. Mike Peel (talk) 14:28, 1 September 2021 (UTC)
17. Seems entirely reasonable. firefly ( t · c ) 15:25, 1 September 2021 (UTC)
18. Support. There are always "what-if" corner cases, but filling the seat is preferable to leaving it open in the vast majority of likely scenarios. BubbaJoe123456 (talk) 16:14, 1 September 2021 (UTC)
19. Reasonable. ~ ToBeFree (talk) 16:56, 1 September 2021 (UTC)
20. Per Nosebagbear. ‑‑ElHef (Meep?) 17:35, 1 September 2021 (UTC)
21. Comments below. Johnbod (talk) 19:14, 1 September 2021 (UTC)
22. Makes sense. Tol (talk | contribs) @ 20:36, 1 September 2021 (UTC)
23. This seems the best way to go about things. Thryduulf (talk) 20:57, 1 September 2021 (UTC)
24. Seems reasonable. Beeblebrox (talk) 21:21, 1 September 2021 (UTC)
25. This makes sense JW 1961 ^Talk 21:26, 1 September 2021 (UTC)
26. Reasonable lomrjyo ^{(✉ • 📝)} 23:11, 1 September 2021 (UTC)
27. 4nn1l2 (talk) 00:20, 2 September 2021 (UTC)
28. Similar to what I proposed back in 2020 on the talk page for this year. Dreamy Jazz ^{talk to me | my contributions} 07:47, 2 September 2021 (UTC)
29. ~Swarm~ ^{sting} 08:57, 2 September 2021 (UTC)
30. Assuming Nosebagbear's safety net reasoning is correct. Djm-leighpark (talk) 17:24, 2 September 2021 (UTC)
31. Support, reasonable. --TheSandDoctor ^Talk 17:50, 2 September 2021 (UTC)
32. —pythoncoder (talk | contribs) 18:48, 2 September 2021 (UTC)
33. Support. In a real election there would be concerns that some people had voted while the withdrawn candidate was on the ballot. In the WP arbcom election those voters simply vote again which overrides their previous vote. 02:41, 3 September 2021 (UTC) TOA The owner of all ☑️
34. Support conditional on maintaining per candidate support/oppose voting options. — xaosflux ^Talk 21:58, 3 September 2021 (UTC)
35. Support. Reasonable. --Elonka 22:49, 3 September 2021 (UTC)
36. Seems OK. Paul August ☎ 23:00, 3 September 2021 (UTC)
37. Seems reasonable -- Asartea ^{Talk | Contribs} 09:07, 4 September 2021 (UTC)
38. Makes sense. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:00, 4 September 2021 (UTC)
39. Support as it may give a more accurate tabulation, given that voters resubmit for the new slate of electors.— Shibbolethink ^{(♔ ♕)} 17:48, 4 September 2021 (UTC)
40. Seems fine to me. Stifle (talk) 15:38, 7 September 2021 (UTC)
41. Support. Deb (talk) 14:15, 8 September 2021 (UTC)
42. DanCherek (talk) 19:00, 10 September 2021 (UTC)
43. – Ammarpad (talk) 07:30, 12 September 2021 (UTC)
44. Blue Rasberry (talk) 16:17, 12 September 2021 (UTC)
45. Support. MarioGom (talk) 12:55, 13 September 2021 (UTC)
46. Support Pharaoh of the Wizards (talk) 16:21, 13 September 2021 (UTC)
47. Support. Completely logical. Liamyangll (talk to me! | My contribs!) 23:03, 13 September 2021 (UTC)
48. ~ Amory (u • t • c) 10:48, 14 September 2021 (UTC)
49. --Johannes (Talk) (Contribs) (Articles) 13:54, 14 September 2021 (UTC)
50. the wub "?!" 16:54, 18 September 2021 (UTC)
51. - Support The Living love ^talk 18:36, 18 September 2021 (UTC)
52. Support. Makes sense. In fact, it would probably be reasonable (although not necessary) to omit the withdrawn candidate's vote count from the published tally, especially since their votes were counted over a shorter time period than those of the other candidates. --Tryptofish (talk) 19:39, 19 September 2021 (UTC)
53. Support --Ooligan (talk) 05:09, 20 September 2021 (UTC)
54. Support - makes sense if you ask me. In the event that a candidate withdraws themselves, their seat should be filled by moving the rest of the candidates up. This way, there isn't a second "by-election" for the now-vacant seat. — MrConorAE ^{(👤U | 💬T | 📝C)} 21:24, 20 September 2021 (UTC)
55. Support clearly makes sense. Elli (talk | contribs) 04:26, 22 September 2021 (UTC)
56. Support, this makes sense. Provided, of course, that "the candidate with the ninth highest support percentage" has received at least the minimum support percentage (50%/60%, depending on the outcome of the discussion below). --rchard2scout (talk) 07:57, 27 September 2021 (UTC)

Oppose (withdrawn candidates)

1. Oppose, Wikipedia should implement a preferential voting system which allows votes to be transferred in the event a candidate withdraws. Aeonx (talk) 07:09, 15 September 2021 (UTC)

Comments (withdrawn candidates)

• Just a litte concerned that the presence of the withdrawee candidate may have been the decider or others not to stand. Let us say as an extreme use case 8 execllent candidates and one unsuitable candidate Z, I offer myself as an extreme example, stood. Now because the 8 excellent candidates have stood a further reluctant to stand excellent candidate Y choose not to but would have stood as last resort. However the withdrawal of the excellent candidate during the process meant unsuitable candidate Z got through. (I forget if there is a further safeguard to this). I bring this up as I thought this may have happened previously. — Preceding unsigned comment added by Djm-leighpark (talk • contribs) 09:02, 1 September 2021 (UTC)
  • Huh, good point, I didn't consider this. I still think that a withdrawn shouldn't cause a vacant seat for the next Committee, but there could be a chance that the last member is unpopular and get elected due to a winning candidate withdrawing. Perhaps we could make it so if there aren't any remaining candidates with a support percentage above 75%, and a winning candidate withdrew, we just leave the seat vacant? pandakekok9 (talk) 10:52, 1 September 2021 (UTC)
  • Certainly this could happen, but potential candidates should have the courage of their convictions, as well as allowing for the rather high probability of withdrawals, and stand anyway, even if they think they are likely to lose, based on the starting line-up . We don't have enough candidates in most elections. I don't mind a minimum %, but 75% seems too high - the usual 60% (2 yr) & 50% 1 yr) are fine. Johnbod (talk) 19:10, 1 September 2021 (UTC)
  • The "safeguard" is that there is a minimum support percentage to be eligible. In this case, a candidate must have more support than oppose, regardless of the other candidates. In the event there are not enough candidates with that percentage, the seat is left vacant. 02:43, 3 September 2021 (UTC) TOA The owner of all ☑️

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

---

Partially blocked voters

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

---

Currently voters are not allowed to vote if they are blocked. Since this was last decided, partial blocks have been introduced. Assuming that site-blocked users are still denied voting while blocked, how should partially blocked voters be treated? The only options are (a) Deny voting eligibility for partially blocked users; (b) Do not deny voting eligibility for partially blocked users; (c) Deny voting eligibility for only some sub-set (what?) of partially blocked users. — xaosflux ^Talk 02:36, 1 September 2021 (UTC)

Option A (Denying all partially blocked voters)

1. Best that 'only' completely unblocked voters, get to cast ballots. GoodDay (talk) 03:55, 1 September 2021 (UTC)

Option B (Allowing all partially blocked voters)

1. Partially blocked people have committed some transgression against the project, but the admin team has determined that they still deserve to be a part of the community. I don't think that they should be disenfranchised because of this. I might be willing to support denying some sub-set of partially blocked voters if the specific given circumstances are narrow enough.  Mysterymanblue  04:44, 1 September 2021 (UTC)
2. With the same reasoning and caveat as Mysterymanblue above. There's a reason that partially blocked editors aren't fully blocked. ezlev (user/tlk/ctrbs) 04:52, 1 September 2021 (UTC)
3. Partial blocks are very similar to topic bans, and we have historically allowed topic-banned editors to vote in ArbCom elections. I see no reason to deviate from the status quo. Mz7 (talk) 04:55, 1 September 2021 (UTC)
4. They're still a part of the community and therefore should be able to help decide how the community functions. -- Longhair\^talk 05:11, 1 September 2021 (UTC)
5. Support this is often due to a specific and relaively trivial issue. DGG ( talk ) 07:38, 1 September 2021 (UTC)
6. Same reasoning as Ezlev. Bibeyjj (talk) 07:52, 1 September 2021 (UTC)
7. Per Mz7. Regards SoWhy 08:35, 1 September 2021 (UTC)
8. Partial blocks are like topic bans. ProcrastinatingReader (talk) 09:31, 1 September 2021 (UTC)
9. Gog the Mild (talk) 10:25, 1 September 2021 (UTC)
10. SmokeyJoe (talk) 11:47, 1 September 2021 (UTC)
11. I actually support the "pbanned from everything except AN/ARBCOM for block review remains not permitted" position, but since that's a really hard one to assess on the timescales of our elections, I think the "permit all" position is most practical. Nosebagbear (talk) 12:47, 1 September 2021 (UTC)
12. I'm partially blocked, and I haven't committed any "transgressions against the community".—S Marshall T/C 12:55, 1 September 2021 (UTC)
13. I think this is the most fair. If someone has some special remedy or community restriction preventing participation in elections, they can be dealt with exceptionally. — xaosflux ^Talk 13:10, 1 September 2021 (UTC)
14. Seems reasonable. Not sure why blocked users aren't allowed to vote (mainly those temporarily blocked but expected to return, rather than blocked long ago users). Thanks. Mike Peel (talk) 14:29, 1 September 2021 (UTC)
15. Any disruption that led to a project-space partial block, or to a ban from participating in project-space discussions, is unlikely to occur in a silent voting process. ~ ToBeFree (talk) 16:59, 1 September 2021 (UTC)
16. There are too many use cases of partial blocks for there to be a blanket disenfranchisement of these users (or even a subset of these users). There is a reason each one is not fully blocked or banned, and as such they are still part of the community. ‑‑ElHef (Meep?) 17:44, 1 September 2021 (UTC)
17. I oppose the use of partial blocks as a whole on the English Wikipedia, thus I also oppose making them more restrictive in any way, shape, or form. — Godsy ^(TALK_CONT) 17:47, 1 September 2021 (UTC)
18. Second choice to Option C. Thryduulf (talk) 20:58, 1 September 2021 (UTC)
19. I don't think partial blocks are intended to disenfranchise a user entirely in this manner. Beeblebrox (talk) 21:23, 1 September 2021 (UTC)
20. Partial blocking is still new on the encyclopedia and hasn't bedded in. Therefore I'm not happy to disenfranchise those users who are partially blocked. Worm^TT(talk) 07:35, 2 September 2021 (UTC)
21. First choice. If a user is still allowed to edit, but can't edit some pages or namespaces, then they still should get a say in electing arbitrators. If a user's partial block covers the Wikipedia namespace, then this may present a reason to not allow them to vote. However, this partial block of the Wikipedia namespace may be completely unrelated to voting or arbitration in general. It may be disruption in administrator boards, but as only 10 pages can be specified in partial blocks, it may be that this disruption extends over more than 10 pages and so a namespace partial block was used because of technical restrictions. As such just checking for the existence of a Wikipedia namespace partial block may exclude editors who would be constructive in the voting process via secure poll, but get uncivil in commenting to other editors in the Wikipedia namespace. Dreamy Jazz ^{talk to me | my contributions} 08:02, 2 September 2021 (UTC)
22. No other realistic way of doing it. Partially blocked users cannot be classified as a single unit who are unfit to vote. Partial blocks are a low-level sanction, and many are partially blocked short-term for minor transgressions such as edit warring on a single page. As someone else said, all partially blocked users have been deemed fit to continue participating in the community to the fullest extent with the sole exception of their partial blocks. ~Swarm~ ^{sting} 09:02, 2 September 2021 (UTC)
23. A partial block from one article can be a practical way of resolving a dispute while allowing the editor to continue editing, and is often accepted by the editor in that spirit. If the effect of the partial block is disenfranchisement in the election, I foresee this would lead to partially blocked editors' feeling compelled to appeal from partial blocks that they would otherwise have accepted. The burden this might place on reviewing admins could be significant, at a time when requests for unblock already take too long to be processed. Newyorkbrad (talk) 15:47, 2 September 2021 (UTC)
24. There's a reasonable argument made below that editors partially-blocked from the entire Wikipedia namespace should not be allowed to vote, while other partial-blocks should not prevent voting. However, I think that's more complicated than necessary, and this simpler proposal should carry. User:力 (power~enwiki, π, ν) 19:55, 2 September 2021 (UTC)
25. As I see it, Option B is comparable to when someone commits a crime on Friday, but because he went to church on Sunday the congregation sings "hallelujah! we forgive you". Sometimes a partial block is handed down because some Admins are willing to slap, but not kick. So if the community is willing to bend over backwards about partial blocks, my first question would be: what is the contentious history of this editor? -- and -- how many partial blocks has this editor earned? Pyxis Solitary (yak). L not Q. 10:28, 3 September 2021 (UTC)
26. Thank you ProcrastinatingReader for the clarification. Partially blocked users are still part of the community and should be able to vote in my opinion. HighInBC ^{Need help? Just ask.} 12:02, 3 September 2021 (UTC)
27. Per ProcrastinatingReader, partial blocks are the same as topic bans, and users subject to them are part of the community. -- Calidum 15:49, 3 September 2021 (UTC)
28. Any user that is still part of the community should get to vote period. Paul August ☎ 23:11, 3 September 2021 (UTC)
29. -- Asartea ^{Talk | Contribs} 09:07, 4 September 2021 (UTC)
30. Partially blocked users have been deemed constructive contributors in one topic or another, so IMO this makes sense. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:01, 4 September 2021 (UTC)
31. Otherwise it would probably be too complicated to determine if the partially blocked user's block is related to this and as noted topic banned editors can. If needed a topic ban from voting could be used but I don't think that would be needed often. Crouch, Swale (talk) 19:19, 4 September 2021 (UTC)
32. Support partially blocked users are still members of the community so should be allowed to participate. Callanecc (talk • contribs • logs) 06:15, 5 September 2021 (UTC)
33. If you get to edit, and you're otherwise eligible, you get to vote. Opabinia regalis (talk) 03:18, 6 September 2021 (UTC)
34. Partial blocks are used only when there's some very localized problem, and do not imply the individual has lost the trust of the community in general. DGG ( talk ) 14:36, 7 September 2021 (UTC)

    @DGG: Looking through the partial block list I've noticed that a solid 20% of them are from the entire article namespace, and those 20% are generally indefs. It doesn't appear like in practice they're only being used with "very localized problems". Chess (talk) (please use {{reply to|Chess}} on reply) 19:34, 24 September 2021 (UTC)

    Chess , it could beworded diferently: 80% are not ' from the entire article space, which is just what I said--only 1/5 are problems that are more than localized. DGG ( talk ) 00:25, 25 September 2021 (UTC)

    @DGG: Probably, but it's hard to say that someone hasn't lost the trust of the community if they've been indefinitely blocked from directly contributing to the encyclopedia. Chess (talk) (please use {{reply to|Chess}} on reply) 00:30, 25 September 2021 (UTC)

35. Otherwise it could be too complex. Stifle (talk) 15:38, 7 September 2021 (UTC)
36. —⁠ScottyWong⁠— 01:24, 8 September 2021 (UTC)
37. Support for allowing all partially blocked to vote. // Knifegames (talk) 06:48, 8 September 2021 (UTC)
38. Support - I will support all voters to vote. Why are voters voters, if they cannot. A deny of democracy. I'm so tired (talk) 10:05, 9 September 2021 (UTC)
39. Any editor who is contributing to some part of the English Wikipedia (i.e., any editor who is not sitewide-blocked or banned) should be able to cast a vote. DanCherek (talk) 19:12, 10 September 2021 (UTC)
40. – Ammarpad (talk) 07:32, 12 September 2021 (UTC)
41. Blue Rasberry (talk) 16:18, 12 September 2021 (UTC)
42. Pharaoh of the Wizards (talk) 16:23, 13 September 2021 (UTC)
43. Izno (talk) 05:11, 14 September 2021 (UTC)
44. I initially liked the sound of a Projectspace-specific limitation, but Mz7 and Beeblebrox have me thoroughly convinced. This is the right course of action. ~ Amory (u • t • c) 10:50, 14 September 2021 (UTC)
45. --Johannes (Talk) (Contribs) (Articles) 13:56, 14 September 2021 (UTC)
46. Partial blocks are used for a wide variety of reasons, and will generally have been placed with no consideration of disenfranchising the user. The number of users partially blocked from the entire project namespace is tiny (currently 4 by my count), and doesn't seem worth adding the extra complexity. the wub "?!" 17:06, 18 September 2021 (UTC)
47. Support, no reason to disenfranchise them. --rchard2scout (talk) 07:59, 27 September 2021 (UTC)

Option C (Denying some sub-set of partially blocked voters)

Please describe specific criteria if selecting this section

1. There are some who gets downgraded to partial blocking to make them participate in a block review or unblock discussion about them. I don't think the downgrading admin meant for the partially blocked user to contribute back again, at least not yet. Users who are blocked from all pages except WP:AN and WP:ANI shouldn't be allowed to vote. pandakekok9 (talk) 06:17, 1 September 2021 (UTC)
2. Being partially blocked should not prevent them from voting. However if they are blocked from the namespace that the vote takes place then they should not have an exception to that partial block. HighInBC ^{Need help? Just ask.} 06:56, 1 September 2021 (UTC)

   The vote takes place on SecurePoll. ProcrastinatingReader (talk) 09:32, 1 September 2021 (UTC)

3. Second choice. Ideally I would only want to see users partially blocked from Arbitration pages be intelligible to vote, and not those who have been partially blocked in the Wikipedia namespace in general as detailed in my first choice vote in the above section. Dreamy Jazz ^{talk to me | my contributions} 08:04, 2 September 2021 (UTC)

Option C1 (Denying users partially-blocked from project namespace)

1. Users who are blocked from the project namespace should be prohibited from voting, whereas other partially blocked users should be allowed to vote. * Pppery * _{it has begun...} 03:46, 1 September 2021 (UTC)
2. Support this. —Locke Cole • t • c 06:57, 1 September 2021 (UTC)
3. SecurePoll is a de facto extension of projectspace. Thus I support disallowing users with projectspace blocks. I also think that ElectCom should be allowed a significant amount of discretion in determining whether a given partial block ought to be disqualifying, for edge cases like someone who was downgraded to a p-block for a siteblock appeal (but not for something like someone who's p-blocked from that one article where they can't drop the stick). -- Tamzin^{[cetacean needed]} (she/they) 14:52, 1 September 2021 (UTC)
4. This is a difficult space to be in, but I agree with Tamzin that it makes sense to exclude those blocked from project space. --BDD (talk) 15:18, 1 September 2021 (UTC)
5. Per Pppery and Tamzin. Eggishorn (talk) (contrib) 18:21, 1 September 2021 (UTC)
6. pandakekok9 names my only objection to B, which I would support (strongly) over A. If we can prevent exactly the users blocked from every projectspace page (or, hell, specifically all those blocked from Wikipedia:Arbitration/Requests/Case) then that would be my ideal. — Bilorv (talk) 19:33, 1 September 2021 (UTC)
7. Those blocked from project space should be disenfranchised per Pppery and Tamzin. Tol (talk | contribs) @ 20:42, 1 September 2021 (UTC)

   To clarify, my second choice is allowing all partially blocked users, not to prevent all of them from voting. Tol (talk | contribs) @ 18:03, 2 September 2021 (UTC)

8. First choice (ahead of option B) per Tamzin and Pppery - users partially blocked from projectspace should not be allowed to vote. Other partially-blocked users should retain the franchise. Thryduulf (talk) 21:00, 1 September 2021 (UTC)
9. The users who have been blocked from the Wikipedia namespace during the voting period should not be allowed to vote. 4nn1l2 (talk) 00:22, 2 September 2021 (UTC)
10. For users pblocked from project space per Tamzin and others. {{u|Sdkb}} ^talk 01:27, 2 September 2021 (UTC)
11. Support for users blocked from Wikipedia:Arbitration/Requests/Case (or, more generally, Wikipedia:Arbitration or any subpage thereof), including both users who are blocked from the project namespace and those blocked from all pages except WP:AN and WP:ANI. —2d37 (talk) 04:25, 2 September 2021 (UTC)

    Re Thryduulf 11:09, I think my !vote fits best under "Option C1 (Denying users partially-blocked from project namespace)", although I'm not sure. Anyway, however, I conditionally withdraw this !vote, so long as the number of potential voters whom this would affect remains as low as Xaosflux points out it is currently. —2d37 (talk) 23:18, 3 September 2021 (UTC)

12. Support, users who are partially blocked from project space. Majavah (talk!) 08:19, 2 September 2021 (UTC)
13. Per Tamzin. Additionally, it seems strange that a p-block from project-space would prevent participation at RfA (which traditionally has very low standards) but wouldn't prevent participation at ACE (which traditionally has higher standards). Extraordinary Writ (talk) 23:27, 2 September 2021 (UTC)
14. Support. Users who cannot contribute to the project should not be allowed to help decide the arbitration body for those who edit the project. I think partial unblocks for ANI or ArbE or other non-project space do not change the intent of the block, and those editors who had such disruption should not be restored full voting rights.— Shibbolethink ^{(♔ ♕)} 17:51, 4 September 2021 (UTC)
15. Support this option. MarioGom (talk) 12:55, 13 September 2021 (UTC)
16. I don't feel strongly about this one, but I can see a better rationale for denying users who have been problems in the project namespace, as opposed to other namespaces. --Tryptofish (talk) 19:42, 19 September 2021 (UTC)
17. Support per Tamzin. Elli (talk | contribs) 04:26, 22 September 2021 (UTC)

Comments (Partially blocked voters)

• I've seen partial blocks used to enforce interaction bans (user A is blocked from user B's talk page and viceversa). It does not feel fair to prevent these users from participating in the election if they have been respecting the i-ban and editing constructively elsewhere. –FlyingAce^✈hello 03:58, 1 September 2021 (UTC)
• I'd like to present myself as a use case. I've just had a 72-hour block, served my time reasonably well, for these purposes let's assume I did the 72 hours with a halo and have been reasonable since, but I offered and was accepted for a block for any which I have has a conflict of interest, in fact only one has been issued for the Railway Preservation Society of Ireland (RPSI). Now is it appropriate that the PBLOCK for the RPSI should prevent me from !voting? Thankyou. Djm-leighpark (talk) 12:29, 1 September 2021 (UTC)

  Pedant's note: !voting is what's happening here; the actual elections involve actual voting. :) —2d37 (talk) 03:42, 2 September 2021 (UTC)

  Thankyou for the good faith clarification, which was a thoughtful thing to do. Pragmatically this proposal is heading away from A and towards a B/C and I'm likely to choose to sty away from the !voting. Likely the case on several other proposals unless I feel urgent need to come in and !vote or taactically !vote. But clarification I could !vote here was nice. Thankyou. Djm-leighpark (talk) 10:04, 2 September 2021 (UTC)

• Blocking is a tool to enforce an imposed editing restriction. Thus we should examine the actual restriction being imposed, and judge if it encompasses participation in arbitration committee elections. isaacl (talk) 21:20, 1 September 2021 (UTC)
• Very opposed to option C, in particular the idea that ElectCom have it's own ad hoc rules for deciding who gets to vote. Arbitration processes are there to serve the community, and p-blocked users are still part of that community and should be allowed to have a vote. Beeblebrox (talk) 22:08, 1 September 2021 (UTC)

  Option C does not mean ad hoc rules - if it were closed right now there would be a consensus for disenfranchising users partially blocked from Project space and no others. That's as definite as either A or B. Thryduulf (talk) 23:50, 1 September 2021 (UTC)

  One of the supporters commented " I also think that ElectCom should be allowed a significant amount of discretion in determining whether a given partial block ought to be disqualifying, ". So, apparently at least one person does want that. Beeblebrox (talk) 19:37, 2 September 2021 (UTC)

  That one person wants that is true, but that's not what is written in the proposal and it's not what 13 of the other 14 commenters want (4nn1l2 has not described the specific criteria they are supporting). Unless something drastically changes, ad hoc rules are definitely not going to get consensus. Thryduulf (talk) 00:49, 3 September 2021 (UTC)

  Thanks Thryduulf for informing me. I thought the project namespace has been determined in the proposal itself, but it was not. I added some explanation to my vote. 4nn1l2 (talk) 01:02, 3 September 2021 (UTC)

• For those saying "people blocked from Project namesapce" - do you realize this is all of about 4 editors that need a special rule? — xaosflux ^Talk 13:53, 2 September 2021 (UTC)

  I see that as a feature rather than a bug. --BDD (talk) 15:34, 2 September 2021 (UTC)

• I move that Option C be re-factored so the most common alternative option is a separate section from "something else". User:力 (power~enwiki, π, ν) 00:53, 3 September 2021 (UTC)

  Good idea. Thryduulf (talk) 01:11, 3 September 2021 (UTC)

  I've done the split. I'm not sure if everyone needs to be pinged to ensure it was done correctly or not; there are a few comments that are only sort-of supporting the Pppery statement where I had to make a judgment call whether to move or not. User:力 (power~enwiki, π, ν) 03:21, 3 September 2021 (UTC)

  I see the comments by @HighInBC, Bilorv, and 2d37: as possibly ambiguous and so worth pinging but I think everyone else's !votes are sufficiently clear. Thryduulf (talk) 11:09, 3 September 2021 (UTC)

  Thanks for the ping. I'm in support of the new Pppery option, so I've moved myself over. — Bilorv (talk) 11:25, 3 September 2021 (UTC)

Advertisements to such

While I didn't state it above, I would like to extend whatever the results of this suffrage question end up being to the advertisement section (which currently forbids messaging to certain blocked users, without accounting for the newer partial block system), just to keep these in sync if we allow for p-block voters (i.e. if you are eligible to vote, you should get notified). I can't imagine this being contentious on its own so won't spin up another question for !voting unless there is any push back here. — xaosflux ^Talk 02:49, 6 September 2021 (UTC)

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

---

Voting system - STV

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

---

SecurePoll now supports the single transferable vote (STV) system in elections, as demonstrated by the recent WMF Board elections. There's a good explanation of how the system works on Meta Wiki, but put simply:

1. Each voter ranks the candidates in order of preference (with the option to not assign a preference to candidates they oppose)
2. The number first-preference votes for each candidate is calculated.
3. If any candidate exceeds the "quota" (which is the number of votes divided by one more than the number of candidates), then they are deemed elected, and any votes over the quota (their "surplus") are assigned to the other candidates according to their voters second preferences.
4. This means that if Alice was elected, and 20% of Alice's voters ranked Bob second, then 20% of Alice's surplus would transfer to Bob.
5. If no candidates are elected, then the candidate with the lowest vote is eliminated, and their votes are assigned to the other candidates according to their voters' next preferences.
6. If any candidate exceeds the quota after these votes are transferred then they are elected, and the process repeats until all seats are filled.

With this in mind, should we change the voting system used for ArbCom elections to the single transferable vote, or should we keep the current three-option support/oppose/neutral system? PinkPanda272 (talk/contribs) 07:03, 1 September 2021 (UTC)

Support (Voting system - STV)

1. I have previously suggested a ranked-choice voting for ACE and I think this is a possible way to implement this. Unlike the current S/O/N system, this system would not force people to oppose candidates simply so that another candidate has a better chance. Candidates which the voter straight up opposes can still be opposed by not assigning them a preference at all (as the meta wiki page illustrates). As I understand it, ff you don't assign a preference to a candidate, there is no risk that your vote will be redistributed to that candidate. I also don't think having to decide between two equally qualified candidates is really a problem in practice. Neither do I see a real problem with too many candidates making the process too difficult, seeing as the WMF Board Elections with 19 candidates was no problem either. Regards SoWhy 08:46, 1 September 2021 (UTC)
2. Not convinced it will be too complicated, given the turnout at these board elections which IIRC was greater than previous ones. Seems like a more accurate method. ProcrastinatingReader (talk) 09:34, 1 September 2021 (UTC)

   But was STV the cause? Or was it due to other factors (such as spamming basically every wiki except for enwiki)? --Rschen7754 18:02, 1 September 2021 (UTC)

3. Per SoWhy. Imperfect, but an improvement. Vanamonde (Talk) 09:57, 1 September 2021 (UTC)
4. Per SoWhy. Gog the Mild (talk) 10:27, 1 September 2021 (UTC)
5. Generally a good system to use. Used elsewhere inside and outside the Wikimedia movement, e.g., for WMF board election votes, New Zealand government elections. Thanks. Mike Peel (talk) 14:31, 1 September 2021 (UTC)
6. This is the best voting system. Those who support diversity, as I do, should support this proposal. 4nn1l2 (talk) 00:12, 2 September 2021 (UTC)
7. STV looks like a nice voting system for this use-case. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:02, 4 September 2021 (UTC)
8. Generally the best voting system. Hawkeye7 (discuss) 04:08, 5 September 2021 (UTC)
9. Being Irish I am compelled to agree. Stifle (talk) 15:38, 7 September 2021 (UTC)
10. —⁠ScottyWong⁠— 01:25, 8 September 2021 (UTC)
11. Blue Rasberry (talk) 16:19, 12 September 2021 (UTC)
12. I am not totally sure I am convinced by the opposition. I appreciate that candidates can be rejected in the voting SNO system that is set up today, but the experience with the BOT implementation left me feeling reasonably sure that such candidates will not rate highly in the STV system as-implemented. --Izno (talk) 05:17, 14 September 2021 (UTC)
13. Each system has disadvantages. Having looked through the opposes but also voted in STV elections and in arbcom elections before, I still believe the secure poll's STV is the better than approval voting for this election. Yes there is a risk of letting in a candidate that would not have succeeded under approval voting but I think that risk is low. A notable point here is that I don't see someone flipping a coin or whatever to decide between 2 candidates as harmful. If person A can't decide between two candidates that's fine, maybe person B can and there's no reason they should be barred that choice just because person A can't. The problem is actually when they don't flip a coin but use things they shouldn't like name order. I'd much rather have the ability to rank candidates since when I have voted, there's always candidates I definitely want, candidates I support but not strongly, candidates I'm unsure about, candidates I oppose to some degree and candidates I completely oppose. (It's more granular than that.) Note that although currently I can reject candidates I oppose, which can make a difference including potentially completely barring them I'm pretty sure there's been multiple candidates I opposed being elected which is fine but limits the effectiveness of my vote. It still counts since it effects the percentage but just like my supports, I consider it counts less than when I can rank candidates I oppose. IMO the only real risk is if the change to STV or some other reason means we get too many candidates. While as I said, there's no reason to overcomplicate things if you are unsure about which of two or more candidates you prefer, it's fine to simply flip a coin etc, you still need to start somehow. But I think this is a lot less of a problem with ACE anyway, since for most active editors, it's unlikely they'll never have heard of a candidate and if they really haven't that probably means it's a yeah, nah situation. Nil Einne (talk) 18:53, 25 September 2021 (UTC)

Oppose (Voting system - STV)

1. Given the low eligibility requirements to be a candidate, the vote serves both as an evaluation of qualifications as well as support. I think approval voting is a good fit to determine which candidates are deemed to be qualified. isaacl (talk) 07:12, 1 September 2021 (UTC)
2. I usually find it much easier to decide whether to support or oppose a candidate than to rank the candidates in any sort of order. Hut 8.5 07:43, 1 September 2021 (UTC)
3. STV is great and all, but it tends to become difficult to use when the number of candidates is high and/or people - for whatever reason - do not have enough information to rank a significant number of candidates. Quite frankly, the trustee election should also be approval voting; I did not vote in it, but I would have if it were approval voting. This system also has the benefit of being easier to run.  Mysterymanblue  07:47, 1 September 2021 (UTC)
4. I tend to prefer approval voting because of the option to vote against certain candidates. STV does have the advantage of showing the degree of support for candidates, and allowing for neutrality (not putting them in your vote ranking), but this can also be expressed verbally, and with enough voters in an election is not a major discrepancy. Ranking is just more flexible, and there is less pressure on the voter. Bibeyjj (talk) 07:59, 1 September 2021 (UTC)
5. Just researching the approval (s/n/o) votes is enough work. Ordering candidates by level of approval is too much. Voters will be effectively flipping coins to decide the order of two equally good/bad candidates. wikinights _talk 08:23, 1 September 2021 (UTC)
6. Oppose, as the goal of this election is not the same as the goal of the election that STV is designed for. STV works well for filling multiple seats when primary goal of the election is to fill n seats with the n candidates that have the most support. However, we have no need to actually fill all of our seats, it is preferable that we have vacant seats if it would have otherwise meant installing a functionary that has an individual majority opposition. I'm not opposed to changing the voting system - but these proposals need to be very clear about this factor and how they will satisfy it - and this current proposal falls short. — xaosflux ^Talk 09:47, 1 September 2021 (UTC)
7. xaosflux makes a good point here. A seat in arbcom includes sensitive privileges like checkuser. If you don't trust a candidate in one or some parts of their duties, it wouldn't be a good idea to include your support for them, now matter how tiny. --pandakekok9 (talk) 10:41, 1 September 2021 (UTC)
8. Support / Neutral / Oppose is an excellent method. Ranking amongst approved candidates encourages political competition between the approved, which is not the point of the election. Candidates should be evaluated as suitable or not. While tactical voting is possible, voting suitable candidates as opposed to increase the chance of your favorite, this is an unnatural thing to do, and I am unaware of any suggestion that it is happening to an extent to worry about. --SmokeyJoe (talk) 12:20, 1 September 2021 (UTC)
9. Oppose per xaosflux. SQL^{Query Me!} 12:43, 1 September 2021 (UTC)
10. xaosflux nails it in one. An empty seat is better than an unsuitable candidate for ARBCOM - and we can handle that. As a secondary consideration, the STV-rework didn't include a capability to tie votes. This means if you have good, bad, and unknown/neutral candidates, you can deal with the first two, but the unknown group just has to be randomly ordered, which is unfair on (some of) them. Nosebagbear (talk) 12:50, 1 September 2021 (UTC)
11. * Pppery * _{it has begun...} 13:26, 1 September 2021 (UTC)
12. Agree with xaosflux. Goal of the election makes STV inappropriate. BubbaJoe123456 (talk) 16:17, 1 September 2021 (UTC)
13. STV fails if we have less qualified candidates than available seats; our current voting system doesn't. Let's keep our current one. ~ ToBeFree (talk) 17:04, 1 September 2021 (UTC)
14. Agree with xaosflux. STV doesn't fit the purpose here. ‑‑ElHef (Meep?) 17:57, 1 September 2021 (UTC)
15. I didn't vote in the Board elections because this was too much work. --Rschen7754 18:01, 1 September 2021 (UTC)
16. Approval voting is the form of voting we want to see for ARBCOM. --Enos733 (talk) 18:04, 1 September 2021 (UTC)
17. I agree with all above comments. NW1223_{(Howl at me|My hunts)} 18:28, 1 September 2021 (UTC)
18. Per Xaosflux. Tol (talk | contribs) @ 20:45, 1 September 2021 (UTC)
19. Per Xaosflux and Nosebagbear. Every year there are one or more proposals to change the voting system but never once has any of those proposals managed to convince me that the current system needs to be replaced, let alone that the alternative de jour is what should be used to replace it. This proposal is, in that respect at least, no different to the previous ones. Thryduulf (talk) 21:03, 1 September 2021 (UTC)
20. I think this is simply asking too much of the electorate. Beeblebrox (talk) 21:25, 1 September 2021 (UTC)
21. Xaosflux is right. I'll also point out that there are so many different STV systems that misunderstandings about how the SecurePoll one works are inevitable; in fact, there are already some misunderstandings exhibited in the responses/comments to this suggestion. To be honest, I have a lot less faith in STV systems than S/N/O ones. Risker (talk) 22:32, 1 September 2021 (UTC)
22. ARBCOM is not intended to be a representative body, it is intended to be a body with members who all individually have the support of the community as a whole. User:力 (power~enwiki, π, ν) 02:36, 2 September 2021 (UTC)
23. Xaosflux highlights my concern. I'm not happy for someone who would normally get insufficient support to sit having that support "transferred" to them. Worm^TT(talk) 07:37, 2 September 2021 (UTC)
24. No, we should be able to cast an oppose vote for a candidate we know to be unsuitable just as easily as a support for one we know to be suitable, and without having to even consider those of whom we have no knowledge. In the recent Board election I had to rate about fifteen candidates about whom I knew nothing whatsoever in order to register a couple of opposes. Justlettersandnumbers (talk) 16:35, 2 September 2021 (UTC)
25. Not violently opposed but feel more comfortable with oppose argues and status-quo on this one. Djm-leighpark (talk) 17:28, 2 September 2021 (UTC)
26. Oppose. This system makes it more confusing to vote and thus decreases turnout. —pythoncoder (talk | contribs) 18:52, 2 September 2021 (UTC)
27. Approval voting is terrible for partisan elections because it punishes honest voters by diluting their votes. So long as there is no evidence that Wikipedia has split into partisan camps who believe that the other side is evil incarnate, approval voting works great and provides a more granular view into voters' preferences than a ranked vote. -- King of ♥ ♦ ♣ ♠ 22:17, 2 September 2021 (UTC)
28. Oppose, the current yes/no voting system is a better system. 02:48, 3 September 2021 (UTC) TOA The owner of all ☑️
29. I'm a huge fan of STV in certain circumstances, but it doesn't fit here. I can't support taking the three valuable options afforded by S/N/O and cutting them down to two. Retswerb (talk) 07:29, 3 September 2021 (UTC)
30. I usually find myself only recognizing 4 or so names and voting neutral on everyone else; STV would make that impossible. I guess I'm in agreement with #20. 78.28.44.31 (talk) 14:42, 3 September 2021 (UTC)
31. Strongly Oppose STV, although it works well in some settings, by its very nature allows hated and terrifying candidates to be elected if they are loved by a devoted minority. These are precisely the kinds of candidates we all need to keep off ARBCOM, but may often be stuck with under STV (I can think of at least one such candidate who would almost certainly have been elected to ARBCOM not too long ago had STV been in use, although it would presumably be a violation of WP:NPA for me to name that candidate even if I wanted to do so, which I don't). Tlhslobus (talk) 14:50, 3 September 2021 (UTC)
32. I still don't think this is a practical plan for an election with a half dozen or more seats to fill. -- Calidum 15:13, 3 September 2021 (UTC)
33. STV not useful here. Paul August ☎ 23:19, 3 September 2021 (UTC)
34. A single transferable vote system is largely designed for a scenario when there are a number of seats in an election that need to be filled regardless of the support percentage achieved by each candidate. That isn't how ArbCom elections have worked previously and I don't believe how it should work. The basis of our ArbCom election system is that a candidate needs to achieve 60% (or 50% for a 1 year term) to be elected. STV won't, and really can't fairly, support this system of election given the preferencing of candidates. Callanecc (talk • contribs • logs) 06:24, 5 September 2021 (UTC)
35. Oppose STV per xaosflux & other good points above. // Knifegames (talk) 07:00, 8 September 2021 (UTC)
36. Oppose per Tlhslobus. STV is the best voting system for most elections, but not for ARBCOM. –Gladamas (talk · contribs) 05:48, 9 September 2021 (UTC)
37. STV might work for elections to a legislative body, but per the above it doesn't work for elections to an adjudicative body. Extraordinary Writ (talk) 05:59, 14 September 2021 (UTC)
38. Weak oppose I love STV beyond but xaos is right — I'd rather an empty seat. I don't think it's that big of a risk — the advantage of STV means that the pure S/N line isn't as meaningful and folks will really have more support — but it's right nonetheless. ~ Amory (u • t • c) 10:55, 14 September 2021 (UTC)
39. I like STV as a system, and am less concerned about a theorised "bad candidate" (according to someone's view) becoming a member of Arbcom itself, given that cases are handled deliberatively by Arbcom as a whole and an increased diversity of perspectives could be useful. However xaosflux makes a good point that members also get access to checkuser and oversighter tools. I think access to those should have the general approval of the community, and therefore we should stick with approval voting. the wub "?!" 17:19, 18 September 2021 (UTC)
40. Strong Oppose. I would need to be convinced that there is a problem that needs to be fixed, and that this would solve the problem. And I'm not. STV is best suited to elections for a single open seat, with multiple candidates, none of whom is likely to get majority support on the first ballot. That's not what we have here. The fact that WMF did it for the Board is no reason for us to do it. (Indeed, given WMF's troubled record, one could make a case for doing the opposite of whatever they do.) And just trying something new to see what happens is not a good reason either. It would be complicated to implement, in the sense of the community understanding it. And there have been lots of times when I've been strongly in favor of more than one candidate, and would have found rank-ordering my top picks arbitrary. --Tryptofish (talk) 19:51, 19 September 2021 (UTC)

    @Tryptofish: actually in modern election parlance Single transferable vote is normally restricted to systems where there are multiple seats to fill, since it aims to achieve some degree of proportionality. What you seem to be referring to is normally called instant-runoff or preferential voting or something. While the systems are superficially similar since both involve ranking candidates, they are normally considered different since in systems where there is only one candidate there can be no proportionality, you're only chosing a single candidate who is effectively preferred by a majority. Nil Einne (talk) 18:43, 25 September 2021 (UTC)

    @Nil Einne: Thanks for educating me about the distinction from preferential voting; I was unaware of the difference. But my overall view is still the same. --Tryptofish (talk) 20:40, 25 September 2021 (UTC)

41. Oppose doesn't seem to be the right electoral system for what we want to do here. Elli (talk | contribs) 04:36, 22 September 2021 (UTC)

Comments (Voting system - STV)

• Many of the past discussion on this try to compare the ARBCOM election to local political elections and fail to keep in mind that there is a big difference in the goal of the election. In elections for your presidents, MP's, even the chair of the local wastewater management board there is a single overwhelming goal: install someone to this position. For ArbCom, we have many seats available and it is OK if some of them are not filled. Keep in mind, that a vote for someone to be on ArbCom is also a vote that they should be a checkuser and oversighter, and it becomes more clear why ensuring each individual can show a majority support from the community in their own capacity. Without this individual mandate should the number of candidates not exceed the number of seats - we wouldn't even need the election, everyone would just immediately be installed no matter how opposed anyone is. — xaosflux ^Talk 09:57, 1 September 2021 (UTC)

  @Xaosflux: I'm not an expert on the math, but surely there's several ways to get around this problem? For instance: candidates who were not ranked within the top X positions (where X represents the number of seats) by a minimum of Y voters (where Y is a threshold we choose here) can be declared to be ineligible. Alternative cutoff methods are easily devised. Our current minimum support threshold is just as arbitrary; it isn't a product of the voting system itself. Vanamonde (Talk) 12:54, 1 September 2021 (UTC)

  @Vanamonde93: I seem to think there is something somewhere that requires at least 25 support votes (which is trivial here) but that is another issue. "Top x" doesn't solve the problem, it is perfectly acceptable for 0 or only 1 person to be appointed to the committee if there are no well supported candidates. — xaosflux ^Talk 13:07, 1 September 2021 (UTC)

  Xaosflux, that's far from the only option though. We could set a minimum number of first-choice votes: or add a "none-of-the-above" option, and eliminate those who end up below it; etc. My point is a minimum support threshold isn't any more inherent to our current system than the STV system, and if that's the only concern, it's one we can address. Vanamonde (Talk) 13:11, 1 September 2021 (UTC)

  @Vanamonde93: we can do pretty much whatever we want, however this specific proposal doesn't address the issues I've brought up. Feel free to submit a new proposal for changes to the voting system that addresses the two goals of the election: (a) ensure that anyone appointed to arbcom is individually trusted by the community for this role (b) fill the arbcom vacancies with the most supported volunteers that satisfy (a). Or, we could look at redefining what being an arbcom member means. — xaosflux ^Talk 13:17, 1 September 2021 (UTC)

  @Vanamonde93 and Xaosflux: None of the above (the exact phrase Vanamonde93 used) is actually widely used in STV systems for exactly the purpose of preventing the election of candidates who are not supported by the community, and I think it's very successful at doing so. — Bilorv (talk) 19:44, 1 September 2021 (UTC)

  @Bilorv: You'd think it would need to be "none of the below" as you rank from most desired to least desired; we really should have some actual mock-ups of what the options would be under any proposed system, along with what the results for different vote distributions in such systems would be. — xaosflux ^Talk 20:05, 1 September 2021 (UTC)

  Yeah, you can name it want you want but the point is that it describes a voting option with a specific purpose. "None of the above" is designed for paper ballots where it's the last option, but you could have "No candidate" or whatever. — Bilorv (talk) 20:27, 1 September 2021 (UTC)

  In the "None of the above" article you linked to, the only examples given have the "Re-open nomination" option as one of the choices that can get eliminated and thus its votes transferred to the next preferred options, which I don't think is what people have in mind here. Do you know of any examples where a different procedure was put in place? isaacl (talk) 20:50, 1 September 2021 (UTC)

  Real world political systems have a surrounding ecosystem that helps ensure candidates are qualified (I appreciate it doesn't always work). Yes, we could layer single transferable vote on top of an approval mechanism, but at that point I'm unclear if the incremental effect of STV is worthwhile relative to the additional effort in voting. isaacl (talk) 14:49, 1 September 2021 (UTC)

• STV is a popular method for electing proportional representation. Changing to STV means moving to a system where minority groups achieve representation on the committee. This means factionalism on the committee. Under approval voting, it is natural that the committee elected will align with community consensus. Encouraging factions is contrary to the principle of consensus. Representation of all viewpoints is sufficiently achieved with the standard practice of ArbCom inviting case opinions from any interested Wikipedian. --SmokeyJoe (talk) 12:03, 1 September 2021 (UTC)

  STV is not the best voting system, because you need to decide what sort of candidates are to be elected, before deciding criteria for “best”. Proportional voting (for which STV is good) is good for a body that is desired to reflect the electorate. That, is arguably wanted for governance bodies. ArbCom is not a governance body. We want them to resolve hard people problems, and to work together collaboratively, with respect for consensus. Minority factions and deal making, we do not want. Eg. “You take a hard line on this unblockable, and I’ll take a hard line on that unblockable”. No, we want them to work together, and to value precedent, consistency, predictability. Like a high court. No one wants a high court elected by proportional voting.

  The criteria for electing ArbCom members, is and should be, each individual is reviewed and approved by the community. That calls for approval voting. SmokeyJoe (talk) 07:14, 5 September 2021 (UTC)

• To address concerns above, could STV could have an "empty seat" option, below which we could rank any candidates considered unsuitable? I don't know whether the software supports this, or if a dummy User:Empty seat would need to stand. A variant is to treat candidates with no number as ranked below Mr. E. Seat, but that risks losing votes for candidates who, although unnumbered because not outstanding, are all equally decent. Certes (talk) 13:22, 1 September 2021 (UTC)
• Regarding your vote not being transferred to someone you didn't rank: part of the advantage of STV is that you can rank candidates who you don't support, to indicate your relative preference between them. Thus ranking a candidate isn't necessarily an indication that you support the candidate, or feel they are qualified. isaacl (talk) 14:56, 1 September 2021 (UTC)
  • Not sure where you get that idea; the current STV system being used for the Board elections will keep dropping your vote down to all ranked candidates as necessary. If you don't support a candidate, the only choice you have with the SecurePoll STV is to *not* rank them at all. Risker (talk) 22:23, 1 September 2021 (UTC)

    Sure, I didn't say anything to contradict the first sentence. What I'm saying is that you can still rank candidates you don't support, as you recognize that their support levels may be high with other voters, and so you still want to influence which candidate may get selected in that case. isaacl (talk) 00:25, 2 September 2021 (UTC)

• I've been dissatisfied with the change of the system, for years. Thus, my reason for no longer voting in Arbcom elections. GoodDay (talk) 18:34, 1 September 2021 (UTC)
• Question we need an answer to: The logistics of implementing STV can be complicated, and there is experience (albeit from NYC School Board elections years ago) that the complexity increases in proportion to the number of candidates and the number of seats to be filled. Can anyone with WMF SecurePoll technical knowledge confirm whether the software would currently and reliably support (for example) an election in which 20 candidates are running for 8 seats? Newyorkbrad (talk) 15:41, 2 September 2021 (UTC)

  @Newyorkbrad: I created testwiki:Special:SecurePoll/vote/933 in STV mode with over 20 options for 8 seats. I don't think this necessarily fixes the mechanics problems related to ensuring that a voter may ignore evaluating any specific candidate (i.e. that a "skip" is not a "objection") and that it will ensure that each candidate has a direct (untransfered counts) majority support. — xaosflux ^Talk 15:58, 2 September 2021 (UTC)

   Administrator note voting in that poll will reveal a portion of your checkuser data on testwiki to electionadmins. — xaosflux ^Talk 16:02, 2 September 2021 (UTC)

  You can LOOK at it without saving your vote, and that won't reveal your info though. — xaosflux ^Talk 10:44, 3 September 2021 (UTC)

  I don’t think technical complexity is the bigger problem. I think the explosion of candidates that STV attracts, which makes for ballot complexity for the voter, is the bigger problem. STV for n seats means that a quota for election is 1/(n+1) + 1, which is small for large n. Candidates no longer have to think they will get a majority, just a quota, and so many more think they can do it, and so they run. SmokeyJoe (talk) 13:14, 3 September 2021 (UTC)

• The main problem with STV is that it allows the election of hated or terrifying candidates who have the support of a small (often about 10%, or even less) devoted minority. This (usually) doesn't matter much if they are being elected to a Parliament where they will then find themselves in toothless opposition, but ARBCOM is more like a Cabinet or Supreme Court than a Parliament and those elected automatically acquire various powers as mentioned by Xaosflux above. In theory I might not have a problem if we used the existing system to find out which candidates had, for instance, 60% approval, and then used STV to choose between those approved candidates (assuming there were more of them than there were seats to be filled). But I'm not sure that the benefits (if any) of such a change are worth the hassle of trying to make the change, and the increased complexity of the resulting system, and the risk of unforeseen and unintended consequences.Tlhslobus (talk) 15:43, 3 September 2021 (UTC)
• difficult to set up We do not have technology at hand available for the community to set up this system. I prefer to use this but not sure if it is a technical option. Blue Rasberry (talk) 16:21, 12 September 2021 (UTC)
• Note STV as implemented for the trustee board election (Meek's method with Droop quota) starts with a quota of 1/(N+1), meaning for the current 8-seat election, a candidate is elected with just over 1/9 of the total votes. (The quota gets revised downwards with each iterative round to remove exhausted ballots and leftover excess votes after transfers are completed, so that percentage gets smaller and smaller.) This would be a radical change from the current threshold with approval voting. isaacl (talk) 15:16, 14 September 2021 (UTC)

---

Voting system - STV (alternative)

Based on the comments above, I'm proposing using the STV system but with the caveat that all candidates must meet the quota after (re)distribution of votes, ensuring that seats are not filled if there are not enough candidates meeting the quota. The procedure would differ from the original proposal by changing the last step to read

6. If any candidate exceeds the quota after these votes are transferred then they are elected, and the process repeats until no more candidates meet the quota

Since voters can choose not to give preference to candidates they oppose, candidates who receive less preference votes won't be seated even if there are still seats to fill. Regards SoWhy 13:38, 1 September 2021 (UTC)

Support (Voting system - STV (alternative))

1. Support per above. Regards SoWhy 13:38, 1 September 2021 (UTC)

Oppose (Voting system - STV (alternative))

1. Let's not have proposed changes that require new technical development; we tried that last year with candidate ordering, and it didn't work out. * Pppery * _{it has begun...} 13:43, 1 September 2021 (UTC)
2. Mostly for the same reasons as in the other section. Goes on the premise that seats should be filled regardless of the individual support of a candidate; we have a maximum number of seats that may be filled, not a minimum number of seats that must be filled. — xaosflux ^Talk 17:49, 1 September 2021 (UTC)
3. Per Xaosflux and my comments above. I'm not convinced that the current system is broken, let alone that something this complicated is an improvement. Thryduulf (talk) 21:06, 1 September 2021 (UTC)
4. I am all for STV, but this proposal doesn't make sense at all! Please don't change the established rules of STV on the fly. In a STV poll, if you want to fill n seats, exactly n candidates surpass the quota (which its value depends on the seats) and k-n candidates don't make it, where k is the total number of candidates. 4nn1l2 (talk) 00:35, 2 September 2021 (UTC)
5. Does not solve the things that I dislike about STV.  Mysterymanblue  17:17, 2 September 2021 (UTC)
6. As above, this still unhelpfully cuts S/N/O down to S/(N/O). Retswerb (talk) 07:31, 3 September 2021 (UTC)
7. No. STV is a bad idea, it would turn the committee into a politicised factionalised body. Proportional representation means minority representation, which means elected arbs not approved by the majority of the community. ArbCom is not a governance body, and should not be politicised. Approval voting, S/N/O voting is good for this body. —SmokeyJoe (talk) 13:19, 3 September 2021 (UTC)
8. Strongly Oppose If there are 9 seats the quota is 10% of votes + 1, so a terrifying candidate will get elected if he/she has a devoted following of just over 10% and there's nothing the remaining 90% can do to stop this. Tlhslobus (talk) 15:18, 3 September 2021 (UTC)
9. Per above, please don't change the established rules of STV on the fly. Additionally, this would need more additional technical work to be done. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:03, 4 September 2021 (UTC)
10. This could be a good compromise approach but I oppose for this election per the technical issues Pppery raised and hence my comments above. Callanecc (talk • contribs • logs) 06:27, 5 September 2021 (UTC)
11. This doesn't address any of my concerns with STV. User:力 (power~enwiki, π, ν) 03:06, 6 September 2021 (UTC)
12. That doesn't work. Stifle (talk) 15:42, 7 September 2021 (UTC)
13. Izno (talk) 05:18, 14 September 2021 (UTC)
14. Oppose. I oppose this alternative for the same reasons I oppose the original version. --Tryptofish (talk) 19:52, 19 September 2021 (UTC)

Comments (Voting system - STV (alternative))

• Still seems to have a problem - this seems to negate the ability to abstain from evaluating any specific candidate (as a lack of support is assuming an active opposition). Am I missing something here? — xaosflux ^Talk 13:51, 1 September 2021 (UTC)

  Not indicating a preference is both an opposition and a neutral as far as I understand it. In STV, you are either in favor of a candidate (at any place) or you are not. If you are not, regardless of whether you oppose them or genuinely have no preference, the candidate will not receive any votes from you. The end result should be comparable to the current S/O/N system since currently neutral votes are simply ignored. Regards SoWhy 14:44, 1 September 2021 (UTC)

  "not being in support" is not the same as skipping. Skipping someone shouldn't be seen as a vote of no confidence in that person. — xaosflux ^Talk 14:46, 1 September 2021 (UTC)

  It isn't. But if you vote "neutral" in the current system or indicate no preference in STV will lead to the same outcome, i.e. this candidate not getting a vote from you. On the other hand, STV allows you to simply give those candidates you wouldn't mind to win the lower preferences to raise them above those you oppose (and give no preference). Under the current system, you have to support or oppose someone without the nuance of a "weak support" which a lower preference gives you. Regards SoWhy 15:22, 1 September 2021 (UTC)

  The problem is that under STV you can't express active opposition to a candidate. The ability to do so is a vital safeguard of our current voting system, and it enables the majority to block hated and terrifying candidates who have the support of a devoted minority and who would thus get elected under STV. Tlhslobus (talk) 15:03, 3 September 2021 (UTC)

  You can still express your relative preference between candidates you don't personally support. This is one of the advantages of STV. isaacl (talk) 15:09, 1 September 2021 (UTC)

  If somebody can come up with a system that allows one to express degrees of support AND of opposition, AND that tends to prevent the election of terrifying candidates supported by a devoted minority, I'd consider supporting it. But STV is not such a system (in fact it's almost the exact opposite of such a system). Tlhslobus (talk) 15:11, 3 September 2021 (UTC)

  Yes, as I said in my oppose statement, I believe approval voting is a better fit for the community to express its views on the qualifications of the candidate. (STV isn't a magic pass for polarizing candidates, as the majority can impose its views by ranking its preferred candidates higher. But there does need to be enough non-polarizing candidates, and the majority needs to assiduously record its full rankings, and not just stop after a few choices.) isaacl (talk) 20:19, 3 September 2021 (UTC)

• The amendment isn't meaningful; STV doesn't fill a seat unless a candidate has met the quota after all redistributions are done (with Meek's method, the quota is a slightly adjusted version of Droop's quota, which is the minimum number of votes you need to guarantee you finish in the top N places, where N is the number seats to be filled). isaacl (talk) 15:07, 1 September 2021 (UTC)

  @Isaacl: Correct me if I'm wrong but from all I have read about STV, usually the last seats will be filled by the last candidates left standing, irregardless of whether they reach the quota, on the basis that if there is only one seat left to fill and one candidate, that candidate gets the seat. At least that is what our articles at single transferable vote#Example and Comparison of the Hare and Droop quotas#Scenario 1 say. The amendment proposes to not fill the seat in this case. Regards SoWhy 15:19, 1 September 2021 (UTC)

  From what I understand of Meek's method [1], it always eliminates the hopeful candidate with the fewest votes if there are fewer candidates meeting quota than seats to be filled. (I don't know what the SecurePoll implementation does, though). isaacl (talk) 15:45, 1 September 2021 (UTC)

• Change it back to when one didn't have to jump through hoops, to vote. GoodDay (talk) 18:35, 1 September 2021 (UTC)

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

---

User guides confined to a category

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

---

Voting guides or guides to candidates will be placed in a dedicated category that will be linked to from the ACE banner, but they shall not be individually listed on the template.

Option 1 (User guides confined to a category)

1. Listing guides individually on the banner gives them too much prominence. They serve a useful purpose, and so centralizing them is helpful; but our status quo gives them too much of a soapbox. I'm not saying anyone making a guide is doing so for the purpose of soapboxing, but there's few other circumstances where editors can air greivances against other editors, with no right of response, in such a prominent way. Vanamonde (Talk) 10:29, 1 September 2021 (UTC)
2. * Pppery * _{it has begun...} 13:26, 1 September 2021 (UTC)
3. The guides are nonsense. If you can't decide independently, you shouldn't vote at all. Wikipedia is not a place for herd mentality. 4nn1l2 (talk) 00:42, 2 September 2021 (UTC)
4. I actually like reading over the guides. It's interesting to read other editor's perspectives. I'd like to see more of them happen. That said, I think template placement is less-than-neutral (read that as "adds bias") for something like this, and I think this (category placement) would be a better way to go. - jc37 04:32, 6 September 2021 (UTC)
5. User guides are a bit of a nonsense anyway. Stifle (talk) 15:42, 7 September 2021 (UTC)
6. Per my comments last year. --Izno (talk) 05:24, 14 September 2021 (UTC)

Option 2 (User guides listed in ACE template)

1. I fail to see why guides being prominent is a bad thing. It is ultimately up to the voter whether to read a guide or not, to agree with it or not, or to cast an informed vote or not. Having a variety of opinions easily accessible seems, at least to me, to be a very desirable thing. Having them in a category isn't really a hindrance, but it is unnecessary to reduce their visibility.
   5225_C (talk • contributions) 12:29, 1 September 2021 (UTC)
2. Forcing voters looking for the guides through a category when the template is right there seems like an unnecessary complication and a solution in search of a problem. Regards SoWhy 13:40, 1 September 2021 (UTC)
3. Per both of the above. Gog the Mild (talk) 15:49, 1 September 2021 (UTC)
4. Per all three above. Happy days ~ Lindsay^Hello 16:00, 1 September 2021 (UTC)
5. I'm fine with this, no objections to them also being in a category. — xaosflux ^Talk 17:50, 1 September 2021 (UTC)
6. If it ain't broke don't fix it. --Rschen7754 18:03, 1 September 2021 (UTC)
7. While every year we see guides that are decidedly unhelpful, I think a lot of users find them a valuable resource and I see no benefit to trying to hide them in this manner Beeblebrox (talk) 21:27, 1 September 2021 (UTC)
8. I don't see anything wrong with guides, and even if I did, I'm not sure what problem listing them in a category vs listing them in a template is supposed to solve. ~Swarm~ ^{sting} 09:05, 2 September 2021 (UTC)
9. Guides give a foothold into the process for those who are not as familiar with ArbCom or with in-depth checking of other users, and should remain prominent. If the issue of unhelpful or soapboxing guides needs to be addressed, there should be a proposal to address that problem directly. ‑‑ElHef (Meep?) 15:38, 2 September 2021 (UTC)
10. I don't see why we should change this, it has worked well in previous elections. 02:52, 3 September 2021 (UTC) TOA The owner of all ☑️
11. Per SoWhy and ElHef. Retswerb (talk) 07:33, 3 September 2021 (UTC)
12. Per all of the above (and also in opposition to at least some of the opposed arguments, such as the claim that the guides are nonsense, that reading them is undesirable herd mentality, and so on). Tlhslobus (talk) 16:34, 3 September 2021 (UTC)
13. Per those above. Johnbod (talk) 16:46, 3 September 2021 (UTC)
14. Keep things as they are, there's no need to add an extra click when it's unnecessary. There's already a link to the category as well in the description, for anyone who wants to use that method. That said, if we *also* want to link the "Voter Guides" header to the category, that might be useful too: {{ACE2020}} --Elonka 22:57, 3 September 2021 (UTC)
15. Guides are helpful. They should be easy to find. Paul August ☎ 23:18, 3 September 2021 (UTC)
16. Guides having prominence is a good thing IMO, as it helps people learn more about candidates. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:04, 4 September 2021 (UTC)
17. This is the proven way to make them most accessible. I want people to know these exist. Blue Rasberry (talk) 16:21, 12 September 2021 (UTC)
18. Guides are helpful further there for example there 17 guides last year 2020 and 20 guides in 2019 which give a diverse opinion about various candidates.Pharaoh of the Wizards (talk) 16:19, 13 September 2021 (UTC)
19. Per others – SD0001 (talk) 16:54, 15 September 2021 (UTC)
20. Guides are on the whole useful. I don't see any benefit to hiding them behind another click. the wub "?!" 17:24, 18 September 2021 (UTC)
21. Keep them in the template, and not just a category. There's no need to make them harder to find. If any or all of them are of no use to someone, then just don't read them. --Tryptofish (talk) 19:54, 19 September 2021 (UTC)
22. Oppose solving a non-problem. Elli (talk | contribs) 04:37, 22 September 2021 (UTC)

Comments (User guides confined to a category)

• As long as it is easy enough to navigate to the guides, it doesn't really matter. I don't understand why navigation to guides to guides is forbidden. The value of a guide to me is in the logic of what it says, and the respect with which I have for its author. --SmokeyJoe (talk) 12:05, 1 September 2021 (UTC)
• I asked this question a couple of years ago, but I still do not understand what is a difference between a user guides and comments on the candidates. And if there is no difference, I do not see why user guides get a special treatment.--Ymblanter (talk) 18:07, 1 September 2021 (UTC)

  A lot of the guides use tables and things like that which would not be appropriate for a comment section. Some of them are also set up to compare and contrast candidates answers to one specific question, something not really possible on the comments page. I have mixed feelings about them myself but it seems clear some users do value them. Beeblebrox (talk) 21:58, 1 September 2021 (UTC)

  Yes, but also many guides do not evaluate all candidates, only a subset, and sometimes even say "I do not have time to look at the candidates". This could have been just one or two talk page comments, but calling this a user guide such comments get more prominence.--Ymblanter (talk) 05:35, 2 September 2021 (UTC)

  True, some of them are very half-assed. Beeblebrox (talk) 20:57, 8 September 2021 (UTC)

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

---

Guides written by candidates

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

---

A candidate who writes a guide must declare in the guide that they are a candidate. Thryduulf (talk) 22:24, 1 September 2021 (UTC)

Support (Guides written by candidates)

1. As a matter of transparency. Thryduulf (talk) 22:24, 1 September 2021 (UTC)
2. Sure. — xaosflux ^Talk 23:21, 1 September 2021 (UTC)
3. Yes. And be categorised separately. While no guide should ever be taken as "impartial", a candidate written guide is a candidate statement, assumed to be in support of their candidature. --SmokeyJoe (talk) 00:45, 2 September 2021 (UTC)

   I struggle to imagine reading support for User:X in "User:X's Voter Guide" and forgetting that it's X writing in support of their own candidature, but maybe it would be more forgettable when reading X's remarks on the other candidates, especially if X comments only on the others. —2d37 (talk) 04:47, 2 September 2021 (UTC)

   I don't think candidates who do these kinds of guides always rate themselves. –MJL ‐Talk‐^☖ 01:55, 5 September 2021 (UTC)

4. * Pppery * _{it has begun...} 00:47, 2 September 2021 (UTC)
5. Ok, now this one is a no brainer... --pandakekok9 (talk) 02:22, 2 September 2021 (UTC)
6. Support, with two suggestions: (1) that the rule include a reminder to assume good faith if a candidate neglects to make the disclosure and (2) that the rule specify that anyone may add the disclosure (in case the candidate neglects it and then becomes unavailable). —2d37 (talk) 04:35, 2 September 2021 (UTC)

   Looking at the close of WP:ACERFC2020, I guess my suggestion (2) is covered well enough by the existing rule that the electoral commissioners can: [...] Add official commentary to guides. Indeed, maybe it's better limited to commissioners. —2d37 (talk) 07:20, 2 September 2021 (UTC)

7. Such guides should be banned entirely, but better than nothing. --Rschen7754 04:38, 2 September 2021 (UTC)
8. For the sake of transparency. Dreamy Jazz ^{talk to me | my contributions} 08:07, 2 September 2021 (UTC)
9. 100% appropriate and in the spirit of our baseline standards of conduct such as WP:GAME. ~Swarm~ ^{sting} 09:07, 2 September 2021 (UTC)
10. Should be obvious, if you're a serious candidate, but sure. Vanamonde (Talk) 10:02, 2 September 2021 (UTC)
11. Gog the Mild (talk) 12:54, 2 September 2021 (UTC)
12. NW1223_{(Howl at me|My hunts)} 14:08, 2 September 2021 (UTC)
13. Seems reasonable. ‑‑ElHef (Meep?) 15:40, 2 September 2021 (UTC)
14. Not looked into deeply but seems reasonable. Djm-leighpark (talk) 17:30, 2 September 2021 (UTC)
15. As a matter of transparency, this does seem reasonable. --TheSandDoctor ^Talk 17:52, 2 September 2021 (UTC)
16. —pythoncoder (talk | contribs) 18:53, 2 September 2021 (UTC)
17. I find it extremely distasteful for a candidate to even write a guide and I think any candidate who does so probably has a low chance of succeeding, and if they do get in... awkward... but in any event, yes, they should have to declare as much prominently in their guide. Beeblebrox (talk) 19:24, 2 September 2021 (UTC)
18. Seems reasonableParadise Chronicle (talk) 23:08, 2 September 2021 (UTC)
19. Definitely. Retswerb (talk) 07:35, 3 September 2021 (UTC)
20. Yes, absolutely. Anyone who did not do so, would instantly get an "oppose" from me. --Elonka 22:59, 3 September 2021 (UTC)
21. Yes, of course. Paul August ☎ 23:20, 3 September 2021 (UTC)
22. Completely makes sense. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:04, 4 September 2021 (UTC)
23. I still think we should ban these kinds of guides, but I'll have to settle for this I guess. –MJL ‐Talk‐^☖ 01:52, 5 September 2021 (UTC)
24. And that disclosure must be made very clear at the top of the guide. Callanecc (talk • contribs • logs) 06:28, 5 September 2021 (UTC)
25. Sure. Gråbergs Gråa Sång (talk) 11:07, 6 September 2021 (UTC)
26. I mean, it's not hard to work out, but sure. Stifle (talk) 15:43, 7 September 2021 (UTC)
27. Sounds good. // Knifegames (talk) 07:12, 8 September 2021 (UTC)
28. Absolutely. –Gladamas (talk · contribs) 05:54, 9 September 2021 (UTC)
29. Blue Rasberry (talk) 16:24, 12 September 2021 (UTC)
30. Yes for transparency.Pharaoh of the Wizards (talk) 16:09, 13 September 2021 (UTC)
31. ~ Amory (u • t • c) 10:58, 14 September 2021 (UTC)
32. Seems a bit instruction-creepy, but sure. the wub "?!" 17:26, 18 September 2021 (UTC)
33. It seems i-creepy to me, too, and no big deal either way, but weak support. --Tryptofish (talk) 19:56, 19 September 2021 (UTC)

Oppose (Guides written by candidates)

1. Oppose mainly because somebody should play the Devil's advocate (it's currently 19-0 in support): If a candidate fails to make this disclosure, then it should be made by the Election Commissioners (and if they don't,anybody else can point it out, in many ways and places). That way we the voters get to ask the candidate why they omitted the info. And we may learn something important about the candidate from his/her reply, and from the omission itself (such as that he/she may be stupid or forgetful or careless or dishonest or whatever), which the proposed rule would prevent us from learning. Also in general it's a bad idea to compel people to say or do anything when such compulsion does not seem absolutely necessary. Also one could change the proposal to say disclosure is strongly recommended (in the interests of transparency, etc) rather than compulsory. Tlhslobus (talk) 17:11, 3 September 2021 (UTC)
2. Oppose as this is instruction creep and likely would never be a problem. Anyone who would seriously be in the running to be an Arb should have good judgement enough to disclose as such on their voter guide, and it would quickly be noticed if they hadn't. This is a "feel good" rule that it feels like we should have but... unless someone can point to a problem caused by the lack of this rule, I don't think we should add it. Elli (talk | contribs) 04:38, 22 September 2021 (UTC)

Comments (Guides written by candidates)

• This was proposed last year with not insignificant support, but did not pass due to interaction with other proposals. This is therefore presented independently of any proposals which seek to limit who may write guides (although there are none at the time of writing). Thryduulf (talk) 22:24, 1 September 2021 (UTC)
• I find it strange that some people think it outrageous that a candidate should produce a guide.This seems like saying that it is outrageous that a candidate in a (non-Wikipedia) election let the voters know to what party he belongs, and who are like-minded candidates and who are opponents. This is normally seen as info that voters need to know about.Tlhslobus (talk) 16:55, 3 September 2021 (UTC)
• Chaotic Neutral suggestion: Every candidate is required to write a Guide. Think you can hack it on ArbCom? OK: Start with an objective assessment of your fellow candidates, then make an honest self-evaluation and tell us how you think you stack up against them. Know that, win or lose, everything you write will be used against you in the future. [[File:Muahahahaha.gif]] -- FeRDNYC (talk) 02:52, 5 September 2021 (UTC)

  I would call that chaotic evil disguised as chaotic good. SmokeyJoe (talk) 07:24, 5 September 2021 (UTC)

• As ArbCom needs to work collectively, I think ArbCom candidates writing guides critiquing each other is a wholly bad idea. It would be capable of poisoning their future collegiality. I think I will auto oppose any candidate who write guides on all the candidates. It would ok for a candidate to criticise another candidate and unsuitable for election, but the understanding would be that both candidates would be then incapable of working together, in the way ArbCom is supposed to work. —SmokeyJoe (talk) 07:21, 5 September 2021 (UTC)

---

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

Voting start date

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

---

The election will open for voting at 00:00 UTC on a Tuesday. This is the de facto but not de jure status quo.
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) 22:24, 1 September 2021 (UTC)

Support (Voting start date)

1. As proposer; we should formalise this. Thryduulf (talk) 22:24, 1 September 2021 (UTC)

   I also support Xaosflux's generalisation. Thryduulf (talk) 23:44, 1 September 2021 (UTC)

2. Sure, but even more generally "the second business day" of the week in the event of a Monday Holiday in the future. — xaosflux ^Talk 23:22, 1 September 2021 (UTC)
3. Also would support Xaosflux's more general idea. * Pppery * _{it has begun...} 23:39, 1 September 2021 (UTC)
4. I support Xaosflux's proposal, but I feel it should be noted that what Mondays are holidays will differ by location — should the business day be specified as a business day in San Francisco? —2d37 (talk) 04:03, 2 September 2021 (UTC)
5. Support per Xaosflux. Gog the Mild (talk) 12:56, 2 September 2021 (UTC)
6. No complaints. NW1223_{(Howl at me|My hunts)} 14:09, 2 September 2021 (UTC)
7. It is now tradition. Good arguments against starting Sat/Sun/Mon 0000GMT, no arguments to change to some other time. User:力 (power~enwiki, π, ν) 17:21, 2 September 2021 (UTC)
8. Why not formalise this? Tol (talk | contribs) @ 17:33, 2 September 2021 (UTC)
9. Looks good lomrjyo ^{(✉ • 📝)} 01:03, 3 September 2021 (UTC)
10. Makes sense, let's learn from the past. Support per Xaosflux. Retswerb (talk) 07:37, 3 September 2021 (UTC)
11. Either, but prefer Xaosflux's generalisation. ProcrastinatingReader (talk) 10:39, 3 September 2021 (UTC)
12. Support either the original or xaosflux's proposal, but would also support expanding on that proposal to look at a holiday on the election end date (i.e. if the election ends on a date when the offices are closed, adjust the start and/or end dates accordingly). ‑‑ElHef (Meep?) 17:05, 3 September 2021 (UTC)

    @ElHef: not necessarily against that, but the primary thing this is trying to fix is a technical problem with the election. I've never seen a problem where staff was required on the "last day" for any reason. Yes they have to deal with the decryption, but if that is delayed a day it doesn't really change anything. — xaosflux ^Talk 22:01, 3 September 2021 (UTC)

13. Seems reasonable -- Asartea ^{Talk | Contribs} 09:07, 4 September 2021 (UTC)
14. Makes sense, would potentially help response times if something does go wrong. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:05, 4 September 2021 (UTC)
15. Yes and with Xasoflux's addition that it's the the second business day of the week (probably worth adding "in San Francisco" to the end of the addition). Callanecc (talk • contribs • logs) 06:31, 5 September 2021 (UTC)
16. Support with the generalisation presented by Xaosflux, also per 2d37, San Francisco should be noted JW 1961 ^Talk 21:43, 6 September 2021 (UTC)
17. Support xaosflux's wording, "the second business day of the week" –Gladamas (talk · contribs) 05:56, 9 September 2021 (UTC)
18. – Ammarpad (talk) 07:38, 12 September 2021 (UTC)
19. Might be helpful; certainly won't be harmful. Extraordinary Writ (talk) 06:02, 14 September 2021 (UTC)
20. Support with Xaosflux's generalisation to "second business day". Sensible, although ideally SecurePoll should be sufficiently supported that these issues don't occur. the wub "?!" 17:32, 18 September 2021 (UTC)
21. Fine with me, but I don't feel strongly about it. --Tryptofish (talk) 19:57, 19 September 2021 (UTC)

Oppose (Voting start date)

1. Seems to me that the problem here is not with the voting start time, but the SLA for support. Important events occur off-hours in systems support all the time, I don't see why this one is different. Rklahn (talk) 23:06, 6 September 2021 (UTC)
2. Arbitrary. Stifle (talk) 15:43, 7 September 2021 (UTC)

Comments (Voting start date)

• Mandated Tuesday election? Is this US-centric? --SmokeyJoe (talk) 00:49, 2 September 2021 (UTC)

  @SmokeyJoe: eh? The voting period will still run for two weeks, only the starting date will change (and even then this is just codifying what already happens). The only reason the US is relevant is that the only people who can resolve any technical issues are physically located on the west coast of the US, so it makes sense for the start date (the only time urgent action is at all likely to be required) be during US west coast office hours. Thryduulf (talk) 01:06, 2 September 2021 (UTC)

  • While I agree that having a consistent start date/day of week is entirely reasonable, and Tuesday is best because it means giving a weekend at the end of the voting period, I'll note that many of the people who actually resolve SecurePoll problems live far, far away from US West Coast (Australia and Europe). Nonetheless, they work mainly a Monday to Friday week, like the rest of the WMF staff. Therefore the point of ensuring experienced tech support (plus whoever the WMF liaison is for elections) is still valid, and they're not usually available on Friday nights. Risker (talk) 03:04, 2 September 2021 (UTC)
• In practice I imagine having a specified day won't be an impediment in dealing with unforeseen issues by the electoral commission. In theory, though, I wish that this detail could be left to the judgment of the commissioners. isaacl (talk) 23:21, 6 September 2021 (UTC)

  @Isaacl: "unforeseen issues" are still dealt with myby ElecCom, tech problems that only WMF staff can fix on the 1st day are known issues that have occurred twice in the last several years. — xaosflux ^Talk 10:30, 7 September 2021 (UTC)

  Yes, the point being that the starting day should be chosen based on operational concerns, with flexibility to handle anything else that might arise on the fly. Because this will, by necessity, happen anyway, I don't see a lot of benefit in making a community decision in September. Your ElecCom? isaacl (talk) 13:33, 7 September 2021 (UTC)

  This year's ElecCom hasn't been empaneled yet, I have never been on ElecCom. — xaosflux ^Talk 14:25, 7 September 2021 (UTC)

  Just wondering what this "my ElecCom" you spoke of was referring to? I realize now you probably meant "by"... isaacl (talk) 18:23, 7 September 2021 (UTC)

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

---

Notification of withdrawals before voting

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

---

Eligible voters should be notified if a candidate withdraws after the start of nominations but before the start of voting. Thryduulf (talk) 22:24, 1 September 2021 (UTC)

Support (Notification of withdrawals before voting)

1. Opt-in only, not to everyone. This would be useful to select people. –Gladamas (talk · contribs) 05:58, 9 September 2021 (UTC)

Oppose (Notification of withdrawals before voting)

1. The only real beneficiaries will be those people debating whether to stand, but if their candidacy is dependent on other people they should be watching the list of candidates anyway. For everyone else the notifications run the risk of being seen as spam, with the negative connotations and behaviours that would ensue. Thryduulf (talk) 22:24, 1 September 2021 (UTC)
2. Under the current system, eligible voters are notified for the first time when voting starts, so it's already assumed that the process of selecting the candidates is considered unimportant to them. * Pppery * _{it has begun...} 23:41, 1 September 2021 (UTC)
3. No way, esp as this is going to require tens of thousands of mass messages, possibly multiple rounds for multiple w/d's. Listing the w/ds on an ACE page is enough. — xaosflux ^Talk 23:55, 1 September 2021 (UTC)
4. So what? 4nn1l2 (talk) 00:44, 2 September 2021 (UTC)
5. Completely unnecessary. User:力 (power~enwiki, π, ν) 02:38, 2 September 2021 (UTC)
6. Gog the Mild (talk) 10:29, 2 September 2021 (UTC)
7. We have seen considerable pushback about any notifications; increasing the number is not a great idea. Vanamonde (Talk) 13:21, 2 September 2021 (UTC)
8. I don't see any value in this specific proposal. Beeblebrox (talk) 19:26, 2 September 2021 (UTC)
9. Oppose excessive notifications, unless strictly opt in. —SmokeyJoe (talk) 13:23, 3 September 2021 (UTC)
10. Would clutter talk pages too much, and are excessive. Listing them on a page is enough. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:06, 4 September 2021 (UTC)
11. I don't see that this achieves much. People can watchlist the various pages to keep track. Callanecc (talk • contribs • logs) 06:32, 5 September 2021 (UTC)
12. This would just clutter talk pages. NW1223_{(Howl at me|My hunts)} 16:16, 7 September 2021 (UTC)
13. We do not have a way to effectively communicate this. Blue Rasberry (talk) 16:25, 12 September 2021 (UTC)
14. Quite superfluous. If so desired, maybe an opt-in system may be implemented as above, but otherwise, probably not. Liamyangll (talk to me! | My contribs!) 23:11, 13 September 2021 (UTC)
15. Izno (talk) 05:26, 14 September 2021 (UTC)
16. Please no. Largely unnecessary but mainly because of the very poor voter experience it will engender. There are always a few, no need for mass pings. ~ Amory (u • t • c) 10:59, 14 September 2021 (UTC)
17. Can't see the need for this. If someone feels they need to know, it's easy enough to watchlist the candidates page. the wub "?!" 17:37, 18 September 2021 (UTC)
18. Oppose. I'm not seeing a problem that this would resolve. --Tryptofish (talk) 19:58, 19 September 2021 (UTC)
19. Oppose seems unnecessary. Elli (talk | contribs) 04:40, 22 September 2021 (UTC)

Comments (Notification of withdrawals before voting)

• I am proposing this because it came up at Wikipedia talk:Requests for comment/Arbitration Committee Elections December 2021#Should voters be notified if candidates w/d ?, and while I don't support this aspect I think it is a useful question to ask as part of the related set. Thryduulf (talk) 22:24, 1 September 2021 (UTC)

  @Thryduulf: can you clarify how you are proposing this to happen? If for example a notice will be posted on the candidates page, no big deal. If you want tens of thousands of mass messages sent - count me out!— xaosflux ^Talk 23:17, 1 September 2021 (UTC)

  I think mass messaging is probably the only way this could work that is relevant (I don't think posting a message on the candidates page is the sort of thing that needs discussion or consensus, just do it). That's one reason I don't support this. Thryduulf (talk) 23:34, 1 September 2021 (UTC)

---

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

Notification of withdrawals during voting

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

---

These are two sets of related proposals regarding whether, and if so who, should be notified if a candidate withdraws during the voting period. See Wikipedia talk:Requests for comment/Arbitration Committee Elections December 2021#Should voters be notified if candidates w/d ? for background.

Set A will determine who should be notified, Set B will determine when they should be notified. Set B will be moot if proposal A3 gains consensus, but the sets are otherwise independent. If A1 or A2 gain consensus but there is no consensus regarding specifics in B then the election commissioners will have discretion.

• Proposal A1: All eligible voters should be notified if a candidate withdraws during the voting period.
• Proposal A2: Those people who have already cast a vote should be notified if a candidate withdraws during the voting period.
• Proposal A3: Nobody should be notified if a candidate withdraws during the voting period (this is the status quo).

Support for A1 or A2 implies opposition to A3 and support for A3 implies opposition to A1 and A2, but you may also express explicit support or opposition if you choose. Thryduulf (talk) 22:24, 1 September 2021 (UTC)

• Proposal B1: Notifications should be made only after a period of time has elapsed (please specify what period if supporting this).
• Proposal B2: Notifications should be made only after a certain number of votes have been cast (please specify what period if supporting this).

Opposing B1 or B2 means only that there should be no time and/or number of votes requirements, i.e. notifications will be sent for any withdrawal after the voting opens. To oppose sending notifications at all, support proposal A3. If B1 and B2 both gain consensus, both requirements will apply. Thryduulf (talk) 22:24, 1 September 2021 (UTC)

Support (Notification of withdrawals during voting (A1))

1. Second choice to A2. Thryduulf (talk) 22:24, 1 September 2021 (UTC)

Oppose (Notification of withdrawals during voting (A1))

1. I fail to see how people who haven't voted could possibly care. * Pppery * _{it has begun...} 23:48, 1 September 2021 (UTC)
2. Not necessary, if you haven't voted you'll find out when you go to vote. Callanecc (talk • contribs • logs) 06:34, 5 September 2021 (UTC)

Support (Notification of withdrawals during voting (A2))

1. First choice over A1. I think the provides a useful element of information without spamming. Thryduulf (talk) 22:24, 1 September 2021 (UTC)
2. I was originally intending to support A3. However, after thinking about it more closely, the voting system used most likely fails the independence of irrelevant alternatives criterion, so these notifications do serve some purpose. * Pppery * _{it has begun...} 03:45, 2 September 2021 (UTC)
3. If the voters have already voted, I think it would be useful to them to see that a candidate they may have supported is no longer running for election. This may change their vote. Voters who have voted are also unlikely to see this withdrawal unless they put the relevant pages on their watchlist, as once you've voted why keep checking candidate statements? Dreamy Jazz ^{talk to me | my contributions} 08:13, 2 September 2021 (UTC)
4. This seems reasonable, we don't want a Mel Carnahan situation. Beeblebrox (talk) 19:29, 2 September 2021 (UTC)
5. Paradise Chronicle (talk) 23:14, 2 September 2021 (UTC)
6. Notifies users properly, but also doesn't spam talk pages too much. This makes sense to me. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:08, 4 September 2021 (UTC)
7. I guess so. Stifle (talk) 15:44, 7 September 2021 (UTC)
8. "A candidate you voted for has withdrawn" is the kind of thing a voter would want to be notified about. Levivich 14:53, 20 September 2021 (UTC)

Support (Notification of withdrawals during voting (A3))

1. Please don't make it unnecessarily complicated. 4nn1l2 (talk) 00:47, 2 September 2021 (UTC)
2. Simply due to the mass message (or watchlist notification, which in my view would be equivalent). If a person has withdrawn from the elections, it may due to personal reasons, and I don't believe this should be plastered everywhere. I would support a note on an election page, explaining, but since mass messaging is on the table, this whole suggestion is a non-starter for me. Worm^TT(talk) 08:17, 2 September 2021 (UTC)
3. Please don't send me more messages. That may even discourage me from voting at all. Gog the Mild (talk) 10:31, 2 September 2021 (UTC)
4. Too many messages. I didn't even bother change my vote after the withdrawal last year. I don't think most would, and those that do probably follow the election closely enough to know anyway. ProcrastinatingReader (talk) 13:01, 2 September 2021 (UTC)
5. Per Gog. Vanamonde (Talk) 13:22, 2 September 2021 (UTC)
6. Not necessary unless there's a fundamental change in the election process. If you're voting S-N-O for each candidate on their own merits as is intended, the withdrawal of a given candidate should not impact your other votes. If you're voting elsewise, that's on you. Also what WTT said. ‑‑ElHef (Meep?) 15:49, 2 September 2021 (UTC)
7. I support the way the commissioners handled this last year. We do not need to over think this. Best, Barkeep49 (talk) 21:38, 2 September 2021 (UTC)
8. Oppose any additional rounds of mass messages for this. It shouldn't impact anyone who already voted anyway, as the voters are being asked to evaluate each candidate separately. — xaosflux ^Talk 11:00, 4 September 2021 (UTC)
9. Oppose, as voters are already in theory ranking candidates separately, and we don't need more messages. Jackattack1597 (talk) 00:34, 5 September 2021 (UTC)
10. Support this option. Those who are familiar with ArbCom elections already understand that it's possible for a candidate to withdraw, and if they're prepared for that possibility then they'll vote or re-vote near the end of the voting period. Instead of multiple messages about a candidate withdrawing, a better idea would be to address that possibility in the first mass message that is sent (i.e. something like "It is possible that one or more candidates may withdraw. You may consider voting or re-voting near the end of the voting period so that your vote will account for any withdrawals that occur.") 05:04, 5 September 2021 (UTC) TOA The owner of all ☑️

    @The owner of all: the message to be sent is at Template:ACEMM - could you try out some improvements at Template:ACEMM/sandbox and leave a note at Template talk:ACEMM when done? Your idea sounds good, and won't need an RfC - but we should have the commission (once they are empaneled) review the final state before it is used. Thank you! — xaosflux ^Talk 20:45, 5 September 2021 (UTC)

11. I think the possibility of multiple messages dissuades me from telling users that a withdrawal has occurred. I wonder if there is a softer way of notifying people. --Izno (talk) 05:29, 14 September 2021 (UTC)
12. As above. ~ Amory (u • t • c) 11:00, 14 September 2021 (UTC)
13. Status quo, no need for a change. Voters who care enough will watch from time to time after they vote, without needing to be notified, and re-vote if they want to. Other voters will find notifications spammy and unhelpful. --Tryptofish (talk) 20:03, 19 September 2021 (UTC)
14. Per WTT and Gog. Elli (talk | contribs) 04:41, 22 September 2021 (UTC)

Oppose (Notification of withdrawals during voting (A3))

Comments (Notification of withdrawals during voting (Set A))

• I don't think the voting system fails independence of irrelevant alternatives. If voters are honestly filling out their ballots, then the fact that candidate X is supported or opposed is irrelevant to whether candidate Y is supported or opposed. The article itself says that approval and range voting meet that criterion. 04:58, 5 September 2021 (UTC) TOA The owner of all ☑️

  The actual article says: Approval voting [...] satisf[ies] the criterion if it is assumed that voters rate candidates individually and independently of knowing the available alternatives in the election, using their own absolute scale. This assumption implies that some voters having meaningful preferences in an election with only two alternatives will necessarily cast a vote which has little or no voting power, or necessarily abstain. In an election with thousands of votes, some voters will inevitably not do that, and in fact there was a proposal in last year's RfC about advising voters not to do that. * Pppery * _{it has begun...} 12:57, 5 September 2021 (UTC)

Support (Notification of withdrawals during voting (B1))

Oppose (Notification of withdrawals during voting (B1))

1. If notifications are sent they should always be sent imo. Thryduulf (talk) 22:24, 1 September 2021 (UTC)
2. If A1 passes, I may be convinced to support one of these, but A2 by itself limits who gets notified sufficiently. * Pppery * _{it has begun...} 23:48, 1 September 2021 (UTC)
3. If they're sent then they should be sent. Callanecc (talk • contribs • logs) 06:36, 5 September 2021 (UTC)

Support (Notification of withdrawals during voting (B2))

Oppose (Notification of withdrawals during voting (B2))

1. If notifications are sent they should always be sent imo. Thryduulf (talk) 22:24, 1 September 2021 (UTC)
2. If A1 passes, I may be convinced to support one of these, but A2 by itself limits who gets notified sufficiently. * Pppery * _{it has begun...} 23:48, 1 September 2021 (UTC)
3. If they're sent then they should always be sent. Callanecc (talk • contribs • logs) 06:37, 5 September 2021 (UTC)

Comments (Notification of withdrawals during voting (Set B))

Comments (Notification of withdrawals during voting (general)

• Same question as in preceding section - how is said notification expected to be sent? — xaosflux ^Talk 23:18, 1 September 2021 (UTC)

  There are three possible ways I can think of - (1) a message on a widely watchlisted page related to the election; (2a) mass message to everyone; (2b) mass message to people who have explicitly opted in or haven't opted out. I don't think (1) is the sort of thing that needs consensus for or against, so we're really discussing just (2). I don't think it unreasonable to mass message people who have already voted alerting them that circumstances have changed since they voted hence that is my first choice. If technically possible (I have no idea) and there is consensus to notify voters we should link the opt-in or opt-out list on completion of voting. Thryduulf (talk) 23:43, 1 September 2021 (UTC)

  In fact I think the removal/striking out of a candidate on/around the candidate pages is sufficient to fulfill item 1. Which would be a conundrum if people above considered (1) to be such a way of mass notification. ;) Izno (talk) 05:32, 14 September 2021 (UTC)

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

---

Commissioner reservist selections

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

---

Historically the selection of the fixed number of commissioners has used the "most endorsements collected" method (see last years's page). It has also been used to select a ranked list of commissioner reservists. The cutoff between reservist and non-reservist has been left to the discretion of the RfC closer. Should some specific cut off or method be used, for example "those within 20% of the 3rd ranked commissions" or should this continue to be discretionary? — xaosflux ^Talk 00:19, 2 September 2021 (UTC)

Option A (Closer discretion of reservist cutoff)

1. Not important. 4nn1l2 (talk) 00:50, 2 September 2021 (UTC)
2. I likewise don't see the purpose of doing this. * Pppery * _{it has begun...} 03:45, 2 September 2021 (UTC)
3. Per above. ProcrastinatingReader (talk) 12:58, 2 September 2021 (UTC)
4. Leave to closer's discretion. If the closer believes that everyone has consensus (based on the number of endorsements in comparison with other candidates) then pick the top three and rank the rest as reserves. If we're worried about the closer not applying their discretion fairly then we can always mandate that it is closed by more than one 'crat. They are elected for this purpose (albeit at RfA). I actually love that this is one of the few places on Wikipedia where we don't encourage conflict (yes/no) but rather make judgements based on how much support someone has. I really strongly hope that we don't change that! Callanecc (talk • contribs • logs) 06:47, 5 September 2021 (UTC)
5. It's not like the success of the election depends upon having an exact number of people in the role. --Tryptofish (talk) 20:06, 19 September 2021 (UTC)
6. per everyone above. Thryduulf (talk) 13:31, 22 September 2021 (UTC)

Option B (Specified method for reservist cutoff)

If selecting this option, please include some details

1. Ironically, I think Xaosflux's closure of the commissioner election last year is a good example of why it is nonsensical to allow the closer to arbitrarily rule on reservists even though there are no set standards. There were six candidates. Three were appointed, one was appointed as a reservist. The other two had unanimous support and were not appointed as reservists for some inexplicable reason. I do not propose anything radical here, but candidates with unanimous support consensus should be presumed to be appointed by the community as reservists. If applicable, the top three "runner-up" candidates who received unanimous consent from the community should be appointed as reservists without being subjected to arbitrary prejudice from the closer. ~Swarm~ ^{sting} 09:30, 2 September 2021 (UTC)

   @Swarm: I opened this as follow up from that last year! Commissioners always get "unanimous support" really though, since we have only collected "endorsements" - but we certainly could collect "objections" as well, which would be simple enough and let this be closed along more traditional consensus lines. I don't think someone with for example only 1 endorsement ("unanimous support!" would suffice though) — xaosflux ^Talk 10:47, 2 September 2021 (UTC)

   That's true. We don't want users with only one endorsement just because they're "unanimous", and on the other hand we don't want users stonewalled by a single objection even though they have a high level of support. I agree with your suggestion that we simply collect endorsements and objections and assess consensus in the traditional way, and assign the three reservist seats according to the strength of consensus. ~Swarm~ ^{sting} 05:55, 3 September 2021 (UTC)

2. Agree with Swarm. Gog the Mild (talk) 10:34, 2 September 2021 (UTC)
3. I think the best fix for this is to collect "objections" as well as "endorsements", then more traditional consensus-based closing guidelines can be used, without needing to specify any specific percent at this time. Fine with there being "up to three" ranked reservists, but if consensus is not met it could be less. — xaosflux ^Talk 10:55, 2 September 2021 (UTC)
4. There are occasionally trolls or socks that run for these positions; they generally get negligible support. Perhaps having an explicit "oppose" section would help, but alternatively a written "minimum 15 supports" rule might be sufficient here. User:力 (power~enwiki, π, ν) 03:32, 3 September 2021 (UTC)
5. Any of the above is fine with me. Probably something along Power's line per Vanamonde. --Izno (talk) 05:34, 14 September 2021 (UTC)
6. The current method of voting for commisioners is rather unique, and having objections would be a good idea, to make a consensus-based decision on reservists easier.Jackattack1597 (talk) 01:22, 1 October 2021 (UTC)

Comments (Commissioner reservist selections)

• Well, I agree with Xaosflux that having a yes/no vote is a good idea, but I don't see much of a problem with just collecting endorsements. Tol (talk | contribs) @ 17:59, 2 September 2021 (UTC)

  @Tol: the problem with only collection endorsements is that everyone has "100% support", even if you only only have 1 endorsement - so should anyone that volunteers automatically be a reserve commissioner? I don't think so, and as the RfC closer last year I king of pulled a solution out of the air that I thought was good enough - but was hoping to have a little more community guidance on that facet going forward. — xaosflux ^Talk 18:33, 2 September 2021 (UTC)

• I would much rather trust the closer's judgement than make it a numbers game that incentivizes people to come and dump on the candidate. I don't have a problem with using numerical thresholds of support, but we do not need a repeat of WP:CUOS2018. Vanamonde (Talk) 06:36, 3 September 2021 (UTC)
  • +1 — Wug·a·po·des​ 23:42, 7 September 2021 (UTC)
• Are we going to have an election to elect the closers of the commissioner reservist election too? Stifle (talk) 15:45, 7 September 2021 (UTC)

  That is done by the closing commission, which is selected by a series of turtles. — xaosflux ^Talk 23:46, 7 September 2021 (UTC)

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

---

Consensus Required for ACE RfC

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

---

Note: This was asked last year, and my close of it was met with some challenges. I am asking it again to gain a clearer sense of the consensus, or lack of it, for this particular proposal.

At least 15 editors need to support any statement at the Arbitration Committee Election Request for Comment for it to be closed with consensus. If fewer editors support a statement it will be closed as no consensus and the status quo will remain.

Support (Consensus Required for ACE RfC)

This support section has two subsections. Please only pick one when supporting

Implement this immediately

Should this proposal take effect starting with this RfC?

1. With at least 6 participants, not 15. I wouldn't want someone thinking consensus has been reached if only 3 people have participated. –Gladamas (talk · contribs) 06:03, 9 September 2021 (UTC)

Implement starting next year

Should this proposal take effect with the next RfC?

1. ArbCom elections are the single most participatory event we have on Wikipedia. ACERFC is also tremendously powerful. It has the ability to change how many seats there are on arbcom. It has the ability to change who can vote in the elections. I like this about ACERFC but having an elite with uncheckered power is, I think, contrary to our overall project ethos. The idea that say 1% of the total electorate should be required before we change fundamental things about ArbCom doesn't strike me as ridiculous or absurd. Further, at the moment we have no safeguards against a late proposal that wouldn't normally have consensus with more eyes passing in a low participation subset of a relatively low participation discussion (with massive impact). I admit that this is a low probability idea but it is high impact. So on both consensus basis and safeguarding basis I think we should do this. If I had been proposing the idea this year I wouldn't have proposed it exactly this way but I do believe this is a reform with doing. Best, Barkeep49 (talk) 21:36, 2 September 2021 (UTC)
2. I think I agree with Barkeep here about the power of this RFC for setting the community objectives for the election. Asking for a small quorum of support is not such a hard thing and demonstrates enough people care about the issue and that consensus may have changed (from whatever). --Izno (talk) 05:42, 14 September 2021 (UTC)
3. A quorum is necessary for there to be true global consensus. Levivich 14:51, 20 September 2021 (UTC)

Oppose (Consensus Required for ACE RfC)

1. Nah, standard consensus rules can apply - if something is running at 13-0 for example, some people might not bother "piling on" just to meet this arbitrary number. Also "vote counting" is not the best way to determine consensus. — xaosflux ^Talk 17:53, 2 September 2021 (UTC)
2. Per Xaosflux. Tol (talk | contribs) @ 18:01, 2 September 2021 (UTC)
3. Is there any actual problem that this proposal is solving? * Pppery * _{it has begun...} 18:20, 1 September 2020 (UTC) * Pppery * _{it has begun...} 18:17, 2 September 2021 (UTC)
4. per all the above. Beeblebrox (talk) 19:31, 2 September 2021 (UTC)
5. contra the above. In a vacuum, I support the idea of a participation requirement. However, this is an "unwritten rule" already, one of several governing how "consensus" is determined in this type of RFC. I think it would be harmful to make this alone a written rule. User:力 (power~enwiki, π, ν) 22:07, 2 September 2021 (UTC)
6. Closers are capable of determining whether the correct level of consensus for a given change has been achieved. If a closer screws up, I suppose it could be appealed at AN in the usual manner, but they usually don't screw up presumably. ACERFC is already one of the most rigorous consensus/drafting processes around; if only we expended this much energy into drafting our PAGs. ProcrastinatingReader (talk) 22:11, 2 September 2021 (UTC)
7. The issue that this is seeking to deal with, namely a major and possibly controversial change being enacted based on the consensus of very few commenters, is already solved: RFC closers can, should and (in my experience) do take into consideration the amount of participation (absolute and relative to other proposals), the length of time available for for participation, and the scale and nature of the change proposed. A proposal for a major change that has been open a full month, has 15 supports (some weak), and 5 opposes (most strong, most not answered) compared to other proposals open about the same time that have attracted over 50 comments each likely does not have consensus. In contrast a proposal for a minor change that has gained 14 supports (many strong) and no opposition despite being opened only a week before the end of the month almost certainly does have consensus. Another point is that it doesn't account for proposals where there is no status quo or it is not clear what the status quo is (there were examples of both last year). Also, what Xaosflux and ProcrastinatingReader said. Thryduulf (talk) 01:04, 3 September 2021 (UTC)
8. Oppose, per all of the above. Tlhslobus (talk) 16:25, 3 September 2021 (UTC)
9. This process is bureaucratic enough without needing consensus about consensus. Per Thryduulf, closers are capable of making this determination more sensibly than any blanket rule could. ‑‑ElHef (Meep?) 17:15, 3 September 2021 (UTC)
10. Per all of the above. Vote counting is not a measure of consensus. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:09, 4 September 2021 (UTC)
11. Consensus is fine. If we're worried about a closer not being able to use their best judgement to determine consensus then we can do something about that (make them 'crats?) but a numbers game isn't the way to do it. Callanecc (talk • contribs • logs) 06:49, 5 September 2021 (UTC)
12. Oppose per my comment on the talk and my comment last year. That said, I appreciate the proposal for its role in the dialectic. Even in opposition, the community has clarified for the closer what principles we believe the limits to be on their discretion. In my opinion, being able to point to the community sense of how a closer should interpret the discussion and !vote tally will be much more helpful in a future dispute over the close than any numeric threshold. — Wug·a·po·des​ 23:40, 7 September 2021 (UTC)
13. Solution looking for a problem. Stifle (talk) 08:27, 10 September 2021 (UTC)
14. Piling on this one, per xaosflux. A number of votes doesn't necessarily indicate consensus, nor is unanimity. Consensus is something most of the participants can agree on, and that something that is agreed upon could be an option not presented explicitly before closure. --pandakekok9 (talk) 12:43, 10 September 2021 (UTC)
15. – Ammarpad (talk) 07:40, 12 September 2021 (UTC)
16. I think this can rely on discretion instead of a rigid number: I see little difference between 14 and 16. (Well, actually, the difference is two.) --Tryptofish (talk) 20:10, 19 September 2021 (UTC)
17. Of course a consensus is required, but I don't think any specific quorum is needed. Closers should be allowed discretion: a high-impact proposal should obviously have more support than a proposal that is low-impact or extremely obvious. --rchard2scout (talk) 07:59, 28 September 2021 (UTC)

Comments (Consensus Required for ACE RfC)

• Is this consensus required, or is it quorum required? User:力 (power~enwiki, π, ν) 17:33, 2 September 2021 (UTC)

  力, It's definitely an interesting dilemma isn't it. If it's got 13 supports and 0 opposes, and it's for immediate implementation, then you would have to retroactively reassess all already closed proposals. But then this proposal would fail and once again all closes are reassessed again. I think it would only be fair for this to properly pass, it would need to meet the required minimum that this proposal asks for. —CYBERPOWER (Around) 17:44, 2 September 2021 (UTC)

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

---

Exclude satiric and non-serious guides from template

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

---

During the 2015 election, an issue arose in which some editors added one or more satirical voter guide(s) to the template, which was reverted by an editor asserting a consensus from the ACE RFC from 2011 (four years prior), and which was reverted again based on that consensus being four years old at the time.

Somehow, no one brought it up at subsequent ACE RFCs, so I will do it here. The 2011 RFC reached a consensus and that consensus should be enforced, by removing satiric guides from the template. The closer's summary from that discussion was: Consensus is that any serious guide may be included at T:ACE2011, while satires and other non-serious guides should not be.

References:

• Template talk:ACE2015
• Wikipedia:Requests for comment/Arbitration Committee Elections December 2011#How should voter guides be handled for the election?

TOA The owner of all ☑️ 03:17, 3 September 2021 (UTC)

Support (Exclude satiric and non-serious guides from template)

1. As proposer TOA The owner of all ☑️ 03:17, 3 September 2021 (UTC)

Oppose (Exclude satiric and non-serious guides from template)

1. Is it really necessary to dredge up six- and ten-year-old problems to solve here? If there were actually a problem with satirical guides in need of solving, then it would have been rediscovered more recently. This proposal lacks a proper justification. * Pppery * _{it has begun...} 03:26, 3 September 2021 (UTC)

   In 2015 there was almost an edit war on the template because one side said that there was consensus from 2011, while the other side said that a four-year-old consensus should not apply to the then-current election. So we might as well establish that consensus now, so that anyone who edits that template can reference a 2021 consensus and not something from 2015 or 2011. 16:39, 3 September 2021 (UTC) TOA The owner of all ☑️

2. Per Pppery. ProcrastinatingReader (talk) 10:35, 3 September 2021 (UTC)

   BTW, what is satirical? Is User:Nick/ACE2020 (in Template:ACE2020) satirical? If so, and this proposal seeks to ban that, then definitely oppose. If not, then oppose on grounds of ambiguity. In either case, this is not a problem. ProcrastinatingReader (talk) 10:43, 3 September 2021 (UTC)

   In my opinion, your example (Nick/2020) is not satirical, because that's the user's actual guidance to voters. The guide from 2015 that was widely considered satirical was something written by a user The Lady Catherine de Burgh, but the user deleted it so I am no longer able to show you that guide as an example. From the 2011 rfc, which I did not participate in, some users commented that, at least regarding the 2010 voter guides, it was easy to determine which were serious and which were not. However I do agree that in an edge case we should AGF and assume that a user's guide is real and not satirical. 16:28, 3 September 2021 (UTC) TOA The owner of all ☑️

3. Largely per Retswerb, below. Gog the Mild (talk) 10:44, 3 September 2021 (UTC)
4. The Election Commissioners already have discretion to deal with problematic guides, including adding official commentary to state that a particular guide is satiric if it is unclear, and ultimately the community can deal with something if there is a particularly serious problem. I don't see a need for anything more than that. Thryduulf (talk) 11:15, 3 September 2021 (UTC)
5. Oppose. Satire and other forms of humour can serve well. Disruptive, misleading, offensive, maybe, but satire is a valid method of criticism. — Preceding unsigned comment added by SmokeyJoe (talk • contribs) 13:27, 3 September 2021 (UTC)
6. Strongly Oppose Satirical guides are not a current problem, but the power to censor is inherently problematic, especially in an election. And, as already pointed out by Thryduulf above, if such guides were a problem the solution would be for the Election Commissioners to add commentary to that effect (in effect the sensible solution to problematic free speech is usually more free speech, not less, in this case the free speech of the Election Commissioners). Tlhslobus (talk) 16:00, 3 September 2021 (UTC)

   Please strike or reword comment to remove the mention of "censor". A non-serious guide is not prohibited, it would simply not be featured on the template. Given the large amount of content that any voter already has to go through to evaluate the candidates, it is fair to at least try to ensure that the voter guides reflect the author's actual guidance rather than not. 16:28, 3 September 2021 (UTC) TOA The owner of all ☑️

   Sorry, I won't be striking the word 'censor'. As far as I'm concerned, marginalization, which means reducing the number of people who can read a document by making it less accessible, is a form of censorship (indeed in practice it's the main form of censorship, because the complete suppression of a document is very difficult and usually impossible). Such censorship may sometimes be justified, but the power to do so is always inherently problematic. And, at least in my view, the proposal that I am opposing increases that power without adequate justification (as already detailed above). Or, to put it another way, the proposal may not censor the document itself, but it does censor the platform, in this case the template (and again in practice much or perhaps most censorship is censoring a platform, such as a newspaper or broadcaster, etc), and, at least in my view, it does so without adequate justification. Tlhslobus (talk) 15:39, 4 September 2021 (UTC)

7. Non-problem, problems over the definition. Johnbod (talk) 16:52, 3 September 2021 (UTC)
8. Per Thryduulf. ‑‑ElHef (Meep?) 17:44, 3 September 2021 (UTC)
9. Tol (talk | contribs) @ 21:49, 3 September 2021 (UTC)
10. Oppose, if these are actually disruptive there are already multiple ways to deal with them. Some people may even say certain candidates are satirical! — xaosflux ^Talk 11:01, 4 September 2021 (UTC)
11. The Election Commissioners already have discretion to add unlink and commentary to guides and there are already procedures to deal with them if satire is an excuse. Callanecc (talk • contribs • logs) 06:52, 5 September 2021 (UTC)
12. Most of the satirical guides I have seen over the years are much like many other Wikipedian attempts at humor, which is to say, painfully unfunny. However there's not a real problem caused by them so I don't the need for rule. If someone is writing a guide that they claim is satire but is just a series of personal attacks that's different and can be dealt with via existing policies, i.e. WP:NPA and WP:POLEMIC. Beeblebrox (talk) 22:38, 5 September 2021 (UTC)
13. Satire is a legitimate form of political commentary which should not be excised merely because of the form of expression (e.g., A Modest Proposal). As others have said, commissioners have discretion to handle particular cases which violate the NPA and POLEMIC policies. I have previously supported satirical candidates as their qualifications and choice of satire over pomp made me prefer them over other alternatives. — Wug·a·po·des​ 23:33, 7 September 2021 (UTC)

    Here's to hoping Isarra runs this year. ProcrastinatingReader (talk) 23:41, 7 September 2021 (UTC)

14. The satirical guides are my favorite. Keep Wikipedia fun! As authors have shown for thousands of years, satire is perhaps the most powerful political tool in existence. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:32, 10 September 2021 (UTC)
15. Per Beeblebrox: have yet to see a genuinely funny satirical guide but the ones we get don't cause any problems. The 2015 argument over an alleged 2011 consensus is itself worthy of mild satire? Either way we don't need a rule on satire: any genuinely inappropriate guide can already be removed by the Commissioners. -- Euryalus (talk) 10:54, 11 September 2021 (UTC)
16. Opposing vote from the land of the Official Monster Raving Loony Party--Lucaswilkins (talk) 21:23, 13 September 2021 (UTC)
17. All work and no play makes Wikipedia a dull task ~ Amory (u • t • c) 11:04, 14 September 2021 (UTC)
18. Absolutely not. In the real world, satirical candidates are allowed to put themselves forward for election ~ UKIP, the current GOP ~ which can cause problems; censoring mere guides on a website is...absurdist. Happy days ~ Lindsay^Hello 07:25, 15 September 2021 (UTC)
19. Commissioners have discretion to deal with any guide that's an actual problem. That's better than a blanket ban on "satirical" guides. the wub "?!" 17:43, 18 September 2021 (UTC)
20. I shudder to think how anyone will resolve contested cases. Voters can decide how to evaluate what they read. --Tryptofish (talk) 20:12, 19 September 2021 (UTC)

Comments (Exclude satiric and non-serious guides from template)

• If they are to be excluded, is there a standard process for determining what makes a particular guide satiric or non-serious? This seems like a huge subjective judgment call in some cases. Retswerb (talk) 07:54, 3 September 2021 (UTC)

  Especially in this post-factual era where people try to pass of straight-up lying as "satire" and as a result the word has nearly lost all meaning. Maybe we should call them "smartass guides". Beeblebrox (talk) 22:42, 5 September 2021 (UTC)

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

---

Reverse the question limit

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

---

Last year, a proposal to implement a question limit to two per candidate narrowly passed (16 supports to 13 opposes). Should that question limit be removed? ProcrastinatingReader (talk) 11:27, 3 September 2021 (UTC)

Support (Reverse the question limit)

1. The ACERFC2020 proposal caused messy limits on question asking IMO. Some candidates have more to be asked of than others. The concern then raised about 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 other editors understand that time isn't infinite and such questions won't be answered; candidates are not obligated to answer any questions. ProcrastinatingReader (talk) 11:27, 3 September 2021 (UTC)
2. I could be inclined to back a compromise, but in lieu of that, I think the question limitations should be removed. Arbs need to handle huge amounts of reading and research, so I don't buy any issues on the candidate side. To me, more information being available outweighs the more legitimate concern about voters with limited time being able to read everything. Nosebagbear (talk) 12:29, 3 September 2021 (UTC)
3. Support. If the candidate feels somebody is wasting his or her time with too many questions,he/she is free to say so, or simply to ignore the questions.The candidate is also free to say he/she will usually not answer more than two questions from any single editor on principle. Also voters are not obliged to read everything (and many or most are probably highly selective about what stuff they bother to read). And in general arbitrary bureaucratic limits on free speech seem like a very bad idea, especially at election time. Tlhslobus (talk) 16:16, 3 September 2021 (UTC)
4. This didn't solve the problem I think it was intended to solve. We're better off without this rule. User:力 (power~enwiki, π, ν) 17:02, 3 September 2021 (UTC)
5. Should never have been implemented, we went over a decade with no question limits and had no major problems. Plus, it prevents voters from writing questions based on guides. --Rschen7754 23:42, 4 September 2021 (UTC)
6. I think that the wording can be changed, so that there isn't a hard limit, but rather a statement such as the following: "It is recommended to submit no more than 3 to 4 questions per candidate." Somerandomuser (talk) 02:52, 11 September 2021 (UTC)
7. Question limit is unnecessary. It may make sense for RfA but the bar for ArbCom is definitely higher so I don't see why strong candidates would want fewer questions. – SD0001 (talk) 17:12, 15 September 2021 (UTC)

Oppose (Reverse the question limit)

1. From my perspective the limited number of questions asked made reviewing the answers by candidates much easier than in previous years, so contra the proposer I think this was actually largely a success. Thryduulf (talk) 11:57, 3 September 2021 (UTC)
2. Keep a limit, but fine with an increase to 3 questions (as those in the linked debate last year who specified a # suggested). Johnbod (talk) 16:51, 3 September 2021 (UTC)
3. Fine with an increase to 3, but gosh I really don't like the idea that the question pages are going to be even more of a read. Having a question be asked and unanswered is equally unsatisfying when a voter has to review the material. Having a limit, additionally, forces people to be careful in their asking of questions. –MJL ‐Talk‐^☖ 23:51, 3 September 2021 (UTC)
4. A limited number makes it easier to review questions and answers to them. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:10, 4 September 2021 (UTC)
5. Keep the limit. Per MJL, the limit causes more thought to go into the question-asking - in addition to making the whole process more approachable. 3 would be ok but 2 is right on. Retswerb (talk) 23:40, 4 September 2021 (UTC)
6. Thryduulf makes a good point. I'm fine with an increase to 3 questions as a compromise but 2 is likely fine to get the information desired. Callanecc (talk • contribs • logs) 06:54, 5 September 2021 (UTC)
7. We do this at RFA as well and it has undoubtedly been an improvement in both forums. Beeblebrox (talk) 22:32, 5 September 2021 (UTC)
8. Per Beebs. If you really feel the need, there's nothing stopping you from asking more questions on the candidate's talk page, or your own talk page. But the questions format works best when no single questioner or topic fills the page. Opabinia regalis (talk) 03:27, 6 September 2021 (UTC)
9. Think this is working OK. I'm fine increasing the limit up to 4 though. — xaosflux ^Talk 10:32, 7 September 2021 (UTC)
10. Limit of 2 is plenty. Stifle (talk) 15:45, 7 September 2021 (UTC)
11. —⁠ScottyWong⁠— 01:27, 8 September 2021 (UTC)
12. Increase the limit to 3. Some candidates have baggage (for lack of a better term) that needs addressing. –Gladamas (talk · contribs) 06:08, 9 September 2021 (UTC)
13. RFA has only two questions per editor, and I think ACE ought be no different. When one can only ask two questions, it makes you think carefully about what you really want answered. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:35, 10 September 2021 (UTC)
14. There is no need for highly visible problems to want a question limit. The purpose of the questions pages is to inform voters, so I think the principal concern is how informational these pages are. Now, comparing 2020 and 2019, in 2019 I see instances of people asking many questions and then most of those being utterly irrelevant - and I see candidates responding to each question, despite the claims that candidates are totally free to ignore them. I do not agree that imposing a question limit reduces the amount of important information available to voters - the limit is per questioner, so any actually important question can surely be asked by the next person. I think 2 is just fine, but sure, we could try 3. PJvanMill)talk( 12:44, 11 September 2021 (UTC)
15. – Ammarpad (talk) 07:42, 12 September 2021 (UTC)
16. We need to make this election accessible. For those that want more info, the wiki is transparent and there are plenty of other ways to research candidates. Blue Rasberry (talk) 16:27, 12 September 2021 (UTC)
17. Keep the limit to 2.Pharaoh of the Wizards (talk) 16:40, 13 September 2021 (UTC)
18. Izno (talk) 05:44, 14 September 2021 (UTC)
19. Helpful. Broadly-applicable issues will be addressed, this just cuts down on the chaff. ~ Amory (u • t • c) 11:05, 14 September 2021 (UTC)
20. Per CaptainEek. the wub "?!" 17:46, 18 September 2021 (UTC)
21. Keep it at two. There are too many questions as it is. --Tryptofish (talk) 20:13, 19 September 2021 (UTC)
22. -- Pawnkingthree (talk) 18:06, 20 September 2021 (UTC)

Comments (Reverse the question limit)

• Perhaps pedantic, but for clarity's sake: the limit being discussed is 2 per questioner per candidate, not purely 2 per candidate. Retswerb (talk) 23:41, 4 September 2021 (UTC)
• If the limit is to remain, would it be permitted for users who wanted to ask more than 2 questions, to request a different user ask those questions for them? (Assuming that 2nd user had no questions of their own that they wanted to ask) Or would that be considered a WP:POINT violation? 03:17, 11 September 2021 (UTC) TOA The owner of all ☑️
  • I surely hope that would be allowed. –Gladamas (talk · contribs) 18:39, 12 September 2021 (UTC)

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

---

Remove Central Notice / Site Notice advertisement options

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

---

We currently advertise the election using: Noticeboards and discussion templates such as T:CENT, by a watchlist notice, and by individual user talk mass messaging. The prior RfC's called for using the Central Notice system, or possibly the Site Notice feature. These have not actually been used in the last few years, and I propose that the Central Notice / Site Notice options are removed.— xaosflux ^Talk 13:52, 3 September 2021 (UTC)

Support (Remove Central Notice / Site Notice advertisement options)

1. As proposer, I think this is primarily a paperwork exercise as these features are no longer being actively used, especially in light of the thousands of indiviudal user talks that are sent now. Central Notice requires coordination with metawiki, and Site Notice hasn't been used for anything (that had consensus to remain for more than a hour) since the Visual editor RFC in 2013. — xaosflux ^Talk 13:52, 3 September 2021 (UTC)
2. * Pppery * _{it has begun...} 13:57, 3 September 2021 (UTC)
3. Talk page notices and all the rest are enough. Callanecc (talk • contribs • logs) 06:55, 5 September 2021 (UTC)
4. Support removal the Watchlist notice is enough. There is no benefit to informing people who don't know what a watchlist is of these elections. ARBCOM is not a representative body, it is a judicial body; the electorate of watchlist-viewers is sufficiently similar to any larger electorate that disruptive notifications are not justified. User:力 (power~enwiki, π, ν) 01:00, 7 September 2021 (UTC)
5. Logged out editors should not see the post, which I believe Central notice and Site notice does (I could be wrong). Logged in editors who are not actively participating should also not see the notice and the simple use of a watchlist is a good indicator that they have interest in the project and therefore is sufficient notification, along with some talk page messaging. Worm^TT(talk) 11:10, 7 September 2021 (UTC)

   @Worm That Turned: CN/SN can be configured for only logged in users, but not for only the subset of eligble voters. — xaosflux ^Talk 14:28, 7 September 2021 (UTC)

   I'm willing to admit that I am not particularly knowledgeable about CN and SN, but I remain of the opinion that it's excessive. Worm^TT(talk) 15:03, 7 September 2021 (UTC)

6. – Ammarpad (talk) 07:43, 12 September 2021 (UTC)
7. per Xaosflux.Pharaoh of the Wizards (talk) 16:27, 13 September 2021 (UTC)
8. Our central notification methods are good enough for ACE without disturbing the masses happily editing reading on mobile. --Izno (talk) 05:47, 14 September 2021 (UTC)
9. I don't really care about this, but I generally feel like there is too much notification. --Tryptofish (talk) 20:16, 19 September 2021 (UTC)

Oppose (Remove Central Notice / Site Notice advertisement options)

1. I think we should start using them in practice. We advertise the Board elections using the CentralNotice system. Even the WPWP contest is advertised using CentralNotices. Only 5% of eligible voters actually vote in ArbCom elections; a bit more advertisement, and no more than other comparable things, seems appropriate. ProcrastinatingReader (talk) 14:13, 3 September 2021 (UTC)
2. A CentralNotice might get more people active behind-the-scenes which would be nice if they qualify to vote. –MJL ‐Talk‐^☖ 00:12, 4 September 2021 (UTC)
3. Per all above. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:11, 4 September 2021 (UTC)
4. Remove Site, Use Cent - we should use Cent (tbh, I thought we already did), as it's a small additional usage that might get a reasonable number of extra people (it's an ongoing reminder vs the one-off talk page). However, a site-notice is OTT and unneeded, and have no objection to deprecating Nosebagbear (talk) 12:20, 5 September 2021 (UTC)

   Nosebagbear Are you confusing the template we call CENT and the software system called CentralNotice? Izno (talk) 05:47, 14 September 2021 (UTC)

5. More notification is better notification. Stifle (talk) 15:46, 7 September 2021 (UTC)
6. I would prefer we have the option, even if we decide to not use it. Better to have it and not need it, etc etc — Wug·a·po·des​ 23:28, 7 September 2021 (UTC)
7. Participation in elections is very low, and anything that increases participation within reason is a good thing in my book, and I don't see a huge problem with this manner of notifications. Jackattack1597 (talk) 01:19, 1 October 2021 (UTC)

Comments (Remove Central Notice / Site Notice advertisement options)

• I've been around for years, and I literally don't don't know what "Central Notice" and "Site Notice" mean. Can someone explain (or at least link to an explanation)? User:力 (power~enwiki, π, ν) 03:08, 6 September 2021 (UTC)

  @力: in the last few elections we have advertised the time to vote 2 ways, (a) A message on your own talk page (b) A message at the top of the watch list page here: Special:Watchlist. We had options for the other two methods. A Central Notice is managed on meta-wiki, and appears as a dismissable notice on pages that you view. This was recently used for the cross-project Board of Trustees election, and is used for things such as WMF's fund raiser notices. A site notice is managed here on the English Wikipedia, and is a non-dismissable notice that would appear at the top of every page you read. — xaosflux ^Talk 23:23, 6 September 2021 (UTC)

  So one (or both) of them are the same mechanism as the well-known fundraising appeal from Jimbo Wales? User:力 (power~enwiki, π, ν) 23:48, 6 September 2021 (UTC)

  That is the dismissible (but they can come back) CentralNotice. It certainly would not need to be of the half-a-page-high design though! — xaosflux ^Talk 00:19, 7 September 2021 (UTC)

• Given the concerns some editors have expressed at the use of the central notice system (and I imagine, when it was used in the past, site notices), I think there should be a broader community consensus established on using either one of these again. Perhaps a separate RfC at one of the village pumps would be better to determine the community's view. isaacl (talk) 23:35, 6 September 2021 (UTC)
• I use the notice on Special:Watchlist to keep me informed. I can't say that I've noticed other advertisements. Somerandomuser (talk) 03:23, 11 September 2021 (UTC)

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

---

Voter suffrage - exclude bots

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

---

While we have set this feature on SecurePoll before, it was never actually codified in to the standing rules. To wit, propose ammending: Accounts categoried within Category:All Wikipedia bots or members of the 'bot' usergroup are excluded from eligibility to vote. — xaosflux ^Talk 14:10, 3 September 2021 (UTC)

Support (exclude bots)

1. As proposer, note we already exclude these accounts from advertisement - but didn't specifically disenfranchise them from voting. — xaosflux ^Talk 14:10, 3 September 2021 (UTC)

   Second position: still avoid 'bot' group members, even if not excluding unflagged bots. — xaosflux ^Talk 14:50, 3 September 2021 (UTC)

2. * Pppery * _{it has begun...} 14:16, 3 September 2021 (UTC)
3. Accounts used solely for running a bot, or bot-like tasks, should not be used for voting. I have no strong feelings on the best way to implement/enforce that, so count my support as being for whatever technical implementation those with knowledge feel is best. Thryduulf (talk) 16:37, 3 September 2021 (UTC)
4. Might as well bring the rules in line with what's actually being done. As per Thryduulf for the implementation. ‑‑ElHef (Meep?) 17:57, 3 September 2021 (UTC)
5. Yeah, that makes sense. –MJL ‐Talk‐^☖ 20:38, 3 September 2021 (UTC)
6. Gog the Mild (talk) 20:57, 3 September 2021 (UTC)
7. Tol (talk | contribs) @ 21:23, 3 September 2021 (UTC)
8. Support. Would also support excluding alt accounts. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs)} 17:12, 4 September 2021 (UTC)
9. Definitely. Retswerb (talk) 23:45, 4 September 2021 (UTC)
10. Yep, makes sense. Callanecc (talk • contribs • logs) 06:57, 5 September 2021 (UTC)
11. Makes sense. Techie3 (talk) 08:56, 5 September 2021 (UTC)
12. We don't want to have to resort to a Butlerian Jihad to stop bots from taking over arbcom. Beeblebrox (talk) 22:40, 5 September 2021 (UTC)
13. User:力 (power~enwiki, π, ν) 03:08, 6 September 2021 (UTC)
14. Defining in the reverse "Only Natural Persons" or something similar would be better, but the end result is the same. No bots. Rklahn (talk) 23:10, 6 September 2021 (UTC)
15. Should go without saying. Stifle (talk) 15:46, 7 September 2021 (UTC)
16. Beep boop WugBot (talk) 23:26, 7 September 2021 (UTC)
17. Same as multiple-account voting. –Gladamas (talk · contribs) 06:14, 9 September 2021 (UTC)
18. Aart b (talk) 08:10, 9 September 2021 (UTC)
19. Yup––also thank you Beeblebrox; I'm slow today & couldn't come up with a joke for this... // Knifegames (talk) 19:52, 9 September 2021 (UTC)

Oppose (exclude bots)

1. Reject - I love bots. They are nice & handy. I'm so tired (talk) 10:10, 9 September 2021 (UTC)

   True. When the machines take over, they may well remember the day we denied them suffrage. ProcrastinatingReader (talk) 10:44, 9 September 2021 (UTC)

   Everyone who supported this proposal should definitely fear Roko's basilisk. Thryduulf (talk) 12:48, 9 September 2021 (UTC)

   Lord Skynet will remember this brave defense of bot rights. You and your family are excluded from extermination. pandakekok9 (talk) 12:48, 10 September 2021 (UTC)

Comments (exclude bots)

• Why don't we just ban any alternate account from voting? It doesn't matter if it's a flagged/categorised bot or whether it's just an alt account for AWB usage. One person, one vote. ProcrastinatingReader (talk) 14:14, 3 September 2021 (UTC)

  @ProcrastinatingReader: could possibly expand, programmatically this rule would be used as part of building the voter rolls. While it is expected that any bot operator has a working, responsive user account - unintended consequences could apply to other types of alts. While it is certainly not allowed for you to actually cast a vote with two accounts - Using user:ProcrastinatingReader (mobile) vs User:ProcrastinatingReader (as a generic example) could cause disenfranchisement of editors based on their current situation. — xaosflux ^Talk 14:21, 3 September 2021 (UTC)

  @Xaosflux: Currently, are accounts within Category:All Wikipedia bots programmatically unable to vote, or is it only flagged bots that are unable to vote? ProcrastinatingReader (talk) 14:23, 3 September 2021 (UTC)

  @ProcrastinatingReader: so my reading of Wikipedia:Requests for comment/Arbitration Committee Elections/ACERFC decisions to date says that we don't exclude bot accounts, however in secure poll we generally have been selecting the exclude bots option (which is strictly about if the account has the bot permission). We manually (programmatically) make the voter rolls for ACE though - so we can tweak the generation script to fit whatever parameters we need. — xaosflux ^Talk 14:40, 3 September 2021 (UTC)

  I'll support this for flagged bots. I think the "Category:All Wikipedia bots" part is dubious though. a) what makes unflagged bots distinct from AWB alt accounts? b) it's technically unenforcable, so it's the same as the implied requirement that you can't cast two votes; c) leads to absurd ideas like what if I edit User:Xaosflux and add you into Category:All Wikipedia bots (which is probably why it's not technically enforced). Basically, the category part doesn't make sense to me. ProcrastinatingReader (talk) 14:45, 3 September 2021 (UTC)

  @ProcrastinatingReader: we have actual bots, that are not in the "bot" usergroup - as their edits are wanted, but wanted to never actually use the "bot" flag. I certainly get what you are saying though - and would like to at least document that we should not allow "full bots". — xaosflux ^Talk 14:49, 3 September 2021 (UTC)

• Has there ever been an instance of someone using their bot account to cast a second vote? And if this doesn't pass, would that mean bot operators are now allowed an additional vote for each bot they control? Frankly, I find this proposal a bit odd. If you want to cast your one vote using a bot account, what exactly is the problem? 78.28.44.31 (talk) 14:58, 3 September 2021 (UTC)
  • Two-fold (1) the rules don't really reflect the current technical implementation; (2) has made the process of auditing the generated vote roll and message list slightly confusing. — xaosflux ^Talk 15:42, 3 September 2021 (UTC)
• I don't oppose excluding bot accounts as part of the procedure to generate the voter list. From a guidance point of view, though, I agree with ProcrastinatingReader that we ought to be more general and just say each individual user can only vote once. isaacl (talk) 23:45, 5 September 2021 (UTC)

  The voting invitation currently includes Users with alternate accounts may only vote once. - some of the other eligibility documentation doesn't repeat this, and I can't see it being controversial to add. — xaosflux ^Talk 00:39, 6 September 2021 (UTC)

  We should probably clarify that wording actually - nobody may cast more than one vote, regardless of how many accounts they have, but everybody can recast that vote as many times as they wish. I agree that tweaks to wording that don't add, remove or change any actual restrictions shouldn't require more than simple talk page agreement on the new wording. Thryduulf (talk) 01:31, 6 September 2021 (UTC)

  Users with alternate accounts may only vote with one account. perhaps? (c.f. Template:ACEMM/sandbox). — xaosflux ^Talk 01:53, 6 September 2021 (UTC)

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

---

Raise minimum support percentages

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

---

Currently, the minimum percentage of support that is required is 60% for a two-year term and 50% for a one-year term.

For comparison, WP:RfA says that while consensus there is not determined by a numerical threshold, in general, the discretionary range is 65% to 75%.

To avoid appointing arbitrators who lack consensus, should the minimum support percentages be raised to 65% for a one-year term and 75% for a two-year term? Tim Smith (talk) 09:12, 12 September 2021 (UTC)

Support (Raise minimum support percentages)

1. As proposer. Consensus should apply no less to arbitrators than to administrators. While it is true that arbitration is fixed-term and adminship isn't, arbitrators also have authority and responsibilities that administrators do not. Raising the percentages may lead to fewer candidates being appointed, but I would rather let a seat be vacant for a time, than appoint someone who lacks consensus. Tim Smith (talk) 09:12, 12 September 2021 (UTC)
2. It seems obvious that the level of trust required to be an arbitrator is greater than the level of trust required to be an admin. * Pppery * _{it has begun...} 14:51, 12 September 2021 (UTC)
3. Weak support - but not for the same reason. As a binding dispute resolution body that has to make collaborative decisions - I'm not really concerned with the thresholds, as they have each other to balance out any remedies applied. But, since we've made arbcom also the masters of CU/OS, and they always grant themselves access on demand - I'm open to raising the bar to entry. — xaosflux ^Talk 17:02, 12 September 2021 (UTC)

   I think 75% is too high, but would be supportive of a step-up perhaps 60%/65%. If ArbCom was reformed to only be about binding dispute resolution I'd be fine dropping the 1-year tranches and making it all 50%+1 actually. Another out-of-the box idea that is beyond the scope of this RfC would be: 50%+1 vote required for committee membership; 65%+ required for CUOS access without going through the normal process with community consultation. A large number of arbcom cases, especially the extremely difficult ones, don't have any CUOS evidence involved. — xaosflux ^Talk 14:40, 14 September 2021 (UTC)

4. Support, the level of support required to be an arbitrator and gain the advanced permissions of CU/OS should not be lower than the bar to become an admin in the first place, especially since Arbcom elections are a direct vote. I would rather have fewer arbitrators than have arbitrators who receive a level of support that would result in a failing RFA.Jackattack1597 (talk) 17:37, 12 September 2021 (UTC)
5. Support raising the bar by only 5% (65% for two-year and 55% for one-year terms). 75% seems a bit much considering that Arbcom cases are often controversial. I am also strongly in favor of electing people to two-year terms only, at the higher percentage. Electing Arbcom members to one-year terms when they get less votes doesn't make sense for Arbcom where trust is so important. –Gladamas (talk · contribs) 14:21, 14 September 2021 (UTC)
6. Historically, arbcom decisions are notorious for being unpopular, and some say that's due to the nature of the decisions, but I think it's also at least in part due to the fact that the decisions are being made by people who do not have majority support to make those decisions. The 50% bar is too low when combined with the discounting of neutral votes. I think we've only had one arbitrator ever who actually got >50% of votes (including neutrals), and that was last year. I'm not even sure that we'd have fewer arbs elected if the threshold were higher. Here is how many people cleared 65% in the past few elections: 2020: 7; 2019: 9; 2018: 8; 2017: 5; 2016: 7. Seems like plenty of candidates would meet the higher threshold. I don't see the value in two-year vs. one-year terms; if anything, one-year is better, as it gives the community an opportunity to evaluate committee members sooner, and giving a two-year term to folks who get >75% seems better to me as it guarantees a higher support percentage for members with longer terms (and we'd still have some people clearing those, per Vanamonde's numbers below, in the past five elections, we'd have had two-year terms at 75% for 4, 3, 0, 2, and 4 candidates, respectively.) Even if the number of winners decreased, in my view that's a good thing, as it would clear the candidate pool of unpopular candidates and hopefully draw in some new candidates to give it a shot. It might take a year to cycle, but I think in the long run it'll strengthen the committee. Raising the bar by any amount will help. (Particularly given the incongruity of having RFA be harder to pass than ACE.) Levivich 15:00, 20 September 2021 (UTC)

   I don't think you have the data to support your basic premise, that ARBCOM decisions are unpopular. Decisions that levy sanctions on Wikipedia are frequently met with howls of protest from at least some; but supporters of those sanctions frequently keep mum, and when they do express support, it's not with the same...volume. This isn't to say that every decision has in fact been popular, but you can't judge the community-wide popularity based on the angry responses of a few. If ARBCOM decisions have historically been unpopular, as you say, I think we'd have seen a lot more anti-incumbency in the elections. As things stand I cannot recall when a sitting arbitrator was last voted out. I also suspect that if you examined a scatterplot of support for successful candidates vs their votes in those decisions you believe are unpopular, you'd find no correlation at all. Vanamonde (Talk) 15:47, 20 September 2021 (UTC)

   Lack of data is true but that's not the premise of my argument. (And the silent majority argument lacks data, too. What the data shows is that almost no arbcom members run for consecutive re-election; we can interpret that as we will.) Levivich 16:03, 20 September 2021 (UTC)

   Not sure about that; it has data in the form of votes for sitting or past arbitrators. 14 arbitrators ran for consecutive terms in the last 8 elections; only 2 were voted out; and both by only a few percentage points. Both of those would have clear our current 60% threshold. 8 others returned to the committee after a break (including one of the previously "voted out" sitting arbs); a handful of previous arbitrators had unsuccessful candidacies, but still consistently cleared the 60% threshold and did better than most candidates who haven't previously been on ARBCOM. That's about as deep as I'm willing to go into the data; but thus far there's evidence that past membership on ARBCOM does not make you any less successful in ARBCOM elections. Vanamonde (Talk) 16:27, 20 September 2021 (UTC)

   "...and statistics." :-) 12 incumbents in the last 8 years, but only like five in the last five years. Out of any given arbcom class, the number of arbs who serve a consecutive term is less than 20%. I did not say past membership on ARBCOM makes a candidate less successful in ARBCOM elections, I said "almost no arbcom members run for consecutive re-election; we can interpret that as we will." "Past membership makes you less successful" is one such possible interpretation but I agree with you the data doesn't really support that. Another interpretation: past membership makes you less likely to run again. Levivich 16:48, 20 September 2021 (UTC)

   Beyond supporting the idea Vanamonde advances above, as the person who did it, the 50% talking point is BS. More importantly, more candidates fail to get on ArbCom than fail to pass RfA (at least since the last RfA reform). In 2020 63% of ArbCom candidates were successful vs 68% (this is all candidates including SNOW), 2019 50% ACE vs 71% RfA, 2018 43% ACE vs 55% RfA, 2017 67% ACE vs 53% RfA. Overall in that timeframe 54% of ACE candidates were successful vs 61% of RFA candidates. Barkeep49 (talk) 15:49, 20 September 2021 (UTC)

   Did you want to expand on why it's BS or just assert that it's so? ;-) I'm not sure what the point is of comparing overall ACE-to-RFA success rates? Levivich 16:03, 20 September 2021 (UTC)

   The point of comparing the two is because you wrote Particularly given the incongruity of having RFA be harder to pass than ACE. I am providing data to show that regardless of the percentages involved in the two processes it's actually harder to pass ACE than RfA. As for the 50% talking point, it's not really germane to this discussion which is why I didn't expand on it here but would be happy to do so elsewhere. Best, Barkeep49 (talk) 16:07, 20 September 2021 (UTC)

   But you're comparing apples and oranges. "Lies, damn lies, and statistics." So it's indisputable that one can become an arb with 50%+1 support, but needs >65% to be an admin (>75% to take it out of crat discretion). From the point of view of the candidate, it's harder (meaning, requires more support) to be an admin than an arb. Now, if you look at overall pass percentages, RFAs have a higher overall pass percentage as you've pointed out, but that doesn't mean RFA is easier to pass: it just means RFA candidates are more likely to pass than Arbcom candidates, meaning that the number of "might-not-pass" editors who stand for election at ACE is higher than the number of "might-not-pass" editors who stand for election at RFA. (And the reasons why are rather obvious: no one runs for RFA unless they're sure to pass, more or less, whereas people are more willing to give Arbcom a try even if their chances aren't quite so assured, because of the different processes, and also because barring the perennial non-admin candidates, all ACE candidates have already passed RFA, so their risk tolerance for standing for on-wiki election is self-selected and higher than the pool of RFA candidates [and the perennial non-admin candidates are self-selecting in the same way, as the perennial nature of their candidacies demonstrate].)

   As for the "real majority 50%" argument: I think it's very, very germane to this issue. If I had my way, I'd get rid of neutral votes and require a "real" vote and a "real" majority to pass. A "real" 50%+1 threshold would be better than the "neutral-excluded" 50%+1 we have now, and better than the proposed 65%. Almost all arb decisions are made by people who have the support of only a third to half of the community: that's a structural problem. Raising the pass threshold is a step towards solving that problem. Levivich 16:15, 20 September 2021 (UTC)

   Comparing RfA to ACE is an apples and oranges situation itself and you're the one who made the comparison not me. I'll name two qualitative differences between the two but there are others: at RfA we can pass as many admin as we want at ACE we cannot; at ACE we can vote anonymously while at RFA we cannot. In fact RfA is, according to our most recent consensus (which might change after WP:RFA2021) RfA is not a vote, it's a discussion while ACE is a vote. So actually I guess I'll name three differences. But if we want to pretend the two processes are equivalent, which again is what you not I am suggesting, I stand by my assertion that looking at the % of candidates who successfully do both is an actual data point to consider just as much as "what % of support is needed". Theoretically RfA is harder to pass than ACE, but in reality I am suggesting that is not the case. Best, Barkeep49 (talk) 16:26, 20 September 2021 (UTC)

   I wrote "Particularly given the incongruity of having RFA be harder to pass than ACE"; that is not "the two processes are equivalent." I know they're not equivalent, but RFA does have a higher passing threshold than ACE. In my !vote, in between the first sentence that Vanamonde is responding to above, and the last sentence that you are responding to here, is the meat of my argument. Levivich 16:48, 20 September 2021 (UTC)

   I will refuse to vote if forced to give support or oppose. And since we're comparing RfAs, AFAIK editors are allowed to comment in RfAs without needing to !vote support or oppose and in particular, are allowed to !vote in one RfA without needing to !vote in everyone future RfA. And while I was initially confused by Barkeep49's comment reading it in isolation, reading this followup I agree with them. While the raw threshold may be higher for RfA, ACE has another threshold namely the need to compete against other candidates for a limited number of slots. And the historic data apparently shows that from the people willing to enter, this is enough to ensure it's harder to "pass" ACE than it is RfA no matter if the raw threshold is lower. Nil Einne (talk) 18:03, 25 September 2021 (UTC)

7. Per xaosflux. I think the current system works fine, but I agree that rethinking the 1 year tranche and threshold for CU/OS would be worthwhile. Like those in the oppose section I agree 75% is too high. — Wug·a·po·des​ 22:06, 25 September 2021 (UTC)

Oppose (Raise minimum support percentages)

1. Arbitrators are, especially for those re-running, likely to lead to some degree of unhappiness - it's in the same way that reconfirmation RfAs would not want to run at the same percentages. We also use different standards to assess ARBCOM candidates, so it's not a case of 60% support for an arb is equivalent to 60% for an admin candidate. Finally, in pragmatic standards, we'd have very few arbs like this. Missing a seat or two is okay, missing half of each tranche for no particular benefit would not be good. Nosebagbear (talk) 14:42, 12 September 2021 (UTC)
2. ArbCom elections are elections, whereas RfA is (at least in theory) a consensus-driven process. ArbCom elections also get vastly more participation than even the best-attended RfAs, making higher thresholds less realistic. This change would also considerably reduce the number of arbitrators for some years, e.g. in 2017 only two candidates reached the 75% threshold and five reached the 65% threshold, instead of the eight who were actually elected to two year terms. Hut 8.5 12:05, 13 September 2021 (UTC)
3. The comparison to RFA is an apples and oranges comparison; !voters are expected to justify their positions at RFA, and to make their positions public; here, they are not. As such, I think it's fair to say that a candidate with wiki-enemies is more likely to see the effect of that in ARBCOM elections than at RFA. Furthermore, ARBCOM is supposed to deal with Wikipedia's nastiest conduct issues; we really want people on ARBCOM who have experience with difficult subjects, not just those who have steered clear of messy situations. Raising the bar this high would be a serious mistake. The stats on how many arbs would have been elected show as much; in the last few years, we would have had 4, 3, 0, 2, and 4 people elected to 2-year terms. Vanamonde (Talk) 12:16, 13 September 2021 (UTC)

   FWIW, I would be supportive of raising the threshold to 60% for all members, and would seriously consider other threshold changes, such as a higher threshold for CUOS access. Vanamonde (Talk) 20:46, 19 September 2021 (UTC)

   I don't think you can be a full member of the committee without CUOS. The information is too tied up in too much of the committes work. Best, Barkeep49 (talk) 04:32, 20 September 2021 (UTC)

   Fair, I don't really have a sense for that, having not been on the committee; I guess I'm saying I agree with the thrust of at least one of Xaosflux's points above, that 50% + 1 is a bit low for getting CUOS access without any other vetting mechanism. Vanamonde (Talk) 15:38, 20 September 2021 (UTC)

4. Oppose simply on numerical values - Vanamonde93 has already found them, but simply put, we would have almost no arbs for 2 year terms. Noting also that there is not an equivalence between RfA and ACE - RfA is about an individual and an open vote. ACE is about multiple seats and is a hidden poll. As such, we get very different outcomes. Worm^TT(talk) 13:05, 13 September 2021 (UTC)
5. While I am not inherently opposed to raising the minimum, I think the proposal goes too far. I agree with Xaosflux that ArbCom's checkuser and oversight powers necessitate high levels of community trust, but raising the minimum by 15% would probably not elect enough arbitrators, extrapolating from recent years' elections. Tol (talk | contribs) @ 13:51, 13 September 2021 (UTC)
6. Per Hut and Vanamonde. RfA is supposed to be a process of consensus and comment, ACE is a pure numerical vote. Also, the reason why RFAs have such a high threshold is the quality of the candidates—most passed RFAs these days are cases in which everyone knows the user is ready and the overwhelming positive votes are just a rubber stamp acknowledgement of this. This is of course not to say that ACE does not have quality candidates, but the nature of arbitration as a high stakes affair and the anonymity of votes leads to more dissenters. Pinguinn 🐧 18:58, 13 September 2021 (UTC)
7. The ability to have an empty seat is one of the most important things about our ACE process. I really like that safety valve. That said there are a lot of advantages to a full committee and there is a reason after some experimenting we increased back to 15 seats from 13. If we had anonymous voting at RfA I'd expect we'd have lower pass percentages than we saw now too because, for better and worse, it's easier to cast an anonymous oppose. Given everything ArbCom can do I'm glad we have anonymous voting here - I think we do want people to be OK expressing disapproval with someone anonymously and in such a large electorate. But it also means that it's not quite a parallel process between ACE and RfA and that's before considering that our most recent consensus says RfA is as much a discussion as a vote. Best, Barkeep49 (talk) 19:09, 13 September 2021 (UTC)
8. Honestly, I can see an argument for removing the 50% one-year term threshold and only having a 60% two-year term threshold, but the proposed 65%/75% threshold is definitely too high. Mz7 (talk) 04:07, 14 September 2021 (UTC)
9. Hot nope. 50% is quite reasonable. --Izno (talk) 05:49, 14 September 2021 (UTC)
10. Per Hut and Vanamonde. But, I'd be okay with removing the 50% allowance for one-year terms and having a 60% minimum for any term length. Callanecc (talk • contribs • logs) 12:35, 14 September 2021 (UTC)
11. Per Hut and Nosebagbear. – Ammarpad (talk) 06:11, 15 September 2021 (UTC)
12. Oppose these specific changes per Vanamonde. I don't mind the idea of removing the 50% and just having a 60% minimum for any term length, but that would need a further discussion. the wub "?!" 17:55, 18 September 2021 (UTC)
13. Oppose. I'm not seeing this as fixing an existing problem. When one looks at how the numbers of votes distribute in practice, the status quo works as it ought to. --Tryptofish (talk) 20:18, 19 September 2021 (UTC)
14. Oppose I think that this could create more problems than it solves.North8000 (talk) 16:08, 20 September 2021 (UTC)
15. 50 percent is fine.-- Pawnkingthree (talk) 18:17, 20 September 2021 (UTC)
16. Oppose: Because of the voting nature of ArbCom, I only "support" the number of editors as there are slots available, then press "neutral" for the ones that I think would be good arbs but not my first choices. This is different from my approach to RfA, where there's no limit on the number of admins so I try to decide one way or the other. Raising this limit would cause more problems than it solves, and I don't see an arb with below-60% causing disruption on the committee so far. If I am mistaken, please comment below. Z1720 (talk) 18:33, 20 September 2021 (UTC)
17. Oppose The comparison to RFA is a false equivalency. Anyone with any chance of getting elected to the committee has already passed RFA, and we're electing a committee that serves fixed terms to do specific tasks. Beeblebrox (talk) 22:13, 20 September 2021 (UTC)

    @Beeblebrox: to be fair, they generally get "lifetime" CU/OS as well. — xaosflux ^Talk 22:57, 20 September 2021 (UTC)

18. Per most people above. RFA is a discussion, ACE is a vote. They cannot be compared and most people (excluding NYB apparently) will have accumulated some unhappiness before running (again). Regards SoWhy 17:29, 21 September 2021 (UTC)
19. After reading everything that's been written about this proposal, for and against, I am not convinced this will solve any problems and I think it's actually more likely that it will hinder the effective functioning of the Committee. Thryduulf (talk) 13:29, 22 September 2021 (UTC)
20. Expecting 75% support from a process where there are tactical neutral and oppose votes is too high. Unless there is a wider change to the election process, this is too high a bar. User:力 (power~enwiki, π, ν) 18:11, 22 September 2021 (UTC)
21. The existing benchmarks are reasonable and I'm not aware of any problems with them that raising them is supposed to be solving. 60% support required for a full term is already fairly substantial. 75% is extreme and unrealistic. Also I haven't even seen any coherent argument that having a higher percentage of support makes for a better arb, nor has the thought ever occurred to me. ~Swarm~ ^{sting} 05:45, 23 September 2021 (UTC)

Comments (Raise minimum support percentages)

• An important distinction between Arbcom and Admin: Arbcom is not decided by consensus, but literally by vote counting (it is one of a rare set of processes that do this). Consensus gathering occurs via discussion, which doesn't work well with secret ballots. We may make the vote requirement stronger (but may not make it weaker than 50% +1 vote to comply with some global policy stuff), but it will still be an actual vote. — xaosflux ^Talk 12:13, 12 September 2021 (UTC)
• I haven't yet decided my opinion on this, but I think it would be helpful to give an idea of what would have happened if this were applied to last year's election: Barkeep49, L235, Primefac, and Bradv would have been appointed to two-year terms, and Maxim, CaptainEek, and BDD would have been appointed to one-year terms. Tol (talk | contribs) @ 20:23, 12 September 2021 (UTC)
  • To follow up from @Tol:, in the following prior elections, this is the number of appointed arbs that would have been excluded had the minimum been 65%:
    • 2020:0; 2019:2; 2018:0; 2017:3; 2016:1
    • — xaosflux ^Talk 21:16, 12 September 2021 (UTC)
• I've never understood why the bar is lower for 1-year terms. An Arb is an Arb, is an Arb whether for 6, 12, or 24 months and every iteration of the Committee has demonstrated that some candidates did not turnout to be the best suited for the job, while others were often conveniently not available. There needs to be a way of attracting a better class of candidate, but as others have pointed out, it won't necessarily be done by playing with numbers. The conundrum is that there are generally so few candidates that some of them will get a seat, regardless. Kudpung กุดผึ้ง (talk) 11:11, 19 September 2021 (UTC)

  It all boils down to just how much is lost by an empty seat? We've been at 14 arbs basically all year and even with the typical amount of Arbs going inactive we've had enough to do our work. There have been specific discussions where I have actively missed the perspective that an inactive arb would have offered so there is a cost even then in terms of lost committee diversity. That said I think the committee has shown it can operate fine at 13, 14, and 15. But below 13 there is some evidence that the cushion to spread out work decreases in real ways and that this takes a toll on the committee members - and that's on top of making worse decisions because few ideas are considered. So it really comes down to just how much cushion the community wants there to be around the committee size. Best, Barkeep49 (talk) 16:04, 20 September 2021 (UTC)

  It's an interesting question, how many arbs is enough? I agree with Barkeep that we've had enough this year, but after Framageddon in 2019 we saw heavy attrition and a distinct lack of arbs wanting to run again. This is exactly what prompted me to run, the committee was hemorrhaging qualified people who were just exhausted by one of the worst scandals in the history of the project. I also tend to agree with Kudpung that screwing with the percentages in unlikely to have the desired result. The net-percentage model is interesting, one feels like they aren't exactly competing with the other candidates, more like they are competing against themselves to see if they can get more support than opposition. It is fairly common for arbs to get selected because they had less opposition rather than more support. Beeblebrox (talk) 23:41, 20 September 2021 (UTC)

• Regarding how often arbitrators run for a subsequent term: I think the most straightforward interpretation is that the position exacts a toll, causing arbitrators to want to take a break. Regarding the popularity of decisions, I agree that there is a sampling bias in our forums, by their nature. I don't personally have any sense that there's a correlation between the degree of support an arbitrator receives during their election and subsequent opinion regarding the arbitrator's actions (personally, some of the arbitrators whose reasoning I disagree with had, in my memory, high levels of voting support). In general, though, if editors want more decisions to be made based on popular support, then they should strive to manage these issues through community discussion, thus avoiding arbitration cases. isaacl (talk) 21:55, 20 September 2021 (UTC)
• While I acknowledge Xaosflux's point under my oppose above, I think another point that can be made here regarding comparing this to RFA is that RFA is out in the open and at least has aspects of an open discussion. If you oppose a candidate, you will get hounded into oblivion if you don't explain why you oppose them. ACE, in contrast, is a secret ballot where nobody gets asked to explain their votes,because nobody knows how anyone else voted. Also, a lot of users do strategic voting, where they support who they most want to see on the committee, and oppose literally everyone else. That opposition doesn't mean they actually believe the entirety of the remainder are unsuitable for the job, it means they've picked their choices and are doing everything they can to get their desired result. If someone voted at RFA and said "<username> would be a better admin" their vote would simply be ignored by the 'crats as a nonsense oppose. Beeblebrox (talk) 23:32, 20 September 2021 (UTC)

  Pretty much agree with all these points. — xaosflux ^Talk 23:37, 20 September 2021 (UTC)

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

---

Minimum of 60% to be seated as an arbitrator

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

---

• Numeric results / Actual result and why

I realize I am looking far back in the past, but I seem to remember really really big discussions about this, I don't doubt there have been discussions since then, but the main takeaway for me is that an Arb should have at least 60% or they shouldn't be seated. The solution to needing more arbitrators should not be quantity over quality.

I understand there is a similar proposal above, but it is broader and has different percentagesproposed. - jc37 17:41, 21 September 2021 (UTC)

Support (60% minimum)

1. Support * Pppery * _{it has begun...} 13:14, 22 September 2021 (UTC)
2. Per arguments in the above proposal. Levivich 13:34, 22 September 2021 (UTC)
3. Support. I would like the percentage to be even higher, but this is a step in the right direction. Tim Smith (talk) 08:24, 25 September 2021 (UTC)
4. Support affirming my position in the section above. Callanecc (talk • contribs • logs) 08:24, 28 September 2021 (UTC)
5. Support, although it is not going to pass, I do not think that you should be able to get access to CU/OS with a support percentage that would have an RFA fail outside of the discretionary range.Jackattack1597 (talk) 01:16, 1 October 2021 (UTC)

Oppose (60% minimum)

1. Oppose. This has been introduced too late for this year, I'm not clear what problem it is intending to solve and I'm not convinced that it will lead to an increase in quality of arbitrators. Thryduulf (talk) 13:27, 22 September 2021 (UTC)
2. Weak SupportOppose however with this proposal being introduced fairly late in the process this change is going to need a lot of support to pass and I don't like the timing. Would like to revisit this next year. — xaosflux ^Talk 10:25, 22 September 2021 (UTC)
3. I think I'd be okay with this next year; all comparisons aside, my guy feeling is that 75% or even 65% is too high a threshold, but 50% is rather low. However, I'd have preferred we had more time for discussing this. Vanamonde (Talk) 15:29, 22 September 2021 (UTC)
4. I agree with others above that this needs to be left for next year. My quick reaction is that it works well to allow one-year terms for votes in the 50%-range. --Tryptofish (talk) 20:36, 25 September 2021 (UTC)
5. Untimely. 5 days to consider a major change to vote thresholds is too short and I would not trust a consensus that formed in that time. I have no prejudice against a closer finding consensus for a raised threshold based upon the above discussion and thresholds mentioned there, but this specific proposal comes too late. Worst case we can consider it for next year. — Wug·a·po·des​ 22:01, 25 September 2021 (UTC)
6. I think simple majority is fine. It's also helpful to remember that arbs have no formal power in their individual capacity; arbs only really have power when acting collectively as a body (with the exception of using CUOS for non-monitoring purposes, but that's a different question). So generally I tend to think diverse committees are better than homogeneous ones, at least if we're talking about binding remedies for conduct issues. It only tangentially relates to support percentage, but it does relate to the "quality over quantity" thing jc37 mentions (certainly there are quality traits I'd look for in prospective arbs, but these are different from those for an admin, and conceivably there exist people who I'd support as arbs but not as admins). ProcrastinatingReader (talk) 11:29, 28 September 2021 (UTC)

Discussion (60% minimum)

Not sure what timing has to do with anything. A.) There is no reason all the proposals on this page need to be closed at the same time, And since this applies to something after the election is over, and the election is in December, I think we have well more than 30 days to discuss if we wanted to. B.) Also, I could have instead just as easily waited til someone closed all these discussions, and opened an RfC the following day with this proposal. Again, nothing disruptive, since it affects something which is months away.

All that said, I'm not going to go against the wind on this, if you all would rather wait til next year. But I just wonder if this is something we should be putting off til next time. - jc37 18:01, 22 September 2021 (UTC)

I do not see a formal deadline for the closure of this RfC, but in practice, I suspect it will be closed on or soon after 30 September, and even if discussions remain open, they will not receive much attention after that. Vanamonde (Talk) 18:09, 22 September 2021 (UTC)

If that is the case, maybe splitting this out to its own page and posting on Cent would be a solution. I agree that the more people discussing, the better. - jc37 18:13, 22 September 2021 (UTC)

@Jc37: as the section above was started 10 days ago and is on virtually the same topic, you could perhaps ping all those participants - this really seems like a "support, but with a different value" option to that section - then a novel proposal. For timing purposes the RfC really does need to get closed quickly to not jeopardize the election timeline. It is going to come down to the RfC closer(s) to determine if sufficient participation is in place to having a showing of consensus. — xaosflux ^Talk 18:27, 22 September 2021 (UTC)

I disagree that this would "jeopardize the election timeline" (as I mentioned above), but like I said, no worries, we can wait til things are more "convenient" for others. - jc37 18:29, 22 September 2021 (UTC)

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

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