Select voting tool for votes

[bnb]

In today's CPC meeting, there was a discussion about voting tools and which to use. As an extension, I recommended and took the TODO of creating an issue to discuss choosing a voting tool.

My recommendation: chose one tool for all votes so there are no surprises or unexpected differences between one vote and the next. Having run a suite of votes as Node.js CommComm chairperson, I've found this was best rather than jumping between tools (which is what we did for a while!).

If folks would like to recommend voting tools, feel free - however we should probably narrow it down to a few and either just agree on one or... have a vote 😅

[tobie]

Worth noting results diverge quite a bit depending on the voting method used. Some voting mechanisms create a more representative and diverse outcome than others. So what solution we pick signals who we are and aspire to be, to some degree. OpaVote provides a fairly thorough and well documented overview of the different voting mechanisms.

As not all services provide all voting methods, deciding which voting method we use upfront seems important.

From a purely practical perspective, knowing how many people have a vote and how many candidates there can be helps inform costs. So having that information upfront would be useful.

Finally, I 100% agree with @bnb that relying consistently on one system is key to build trust.

[brianwarner]

Thanks for doing this!

In the call I'd suggested CIVS as a possibility, as it's used pretty widely by other projects: https://civs.cs.cornell.edu/

We use it elsewhere because it supports multiple candidates, and can handle both open and invite-only votes (without requiring a user account). In general it's worked pretty well, in part because the multiple-candidate math can get hairy and it handles that for you. :-)

[mcollina]

+1 for civs

[tobie]

I'd be happy using civs if we only used its experimental proportional representation mode. Otherwise, we'll be creating winner takes all situations which I don't think is what we should stand for as a group.

[joesepi]

@tobie as someone who doesn't have a deep understanding of election techniques, can I ask you to share your reasoning in above comment regarding experimental proportional representation? Thanks.

[bnb]

FWIW we have used adoodle in the past in the CommComm and it worked pretty well: https://www.adoodle.org/

[eemeli]

I'm with @tobie on this one. Having been involved in the management and implementation of some voting systems that needed to deal with cliques and otherwise adversarial conditions, any voting system that does not directly address the fairness of a vote which is selecting more than one winner is sub-par.

It also helps that CIVS is both open source and free.

[tobie]

@joesepi the CIVS website does a good job of providing an example. Let me quote it below, emphasis mine:

CIVS supports an experimental mode in which it can be used to select multiple candidates while enforcing proportional representation. We refer to the possible sets of selected candidates as committees. The goal is to pick the best committee in a proportional way. Roughly speaking, this means that a set of voters can only influence a fraction of the selected committee that is proportional to the number of voters in that set.

For example, suppose that 60% of the voters want candidates a, b, c, d, and e, in that order, but the other 40% want x, y, z, u, and v. Ordinary Condorcet voting will rank a, b, c, d, and e higher than the other five candidates, because a majority likes them better. For some tasks, electing these five (a, b, c, d, e) is the right way to run the election. However, if the goal is to find a five-person committee that fairly represents the whole population, the committee abcde gives 40% of the population no representation at all. By contrast, the proportional representation algorithm used by CIVS elects the committee abcxy, achieving perfect proportional representation.

It is really important to note that CIVS's default mode DOES NOT DO THAT and has a "winner takes all" model. Only the experimental mode provides proportional representation. This is why I would, personally, chose another solution, like OpaVote, that supports proportional representation natively and not just as an experiment. That being said, CIVS's experimental proportional representation mode sounds like an acceptable compromise. But we'd need to be specific about using the proportional representation.

[tobie]

Another way of looking at this: what tool we use is a tooling decision that could be taken by foundation staff, what vote counting mechanism we chose is a policy decision that belongs to the CPC.

[kborchers]

A big +1 to @tobie's last comment. We could go in circles while trying to simultaneously decide which voting method and which tool to use but I believe the CPC should make a decision on the voting mechanism ASAP, document that decision in our governance, and then based on that policy, foundation staff can find/implement a tool which works within that policy.

[eemeli]

I think it's important to note here that the immediate vote is for voting members that may be nominated by regular members. Unlike practically all other votes, this is not in fact an activity of the whole CPC, but strictly of its regular members. This means that for the immediate issue, the decision on voting method, administration and tooling needs to be made by the regular members, rather than the whole of the CPC.

Therefore, I think it's a bit dubious to base a policy decision on pretty much the only activity of the CPC where its voting members are explicitly not empowered to have a vote. We should instead just select something now that's suitable for the immediate case, give it a test run, and then consider the policy going forward while being informed of the results and experience.

[joesepi]

In an effort to move this forward as the election should be underway, I propose we use OpaVote for this election. Regular members would need to approve this proposal.

[eemeli]

I approve of the proposal to use OpaVote.

[mhdawson]

I approve of the proposal to use OpaVote.

[dmethvin]

I approve of the proposal to use OpaVote. We can revisit if we or others feel that it is not achieving a fair outcome.

[kborchers]

I approve of the proposal to use OpaVote.

[bnb]

I don't care which platform we use. I approve whatever the majority agrees to 👍

I would like to further clarify that I disagree with the assertion that Regular Members should decide their tool independently of the Voting Membership. That ends up being unnecessarily divisive between the two groups when I'm sure we could agree on one tool that suits us all. However, I think that can be conducted after this first vote for regular membership.

[molant]

+1 on OpaVote

[mhdawson]

I would like to further clarify that I disagree with the assertion that Regular Members should decide their tool independently of the Voting Membership.

I agree. I think we should agree on tools as the CPC and use them across the different voting instances unless there is a really good reason for one to be different.

[eemeli]

Having now experienced OpaVote for this as well as administering another non-OpenJS vote, I would be very happy to support it for further use. The $10/election cost is well worth the service that's provided.

[eemeli]

Added this to the agenda in order to get some kind of a decision on this.

[bnb]

I'd like to propose that we just pick one - either everyone agrees on one or the chair picks one. This really shouldn't be a complicated decision.

[bnb]

(that isn't to undermine the assertion of it being discussed in the meeting, just raising that for the meeting)

[joesepi]

OpaVote worked well last time. No objections to choosing OpaVote as the tool moving forward. Foundation staff agrees. Foundation staff will assist in executing votes.

[joesepi]

Email operations@openjsf.org for election support. Thanks @jorydotcom @brianwarner and @rginn for your help here.