Re: supermajority options
>>"Branden" == Branden Robinson <firstname.lastname@example.org> writes:
Branden> On Tue, Nov 19, 2002 at 05:54:30PM -0500, Raul Miller wrote:
>>  The simplest: discard supermajority entirely. Nothing special is
>> required to override "important decisions". This has some elegantly
>> simple mathematical properties but I don't know of any other argument
>> for it.
Branden> I support this. I'd rather see whether or not we screw up in the
Branden> absence of supermajority requirements instead of just assuming that we
I think this is not really a matter of screwing up, this is a
matter of, in some cases, avoiding the tyranny of the majority;
allowing a preset minority to block an amendment.
There are a number of cases where this may be used; one of
which apparently gets Branden's goat: requiring changes to what I
called foundation documents to get the buy in of a more than 51% of
My contention is that there are a number of documents that
define what the project is; and that we agreed to follow when we
signed on to the project, and any changes to these documents, which
cut to the heart of not just the developers, but the whole free
software community (the DFSG is known as the gating criteria for free
software far beyond the extents of the project), ought to be signed
on by _most_ of the developers.
So, supermajorities are, in my opinion, still needed for cases
where we want a (very) rough consensus, where mere majority ought not
be the sole criteria for adopting a measure.
If a person (a) is poorly, (b) receives treatment intended to make
him better, and (c) gets better, then no power of reasoning known to
medical science can convince him that it may not have been the
treatment that restored his health. Sir Peter Medawar, The Art of the
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C