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. 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. 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. 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? 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). 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. 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? Thank you for your attention and I await your replies with interest. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha