[Koha] Koha license upgrade voting method

[Thomas Dukleth]

[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