The fix to the constitutional supermajority bug has been delayed
rather. Sorry about that. I have drafted what I think is an
implementation of our conclusions here and in the TC.
Opinions welcome.
Thanks,
Ian.
- 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 -
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21419.25157.72007.339...@chiark.greenend.org.uk
