[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Our supermajority requirement has changed !



On Wed, 26 May 2004 00:53:41 +0100, Ian Jackson
<ian@davenant.greenend.org.uk> said:  

> IME people nearly always put FD ahead of the options they disagree
> with.

	My experience has been different: people seem to put a number
 of options ahead of the default; and I would hope the TC members are
 enlightened enough to realize that the voting mechanism is merely a
 tool for determining decisions; and only put solutions they really
 can't liove with behind the default option (this is called voting
 sincerely).

	As I have said for the general resolution voting methods, if
 we have come to the ppoint that winning has become more important
 than resolving issues, we have larger probelms than the voting
 methods.

>          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

	On what basis do you thinbk it is worse? If we all want a
 solution, but there is no solution better than the default (as
 evidenced by no one being able to loive with the other solutions), I
 think the vote mechanism is reflecting thew will of the members.

	Surely we are intelligent enough to realize that, and vote
 accordingly? If we are not that competent, should we be on the TC in
 the first place?

> 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.

	This is a social problem, and does not need a technical
 solution. 


>> 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.


	Well, mathematically, the effects are not the same. A 6(3)
 also refers to the general resolution, where the difference between
 3.0132:1 and 3.5099:1 majority is 25 votes, assuming 100% voters out
 of 911.

	Assuming 55%participation, 911 voters, (501 people voting),
 we have 3.0080:1 (376 for) vs 3.5135:1 (390 for), a difference of 14
 votes.

	So no, I do not think changing the requirement to 3.5 is the
 sane thing.

	manoj

-- 
Oh, wow!  Look at the moon!
Manoj Srivastava   <srivasta@debian.org>  <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



Reply to: