Best-candidate makes sense for representative bodies, in which case it optimizes for the likelihood that a given voter gets a member of the elected body that they feel is aligned to their interests.
This was a deliberate choice, then? Just trying to understand.
I donāt have any non-public knowledge of the NCAās deliberations on this; Iām just saying that itās not a surprising choice to me.
OK, Iāve sent an email to the elections committee, maybe someone will chime in.
I think that is the function of the āproportionalā part of āproportional best-candidate,ā but not the ābest-candidateā bit. āBest-candidateā is for single-winner elections.
If it really is being run as a proportional representation election, what are the subgroups of the electorate?
The voters.json is public, and itās just a single list, no categories or anything. Thereās no need for a PR method, then. Have I missed something?
No, I donāt think thatās right. The best-candidate versus combined-weights decision is about how to āliftā (CIVSās term) a voterās ranking of individual candidates to a ranking of sets of candidates. CIVSās proportional elections work by conducting a āsingle-winnerā election over potential winner setsāif there are 20 candidates for a 7-winner election, there are (20 choose 7) 7-candidate winner sets to be ranked in this way. This is true of both best-candidate and combined-weights modes; the only difference is how the ranking of the (20 choose 7) sets is computed from a voterās ranking of the 20 candidates. Best-candidate will prefer set A over set B if the best candidate from A is better than the best candidate from B, and combined-weights will look at the entire composition of A and B to compare them.
The subgroups are sort of dynamically calculated from the votes; see the CIVS docs for details, but the short version is that votersā preferences for a winner set are truncated past the number of candidates approximately equal to the size of that voting bloc, so that 60% of the voters who more or less agree can only influence about 60%-ish of the final committee.
Ah. I donāt have an opinion then. Well, I have one- CIVS is misusing terminology and causing confusion. Elections shouldnāt be this hard to understand.
OK, I wonāt quibble about it. Iād still like to know how the result will be computed, because Iāve been told that OpaVote doesnāt support this particular best-candidate mode.
@7c6f434c is on the EC and already replied: Nix Steering Committee Election 2024 - #20 by 7c6f434c
Yes, as everything else important for the election, the EC decided this together.
As mentioned earlier, weāll use CIVS to compute the result:
Thanks for the confirmation, Sil.
Just to be clear.
The CIVS recommendation has been considered, but the level of confidence of this recommendation was found not high enough for overruling other considerations.
The tallying systems considered were those supporting some emergent proportionality, not proportionality among explicit electoral blocks. This is unlike e.g. Kubernetes who choose top-Condorcet-ranked candidates.
Note to the people who havenāt voted yet: Please be aware that if you leave the voting page open for more than an hour, you wonāt be able to submit the ballot without reloading and losing what you entered, so you might want to make a screenshot beforehand!
And the deadline for voting is this Sunday!
(This is a personal message by me)
While testing tallying of ballots using CIVS this weekend, Iāve noticed a potentially major problem: CIVS might be infeasibly slow to compute the result. In a test with randomised ballots, the result is still being computed after ~40 hours, with absolutely no progress being reported!
Since closing the election would give us access to the ballots, Iām making the case to the EC that we need to delay closing until we are sure that using CIVS is feasible, and otherwise decide on an alternative tallying mechanism in advance.
As such, Iām holding off closing the election myself for now and am bringing this topic up for internal discussion in the ECās meeting later today. So you can still vote for now if you havenāt already, but should expect it to be closed later today.
My election nerd friend notes:
The most obvious way to implement the contrived ābest candidateā
variant takes time proportional tomath.comb(number_of_candidates, number_of_winners) * number_of_voters
If youāre picking 2 entrees out of 5 m, thatās trivialā¦ Which is what
that variant was intended for.But it scales horribly as numbers get larger.
In fact CIVS calculated the result rather quickly. We are preparing an announcement right now and will release it today (Anywhere on Earth).
Was it the random ballots making the optimization CIVS implemented go haywire?
Itās not even optimisation, as much as exploration ā random ballots mean that basically all combinations are plausible, and life is full of pain because one needs to apply tie-breaking rules to thousands of thousand-committee preferences cycles (which need to be enumerated first). Have some people with a large support base and some with a much smaller one, and there are suddenly much fewer plausible committees to even compare.