Re: Our supermajority requirement has changed !
Manoj Srivastava writes ("Re: Our supermajority requirement has changed !"):
> Yes, there is a discrepancy between 6.1(4) and A.6(3). If it
> were possible to have 9 members of the tech ctte, then a 3.5:1 super
> majority would also be possible, but the ctte seems to ve restricted
> to 8 members.
Indeed.
> This one is a difference, but not necessarily a bug.
Well, it seems to me that if the obvious reading of one part of the
constitution is later contradicted by a close reading of the section
covering the implementation details, that's a bug.
> If the committee is so split upon a course of action, and each
> option is unpalatable to an equal number of members, it does seem
> reasonable that the default option prevail. If we did get votes
> like A B : FD (or equal numbers of A:B:FD and B : A : FD votes),
> then the chairperson still gets to decide between A and B; and
> again, this makes sense, since the committee wanted a resolution
> other than the default option, but were split on which option to
> select.
IME people nearly always put FD ahead of the options they disagree
with. This feature also means that in the common case where
(a) everyone agrees that a decision should be made by the TC
eventually; (b) probably no-one is going to change their mind;
but (c) each individual member would prefer to revisit the issue than
to give in: it is optimal for each member to vote A:FD:B or B:FD:A,
even though this produces an outcome that is worse overall (the TC is
unable ever to decide). Any member who votes A:B:FD effectively hands
the vote over to the other side, because now B (which they dislike)
strictly defeats FD even though their own option A (which their
B:FD:A-voting opponents dislike) is eliminated.
> Ian Jackson <ian@davenant.greenend.org.uk> said:
> > I think the right fix is to delete the word `strictly'. If we do
>
> This is one of two possible options; one could just as easily
> add the word strictly to 6.1(4). I am personally inclined to remove
> the "strictly greater" requirement from A.6(3) (indeed, my initial
> coding up of the vote method in devotee did not adhere to "strictly
> greater"), but I guess the project membership could decide to go the
> other route.
I think if one were to change 6.1(4) the wording required to express
the true behaviour (_strictly more than_ 3:1 majority or some such) is
clumsy. If the Developers decide that the quorum for the TC
overruling should really be 4 voting in favour if one votes against
then IMO the right answer is to remove `strictly' from A.6(3) and
change 3 to 3.5.
> > [It] might be better to invent a different phrase for `defeat[s]
> > the default option' in A.6(3) because `defeats the default option'
> > in A.6(3) means something different to `defeats [an option which
> > happens to be the default option]' in A.6(4) onwards. Perhaps
> > replace `defeats' with `matches'.
>
> In a.6.4 onwards, there is no mention of the default option,
> since it is no longer treated any differently than any other
> option. I do not see any ambiguity here; perhaps I am missing
> something.
I agree it's not ambiguous, but the dual use of the term `defeat'
could be confusing. If we're changing it to be even less like the use
later in A.6, it would probably be better to use a different word.
Ian.
Reply to: