[New subject for narrower aspect. My original subject was a little too long for some email subject displays and more importantly I made a mistake in the word order.] Reply inline: Original Subject: Re: [Koha] Restarting the Koha copyright license ballot upgrade process On Thu, January 6, 2011 16:58, MJ Ray wrote:
Thomas Dukleth wrote:
4. VOTING METHOD.
M J Ray had suggested using some method for voting to consensus which would allow revoting. He needs to provide some details for how that would work along with a method of vote counting which maximises preferences.
On the issue of preferential voting generally, see the Wikipedia preferential voting article, http://en.wikipedia.org/wiki/Preference_voting .
That's a good start.
4.1. SUMMARY OF PROBLEM
A problem with this vote is that the candidate options are very similar and we need to pick the one which is most acceptable to most people. The candidate which only has the most first-preference votes (which would win a first-past-the-post election) or even the best position in a preference ranking (which would win a single-winner single transferable vote election) may not be the best-supported one if it is too divisive and completely unacceptable to some project supporters.
Certainly, the similarity of the options may be confusing to some people. Divisive outcomes are to be avoided, hence the great advantage of some system for voting to consensus. The straw poll at the meeting which prepared a plan for the ballot process suggested hardly any division, however, we do not know about the community at large. We need to address the potential for an outcome which might be chosen by most everyone, but yet be unacceptable to some people. I am not aware of any people in such a position for this issue but we should be alert to the possibility. The Koha community is an inclusive community and people should not perceive that they are unwelcome in the community choosing a particular option.
4.2. A SUGGESTED VOTING METHOD
The debian project uses a type of Condorcet voting with some tweaks. Its description is at http://www.debian.org/devel/constitution#item-A That's a sort of preference voting.
I like the advantage of preference voting for maximising individual preferences. Preference voting aims to favour the option which has the most support if expression of preference would not be divided by more than two options. Most importantly, when there are more than two options, protects against an option with minority support winning merely because it has the largest number of first preference votes. If options are A, B, or C; and first preference votes are 101 for A, 100 for B, and 100 for C; then A should not win merely by having the most votes when the majority may prefer any option but A. Some version of the Condorcet method is often considered to better conform to the preference maximising objectives of preference voting than other non-Condorcet preference voting methods. Debian has some rules about minimum votes which do not conform to the Condorcet method and can lead to some strange results under some circumstances but a simple amendment to the minimum vote rules used by Debian would correct the problem.
But I think I lean towards some sort of range voting rather than preference voting. See http://en.wikipedia.org/wiki/Range_voting After all, we already see this in meetings, although most votes are uncontroversial and mostly a stream of explicit +1s or silent 0s.
Most every question at meetings has only two options, essentially yes or no, not counting abstention. We essentially have approval range voting at meetings but I do not know of a case when a different voting method would have actually changed the outcome. Issues on which there is no clear consensus or which need wider input than those present at an IRC meeting are defered to the mailing list for discussion. Some particular option almost always has overwhelming support. Almost every elected office in the Koha community has only one candidate. When there is a strong objection from someone to an option presented at an IRC meeting, then the question is changed; such as when someone has a scheduling problem with a proposed date to hold the next meeting, the proposed date is changed to accommodate.
I think I would centre the range on 0 and ask people to vote on each option between -10 and +10, but try to avoid putting two options on the same number. We should understand -10 as the option is completely unacceptable and that voter will probably start looking for the exit. We should ask for a reason for any -ve vote, to see if that can be changed by some amendment to the option. I'd like those reasons to be announced anonymously and used as a start for some further discussion.
Does that voting system make sense? Can we do better?
Is "-ve a typing mistake" or a voting option? I understand the goal of range voting to capture the strength of individual preference as opposed to merely the presence . I am not certain exactly how range votes are counted. The criticism of range voting linked from the range voting Wikipedia article concerns me, http://archive.fairvote.org/?page=1920 . A minority of one should not be counted to outweigh the votes of the vast majority. Perhaps there is a means of combining range voting with preference voting.
4.3. BUILDING CONSENSUS: FURTHER DISCUSSION OR BALLOT-REWRITING?
There is an option in the debian project's votes for "Further Discussion" but when that wins, it's sometimes understood as a vote for no change, rather than automatically triggering a further round of discussion, proposals and voting. I think we won't have that problem because "no change" will be explicitly on the ballot, so should we include a "further discussion" option and commit to actually do another round if that option wins?
If we don't like a "further discussion" option, one alternative would be to: 1. have a relatively long vote period, 2. allow revoting, 3. continue discussions while voting, 4. post interim results during the vote (2 or 3 times perhaps?) and 5. have a pool of people trying to build consensus among the voters could help us to gather around the best-supported option.
Would that be better than including "further discussion"? It means that the vote will only run for a finite time, which is both good (there is a definite decision day) and bad (it risks dividing the community if the discussion goes badly and does not build consensus).
All ballots should have some means of exercising a postpone for further discussion option, except perhaps for some vital elected office which we cannot afford to leave vacant. Certainly, choosing to retain GPL 2, with the or later version option, is almost the equivalent of choosing to postpone for further discussion. A sufficiently long voting period with revoting should be sufficient for obtaining consensus. Interim results should be posted at least three times. Would a daily automatic calculation of the results help build a consensus? We want the widest degree of informed participation. Multiple ballots with intervening discussion periods may be considered tiresome and lead to a loss of attention to the issue and a decline in participation relative to an long voting period allowing revoting. Multiple ballots would require participants to vote again with a new opportunity to re-evaluate their choices but that may impose an unnecessary effort on whatever portion of people would be firm in their choices.
The debian project allows revoting, but only votes after the discussion period has finished, so the ability to change one's vote doesn't seem to help to build consensus. Revoting's main purpose there seems to be correction of errors when filling out the ballot.
I assume that discussion is always open even if there is no specifically reserved period of discussion.
If we have a single voting period, should we allow new compromise options to enter the ballot and defunct options to leave the ballot, up to (say) the day after last interim results before the vote closes?
What procedure would allow new options to enter the ballot? The limited set of possibilities for upgrading the copyright license from GPL 2, invoked with the or later version option, seem to greatly limit the possibility of alternative compromises to add to the known cases of retaining GPL 2, GPL 3, or AGPL 3: each invoked with the or later version option. The only compromise alternatives which I can conceive are adding some condition for upgrade ballot options, such as for Koha 3.6 instead of 3.4 or when adding some specified new feature. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783