----- GENERAL RESOLUTION STARTS -----

   Constitutional Amendment: TC Supermajority Fix

   Prior to the Clone Proof SSD GR in June 2003, the Technical
   Committee could overrule a Developer with a supermajority of 3:1.

   Unfortunately, the definition of supermajorities in the SSD GR has a
   fencepost error.  In the new text a supermajority requirement is met
   only if the ratio of votes in favour to votes against is strictly
   greater than the supermajority ratio.

   In the context of the Technical Committee voting to overrule a
   developer that means that it takes 4 votes to overcome a single
   dissenter.  And with a maximum committee size of 8, previously two
   dissenters could be outvoted by all 6 remaining members; now that
   is no longer possible.

   This change was unintentional, was contrary to the original intent
   of the Constitution, and is unhelpful.

   Additionally, following discussion of the supermajority mechanism
   within the project, it was realised that certain situations could
   cause anomalous results:

   * The existing rules might result in a GR or TC resolution passing
     which was actually the diametric opposite of the majority view.

   * The existing rules unintentionally privilege the default option
     in evenly contested TC votes where no supermajority is required,
     possibly encouraging tactical voting.

   Therefore, amend the Debian Constitution as follows:

   (i) Delete most of A.6(3) (which implemented the supermajority
   by dropping options at an early stage).  Specifically:
      - Move A.6(3)(1) (the definition of V(A,B)) to a new subparagraph
        A.6(3)(0) before A.6(3)(1).
      - Remove the rest of A.6(3) entirely, leaving A.6(2) to be
        followed by A.6(4).

   (ii) In A.6(8) replace all occurrences of "winner" with
   "prospective winner".  Replace "wins" in "which of those options
   wins" with "is the prospective winner".

   (iii) In A.6(8) add a new sentence at the end:
     + If there is no elector with a casting vote, the default option
     + wins.

   (iv) Add a new section A.6(9) after A.6(8):
     + 9. 1. If the prospective winner W has no majority requirement,
     +       or defeats the default option D by its majority
     +       requirement, the prospective winner is the actual winner.
     +    2. Otherwise, the motion has failed its supermajority with
     +       the consequences set out alongside the majority
     +       requirement (or, if unspecified, the default option
     +       wins).
     +    3. An option A defeats the default option D by a
     +       majority of N:M if M * V(A,D) is greater than or equal to
     +       N * V(D,A).

   (v) In
       * 6.1(4) (Technical Commitee power to overrule a Developer)
       * 4.1(4) (Developers' use of TC powers by GR) (if another
           constitutional amendment has not abolished that
           supermajority requirement)
   in each case after the "N:M majority" add
     +   ; failing that, the prospective winning resolution text becomes
     +   a non-binding statement of opinion.

   (vi) In A.3(2) delete as follows:
	 2. The default option must not have any supermajority requirements.
     -       Options which do not have an explicit supermajority requirement
     -       have a 1:1 majority requirement.

   For the avoidance of any doubt, this change does not affect any
   votes (whether General Resolutions or votes in the Technical
   Committee) in progress at the time the change is made.

   The effect is to fix the fencepost bug, and arrange that failing a
   supermajority voids the whole decision (or makes it advisory),
   rather than promoting another option.  The fencepost bugfix will
   also have a (negligible) effect on any General Resolutions
   requiring supermajorities.  And after this change the TC chair can
   choose a non-default option even if it is tied with a default
   option.

   ----- GENERAL RESOLUTION ENDS -----