[Koha] Koha license upgrade voting method

[MJ Ray]

[Sorry to anyone who had problems emailing me the last day or two.  I
think my on-list domain (phonecoop.coop) had one DNS server change IP
address before that co-op's DNS admin reconfigured, but it works now.]

Thomas Dukleth wrote:
> On Thu, January 6, 2011 16:58, MJ Ray wrote: [...]
> > 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.  

Well, without knowing how people would have voted in an ordering
system, it's hard to compare.

> 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.

Can anyone think of other issues which haven't reached some
compromise after the come to the mailing list?

> [...] 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'd like to see something similar happen in this vote if possible,
hence the later suggestion of some way for options to join and leave
the vote.

> > 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?

-ve = negative = all voting options below 0.

> 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.

In the positive-negative range voting, some average is the
result.  I don't think we need to use truncated mean (the mean
vote ignoring the highest and lowest N% of votes) and I think
I prefer the mean to the median, but it's a choice we can make.

> 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.

A far more learned expert has criticised that article much more
robustly than I can, but I feel that a basic principle of
consensus-building is that a majority should not overrule a
substantial minority.

> Perhaps there is a means of combining range voting with preference voting.

I'm not sure how we'd do that?

[...]
> 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.

That is exactly the debian ambiguity problem to which I referred!
I really don't want us to vote 98-to-2 for GPL-2 for example, then the
2% interpret it as a wish to start the process all over again.
If we want further discussion, we should vote for further discussion
explicitly and not have a possible stand-in.

I know voting for GPL-3 would be going through a one-way door, so we
couldn't vote to return to GPL-2 later (well, probably not and at
least not without a lot of work) but if we want to retain GPL-2, we
should vote to retain GPL-2 and then the project should remain GPL-2
for a while.

So is everyone OK with a "further discussion" option being present?

> 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?

I think it could, but I don't know of experiments about it.

[...]
> > 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?

This may be a difficult question to answer.  The common process
I've seen elsewhere is if an option gets some required number of
supporters, then it is added to the ballot.  If enough supporters
revoke their support that it falls below the requirement, then it
is removed.

> 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.

I think the most obvious possible new options are additional
permissions or exceptions on top of each licence?

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