Default options (Technical Committee supermajority)

[Ian Jackson <ian@davenant.greenend.org.uk>]

The Condorcet/Cloneproof-SSD GR changed section A.6 of the
constitution with some unexpected effects from the new A.6(3):

1. In a vote where there is a supermajority requirement, the ratio of
   votes in in favour to those against must _exceed_ the specified
   supermajority ratio.

2. In a vote where there is a default option, the elector with the
   casting vote used to be able to decide amongst the tied options.
   Now, when there is a tie involving the default option, the default
   option always wins.

Neither of these have much impact on General Resolutions, where the
number of people voting is so high so that what amounts to an
off-by-one error is not very relevant.

However, they have some significant effects on the Technical
Committee.

1. Supermajority:

  6.1(4) says that the TC requires a 3:1 majority.  However, A.6(3)
  interprets this to mean that the number voting in favour must
  exceed those voting against by a factor of _more than_ 3.  Since the
  TC is never more than 8 people, this effectively means that the TC's
  supermajority for overruling a developer has been changed from 3:1
  to 4:1.

  This weakens the ability of the TC to overrule a developer when
  exactly one TC member disagrees.

2. Casting votes:

  6.3(2) says that the TC chairman (that's me ATM) has a casting vote.
  However, A.6(3) and A.3(3) mean that the casting vote cannot be used
  to choose between Further Discussion and another option - FD always
  wins.

  This takes away much of the point of the casting vote, which is to
  allow an issue to be resolved even when the committee is `hung'.

Also, of course, there may be other people who use the Debian vote
counting system, incorporating it by reference.  Those people may not
be aware of these unforeseen effects.  The supermajority requirement
off-by-one error is a particularly clear bug, where the main body of
the constitution appears to specify one thing, but is undermined by
the details of the vote counting.

Looking at historical TC votes, had these changes been in effect the
outcomes of the decisions on VESA framebuffer support and on library
dependencies would have been different.  The VESA FB vote (which was
3:1) would have no longer overruled the maintainer, but instead merely
been a recommendation.  The library dependencies vote would have
resulted in Further Discussion winning.


I'm convinced that these changes were unforeseen because none of the
rationale or documentation surrounding the Cloneproof-SSD GR notes
either of them.  If these were intentional changes then the GR ought
to have modified 6.1(4) to change 3:1 to 4:1, rather than introducing
a fencepost bug in the voting system ...


So what should be done ?  It seems to me that the clear answer is a GR
to fix the voting system.  This could be achieved by changing A.6(3),
as follows:

 Any (non-default) option which does not suffice compared to the
 default option is dropped from consideration.

   1. Given two options A and B, V(A,B) is the number of voters who
      prefer option A over option B.
   2. M:N is the supermajority ratio required for A; M:N is 1:1 if no
      supermajority is required.
   3. An option A suffices compared to
      the default option D, if M * V(A,D) is equal to or greater than
      N * V(D,A).

or some similar text.  This would restore the supermajority situation
so that when a 3:1 majority is stated as being required, a 3:1
majority does suffice, and simultaneously arrange that casting votes
can once more be used to choose between FD and other options.


What are the opinions here ?  I'm not asking for sponsors or drafters
of a GR atm; I can draft it myself if necessary and the TC has the
power to introduce a GR by itself anyway.

I would like to know whether people agree with my analysis and
proposed fix.


Ian.