Yeah I saw that plot, but it seems weird to me to look at the plot and target a particular voting pool size, rather than try to come up with an a priori estimate of what level of contribution ought to be required to participate in the community.
25 just seems pretty high to me. Personally, I feel like I am well past the “level of investment in and contribution to the community” that should be required as a minimum for having some say.
Recently we kicked off the first election for the Nix Steering Committee as a major step towards a renewal of project governance.
Since starting this election, we’ve had a lot of engagement in the election repository with 25 nominees being endorsed by more than 80 different people.
We’re now approaching the end of the nomination phase with some upcoming deadlines:
Furthermore, if you’re a nominee yourself:
Following these dates, the final list of confirmed candidates along with their forms is expected to be published on 2024-10-04 Wed, while voting starts on 2024-10-07 Mon.
Note that deadlines are in Anywhere on Earth time, meaning submissions are still valid as long as it is still the given day anywhere on the planet (i.e. at the end of that day in UTC-12).
We’ve now reached the end of the nomination phase, ending up with 25 confirmed candidates!
All candidate forms have now been published together:
We’re also confirming that there are no same conflicts of interests among the candidates, meaning that there will be no further need to take the constitutional conflict of interest restrictions into account.
Until this Thursday, eligible voters can still ask questions to candidates, and are encouraged to do so. Note that questions can also be based on the candidates forms.
Until this Sunday, candidates can answer questions they’d like to answer.
Until this Sunday, voter exceptions can be requested if you’re not already an eligible voter.
The voting phase starts on Monday and will last for almost 2 weeks until 2024-10-20 Sun.
Candidates for the first Nix Steering Committee have now been selected, and the voting phase of the election has begun. The list of voters is now final, and the deadline for exception requests and updating emails has passed.
You must cast your vote by 2024-10-20 Sun in Anywhere on Earth time, meaning as long as it is still the given day anywhere on the planet (i.e. at the end of that day in UTC-12). After the poll is closed, votes will not be accepted for any reason.
We will send a reminder to vote on 2024-10-18 Fri.
Please inform yourself about the candidates by looking at their candidate info documents, which include:
Each candidate’s individual info document is also linked on the ballot.
To be able to vote, you need to activate your email in the voters.json file with CIVS by following the steps on the CIVS Activate User page.
If you already did so, you should’ve already received an email from civs@cornell.edu with a link to the poll.
If you’re only activating your email now, you will get a link to the poll in the activation page under “Pending poll invitations”. If you missed this, you can go through the email activation again.
If you have a question, please contact the Election Committee.
Unfortunately the CIVS poll we used for the election got corrupted due to technical issues out of our control. A symptom of the problem is that the system appears to allow voters to vote multiple times. As such we are invalidating the existing poll, please hold off voting for a new future poll instead. Already submitted ballots appear to be irrecoverable. We apologise for the inconvenience.
According to the CIVS admin, a data corruption like that has never been seen before. The CIVS FAQ (archive link) implies this to be first time data has been lost since 2006. As far as we understand, the Berkley DB files got corrupted in such a way that at least the table of the voters who have voted is not handled correctly anymore.
We have no insight into the CIVS server, but are in contact with the admin to try figure out what went went wrong in more detail and how to best proceed. We will follow up with another announcement no later than this Friday.
As a consequence of the above, we can again allow email updates until the new poll is started. To do so, follow these steps.
You can also still prepare yourself to vote by looking at the candidates.
Because we don’t have sufficient confidence in the CIVS problem not reoccurring again, we have decided to use OpaVote to collect the ballots instead. We’re still going to use CIVS tallying of the results, so that they won’t get influenced based on how ballots are collected. Note that OpaVote (like CIVS) allows the voters to get an anonymised list of all the ballots cast, and we will enable this after the election.
Unlike CIVS, OpaVote doesn’t require a separate activation step for emails, so all eligible voters with email addresses considered valid will be sent emails with the voting link from noreply@opavote.com, as well as voting reminders every 3 days.
You must cast your vote by 2024-11-03 23:59:59 Sun in Anywhere on Earth time, meaning as long as it is still the given day anywhere on the planet (i.e. at the end of that day in UTC-12). After the poll is closed, votes will not be accepted for any reason.
Note that, unlike CIVS, OpaVote does not allow to correct your ballot once cast! Furthermore, you cannot rank two candidates the same, except for unranked candidates. We will treat all the unranked candidates as tied for the last place when tallying.
Because OpaVote’s terms has potential sanctions for undeliverable emails and doesn’t have a separate email activation step like CIVS, we have removed some voter email addresses that couldn’t be reached.
We cannot change the voter emails where the voting link has been delivered, but for missing and bouncing addresses, users can still update their email address. Everybody without an email address in voters.json will be notified once more.
I know it’s a bit late for this, but I have a colleague whom is a bit of a voting systems nerd who questioned the use of “proportional / best candidate” mode proposed to rank the results of the voting as per GitHub - NixOS/SC-election-2024: 2024 Election for the Steering Committee , particularly the “best candidate” part of that.
And indeed I looked at Condorcet Internet Voting Service to see what that meant, and it doesn’t seem ideally compatible with our desire to elect more than one person in a single election.
Best candidate. In best-candidate mode, the voter’s goal is to get a single very good candidate elected, and the quality of other elected candidates is a strictly secondary consideration. This is appropriate for an election where the voter really only cares about the best candidate: for example, the selection of a set of entree dishes for a menu, where the voter will only eat one of the entrees. Here, two committees are compared using their best candidates (according to the voter); other candidates are considered only if the voter has no preference between the best candidates. In the examples above, x would be preferred to yz in either case, because x is preferred to y. If the most-preferred candidate in each committee is equally preferred, then the second-most preferred candidate is used, and so on up to candidate f.
I think the alternative “Combined weights mode” would make more sense.
Can anyone give a defense for why Best Candidate mode is a sensible way to rank our votes?
There is no proportional representation component to this election, right? That makes it a particularly bad choice.
I’m somewhat familiar with social choice theory. Rank aggregation is not a straightforward thing. This is worthy of some consideration.
In my opinion, the most theoretically justifiable method is Kemeny-Young. Unfortunately, it’s quite difficult to compute. Maybe someone will take that as a fun challenge 
(This is not in any way an aligned answer from a group, but this does reflect how I perceived — and participated in — some of the relevant discussions within NCA)
On the one hand, even combined weights combines the weights of your best candidates, so it is less «combined weights» than it sounds.
On the other hand, this makes the semantics of addition of scores complicated, too.
On the third hand, if SC needs to be able to represent community opinions in internal discussions, it is important for the process to work to trust at least one person there to represent the arguments from the contributors, including yours, well. It won’t be all about voting, the SC is small enough to also do some figuring out what’s going on.
On the fourth hand, there are skeletons in the closet for proportional-Condorcet in general in terms of what exactly the tallying produces, and there are drawbacks to STV too and some people like the general properties of Condorcet that still apply here and it’s all complicated. (The choice is limited to approaches with some proportionality and there are not that many available in terms of implementation)
On the fifth hand, it looks like ranked-choice popularity compared to range-voting is partially related to the fact that there are slightly more people for whom it is easier to rank than to score with any useful level of detail.
On the sixth hand, the popularity of ranked-choice voting provided us with an easier fallback as «rank as many as you wish» is available in many places and high-level-of-detail scores are more niche.
On the seventh hand, given that all approaches of summarising have significant complications and drawbacks, the question of limiting the level of detail the voter can swerat over to not too little not too much is relevant.
So it is all somewhat messy in any case, and the octopus says hi and waves with the eighth hand.
All that said, if we know we’re using proportionate representation ranking, the CIVS docs really can’t be clearer about which mode is applicable wrt to best-candidate vs. combined-weights in a multiwinner election:
Combined weights. In combined-weights mode, the voter gives a nonnegative weight to each candidate instead of ranking the candidates. The voter’s goal is to maximize the sum of weights of selected candidates. This is an appropriate criterion for elections where the quality of all the candidates is important to the voters, such as the election of an actual committee that will be voting on some issues.
https://civs1.civs.us/proportional.html
The SC is “an actual committee that will be voting on some issues”. In which case, the CIVS docs plainly say “use ‘combined weights, don’t use best-candidate’”. I’m concerned that the decision to use best-candidate mode was just an oversight, and I have no idea what impact it will have on the outcome, because it seems like a nonsensical choice for any multiwinner election.
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: