On Thu, Jan 31, 2008 at 07:24:50PM +0000, Ian Jackson wrote: > The Technical Committee (and those interested in the libc's resolver > behaviour) are having some trouble because of an off-by-one error in > the supermajority specification in recent versions of the > constitution. > > > This was discussed in > http://lists.debian.org/debian-ctte/2004/05/msg00027.html > and has recently caused trouble for an actual vote. > > To give a clear and simple hypothetical example: suppose 120 > developers vote on constitutional amendment GR, with a simple Y vs. FD > ballot (requires 3:1). Suppose the quorum is met and 90 vote in > favour and 30 against. > > Then according to the current wording, Y fails to defeat FD by 3:1 > because 90 is exactly 3 times 30, whereas the requirement from A.6 is > that it should be strictly greater. I'm not so sure this is an off-by-one *error*; for example, when simple majority is required, then a strict 50% against vs 50% in favour result should result in the status quo being kept. A simple majority thus needs to say "*more* than X percent of people need to agree for the vote to pass", and it seems reasonable to give a supermajority system the same set of rules. Having said that, I agree with you that it makes sense for the TC to not require 'X + 1', since the electorate is so small anyway; and on the whole of Debian, the numbers don't really matter that much, anyway; in principle, I don't object to this change for supermajority votes. In effect, it's a change of what "supermajority" means, but with not much problems in practice (and serious practical benefits, as in the TC). > I suggest the following wording: > > * Replace `strictly greater than' with `at least' in A.6(3)(2). > The result reads: > 2. An option A defeats the default option D by a > majority ratio N, if V(A,D) is at least N * V(D,A). > > The immediate effect of this is that options which are tied with > the default option are not dropped; I don't think that's a good idea. If a vote is tied with the default option, it failed to convince a *majority* of voters. I don't think the principle of majority is one that should be touched if we want to hold the semblance of democracy in our votes; for that reason, I can't agree with your proposal as is. If you were to change it so that your proposed change would only apply to supermajorities, I'll probably second it. > options with a supermajority requirement are likewise not dropped > if they exactly meet the supermajority requirement. > > This has two practical consequences: > > Firstly, the off-by-one error in supermajorities is fixed: if the > number of Yes voters is exactly 3x or 2x (as the case may be) > the number of FD voters, the resolution is considered successful. > (In a vote with no cycles and where a position option meets a > supermajority, FD will be eliminated from the Schwartz set by > A.6(6).) > > Secondly, where there is a casting vote, it allows the elector with > the casting vote to choose between FD and Yes if they are tied. The rest, I think, you should put in different proposals; I have no problem with them, though, and could probably second them. > While we're looking at this text, the use of `defeat' is slightly > confusing, and made more so by this change, because the criterion for > defeating the default option in the new A.6(3) is different from the > definition of defeat provided in A.6(4). So I propose one other > change to go along with this: > > * Change to `defeat [the default option]' throughout A.6(3) to > `overcome'. That gives: > > Any (non-default) option which does not overcome the default > option by its required majority ratio is dropped from > consideration. > > 1. Given two options A and B, V(A,B) is the number of voters > who prefer option A over option B. > 2. An option A overcomes the default option D by a majority > ratio N, if V(A,D) is at least N * V(D,A). > 3. If a supermajority of S:1 is required for A, its majority > ratio is S; otherwise, its majority ratio is 1. > > > Additionally, the TC had considered experimenting with the idea of > rotating the post of TC Chairman, to try to make things a bit more > dynamic. However it's not clear with the current constititution that > the TC has the power to (for example) set out a timetable specifying > the chairman at various times. > > So I would like to suggest replacing 6.1(7) with something like: > > 7. Appoint the Chairman of the Technical Committee > > The Committee may by resolution specify which of its members is > its Chairman. If it does not do so, or circumstances arise which > are incompatible with the resolution, the Chairmanship is vacant > until this situation is remedied. > > /Rationale: For example, the Committee might establish a schedule > for a rotating Chairman, or appoint a Deputy to take over under > specified conditions./ -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Attachment:
signature.asc
Description: Digital signature