Re: Request for comments [voting amendment]

[Buddha Buck]

Raul Miller wrote:

This is not a full draft.  In this post, I'm only including
text for replacing A.6 of the constitution.  I wanted to
also rewrite the changes to A.3, but I've got to run some
errands tonight and I'm not going to have time to write up
a full draft.

Please let me know of any flaws in the following partial draft:


I'd like some clarifications...



  A.6 Vote Counting

1. Each ballot orders the options being voted on in the order
   specified by the voter.  Any options unranked by the voter are
   treated as being equal to any other unranked options and below
   all options ranked by the voter.


Definition:  A "ballot" consists of a ranking A>B>C>D>... of options 
submitted by a voter.  It defines a total ordering of options for a 
particular voter (i.e., for any pair of options A and B, we can claim 
that a particular voter feels either A>B, AB, then 
B

Let |A>B| be the number of voters who voted A>B.
Similarly, for |A(Obviously, |A>B| + |A=B| + |Athe definition of a ballot.)



2. Options which do not defeat the default option are eliminated.

   Definition: Option A defeats option B if more voters prefer optio
   A over option B than prefer option B over option A.


Let A>>B ("A defeats B")if |A>B| > |B>A|
Let A==B ("A ties B")   if |A>B| = |B>A|
Let AA|
(Note: A==A, for all options A)

Eliminate all options A if Default>>A.

Clarification:  What if Default==A?


3. If an option has a quorum requirement, that option must defeat
   the default option by the number of votes specified in the quorum
   requirement or the option is eliminated.


Does is mean:

Eliminate A if |A>Default| < Quorum

or

Eliminate A if |A>Default| - |Default>A| < Quorum

Again, how do we deal with that |A=Default| case?



4. If an option has a supermajority requirement, that option must
   defeat the default option by the ratio of votes specified in the
   quorum requirement or the option is eliminated.


(?) Eliminate A if |A>Default| / |A

5. If one remaining option defeats any other remaining options,
   that option wins.


s/any/all/

"Condorcet Winner"

If there is a remaining option A, such that for all remaining options B, 
either A=B, or A>>B.



6. If more than one option remains after the above steps, we use
   Cloneproof Schultz Sequential Dropping to eliminate any cyclic
   ambiguities and then pick the winner.  These represent a procedure
   and must be carried out in the specified order:

   i. All options not in the Schultz set are eliminated.

  Definition: An option C is in the Schultz set if there is no
  other option D such that C is in the beat path of D AND D is
  not in the beat path of C.


Let A>>>B mean there is a possibly empty sequence C, D, ..., E, F of 
remaining options such that A>>C, C>>D, ..., E>>F, F>>B


Then B is on the beat path of A.

The Schultz Set = { A | A>>>A }

Note:  Because A==A, it isn't the case that A>>A, so if the Schultz set 
includes A, then there must be a B!=A such that A>>B>>...>>A.  Since 
A>>B, we then have B>>...>>A>>B, so B is also in the Schultz set. 
Therefore, the Schultz Set can't be a Singleton Set.



  Definition: An option F is in the beat path of option G if
  option G defeats option F or if there is some other option
  H where option H is in the beat path of G AND option F is in
  the beat path of H.

   ii. Unless this would eliminate all options in the Schultz set,
   the options which have the weakest defeat are eliminated.

   Definition: The strength of a defeat is represented by two
   numbers: the number of votes for the defeated option and the
   number of votes for the defeating option.

   The more votes in favor of a defeated option, the weaker
   the defeat.  Where two pairs of options have the same number
   of votes in favor of the defeated option, the fewer votes in
   favor of the defeating option, the weaker the defeat.


So if we have two defeats A>>B and C>>D, then we lexigraphically compare 
(|B>A|, -|A>B|) and (|D>C|, -|C>D|)


What do you mean by "options with the weakest defeat"?

My understanding was that we were removing defeats from consideration. 
If, for example, there were four options A, B, C, D in the Schultz Set, 
we'd initially be looking at the following set of defeats, in strongest 
to weakest order:


A>>B
A>>D
B>>C
C>>A
D>>C
B>>D

After eliminating the weakest defeat (in this case, B>>D, we no longer 
consider it when determining the Schultz Set, as if we had declared 
B==D, so that neither B>>D or D>>B held.


So what do we really want to eliminate here?

And...

What if we had |D>C| = |B>D|, |D=C| = |B=D|, |Dneither D>>C nor B>>D was weaker than the other?  Do we eliminate both 
defeats?



   iii. If eliminating the weakest defeat would eliminate all options

Re: Request for comments [voting amendment]

[Buddha Buck]

Matthias Urlichs wrote:

Hi,

So who did come up with the mistake "Schultz", and did they eat too many
peanuts? ;-)

Anthony Towns:



The correct restatement is something more like:

{ x | forall y: y >> x --> x >>> y }



Or, in understandable language: The Schwartz set is the innermost unbeaten
set, or the smallest set of candidates such that none are beaten by any
candidate outside the set.


I think we need to come up with better, understandable, language.

Let me make sure I understand the Schwartz set.

Is it accurate to say that if x is in the Set, and y>>x, then y is in 
the set?


Is it accurate to say that if there is no y such that x>>y (i.e., x 
defeats nothing), then x is NOT in the set?


If we have options A, B, C, D, an A>>B,C,D, B>>C>>D>>B, then {B,C,D} is 
not the Schwartz Set because A>>B?  A is in the Schwartz Set because 
there is no x such that x>>A?


I'm trying to figure out where x>>>y comes into play with the Schwartz set.

What is the Schwartz set for:

A==B; A>>C,D,E; B>>C,D,E; C>>D>>E>>C?

I coul make an argument that {A} is the Schwartz set. It's an unbeaten 
set, and the smallest of all possible unbeaten sets (tied with {B}, etc. 
 The same argument could be made for {B}.  I think the answer is {A, 
B}, but I don't have any real justification for it.




As for resolution, I'd adopt the SSD method, which states
1- Determine the Schwartz set.
2- Drop the smallest defeat(s) within the set.
3- Repeat 1-3 until there's a winner.

See http://electionmethods.org/CondorcetEx.htm.
It explains all of this in reasonably easy-to-understand language.

Re: Another proposal.

[Buddha Buck]

Anthony Towns wrote:

On Tue, Nov 19, 2002 at 12:06:20AM +1100, Clinton Mead wrote:


Andrew Pimlott wrote:


So for example, the clause, in most drafts, that first eliminated
options that were defeated by the default option, was a direct
invitation to insincere strategic voting. It would encourage voters
to put the default option second, in an attempt to knock out the
other candidates early. Exactly what we're trying to avoid with the
Condorcet method.



But it's exactly what we're trying to achieve with the supermajority
requirement, isn't it? Allowing voters to vote strategically so as to
knock out candidates they don't like?


If I remember correctly, the biggest stumbling blocks in the voting 
proceedure committee were a) what is the supermajority requirement for, 
and b) how do we acomplish the same goal in a Condorcet-style voting system?


I still think that this is a fruitful route to pursue.

The main reason for supermajority requirements on some actions is to 
ensure that there is a large amount of support for those actions by the 
voting population.  Extraordinary actions like modifying the Debian 
Constitution should not be done without the support of the developers -- 
more support than for a ordinary resolution.


When you are limited to two choices, the requirement of a supermajority 
voting in favor of the extraordinary action over doing nothing clearly 
indicates a large amount of support for the extraordinary action.  This 
is why supermajority requirements are often written in that form.


But Condorcet voting (or ranked voting option in general) don't lend 
themselves to this same sort of overwhelming support idea, especially 
with a mixture of extraordinary actions, ordinary actions, and 
"do-nothing" actions.  It becomes harder to define what "supported by a 
large number of voters" means.


I believe our conclusion was to use the "default" or "None of the Below" 
 (NOTB) option on a ranked ballot as a proxy for approval on an 
Approval ballot.


In Approval balloting, it is easy to determine if a measure has 
supermajority support.  Simply look at the "yes" votes for an option, 
compared to the "No" votes.  If a supermajority voted "yes", then that 
option has supermajority support.


By defining an option as "approved" on a ballot if it is ranked higher 
than the NOTB, we can check the supermajority approval requirement for 
an option simply by comparing it to the NOTB option. When we say "an 
option defeated the default option by a supermajority", that's an 
operational way of saying "an option is approved by a supermajority of 
the voters".


That, I believe, is the rationale for judging supermajority requirements 
versus the NOTB option, as opposed to any other option.


But that doesn't solve the entire issue of extraordinary action. 
Examine the following results of an approval ballot between a non-free 
amendment A, non-free resolution b, and "further discussion" 
(Assumption: no majority vote would mean "stop talking and do nothing"):


Amendment A:  70%  (66% minimum needed for adoption)
Resolution b: 68%  (50% minimum needed for adoption)
Keep Talking: 25%  (50% minumum needed for adoption)

Here, A clearly got a higher rating that b, and beat the supermajority 
requirement as well.  But b was nearly as well liked.  My personally 
feeling is that the resolution, being the more "ordinary" action, should 
win over the extraordinary amendement in such a close ballot.  But it's 
hard to tell.  On an approval ballot, I'd probably scale the options 
based on their minimum vote needed to succeed, to get:


Amendment A:   1.06
Resolution b:  1.36
Keep Talking:  0.50

and note that that Resolution b: exceeded it's threshold by a larger 
proportion of the voters than the Amendment A, and thus, passes.


My feeling, for a Condorcet-style election procedure is that to deal 
with extraordinary options,


a) if there is an extraordinary option, there must be a NOTB on the ballot.
b) if an extraordinary option does not defeat NOTB by a supermajority, 
that extraordinary option cannot win.
c) The winner of the normal Condorcet-style vote resolution method (in 
our case, CSSD) wins, if able.


I thought that the voting procedure committee had accepted esentially 
that conclusion.


The above method for dealing with supermajorities in Condorcet-style 
elections has one loose thread:  when do extraordinary options lose?


If they lose (and are eliminated) before the CSSD procedure is applied, 
then the CSSD procedure is simplified by the elimination of extraneous 
choices.


If the supermajority option is checked

But look at the following set of ballots (A is extraordinary, N is NOTB, 
b and c are ordinary):


4 cAbN
1 cNAb
3 bcNa
3 AbcN

  A  b  c   N
A 0  8  3   7
b 3  0  6  10
c 8  5  0  11
N 4  1  0   0

A fails the supermajority requirement, so by my conclusion above, can't 
win the overall vote.  If we eliminate it as an option before applying 
CSSD, then b is th

Re: Another proposal.

[Buddha Buck]

Raul Miller wrote:

Raul Miller wrote:


On the other hand, we've never had an official vote which was even close
to failing to meet our quorum requirement.



On Tue, Nov 19, 2002 at 10:01:01AM -0800, John H. Robinson, IV wrote:


let me see if i undserstand this quorom thing:

we want to know that a significant portion of the electorate care enough
to represent themselves.

so would not the quorum be the simple number of votes cast?

if the quorum is 72, and seventy people vote, then quorom is not met,
and the vote is invalidated on those grounds. regardless if all vote ABF
and thus A has supermajority (at any ratio) over B and F.



That would be bad.

If you do it this way, there are circumstances where a vote against
an option may cause that option to win (because without that vote the
option wouldn't have met quorum).


I think you are misunderstanding the suggestion.

The way quorum usually works in face-to-face meeting is that the 
deliberative body cannot come to a decision without a quorum.  If a vote 
is held and then it is discovered that there was not quorum at the time 
of the vote, then the vote is discarded.  No option wins, no option is 
defeated.


In the case that John Robinson mentioned, if the quorum is 72, and 70 
people vote, there is no quorum, so all 70 ballots are discarded and the 
vote is null and void.


I read his suggestion as extending that to Debian voting procedure.  He 
would have quorum measured not on an option-by-option basis, but on a 
total-ballot basis.  Too few valid ballots received nullifies the vote. 
 If enough valid ballots are received by the deadline, then the vote is 
binding, regardles of the number of people who voted for (or against) 
any particular option.








also, with the Condorcet + SSD election method, is the supermajority
requirements really required? it does allow a vocal minority to block an
action. is that desired? if so, why?



The supermajority requirements give you a (relatively) stable frame of
reference to reason against.  Thinking about voting in a context where
it's just as easy to change the voting system as it is to change what
the voting system is being used to decide is... rather difficult.

Re: Another proposal.

[Buddha Buck]

John H. Robinson, IV wrote:

Raul Miller wrote:


That's the way I read his suggestion, also.  And that's what I was saying
is bad.  I don't think you understood my objection.

Here's the problem: a vote against an option can cause quorum to be met
and therefore cause the option to win.  This discourages sincere votes
against the option.



i don't buy that logic. the case is true, and having X>Q votes causes
the vote to be binding.


I agree with John.


i can see two major outcomes when X

I'd sort of be willing to see 3) the ballot, and all proposals on it, 
are dismissed without prejudice (meaning they can be proposed again). 
This is different than "Further Discussion".



the whole supermajority thing i feel would make people vote insincerely.
the ony way to avoid it, as i see it, is to _remove entirely_ the Quorum
and Supermajority requirements.


I don't see Quorum requirements as a problem, as long as they don't 
apply differently to different ballot options.


There is a goal of making some actions (like modifying the constitution 
and/or Social Contract and/or the DFSG) harder than others (like issuing 
a resolution).  This goal is traditionally met with supermajority 
requirements.


If we drop the supermajority requirements, how would you meet the stated 
goal?





-john

Re: Another proposal.

[Buddha Buck]

Matthias Urlichs wrote:

Hi,

John H. Robinson, IV:


i had always understood quorum as the minimum number of participants to
conduct business. 


[Matthias's comments rearranged...]


Sorry, but I don't like that. With a quorum, the people against a proposal
need to actively solicit support for their objection if they want to
defeat it. That's good democracy. Defeating the proposal by walking out
is bad democracy.


In parliamentary terms, "conducting business" means "making decisions by 
vote".  Normally, a measure can't be defeated by lack of quorum.  If 
there is a lack of quorum, no vote can be held -- or if a vote is held 
before quorum is determined to be lacking, the vote isn't binding.


Bringing this quorum principle over to Debian, the most straight forward 
rule would be that if there aren't enough participants in the balloting, 
then the status is reset to what it was before the vote -- i.e., nothing 
is defeated, nothing is passed, nothing is decided.  Another ballot is 
advertised and distributed (perhaps after a short period), and another 
vote is held.


That may not be the best option -- there may be better solutions, like 
dimising the ballot options without prejudice, requiring the proposers 
to repropose them (if the proposals were dead, that shouldn't be 
possible), or defaulting to "further discusion", etc.



> OK. Let's say we have a quorum of 90 and a supermajority of 2:1.
70 people are for the proposal, 30 against => the proposal wins.
70 people are for the proposal, 10 against, the remaining 20 refuse to
vote => the proposal fails. 


What do you mean "the proposal fails"?  Is it dead, and can't be 
resurrected?  Is it up for "further discusion", with a future revote?  I 
feel that a lack of quorum shouldn't be able to kill a measure, but 
forcing another vote on the issue after further discussion is fine, IMHO.




IMHO.

Re: Another proposal.

[Buddha Buck]

Raul Miller wrote:

Raul Miller wrote:


Here's the problem: a vote against an option can cause quorum to be met
and therefore cause the option to win.  This discourages sincere votes
against the option.



John H. Robinson, IV wrote:


i don't buy that logic. the case is true, and having X>Q votes causes
the vote to be binding.



On Tue, Nov 19, 2002 at 03:50:10PM -0500, Buddha Buck wrote:


I agree with John.



Can you explain what he's saying in a meaningful fashion?  [It looks to me
like he's contradicting himself, but apparently you have a self-consistent
way of interpreting what he's saying?]


Sure.

In the case you mentioned, sentiment is for the proposal, so the option 
should win -- assuming the vote is binding.  If there are enough total 
ballots to meet quorum, the vote is binding.  If there aren't enough 
total ballots to meet quorum, the vote shouldn't be binding.


Quorum is traditionally a way to determine if there is sufficient 
participation in the deliberations to make any decision binding on the 
organization making the decision.  If too few people actually return a 
ballot, then too few people participated in the decision-making process 
for the decision to be valid.


You (and Matthias) seem to be assuming that if quorum isn't reached, 
then the ballot measures should be shot down.  I and John are saying 
that if quorum isn't reached, then the trigger hasn't been pulled yet 
(to stretch a metaphor).


But that is making a binding decision based on a lack of quorum.  That 
goes against what quorum is usually used for.


You are also applying quorum requirements to individual options on the 
ballot, rather than the vote as a whole.  I've rarely seen that use of a 
quorum in the past.


Would you be satisfied if the too-small minority were unable to get 
their way by not voting, but would only serve to delay the final 
approval of the supermajority option, by forcing another vote?


In otherwords, if X (the number of ballots) < Q (quorum), then the 
results of the vote is non-binding.  It doesn't even need to be 
computed, since it doesn't matter which option won.


If X > Q, then the vote is binding, and we go with whatever option won 
after applying supermajority and Condorcet/CpSSD procedures.


That is in line with how I would normally interpret a quorum.

Re: supermajority options

[Buddha Buck]

Raul Miller wrote:

Here's some thoughts about how we might implement supermajority:

[1] 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.


It would certainly be easiest to implement, but it would make it as easy 
to amend the Constitution as to pass a resolution.  There is some sense 
in making it harder to amend the governing documents.



[2] Discard the election if the winner doesn't meet supermajority.
Perhaps, if the ballot has nondefault options with differing supermajority
ratios, immediately hold another election using only the options with
a lesser supermajority ratio.  I'm leaning towards this at the moment.


This is underspecified.  Define "winner doesn't meet supermajority.".

Once that definition is made to my satisfaction, I like this option, or 
one of these two variants:


[2a] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Default option (Further Discussion) wins by default.  New election to 
be held after appropriate discussion period.


[2b] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Hold an "instant runoff" using all the remaining options and the same 
ballots.  Repeat until a winner is found.


I used to favor [2b], but I think I like [2a] best right now.


[3] (current draft) Only consider supermajority in terms of defeating
the default option.  This gets a bit confusing to think about in the
context of transitive defeats.

[4] (my old hobby horse) Consider supermajority in every comparison
involving an option with a supermajority requirement.  This gets a bit
confusing to think about in the context of transitive defeats.

[5] (Nov 16 and earlier drafts) Discard options which don't satisfy
supermajority before considering transitive defeat.  This gets a bit
confusing to think about in the context of transitive defeats.

Suggestion?  Comments?  Incoherent ramblings?

[Note: I'm not going to be around much tomorrow.  Maybe you'll have
everything solved for me when I get back?]

Thanks,

Re: supermajority options

[Buddha Buck]

Matthias Urlichs wrote:

Hi,

Buddha Buck:

[2a] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Default option (Further Discussion) wins by default.  New election to 
be held after appropriate discussion period.


[2b] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Hold an "instant runoff" using all the remaining options and the same 
ballots.  Repeat until a winner is found.


I used to favor [2b], but I think I like [2a] best right now.



... but what if the second vote fails too? 


I'd prefer [2b], with a mandatory "do nothing" option on the ballot. That
way, people can indicate whether further discussion or something else
(or nothing at all) should take place, should the supermajority option
fail.


Except in the case of an election, there should always be a "reject all 
options" choice on the ballot.  Assuming the simple case of a single 
resolution option, we'd want the ballot to look like:


[  ] ACCEPT resolution declaring Buddha Buck a forbidden interloper
[  ] REJECT resolution declaring Buddha Buck a forbidden interloper
[  ] FURTHER DISCUSSION

It makes no sense to have no way to reject a proposal or an amendment.

Re: Nov 19 draft of voting amendment

[Buddha Buck]

Branden Robinson wrote:



Yes, it does.  See the flamewar about non-free on debian-devel.  Giving
people their opportunity to explicitly express their preference for the
status quo (", damnit!") is a good thing, if someone can be bothered to
propose that as an amendment to the proposed GR, and if it acquires
enough seconds live on its own.

"FURTHER DISCUSSION" is not highly communicative.  When ranked first, it
tells you relatively little about the voter's intent.

I am wondering if it is really a good idea to always have a do-nothing,
futher-discussion option that is the default.  It may be better to make
these get proposed and seconded like any other option, and make them
have to fight for victory just like every other option.


Hmmm, so if I make a suggested amendment to the Debian Constitution 
(such as "Replace all instances of the word 'Concorde' in connection 
with the voting system with the word 'Condorcet'.  Rationale:  This was 
clearly a misspelling or mistake in the original drafting of the 
Constitution"), that no one on Debian-Vote appears to object to, the 
ballot should look like this:



Rank all options in order of preference.  Unranked options will be 
considered equal to each other and ranked lower than any ranked options.


[   ]  AMEND the Constitution as per Proposed Amendment I, above.

Sign your completed ballot with your Debian PGP key, and send it to


My opinion is that that is a stupid ballot.  There should always be a 
method to reject a proposal, unless there is some good reason not to.


What would be a good reason not to?  Imagine the following resolution, 
hypothetically enacted:



Be it RESOLVED, that the Debian Project shall adopt a mascot, and that 
the Debian Project Leader shall appoint five Debian Developers to review 
and select at least five candidate mascots by no later than three months 
 from the date of this reolution.  The Debian Developers shall select, 
by vote, a mascot from among the selected candidate mascots.

-

This is a case where I can see there being no default option, no 
none-of-the-above, and no "further discussion" either.


But that's an exception, because the decision to do something was 
already made, the only thing remaining is a choice over what to do. 
When the decision to do something hasn't been made, there needs to be a 
"do nothing" choice of some sort.



If we retain a quorum requirement in terms of a minimum number of
ballots that have to be received before the result will be formally
tabulated, then "FURTHER DISCUSSION default options" are even less
necessary because people can just "indifference" a proposal to death.

Re: supermajority options

[Buddha Buck]

Raul Miller wrote:
Once that definition is made to my satisfaction, I like this option, or 
one of these two variants:


[2a] Discard the result if the CpSSD winner doesn't meet supermajority. 
Default option (Further Discussion) wins by default.  New election to 
be held after appropriate discussion period.


[2b] Discard the result if the CpSSD winner doesn't meet supermajority. 
Hold an "instant runoff" using all the remaining options and the same 
ballots.  Repeat until a winner is found.


I used to favor [2b], but I think I like [2a] best right now.



I'm thinking a version of 2b could work quite well.

What's your reason for disliking instant runoff?  [Let's assume we
only use it for cases where all options in schwartz set had a majority
requirement greater than 1:1].


I didn't say I didn't like instant runoff -- I think I was one of the 
original proposers of an instant-runnoff idea in the past.  I said I 
liked 2a better than 2b.  2b works, but in my opinion not as well as 2a.


The rationale for the my opinion is something like the following:

The CpSSD process, in some sense, determines what, in the collective 
opinion of the voters, is the "best" option.  Both 2a and 2b try to, at 
first pass, determine what the overall "best" option is.  The 
supermajority requirement, on top of that, says that some options need 
extraordinary support to be adopted.  The difference between 2a and 2b 
happens when the "best" option doesn't have the extraordinary support it 
needs.


One choice (2a) is to keep discussing the issue until a workable "best 
option" can be found.  In this schenario, it may take more time, but 
eventually an electable "best" option will be found.  Proponents of an 
amendment (the "best" option found so far) may gather more support. 
Proponents of another option may sway opinion so that when the next vote 
comes, some other option is now regarded as the "best", and that option 
will win.  If you want to get the best option, 2a says "settle for 
nothing less than the best".


Another choice (2b) says to find a winning option in one vote, without 
further discussion.  If the "best" option is unelectable because it 
lacks necessary extraordinary support, try to find the 2nd best option. 
 If that is also unelectable, go for 3rd best.  Every vote will have a 
decided winner (even if that winner does turn out to be "further 
discussion").  In a sense, 2b says "If we can't get the best, take what 
we can get now".


Naturally, I'd prefer to select the best option, not what we can get, 
even if it takes more time.  Things are rarely so pressing that making a 
 decision to change the constitution must be made immediately.


As to why I prefer (2) over the rest...  CpSSD is well-defined and 
reasonably well studied when all votes are counted equally.  I find the 
idea of scaling votes involving particular options to change it enough 
that its properties become unknown and unpredictable.  It may be 
severely broken in ways that CpSSD isn't.  I'd rather have the core be 
something we know is good.  That means that I have legitimate FUD with 
[3] and [4].


CpSSD does not satisfy the Independence from Irrelevant Alternatives 
criterion.  It's possible to create a set of ballots with amendment A 
such that resolution B wins, but when A is dropped form the ballot, 
resolution C wins:  create a ballot where C>>B>>A>>C, and C>>B is the 
weakest defeat in the cycle.  I have done it in the past, it's not hard. 
   As such, I feel there is a loss of information, a loss of 
expressiveness in the ballots by dropping an option before we know that 
doing so won't hurt the election.  Dropping a "best" option that is 
unelectable will obviously change the outcome of the election, but 
that's what we want in that case (2b).  But dropping early raises doubts 
that we are really following the voters will.  So that's my problem with 
[5] and any other option that tries to eliminate options before 
performing CpSSD.


Unlike Branden, I would like some issues to be hard to change -- things 
like the Social Contract and the DFSG.  I think it's one of Debian's 
strenghts that we take a principled stand, and have not waivered on 
those principles (at least, in principle) since we stuck our necks out 
and said "this is what we believe".  Debian has, by example, said "It's 
not good enough to be best, it's important to do the right thing, as 
well".  I feel the fact that the Open Source Definition has changed to 
be a weakness of the OSD, compared to the DFSG.  The Social Contract is 
older still, and it, too, has been steadfast.  It should be hard to 
change, and it's important that we don't forget why we are doing what we 
are doing.  I don't want it to be as easy to change these things as it 
is to pass a technical policy statement.  As such, I do not believe it 
is right to drop the supermajority requirement as stated in option [1].


(You might be able to tell from the above political rant that I align 
myself c

Re: supermajority options

[Buddha Buck]

Branden Robinson wrote:

On Fri, Nov 22, 2002 at 12:39:27PM -0600, Manoj Srivastava wrote:


Interesting. However, that paper makes a number of assumptions

  May (1952) shows that majority rule is the only positively
  responsive voting rule that satisfies anonymity (all voters are
  treated equally) and neutrality (all alternatives are treated
  equally).  If we use a system other than majority rule, then we
  lose either anonymity or neutrality.

Eh? this obviously does not apply.



It isn't even the central thesis of the paper, so I'm not sure what
you're really establishing here.

Our voting system does not have anonymity, except in Project Leader
elections (well, in theory anyway[1]), which are already conducted under
a simple majority requirement and wouldn't be impacted by a proposal to
eliminate supermajority requirements from the Constitution.

So, the remaining question is, do we lose "neutrality"?


Obviously -- The paper defines "neutrality" as "all options are treated
the same".  If we are asserting a supermajority requirement on certain
actions, like constitutional amendments, then we are not treating all
options the same, and therefore lose neutrality.

The remaining question:  Do we want "neutrality"?

"Neutrality" isn't always a desirable condition.


Additionally, the core of the argument is about bargaining powers,



No, it isn't.  The core of the argument is that supermajorities prevent
consensus from being expressed through minorities' defense of their
positions.

Our thinking about majority rule has been considerably sharpened
by formal social choice theory.  As already noted, May (1952)
shows that majority rule is the only positively responsive
decision rule satisfying anonymity and neutrality.  In a similar
vein, Rae (1969) and Taylor (1969) show that majority rule is
the decision rule that minimizes the probability that an agent
votes for something that is not enacted or votes against
something that is.  Straffin (1977) shows that majority rule is
the decision rule that maximizes responsiveness to individual
preferences.  Social choice theory has demonstrated that
majority rule is prone to cycles (Condorcet 1788/1955; Arrow
1952; Plott 1967; McKelvey 1976, 1979; Schofield 1978).  The
conditions under which this applies to super-majoritarian
decision rules has been explored by Nakamura (1979), Greenberg
(1979) and Schofield et al.  (1988). Miller (1980) and McKelvey
(1986) show there are strict limits to majority rule cycling
under normal institutional settings, and Miller (1983) argues
that the instability produced by cycling may actually beneficial
to systemic stability by assuring that there are no permanent
losers.  Laing and Slotznick (1987) show that under
super-majoritarian rules, it may be strategically rational for
blocking minorities to defend extreme status quo positions, even
though they would like to see them replaced.

Note especially the last sentence.  Is insincerity really a feature we
want in our voting system?


Defend against what?  Replaced by what?  If the proposed alternative to
an extreme status-quo is an extreme in the opposite direction, and my
real position is that the status quo is in the right direction but too
extreme, I'd defend the status quo over the proposed alternative.


A point directly rebutted by the paper.

"With super-majority voting, the status quo is privileged­if there is no
alternative for which a super-majority votes, the status quo is
maintained.  Following Rae's (1975) argument, given that the status quo
is more desirable to some voters than to others, some voters are
effectively privileged.  It is certainly the case that super-majority
rules can privilege (protect, if you prefer) some voters.
Unfortunately, it is not possible to privilege every group over every
other group. If super-majority rules create a privileged group, there
must be a corresponding under-privileged group."


This argument seems circular.  The "priviledged group" is the group that
supports the status quo over a proposed alternative.  This "priviledged
group" has no other definition, and can't be identified except by voting
records.

That the group of voters who prefer the status quo have their voting
power enhanced by a supermajority system is obvious.  In fact, I'd say
it's a *design goal* of supermajority systems.  Similarly, that the
groups of voters who desire change have more work to do, more support to
gain in a supermajority system is also , in my opinion, a design goal of
supermajorities.

Claiming that this is a problem requires more proof than simply stating
that there is are privileged and underprivileged groups, as if this is
an apriori bad thing.  Especially when the privileged and
underprivileged groups change silently with each proposed change.


"U

Re: supermajority options

[Buddha Buck]

Jochen Voss wrote:

Hello,

On Fri, Nov 22, 2002 at 10:16:27AM -0500, Buddha Buck wrote:

I agree with this.  But doesn't the same argument apply
to at least [5]?


Very possibly.  (I'm out of town at the moment, and don't remember 
exactly what [5] was).  But I had other issues with [5] as well which 
discounted it.





Jochen

Re: supermajority options

[Buddha Buck]

Please forgive my late reply.  I'm on vacation, and haven't had access 
to email since Friday.  I should bow out of this discussion until I am 
back from vacation and have more reliable email access.


Branden Robinson wrote:

On Fri, Nov 22, 2002 at 03:42:12PM -0500, Buddha Buck wrote:


Obviously -- The paper defines "neutrality" as "all options are treated
the same".  If we are asserting a supermajority requirement on certain
actions, like constitutional amendments, then we are not treating all
options the same, and therefore lose neutrality.

The remaining question:  Do we want "neutrality"?

"Neutrality" isn't always a desirable condition.



I argue that we do want neutrality.  It's the same thing as arguing
against supermajorities.


In which case, arguing against supermajorities because of neutrality is 
fairly circular, don't you think?


Personally, I think it should be harder to change the DFSG, the Social 
Contract and the Constitution than to do most other tasks that can be 
done by the General Resolution process.  As such, I do not favor 
neutrality (i.e., treating all possible options equally), but 
specifically *want* to treat certain options more differently.


(Nota Bene:  I am certain that supermajority procedure implies a lack of 
neutrality, but I'm not certain that a lack of neutrality implies 
supermajority procedure.  But it may be a matter of definition.  If a 
non-Amendment GR passes if it is the CpSSD winner, but an Amendment is 
required to be the Condorcet winner (vote to be held again, after a 
discussion period, if an Amendment is the CpSSD winner but not the 
Condorcet winner), is that a supermajority procedure?  It is definitely 
a non-neutral procedure).


Most of my argument you quoted below was directly related to the McGann 
paper, and not customized to deal with Debian Politics at all.



"Can lead...to" is very open-ended, wishy-washy words.



You should read the whole paper, including the examples.



Likewise majority-rules can lead to situations where there is no
stability, and adapted positions flip-flop back and forth between
extremes.



Why would they flip-flop between in extremes under our system, where we
can have multiple options on the ballot, and rank-ordering by the voter?


My statement was intended to be taken as a similar open-ended 
wishy-washy statement as McGann's, conveying an equally true issue, but 
contrary to McGann's thesis.


It is very likely that Debian's ability to have lots of ballot options 
on one ballot, and using rankings for all the options by each voter 
individually to determine the outcome will sucessfully short-circuit 
extreme positions -- if people are aware of how easy it is the place 
amended version of a ballot on the ballot against the original proposal.


On the otherhand, it might also short circuit debate and compromise, 
since there is less impetus to convince people of your version over 
another before the ballot is drawn up.  I suspect that that won't be a 
problem with Debian, but you never know.  I have been tempted to simply 
suggest to you that you propose the "neutral majority rule" version of 
the changed voting procedures as another ballot option running against 
whatever the supermajoritarians finally suggest.



Witness, for instance, the recent US Congressional elections, and the
declared "conservative mandate" from a very narrow majority for the
majority party.



You're claiming this is evidence for what, exactly?


In support of my wishy-washy, open-ended claim that majority rule can 
cause a rapid flip-flop from extreme position to extreme position without.


Actually, it is stronger evidence against McGann's thesis, that majority 
rule provides the best protection for the minority.  As you point out, 
if the majority can, before the minority opposition has a chance to 
reorganize into a majority, entrench its position, then the problems 
caused by the majority can be long-lasting.  Since there is no recall 
provisions for Senators and Congresscritters in the US system, there 
will be no way for the voters to effectively challenge what the very 
slim majority in Congress does for two years.  If the opinions of the 
voters change based on the actions of Congress, acting on their 
illusionary "Mandate", the new majority can't "promptly repeal" those 
actions.

Re: Hybrid Theory

[Buddha Buck]

Raul Miller wrote:

On Thu, Dec 12, 2002 at 04:29:49AM +1000, Anthony Towns wrote:


Sorry, I don't buy this.



Ok.

I'm wondering if other people agree.  [I wish Buddha wasn't
on vacation, this was his example.]


Sorry...  I'm back, but my computer at home is having some problems (old 
power supply was advertised at 300W, but rated for 160W continuous; new 
power supply (installed last night) is rated at 350W continuous, but now 
I need to rebuild my system), so I've been limited to reading from work 
-- where I should be working rather than arguing debian politics.


My argument was in support of late-dropping of unwinnable supermajority 
options.  I felt that we should leave the mechanics of CpSSD alone, and 
decide after a winner had been chosen if the winner has supermajority 
support.  If not, punt, in some way.  Most likely by eliminating that 
supermajority candidate and running CpSSD again.


THe other option to modifying the mechanics of CpSSD is to early-drop 
unwinnable supermajority options.  This leaves the behavior of CpSSD, 
and its properties, intact for the possible winning options.


The case where the two would give different results is when there is no 
Condorcet winner, and a supermajority option is in the Schwartz set in a 
loop with the potential winners, yet CpSSD does not select either the 
supermajority option or the option it defeats.  The example I gave led 
to the following loop:


A->b->c->A

where A is a supermajority option, and b, c are normal options and the 
b->c defeat was the weakest.


With late-dropping, the CpSSD procedure would have declared c the 
winner.  With early-dropping, the CpSSD procedure would have declared b 
the winner.


To decide which of these two procedures makes the most sense, compare 
these two statements:


(late-dropping): c won, because we discounted the votes of the people 
that preferred b over c, but counted the votes of the people that 
preferred A over b, even though B couldn't have won.  This is unfair and 
counterintutive.


(early-dropping): b won, but only because A was a supermajority option. 
 If A had been a normal option, c would have won.  Why is it that 
making A harder to win shifted the result from one winner to another? 
This is unfair and counterintuitive.


Which of those two statements is the most convincing?





Define "like Condorcet".


Same outcome as Condorcet for the same votes.


Heh. Condorcet doesn't produce a winner for the case you give;



Sorry, I should have been saying CpSSD.

Thanks,

Re: February 17th Voting GR draft

[Buddha Buck]

Sam Hartman wrote:

Would someone mind giving me a few examples of how this works in practice?

Let's say I propose a GR and get seconds and it comes to a vote with
no amendments.

Would the two options on the ballot be my GR and a default option of
more discussion?


I think that, under the proposal as made, this is correct.  I think 
that, as a matter of voting, it should be wrong.  I hold the position 
that there should always be an option to reject, without more 
discussion, a GR.


When this has been brought up in the past, I believe that it has been 
recommended that a reject/status-quo amendment be proposed by someone 
who wants to reject the GR (and gets it seconded) as a way of getting a 
"reject" option on the ballot.  It has also been mentioned that because 
of the way that GRs are proposed, there is little practical difference 
between "reject" and "further discussion".  I don't agree with either of 
these.



I realize this is a simplistic example; my actual question has to do
with how supermajorities work, but answering this question is
sufficient to answer my real question.


Ask your actual question, then.

Re: [Moshe Zadka ] Independent Count

[Buddha Buck]

Martin Schulze wrote (publically to Moshe Zadka):



If you can't trust Manoj, who else can you trust in this project?

And do you really believe that people want you as DPL when you are
apparently unable to compress an IRC log to the relevant "offensive"
messages, but send a 300 lines IRC logfile instead?


Er, in fairness to Moshe, the impression I got from reading the 300 
lines of IRC logfile was that the log was added, unedited, by Manoj.


The log includes comments from Moshe that he had already emailed the 
DPL, inquiries from Manoj about the legitimacy of posting #debian-devel 
IRC logs to the lists (in case the policy was that it was private, like 
debian-private email list email), and Manoj stating that he wasn't going 
to let the accusations of impartiality stand without the evidence of 
where they came from, and statements from Moshe that he was going to 
summarize the IRC log.


I have not seen Moshe's summary yet, though.




Regards,

Joey

Re: integrity of elections

[Buddha Buck]

Hamish Moffatt wrote:

On Wed, Mar 26, 2003 at 02:18:45PM +1100, Glenn McGrath wrote:


And why do you think this should be allowed?


Because they are a part of the debian community, and probably have a
reasonable understanding of debian politics.



That's true of some of our users too. There would be a few who have been
around longer than most of our developers. Some who have contributed
more than some of our developers, too.


True, but we don't get a vote, either.  And that's OK by me.

Debian has, in general, been very, very good about letting anyone who 
has a valid point participate in the political and policy debates, 
regardless of status -- sometimes at fairly high levels, too.  There was 
at least one non-voting user on the committee tasked to develop the new 
proposed voting method.



Hamish

Re: Debian Project Leader Election 2003 Results

[Buddha Buck]

Manoj Srivastava wrote:

On Mon, 31 Mar 2003 15:35:15 +0100,
Matthew Wilcox <[EMAIL PROTECTED]> said: 



 > I believe the method for choosing the hash that allows one to
 > identify one's vote is flawed.  Since all components of the string
 > to be fed to md5sum are chosen by the secretary or known well in
 > advance, it would be possible for a malicious secretary to stuff
 > the ballot box.  If it is possible for the secretary to choose two
 > strings which hash to the same value, the secretary can replace one
 > of the votes with a vote of their choosing.  This is admittedly
 > rather hard, but the secretary has an unlimited amount of time to
 > work in to achieve this result.

If I could find a means of two strings (of the same size) that
 gasg to the same vlaue in md5sum, I'd be too busy raking in money to
 bother stuffing debian ballots.

If you voted, please take the rest of the year trying to come
 up with another string that would hash to _your_ md5sum. If you can
 come up with something even remotely reproducible, we'll have a majot
 math paper on out hands, and I;ll happily change things around.


Speaking hypothetically, I'd like to point out that the FAQ on the 
RSA.com web site about various hash algorithms, including MD5, cites a 
1994 paper estimating that a machine built for brute-forcing MD5 hash 
collisions could probably be made for US$10M out of 1994 technology and 
1994 dollars that would find a hash collision in 24 days on average.


Moore's Law would suggest that such a machine would cost on the order of 
US$150K.


Doing some quick orders-of-magnitude calculations, I can't see how they 
would do it in that time-frame as "brute force", though.






manoj

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Buddha Buck]

Raul Miller wrote:


On Wed, May 21, 2003 at 09:57:13PM +1200, Nick Phillips wrote:
 


I don't believe that it's acceptable for an otherwise beaten option
to win due the the otherwise winning option being discarded due
to a quorum requirement, as John suggests might happen.
   



Under the proposed system, we would do exactly the same thing for otherise
winning options being discarded due to a supermajority requirement.

What makes this behavior acceptable for supermajority requirements and
unacceptable for quorum requirements?

To my knowledge, the only issue here is that other voting systems [for
example, those indicated by Roget's Rules of Order] have defined quorum
in terms of number of voters present and do not collect votes if quorum
is not met

I've not been following this thread too closely (between trying to get 
work done, trying to get plants into the ground, and trying to spend 
time with my SO, I've been too busy to pay close attention to Debian 
politics), but I've two questions:


1) Has anyone developed standard terminology for:
 a) The proposed amendment to the Debian Constitution formally offered 
by Manoj

 b) The proposed amendment to (a) above as offered by John

2) Would an amendment to (a) to the following effect be acceptable and 
clear up nomenclature issues:


Replace A.6.2-4 in the proposed amendment with:

2.  Procedural Definitions
a. V(A,B): For any options A and B, V(A,B) is defined as the number
of ballots cast that rank option A higher than option B
b. margin of A over B: The margin of A over B M(A,B) = V(A,B)-V(B,A)
Note that M(A,B) = -M(B,A)
c. defeats: For any options A and B, A defeats B if and
 only if M(A,B) > 0
d.  Acceptable:  An option A other than the default option is
 considered "acceptable" if and only if M(A,default) >= R, where
 R is the "quorum requirement" for the vote.
e. Superacceptable: An option A with a supermajority
requirement of N:M is considered superacceptable if and only if
M*V(A,default) > N:V(default,A).
f.  Pairwise defeat:  A pairwise defeat is an ordered pair of
 options (A, B) where A defeats B.
g.  "weaker" A pairwise defeat (A,B) is considered weaker than
 pairwise defeat (C,D) if V(A,B) < V(C,D)
3. Dropped options
a. Any non-default option A which is not acceptable is dropped
b. Any option A with a supermajority requirement which is not
superacceptable is dropped.
4. Create a list of all pairwise defeats (A,B), where neither A nor B 
are dropped, sorted by V(A,B).


with related changes elsewhere to use these definition.

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Buddha Buck]

Manoj Srivastava wrote:

On Wed, 21 May 2003 14:27:53 -0400, Buddha Buck <[EMAIL PROTECTED]> said: 

 


2) Would an amendment to (a) to the following effect be acceptable
  and
clear up nomenclature issues:
   



 


Replace A.6.2-4 in the proposed amendment with:
   



 


2.  Procedural Definitions
a. V(A,B): For any options A and B, V(A,B) is defined as the number
of ballots cast that rank option A higher than option B
b. margin of A over B: The margin of A over B M(A,B) = V(A,B)-V(B,A)
Note that M(A,B) = -M(B,A)
c. defeats: For any options A and B, A defeats B if and
 only if M(A,B) > 0
d.  Acceptable: An option A other than the default option is
 considered "acceptable" if and only if M(A,default) >= R,
 where R is the "quorum requirement" for the vote.
   



This changes the meaning of Quorum as used by Debian. In
Debian, quorum is used to ensure there a modicum of interest in an
option -- so, if R people vote for an option, there is interest. It
does not matter how many people vote _against_ the option -- Quorum
is not used to ensure a margin of victory.

Ah...  then I was confused.  Replace "M(A,default) >= R" with 
"V(A,default) >= R and M(A,default)>0" 

The V(A,default >=R clause comes from your proposed A.6.2, and the 
M(A,default)>0 clause comes from your proposed A.6.3.



If you meant to change the meaning of quorum, I must confess I
disagree. 

My intent was to change none of the semantics of your proposal.  My 
initial intent was to change the terminology from "per-option quorum" 
(which is subject to misunderstanding and confusion with the standard 
"total votes cast quorum" concept) to "acceptability".  Instead of 
saying an option that only a small handful of people prefer to the 
default does not meet quorum, we would say that such an option is not 
acceptable to enough people.




 


e. Superacceptable: An option A with a supermajority
requirement of N:M is considered superacceptable if and
only if M*V(A,default) > N:V(default,A).
f.  Pairwise defeat: A pairwise defeat is an ordered pair of
 options (A, B) where A defeats B.
g.  "weaker" A pairwise defeat (A,B) is considered weaker than
 pairwise defeat (C,D) if V(A,B) < V(C,D)
3. Dropped options
a. Any non-default option A which is not acceptable is dropped
b. Any option A with a supermajority requirement which is not
superacceptable is dropped.
4. Create a list of all pairwise defeats (A,B), where neither A nor
  B
are dropped, sorted by V(A,B).
   



 


with related changes elsewhere to use these definition.
   




So, to answer your question, no, I would not find this
acceptable for my version of the GR, for the reasons presented
above. 

I understand that, since I messed up a crucial definition.  Is the new 
definition better?




manoj
 

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Buddha Buck]

John H. Robinson, IV wrote:



with presence for the purposes of meeting quorum.

another example: DPL election, two candidates, R=45

450x DAB
45x ADB

Condorcet: D wins
Proposed:  A wins
Amended:   D wins

here we have a case where ten times the number of people think that both
candidates are so rotten, they would rather see no one in office. a
minority of a voters would like to see their candidate win. under the
proposed mechanism, the minority of the voters win, because the loud
majority voice was squelched by the per-option implementation of quota.

You are going to have to walk me though this one.  Here's what I see 
happening under Manoj's proposal:


45 voters prefer A to D, which is equal to R, so A "meets quorum".
No voters prefer B to D, which is less than R, so B does not meet 
quorum, and is eliminated.


More voters prefer D over A than A over D, so A is eliminated as not 
acceptable.


The only remaining candidate to feed into the SSD procedure is D, so D wins.

How do you get A winning?

Per-item "quorum" and truncated ballots

[Buddha Buck]

If it were impossible to rank options equally, then the combination of a 
global quorum and an an elimination of unacceptable option (options to 
which the default is preferred by a majority) would have essentially the 
same effect as a per-option quorum.


This is easy to see.  Every ballot would rank an option A as either 
better than D or worse than D, so if Z is the total number of ballots 
cast, then Z = V(A,D) + V(D,A), for all options A not equal to D 
(actually, more generally Z = V(A,B)+V(B,A) for all B != A).  If we say 
that if Zwhen Z>Q.  If A is to be considered acceptable, then V(A,D) > V(D,A).   
But if we assume that A would be rejected by a per-option quorum, then 
we have R>V(A,D), or 2R > 2V(A,D) > V(D,A) + V(A,D) = Z >= Q, or 2R > 
Q.   But we choose R and Q, so we can easily set Q = 2R if we want.  
Then the only way that the difference between per-option quorum and 
global quorum would make a difference is if the total votes were between 
R and 2R.  Arguably, that's a small enough turnout that we'd want to 
reject the vote as too few voters anyway.


However, we allow truncated ballots and equally-ranked options.  None of 
the examples I've seen so far have used this as a reason to argue 
against per-option quorum, or even taken them into account in the 
discussion.


Imagine a vote along the lines of:

100 ballots of the form:
  [1] Red
  [ ] Blue
  [ ] Default

100 ballots of the form:
  [1] Red
  [ ] Blue
  [1] Default

25 ballots of the form:
  [ ] Red
  [1] Blue
  [ ] Default

with an R of 105.

The defeats matrix looks like
 Red   Blue   Default
Red   ---   200  100
Blue  25---   25
Def0100   ---

In this example, Red is the IDW, and absolutely no one thought that Red 
was worse than the default option.  Yet Red is rejected because fewer 
than 105 people thought it was better than the default option, so 
default wins.


Is this the "expected" behavor?

Let's say we have the following ballots:

100:  Red>Blue>Default
100:  Red=Default>Blue
25:   Blue>Red=Default

Then Red is still the IDW because it defeats default 100:0 and defeats 
blue 200:25.  Yet Red is eliminated because only 100 voted for it over 
the default, and Blue wins.


We allow options to be equally ranked to give voters a way of saying 
that option A is equally acceptable to them as option B -- they would be 
equally happy with either outcome. 

But there is no way to say that one would be equally satisfied with 
option A or the default. Ranking an option A as equally acceptable with 
the default option penalizes A, since that ranking does not count 
towards option A's quorum requirement.


We've made three changes to SSD:

1) We've instituted a per-option quorum, requiring a minimum number of 
votes for a particular option over the default in order to be considered.


2) We've instituted the ability to rank options as equal on a ballot.

3) We are using the ranking relative to the default option as proxy for 
an approval ballot, and only considering options that are approved by 
the majority.


Our analysis of 1 and 3 have been based on the law of the exclused 
middle:  for any ballot, either A>D or D>A.  We haven't considered the 
effects of 2.


I think that the combination of all three changes has unforseen effects.

Re: Per-item "quorum" and truncated ballots

[Buddha Buck]

[EMAIL PROTECTED] wrote:

On Fri, May 23, 2003 at 05:24:59PM -0400, Buddha Buck wrote:


Imagine a vote along the lines of:
100 ballots of the form:
  [1] Red,[ ] Blue,[ ] Default

100 ballots of the form:
  [1] Red,[ ] Blue,[1] Default

25 ballots of the form:
  [ ] Red,[1] Blue,[ ] Default

with an R of 105.



I presume you mean with a quorum of 105.  Which would mean that we have
something like 44100 debian developers.



The defeats matrix looks like
 Red   Blue   Default
Red   ---   200  100
Blue  25---   25
Def0100   ---

In this example, Red is the IDW, and absolutely no one thought that Red 
was worse than the default option.  Yet Red is rejected because fewer 
than 105 people thought it was better than the default option, so 
default wins.


Is this the "expected" behavor?



Out of more than fourty thousand debian developers, less than one hundred
stated that they preferred red over the vote defaulting?

Yes, I'd say that this is the expected behavior.  Those other votes,
which rank red and default equally above blue, constitute votes against
blue, not votes for red.  Those people would have accepted red as being
no worse than the current situation, but they didn't actively think it
was a good idea.


So you are saying it is acceptable and desirable for there to be no way 
to express truely equal preference for "Further Discussion" and some 
other option?  Using my example, voting red equal to blue doesn't hurt 
or hinder either options chances of winning in relation to each other. 
But voting red equal to the default hinders red's ability to get 
accepted in favor of defaulting.


We've made three changes to SSD:

1) We've instituted a per-option quorum, requiring a minimum number of 
votes

for a particular option over the default in order to be considered.

2) We've instituted the ability to rank options as equal on a ballot.

3) We are using the ranking relative to the default option as proxy
for an approval ballot, and only considering options that are approved 
by the majority.


Our analysis of 1 and 3 have been based on the law of the exclused middle:
for any ballot, either A>D or D>A.  We haven't considered the effects of 2.

I think that the combination of all three changes has unforseen effects.

In particular, I think change #2 sets up the expectation with developers 
that they can vote "I don't care which of these two options win", while 
the other two changes do not treat a ballot equating an option and the 
default as neutral with regard to that option and the default -- they 
favor the default.


I think change #1 is the most troubling for me, and I would not mind 
seeing its removal.  It's designed to eliminate options that don't have 
many supporters. But surely if there are enough ballots cast, an option 
that doesn't have many supporters will be unlikely to win anyway.  The 
only time an option that doesn't have many (active) supporters has a 
chance of winning is when it also doesn't have many (active) detractors 
-- and when everyone else is expressing no preference one way or the other.


Why shouldn't the will of a small number of supporters win out over the 
will of a smaller number of detractors when the majority opinion is "I 
don't care"?

Re: Call for votes for the Condorcet/Clone proof SSD voting methods GR

[Buddha Buck]

Hamish Moffatt wrote:


For the benefit of the average non-voting-geek Debian developer,

could the proponents of this amendment please explain what problem
it attempts to solve, with real life examples?


The main problem is that the existing voting system as described in the
Debian Constitution is poorly defined, with some inherent
contradictions.  It wasn't looked at too closely when the Constitution
was first developed.  Among other problems:  It tries to implement a
Condorcet-based voting system, but calls it "Concorde" instead; it has
the property that if there is no clear winner (what Condorcet proponents
would call an "ideal democratic winner" or a "Condorcet winner", then
all the options are rejected before a winner is chosen from the
"remaining" options, etc.

There were also severe questions as to how the supermajority
requirements should be implemented.

These issues came to a head when a GR was proposed a modification to the
Social Contract that would eliminate the commitment by Debian to support
the "non-free" section.  It became clear that any ballot would contain
an amendment to the SC (viewed as requiring a supermajority to change),
a proposed policy statement (viewed as requiring only a simple
majority), and the "default" option.

A review of the constitution to figure out how to conduct such a vote
provided more confusion than answers.  So the secretary decided to
shelve the non-free GR until the voting issues were cleared up.  It's
been a while, however.


An explanation of why we need such a complicated system at all would be
interesting too.


Simple reason:  When you get more than two choices to vote for, all
election methods suck (lookup "Arrow's Theorem" for a proof of this),
but some suck more than others.   We want to find an election method
that has a minimal amount of suckiness for our goals.

More complicated reason:  While normal voting methods and procedures are
sufficient for deliberation in person, where everything can be settled
by multiple procedural votes, online deliberations have more complicated
requirements, requiring more complicated voting procedures.

We have the following complications:

1) We want to have as few votes as possible to settle an issue, since
each vote requires two weeks to run in order to get the most input.
This means that we can't follow a traditional procedural amendment
process -- each vote has to have all proposed (and seconded) amendments
on it, and the procedure has to select from among them.

2) We want to be conservative, and err towards continuing discussion, if
we can't achieve some sense of "consensus" on an issue.  As such, we
want to require continuing discussion to always be a ballot option

3) Very often more than a yes/no or either/or choice -- 3+-way decisions
are the norm and possibly required.  This is because of the multiple
variant issue mentioned in (1) above, and because of the "continue
discussion" option mentioned in (2).

4) Some options must be approved by a supermajority.  Other options
don't.  So some votes will be a mixture of supermajority requirements.

5) And we want some justifiable semblance of majoritarian rule.

The most common method, where everyone gets to vote for one (and only
one) option, and the option with the most votes wins suck big-time,
because in the presence of lots of options, the vote tends to get split
to the point where it's hard to justify saying any particular option has
a majority.

The methods chosen by Debian, both in the current constitution and in
the proposed constitutional amendment, are variants on a method
developed by a scientist named Condorcet over 200 years ago in France.

Condorcet was trying to answer the question "what does majoritarian rule
mean when there are three or more candidates in an election?".   In a
two-way election, it's easy to see what "majority rule" was -- whoever
got the most votes would win.  But in a three-way race, it's possible
for no candidate to get the majority of votes.  He proposed the
principle that if there was a single candidate who, when pitted against
all others in two-candidate, one-on-one races, would win all those other
races, then that single candidate should be the winner.  Both the
current and proposed election methods are at least supposed to have that
property.

But Condorcet's principle doesn't say anything about what to do when
there is no single candidate that would be undefeated against all other
candidates one-on-one.  Some evidence (via simulated elections) seems to
show that in 95% of elections there will be a "Condorcet winner", but in
5% there won't.  Hence any election method has to be enhanced to deal
with that issue.  The particular technique proposed here is called
"Cloneproof Schwartz Sequential Dropping" (cSSD), which refers to some
specific properties of the technique -- it is impervious to certain
types of election strategy.

Standard cSSD solves many problems; it allows for as many ballot options
as we choose, includin

Re: Call for votes for the Condorcet/Clone proot SSD voting methodsGR

[Buddha Buck]

Sam Hartman wrote:


"John" == John H Robinson, IV <[EMAIL PROTECTED]> writes:
   



   John> but is it a lack of interest in an issue at large, or a lack
   John> of interest in a particular response to an issue that you
   John> are worried about?

Before I thought about voting, I would have said lack of interest in
the issue at large.  Now, I see the arguments and believe that for
Debian it is lack of interest in a particular option.


What argument changed your mind?

Re: RFD: amendment of Debian Social Contract

[Buddha Buck]

Branden Robinson wrote:

On Sat, Nov 08, 2003 at 08:28:54PM -0500, Raul Miller wrote:


On Sat, Nov 08, 2003 at 06:56:15PM -0500, Branden Robinson wrote:

Anthony's example splits a potential "change social contract" 
supermajority into two, and yours splits it into three.


This pretty much ensures the defeat of any option that requires a
 3:1 majority, and makes it extremely difficult even to satisfy a
 propostion that requires only a simple majority.


This doesn't make sense.



Of course it does.  Consider:

[   ] Choice 1: Remove Clause 5 of the Social Contract(, Keep Debian 
Swirl Red) [   ] Choice 2: Remove Clause 5 of the Social Contract, 
Make Debian Swirl Green [   ] Choice 3: Remove Clause 5 of the Social

 Contract, Make Debian Swirl Blue [   ] Choice 4: Further Discussion

250 ballots ranking 1234 250 ballots ranking 2314 250 ballots ranking
 3124 250 ballots ranking 2221

Choices 1, 2, and 3 require a 3:1 majority to pass, of course.


What happens?  Our voting system does not give us the ability to 
reach the common-sense conclusion that 3 out of every 4 voters wanted
 to remove clause 5 from the Social Contract.  Instead, "further 
discussion" wins.  Is that because the proposition to remove clause 5
 from the Social Contract failed to persuade 3 out of 4 developers 
that it was a good idea?  That doesn't follow from interpretation of 
the results.


It follows from a correct interpretation of how the consititution
results.  The voting system is designed to be cloneproof, so that the
vote-splitting strategy doesn't work.

"3:1 Majority", in this case, is defined in relation to the "default
option", which is Choice 4.  To test the supermajority requirement,
choices 1, 2 and 3 are not compared with each other.  Check section
A.6.3 of the Debian Constitution (available at
)

I assume, from your further comments, that you think this vote should
mean that a supermajority of the voters support removing Clause 5, and
the addition of choices 2 and 3 spoilt the result.  This example is
flawed, in that even without choices 2 and 3, further discussion would
have won, since the Constitution says that the votes in favor of option
1 over option 4 must be "strictly greater" than three times the votes in
favor of option 4 over option 1 (section A.6.3.2).  Since 750 people
preferred option 1 over option 4, and 250 preferred option 4 over option
1, the ratio of those two votes is exactly 3, not strictly greater than
3.  Option 1 would fail.

I think your thesis was not intending to be dependent on such
edge-cases, but rather merely on the thesis that irrelevant options
"split the vote", as it were, and dilute the supermajority.  So I'm
going to assume, for the sake of argument, six additional voters, three
of whom voted 2314, two voting 1234 and one more voting 3124:

252 ballots ranking 1234
253 ballots ranking 2314
251 ballots ranking 3124
250 ballots ranking 2221

And I'm going to walk this through the entire voting counting procedure,
step by step:

# A.6.1 Each voter's ballot ranks the options being voted on. Not all
#   options need be ranked.  Ranked options are considered preferred
#   to all unranked options. Voters may rank options equally.
#   Unranked options are considered to be ranked equally with one
#   another. Details of how ballots may be filled out will be
#   included in the Call For Votes.

We have the ballots above.

# A.6.2 If the ballot has a quorum requirement R any options other than
#   the default option which do not receive at least R votes ranking
#   that option above the default option are dropped from
#   consideration.

I think it is reasonable to assume that since all three options 1, 2 and
3 received over 500 votes more votes ranking those options above the
default option than ranking the default option over any of those
options, that any sensible quorum requirement has been met.

# A.6.3 Any (non-default) option which does not defeat 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 defeats the default option D by a majority ratio N,
#  if V(A,D) is strictly greater than 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.

We have three non-default options to consider here: "R", "G", and "B",
all of which have a supermajority of 3:1, and thus a majority ratio of 3.

We have:
   V(R,D) = 756 > 3* V(D,R) = 3 * 250 = 750 so R is not eliminated
   V(G,D) = 756 > 3* V(D,G) = 3 * 250 = 750 so G is not eliminated
   V(R,D) = 756 > 3* V(D,B) = 3 * 250 = 750 so B is not eliminated

# A.6.4 From the list of undropped options, we generate a list of
#   pairwise defeats.
#
#   1. An option A defeats an option B, if V(A,B) is strictly greater
#  t

Re: RFD: amendment of Debian Social Contract

[Buddha Buck]

Manoj Srivastava wrote:
On Tue, 11 Nov 2003 19:47:23 -0500, Branden Robinson <[EMAIL PROTECTED]> said: 




On Sat, Nov 08, 2003 at 08:28:54PM -0500, Raul Miller wrote:


On Sat, Nov 08, 2003 at 06:56:15PM -0500, Branden Robinson wrote:


Anthony's example splits a potential "change social contract"
supermajority into two, and yours splits it into three.

This pretty much ensures the defeat of any option that requires a
3:1 majority, and makes it extremely difficult even to satisfy a
propostion that requires only a simple majority.


This doesn't make sense.




Of course it does.  Consider:



I don't think you understand the voting system.




[   ] Choice 1: Remove Clause 5 of the Social Contract(, Keep Debian Swirl Red)
[   ] Choice 2: Remove Clause 5 of the Social Contract, Make Debian Swirl Green
[   ] Choice 3: Remove Clause 5 of the Social Contract, Make Debian Swirl Blue
[   ] Choice 4: Further Discussion

250 ballots ranking 1234
250 ballots ranking 2314
250 ballots ranking 3124
250 ballots ranking 2221




Choices 1, 2, and 3 require a 3:1 majority to pass, of course.




What happens?  Our voting system does not give us the ability to
reach the common-sense conclusion that 3 out of every 4 voters
wanted to remove clause 5 from the Social Contract.  Instead,



Which, in a 3:1 majority, is barely enough.


The language in the Constitution is "strictly greater", so it is barely 
not enough.






"further discussion" wins.



Wrong.  I think that this is where the disconnect is; this
 example represents a profound misunderstanding of our voting system.


Well, "further discussion" does win, since 750:250 is not "strictly 
greater" than 3:1.


But, modulo that edge case,  I agree this example represents a profound 
misunderstanding of our voting system.




Option 1 passes Majority.   3.000 (750/250) > 3
Option 2 passes Majority.   3.000 (750/250) > 3
Option 3 passes Majority.   3.000 (750/250) > 3


For the sake of argument, let's say 3.000 > 3 instead of 3.000 == 3.

Re: The "Free" vs. "Non-Free" issue

[Buddha Buck]

Michael Banck wrote:

On Wed, Jan 07, 2004 at 09:21:50AM +0100, Sven Luther wrote:

(It is not part of debian, we were told in the past. Opponents of the 
suggested GR seem to forget that and talk of things like removing from 
debian, or phasing out from debian.) What's your suggested plan for 


I don't really care if it is part of debian or not, what we are speaking
about here is the debian infrastructure. If we were to move non-free to
a virtual non-free host or something, pointing to the real debian
infrastructure, this would be fine with me, but seriously, i don't see
what would be gained by it.



I see only one vital point for having those packages on the "real Debian
infrastructure", instead of a mere copy of it: You could continue to
reassign bugs from non-free to main.

Anything else I missed?


Yes.  The web of trust issue.

I've used Debian for 9 years now.  I've watched it grow, mature, etc.  I 
trust Debian.  As an example of my level of trusting Debian, I allow 
arbitrary Debian Developers run scripts and other programs on my machine 
with root priviledges.  Because that's what installing a .deb requires.


I also know that the thousand or so Debian developers sign their uploads 
to the Debian servers, so every package in the Debian archives has been 
uploaded by someone willing to sign their name to it.  This helps 
enforce and confirm my trust in Debian.


I don't have many packages from non-free on my machine -- most of them 
are documentation, fonts, and Java -- and could probably eliminate half 
without any noticable loss.  But I use a decent amount from contrib -- 
Eclipse, ant, other Java-based tools, etc -- and I would be loathe to 
get rid of them.


If non-free went away, I'd lose the web of trust.  I'd be forced to get 
the tools I need from non-trusted sources.  That is a major problem I 
see with getting rid of non-free.


It is not Debian's historical policy to make things harder solely to 
pursue a political goal.  Even the KDE issue wasn't about politics, but 
legalities.  Let's not make things harder to pursue political goals now.


As far as the Java stuff goes, Sun won't free their JDK, but there are 
other free JDKs out there.  The packages I'm interested don't work with 
them; which is why they are in contrib and I use the non-free Sun SDK. 
In my opinion, encouraging the free Java SDKs to become better so that 
Eclipse, et alia, can move to main is a more important goal than 
dropping support for Eclipse, etc.






Michael

Re: Results for future handling of the non free section GR

[Buddha Buck]

Debian Project Secretary wrote:

Hi,

At this point, with 563 ballots resulting in 491 votes from
 482  developers, "Choice 2: Re-affirm support for non-free" has
 carried the day. "Choice 1: Cease active support of non-free [3:1
 majority needed]" failed to even win simple majority (more people
 preferred further discussion than option 1).


The list of voters  is available at:
 http://master.debian.org/~srivasta/gr_non_free_voters.txt

And the tally sheet is available for review at:
 http://master.debian.org/~srivasta/gr_non_free_tally.txt

manoj


I'd just like to comment that I find the output of the below list hard 
to read, and I'm one of the folks who helped recommend our current 
voting procedure.





-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Starting results calculation at Mon Mar 22 00:03:07 2004


In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  1 2 3
===   ===   ===
Option 1  169   199
Option 2303 304
Option 3260   156


I think a format for the defeats table like:

Option 2 defeats Option 1 by 303 votes to 169 votes
Option 2 defeats Option 3 by 304 votes to 156 votes
Option 3 defeats Option 1 by 260 votes to 199 votes

would have been easier to read.

While a similar table does appear later on, it doesn't give the vote 
counts, only the margins of victory.  I have issues with that table, as 
well






Looking at row 2, column 1, Choice 2: Re-affirm support for non-free
received 303 votes over Choice 1: Cease active support of non-free [3:1 
majority needed]

Looking at row 1, column 2, Choice 1: Cease active support of non-free [3:1 
majority needed]
received 169 votes over Choice 2: Re-affirm support for non-free.


Even with this explanation, I had trouble reading the table above.


Option 1 Reached quorum: 199 > 45.1995575199581
Option 2 Reached quorum: 304 > 45.1995575199581


Dropping Option 1 because of Majority.  0.765 (199/260) <= 3
Option 2 passes Majority.   1.949 (304/156) > 1


  Option 2 defeats Option 1 by 134
  Option 3 defeats Option 1 by 61
  Option 2 defeats Option 3 by 148


If Option 1 was dropped because of Majority, why is it listedin this table?

For that matter, since Option 2 is clearly the Condorcet winner


The Schwartz Set contains:
 Option 2 "Choice 2: Re-affirm support for non-free"


...why are we looking at the Schwartz set?





-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option 2 "Choice 2: Re-affirm support for non-free"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Social Contract GR's Affect on sarge

[Buddha Buck]

Hamish Moffatt wrote:



Good for you. But admit that some people disagree, at least.

Perhaps next time the subject of the CFV could make no comment on the
proposal at all. Call it "SC changes", rather than "SC editorial
changes". The secretary's opinion is irrelevant to the project so please
leave it out of the CFV.


I don't like Manoj's tone in this thread.  It's harsh, accusatory, and 
somewhat rude.  It seems like he is reacting defensively, as if he feels 
people are blaming him for the results they don't like.  I don't think 
he was responsible for the results, just for running the vote.


Comments like this don't help.  This directly accuses him of mislabeling 
the proposal to support his own position.  In otherwords, accuses Manoj 
of malfeance of office as Debian Secretary.


In my opinion, that's libelous (or slandarous, I'm not sure which 
applies to emails like this).  It defames Manoj, and it's blatantly 
false, as the record will show.  This proposal has a long and 
complicated history, dating back over several years of discussion.  Only 
recently was it put into the current form, and was debated since 
December as "editorial" changes.  Manoj didn't put that label on it, and 
it was called "editorial" in the subject line of Andrew Suffield's 
original official proposing of it.





Hamish

First Draft proposal for modification of Debian Free Software Guidelines:

[Buddha Buck]

A few things first:

1.  I am not a Debian Developer, so I can not formally propose a GR or a 
foundational document amendment.  I have, however, had a long-time 
involvement in the project, and have assisted in project-related 
activities, such as developing the current standard resolution process. 
 So while I'm not able to formally do anything, I'm not coming 
completely out of left field.


2.  This is a very first draft.  There will likely be suggested changes; 
there will likely be complete overhauls.  I'm not committed to the form, 
 just the principles.  Given good arguments, it's probable that my 
stand on the principles can be modified.  I'd rather see a version we 
all can like go forward than stubbornly stand behind a flawed proposal.


3.  I've been reading too much GrokLaw lately.  It seems like it's had 
an effect on my writing style.  If you don't like numbered paragraphs, I 
apologise



(Draft) Proposal for Modification of the DSFG to allow certain forms of 
documentation, fonts, and other matters that don't conform to the 
existing DSFG into Debian.


I propose that the DSFG be amended by the addition of the following 
numbered sections.  Comments in brackets [like this] are not part of the 
amendment, but rather clarify references in the proposal:


 Additions to the DSFG 
11. Documentation and other written materials.

  Documentation and other written materials that are not programs are
  not required to meet guideline 3 [Derived works] fully.

  a.  Certain other types of written materials may restrict derivative
  works, but must allow repackaging or reformatting in ways that do
  not change their written content:

 (i)   Standards documents, such as IETF RFC documents, published
   star catalogs, and certification test suites.
 (ii)  Legal documents, such as licenses, contracts, judicial
   opinions
 (iii) Opinion documents, such as the GNU Manifesto or position
   papers that have no technical content

  If a document contains multiple sections that only some of fall under
  the exception above, only those sections may be exempt from allowing
  Derived works.

  In particular, documents (or sections of documents) which describe
  the operation or function of other software must allow creation and
  distribution of derivative works as per guideline 3 to the extent
  that the describes software does.


12.  Images, fonts, and sounds.

  Images, fonts, and sounds do not have to comply with guideline 2
  [source code] fully.  (This is a compromise.  The Debian Group
  encourages all authors to provide source code for all software,
  including images, fonts, and sounds).

Special Exception for Non-Free Firmware provided with the Linux Kernel.

  As a specific exception to the above guidelines, The Debian Project
  recognises that some Linux Kernel hardware drivers contain firmware
  and other software that is not Free Software by these guidelines.
  Many of these drivers are included with the standard Linux Source
  distribution.  Strict adherence to these guidelines would prevent us
  from including the unmodified upstream source code for the Linux
  Kernel, and would require us to remove support critical to many of our
  users.

  Therefore, we allow into the Debian Project any non-free software
  included in the standard Linux Kernel distribution solely for use
  within Debian as part of the Linux Kernel.

--- End Additions to the DFSG ---

Because this resolution changes a foundation document, it requires 3:1 
majority approval


--- End Draft Proposed GR -
--- Memorandum in Support of Proposed GR Amending the DSFG ---

Memorandum In Support of the Proposed GR Amending the DSFG to allow 
certain non-modifiable documents into the Debian Distribution.


I. Overall purpose and justification for amending the DSFG

1.  The Debian Project's Social Contract commits Debian to distributing 
Free Software, but rightly defers the definition of what is "Free 
Software" to the Debian Free Software Guidelines.  As such, when 
controversy arises over Debian's ability to keep that commitment, 
attention should not be directed at the Social Contract, but rather to 
the Debian Free Software Guidelines.


2.  In the past, the issue of documentation, fonts, images, sound files, 
and other non-program type files was "dealt with" by treating them as if 
they weren't "software".  Recent changes in the Debian Social Contract 
clarified the issue by making it clear that everything in the main 
Debian Distribution was "software", forcing all documentation, fonts, 
images, sound files, and other non-program type files that did not 
conform with the DSFG to be removed before release (at least, in the 
opinion of the release manager.


3.  Since the issue of the "freeness" of documentation, fonts, images, 
sound files, and other non-program type files is now clearly a 
"software" issue, 

Re: Proposal -- Change constitution to adopt Smith/Condorcet vote tallying

[Buddha Buck]

pear in "against" column, the person
> !with a casting vote picks the chosen option.

All options are in both columns

> ! 8. Until there is a chosen option, the last row of the winning
> !criteria table is examined and (permanently) removed from the
> !winning criteria table.  At the same time, any adjacent row(s) are
> !removed, if they are identical to what the removed row has in the
> !"votes in favor" and "votes against" columns.

F/C removed, no winner
F/B removed, no winner
A/A, B/B, C/C, D/D removed, no winner.
B/C removed, no winner
A/B removed, no winner
C/A, F/A removed, no winner
A/F A/C removed, C no longer in "Against" Column

C is declared the winner.

> ! 9. Once the chosen option is picked, the ballots are re-checked:
> !if the number of ballots which mention the chosen option is less
> !than a quorum for the vote, the default option wins.  Otherwise,
> !the chosen option wins.

C was cast on all 85 ballots cast.  C wins.

Suggested changes:

Minor: When creating the winning criteria table, include only rows 
where the "votes in favor" column equals or exceeds the "votes 
against", and do not include the i/i rows.  

That would have shortened the above sorted table to just the C/F, C/B, 
B/F, B/A, A/C, and A/F rows.  The last two rows would have been 
eliminated first, and C would have won.

I don't think that change would have an effect on the outcome, but 
would make book-keeping easier.  For one thing, if there is a Condorcet 
winner (meeting the criteria of proposed step 6).

BTW, can you state an instance where proposed step 7 would have a role? 
 I guess it could happen when you have a (reduced) table like:

   A/B50>30
   C/B45>35
   A/C40=40
   C/A40=40

The last two rows would be eliminated, leaving:

   A/B   50>30
   C/B   45>35
   
Major: Measure quorum being met by the total number of ballots cast, 
before vote-counting is done.  I.e., if quorum is (say) 40 votes, then 
the vote is valid if 40 or more ballots were cast, even if the winner 
wasn't mentioned on at least 40 of them.  If 39 ballots are cast, the 
vote did not achieve quorum, and is not counted. 

> ! 
>  When the Standard Resolution Procedure is to be used, the text which
>  refers to it must specify what is sufficient to have a draft
>  resolution proposed and/or sponsored, what the minimum discussion
> 
> 
> 
> Rationale:  We've had a number of problems from ambiguities in our
> constitutional vote tallying procedure.  Changing the voting procedure
> to Smith/Condorcet (as several people have suggested) would give us the
> same results on historical votes as the existing procedure, and would
> not suffer the ambiguities of the current procedure.
> 
> I've chosen to describe this procedure in a fairly simplistic mechanical
> fashion, to try to avoid later ambiguities in interpretation, from the
> new procedure.
> 
> This proposal would fix ambiguity #2 and #4, which were summarized in my
> 12/13 debian-vote message.  This proposal does not attempt to address
> the other two ambiguities mentioned in that message.
> 
> While we're amending the constitution, I'd also like to fix a minor
> spelling problem (minimum was misspelled).
> 
> Thanks,
> 
> -- 
> Raul
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Putting the smith back in smith/condorcet [re-call for sponsors]

[Buddha Buck]

I'm not really happy about it, but I'm not sure I can poke holes in it.

Your procedure for determining the Smith Set is dependent upon 
computing the transitive closure of the pairwise victories (the 
"beatpaths").  But the definition of the Smith Set doesn't depend on 
beatpaths at all.

I have yet to see any attempt to show that your procedure produces the 
Smith Set.  Without that, I'm not comfortable that it's equivalent.

Norman Petry did mention a procedure that would compute the Smith Set 
that has two advantages I can see to yours: a) it works directly off of 
the definition of a Smith Set, so it is easier to understand; and b) it 
has (presumably) been discussed, tested, and critiqued by experts. 

I'll also note that since you are the one proposing the method and 
claiming that they are equivalent, I believe the burden of proof is on 
you, not me.

Having said that...  I think this ballot set illustrates a problem.  
Please verify that my work-through is correct:

4 options, 3 classes of ballots cast:

10 ABCD
10 ACDB
10 ADBC

By inspection, the Condorcet Winner is A, and the Smith Set is also (by 
inspection) {A}.

Step 2: Construct Initial Totals Table

   A  B  C  D
A  - 30 30 30
B  0 -  20 10
C  0 10 -  20
D  0 20 10  -

Step 3: Construct Adjusted Totals Table

Skipped, no Supermajority Requirement

Step 4: Construct Transposed Adjusted Totals Table

   A  B  C  D
A  -  0  0  0
B 30  - 10 20
C 30 20  - 10
D 30 10 20  -

Step 5: Construct "Beats Table"

   A  B  C  D
A  0  1  1  1
B  0  0  1  0
C  0  0  0  1
D  0  1  0  0

Step 6: Transitive Closure

Both [B,C] and [C,D] are set, so set [B,D]
Both [C,D] and [D,B] are set, so set [C,B]
Both [D,B] and [B,C] are set, so set [D,C]
Both [B,C] and [C,B] are set, so set [B,B]
Both [C,D] and [D,C] are set, so set [C,C]
Both [D,B] and [B,D] are set, so set [D,D]
There exists no x such that both [y,x] and [x,A] is set,
so no [y,A] can be set.

Final transitive closure:

   A  B  C  D
A  0  1  1  1 == 3
B  0  1  1  1 == 3
C  0  1  1  1 == 3
D  0  1  1  1 == 3

Step 6: Total rows and find largest, reduce table.

The totals are shown above, and the largest is 3.  No items are 
eliminated.

It appears that the computed "Smith Set" is {A,B,C,D}, whereas the real 
Smith Set is {A}.

Did I make a mistake?

 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for comments [voting amendment]

[Buddha Buck]

Raul Miller wrote:

This is not a full draft.  In this post, I'm only including
text for replacing A.6 of the constitution.  I wanted to
also rewrite the changes to A.3, but I've got to run some
errands tonight and I'm not going to have time to write up
a full draft.

Please let me know of any flaws in the following partial draft:


I'd like some clarifications...



  A.6 Vote Counting

1. Each ballot orders the options being voted on in the order
   specified by the voter.  Any options unranked by the voter are
   treated as being equal to any other unranked options and below
   all options ranked by the voter.


Definition:  A "ballot" consists of a ranking A>B>C>D>... of options 
submitted by a voter.  It defines a total ordering of options for a 
particular voter (i.e., for any pair of options A and B, we can claim 
that a particular voter feels either A>B, AB, then 
B

Let |A>B| be the number of voters who voted A>B.
Similarly, for |A

(Obviously, |A>B| + |A=B| + |A

2. Options which do not defeat the default option are eliminated.

   Definition: Option A defeats option B if more voters prefer optio
   A over option B than prefer option B over option A.


Let A>>B ("A defeats B")if |A>B| > |B>A|
Let A==B ("A ties B")   if |A>B| = |B>A|
Let AA|
(Note: A==A, for all options A)

Eliminate all options A if Default>>A.

Clarification:  What if Default==A?


3. If an option has a quorum requirement, that option must defeat
   the default option by the number of votes specified in the quorum
   requirement or the option is eliminated.


Does is mean:

Eliminate A if |A>Default| < Quorum

or

Eliminate A if |A>Default| - |Default>A| < Quorum

Again, how do we deal with that |A=Default| case?



4. If an option has a supermajority requirement, that option must
   defeat the default option by the ratio of votes specified in the
   quorum requirement or the option is eliminated.


(?) Eliminate A if |A>Default| / |A

5. If one remaining option defeats any other remaining options,
   that option wins.


s/any/all/

"Condorcet Winner"

If there is a remaining option A, such that for all remaining options B, 
either A=B, or A>>B.

6. If more than one option remains after the above steps, we use
   Cloneproof Schultz Sequential Dropping to eliminate any cyclic
   ambiguities and then pick the winner.  These represent a procedure
   and must be carried out in the specified order:

   i. All options not in the Schultz set are eliminated.

  Definition: An option C is in the Schultz set if there is no
  other option D such that C is in the beat path of D AND D is
  not in the beat path of C.


Let A>>>B mean there is a possibly empty sequence C, D, ..., E, F of 
remaining options such that A>>C, C>>D, ..., E>>F, F>>B

Then B is on the beat path of A.

The Schultz Set = { A | A>>>A }

Note:  Because A==A, it isn't the case that A>>A, so if the Schultz set 
includes A, then there must be a B!=A such that A>>B>>...>>A.  Since 
A>>B, we then have B>>...>>A>>B, so B is also in the Schultz set. 
Therefore, the Schultz Set can't be a Singleton Set.

  Definition: An option F is in the beat path of option G if
  option G defeats option F or if there is some other option
  H where option H is in the beat path of G AND option F is in
  the beat path of H.

   ii. Unless this would eliminate all options in the Schultz set,
	   the options which have the weakest defeat are eliminated.

	   Definition: The strength of a defeat is represented by two
	   numbers: the number of votes for the defeated option and the
	   number of votes for the defeating option.

	   The more votes in favor of a defeated option, the weaker
	   the defeat.	Where two pairs of options have the same number
	   of votes in favor of the defeated option, the fewer votes in
	   favor of the defeating option, the weaker the defeat.


So if we have two defeats A>>B and C>>D, then we lexigraphically compare 
(|B>A|, -|A>B|) and (|D>C|, -|C>D|)

What do you mean by "options with the weakest defeat"?

My understanding was that we were removing defeats from consideration. 
If, for example, there were four options A, B, C, D in the Schultz Set, 
we'd initially be looking at the following set of defeats, in strongest 
to weakest order:

A>>B
A>>D
B>>C
C>>A
D>>C
B>>D

After eliminating the weakest defeat (in this case, B>>D, we no longer 
consider it when determining the Schultz Set, as if we had declared 
B==D, so that neither B>>D or D>>B held.

So what do we really want to eliminate here?

And...

What if we had |D>C| = |B>D|, |D=C| = |B=D|, |D>C nor B>>D was weaker than the other?  Do we eliminate both 
defeats?

   iii. If eliminating the weakest defeat would eliminate all options
	in the Schultz set, a tie exists and the person with the
	casting vote picks from among these options.


Hmmm

Re: Request for comments [voting amendment]

[Buddha Buck]

Matthias Urlichs wrote:

Hi,

So who did come up with the mistake "Schultz", and did they eat too many
peanuts? ;-)

Anthony Towns:



The correct restatement is something more like:

	{ x | forall y: y >> x --> x >>> y }



Or, in understandable language: The Schwartz set is the innermost unbeaten
set, or the smallest set of candidates such that none are beaten by any
candidate outside the set.


I think we need to come up with better, understandable, language.

Let me make sure I understand the Schwartz set.

Is it accurate to say that if x is in the Set, and y>>x, then y is in 
the set?

Is it accurate to say that if there is no y such that x>>y (i.e., x 
defeats nothing), then x is NOT in the set?

If we have options A, B, C, D, an A>>B,C,D, B>>C>>D>>B, then {B,C,D} is 
not the Schwartz Set because A>>B?  A is in the Schwartz Set because 
there is no x such that x>>A?

I'm trying to figure out where x>>>y comes into play with the Schwartz set.

What is the Schwartz set for:

A==B; A>>C,D,E; B>>C,D,E; C>>D>>E>>C?

I coul make an argument that {A} is the Schwartz set. It's an unbeaten 
set, and the smallest of all possible unbeaten sets (tied with {B}, etc. 
 The same argument could be made for {B}.  I think the answer is {A, 
B}, but I don't have any real justification for it.


As for resolution, I'd adopt the SSD method, which states
1- Determine the Schwartz set.
2- Drop the smallest defeat(s) within the set.
3- Repeat 1-3 until there's a winner.

See http://electionmethods.org/CondorcetEx.htm.
It explains all of this in reasonably easy-to-understand language.








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Another proposal.

[Buddha Buck]

Anthony Towns wrote:

On Tue, Nov 19, 2002 at 12:06:20AM +1100, Clinton Mead wrote:


Andrew Pimlott wrote:


So for example, the clause, in most drafts, that first eliminated
options that were defeated by the default option, was a direct
invitation to insincere strategic voting. It would encourage voters
to put the default option second, in an attempt to knock out the
other candidates early. Exactly what we're trying to avoid with the
Condorcet method.



But it's exactly what we're trying to achieve with the supermajority
requirement, isn't it? Allowing voters to vote strategically so as to
knock out candidates they don't like?


If I remember correctly, the biggest stumbling blocks in the voting 
proceedure committee were a) what is the supermajority requirement for, 
and b) how do we acomplish the same goal in a Condorcet-style voting system?

I still think that this is a fruitful route to pursue.

The main reason for supermajority requirements on some actions is to 
ensure that there is a large amount of support for those actions by the 
voting population.  Extraordinary actions like modifying the Debian 
Constitution should not be done without the support of the developers -- 
more support than for a ordinary resolution.

When you are limited to two choices, the requirement of a supermajority 
voting in favor of the extraordinary action over doing nothing clearly 
indicates a large amount of support for the extraordinary action.  This 
is why supermajority requirements are often written in that form.

But Condorcet voting (or ranked voting option in general) don't lend 
themselves to this same sort of overwhelming support idea, especially 
with a mixture of extraordinary actions, ordinary actions, and 
"do-nothing" actions.  It becomes harder to define what "supported by a 
large number of voters" means.

I believe our conclusion was to use the "default" or "None of the Below" 
 (NOTB) option on a ranked ballot as a proxy for approval on an 
Approval ballot.

In Approval balloting, it is easy to determine if a measure has 
supermajority support.  Simply look at the "yes" votes for an option, 
compared to the "No" votes.  If a supermajority voted "yes", then that 
option has supermajority support.

By defining an option as "approved" on a ballot if it is ranked higher 
than the NOTB, we can check the supermajority approval requirement for 
an option simply by comparing it to the NOTB option. When we say "an 
option defeated the default option by a supermajority", that's an 
operational way of saying "an option is approved by a supermajority of 
the voters".

That, I believe, is the rationale for judging supermajority requirements 
versus the NOTB option, as opposed to any other option.

But that doesn't solve the entire issue of extraordinary action. 
Examine the following results of an approval ballot between a non-free 
amendment A, non-free resolution b, and "further discussion" 
(Assumption: no majority vote would mean "stop talking and do nothing"):

Amendment A:  70%  (66% minimum needed for adoption)
Resolution b: 68%  (50% minimum needed for adoption)
Keep Talking: 25%  (50% minumum needed for adoption)

Here, A clearly got a higher rating that b, and beat the supermajority 
requirement as well.  But b was nearly as well liked.  My personally 
feeling is that the resolution, being the more "ordinary" action, should 
win over the extraordinary amendement in such a close ballot.  But it's 
hard to tell.  On an approval ballot, I'd probably scale the options 
based on their minimum vote needed to succeed, to get:

Amendment A:   1.06
Resolution b:  1.36
Keep Talking:  0.50

and note that that Resolution b: exceeded it's threshold by a larger 
proportion of the voters than the Amendment A, and thus, passes.

My feeling, for a Condorcet-style election procedure is that to deal 
with extraordinary options,

a) if there is an extraordinary option, there must be a NOTB on the ballot.
b) if an extraordinary option does not defeat NOTB by a supermajority, 
that extraordinary option cannot win.
c) The winner of the normal Condorcet-style vote resolution method (in 
our case, CSSD) wins, if able.

I thought that the voting procedure committee had accepted esentially 
that conclusion.

The above method for dealing with supermajorities in Condorcet-style 
elections has one loose thread:  when do extraordinary options lose?

If they lose (and are eliminated) before the CSSD procedure is applied, 
then the CSSD procedure is simplified by the elimination of extraneous 
choices.

If the supermajority option is checked

But look at the following set of ballots (A is extraordinary, N is NOTB, 
b and c are ordinary):

4 cAbN
1 cNAb
3 bcNa
3 AbcN

  A  b  c   N
A 0  8  3   7
b 3  0  6  10
c 8  5  0  11
N 4  1  0   0

A fails the supermajority requirement, so by my conclusion above, can't 
win the overall vote.  If we eliminate it as an option before applying 
CSSD, then b is the Condorcet winner

Re: Another proposal.

[Buddha Buck]

Raul Miller wrote:

Raul Miller wrote:


On the other hand, we've never had an official vote which was even close
to failing to meet our quorum requirement.



On Tue, Nov 19, 2002 at 10:01:01AM -0800, John H. Robinson, IV wrote:


let me see if i undserstand this quorom thing:

we want to know that a significant portion of the electorate care enough
to represent themselves.

so would not the quorum be the simple number of votes cast?

if the quorum is 72, and seventy people vote, then quorom is not met,
and the vote is invalidated on those grounds. regardless if all vote ABF
and thus A has supermajority (at any ratio) over B and F.



That would be bad.

If you do it this way, there are circumstances where a vote against
an option may cause that option to win (because without that vote the
option wouldn't have met quorum).


I think you are misunderstanding the suggestion.

The way quorum usually works in face-to-face meeting is that the 
deliberative body cannot come to a decision without a quorum.  If a vote 
is held and then it is discovered that there was not quorum at the time 
of the vote, then the vote is discarded.  No option wins, no option is 
defeated.

In the case that John Robinson mentioned, if the quorum is 72, and 70 
people vote, there is no quorum, so all 70 ballots are discarded and the 
vote is null and void.

I read his suggestion as extending that to Debian voting procedure.  He 
would have quorum measured not on an option-by-option basis, but on a 
total-ballot basis.  Too few valid ballots received nullifies the vote. 
 If enough valid ballots are received by the deadline, then the vote is 
binding, regardles of the number of people who voted for (or against) 
any particular option.






also, with the Condorcet + SSD election method, is the supermajority
requirements really required? it does allow a vocal minority to block an
action. is that desired? if so, why?



The supermajority requirements give you a (relatively) stable frame of
reference to reason against.  Thinking about voting in a context where
it's just as easy to change the voting system as it is to change what
the voting system is being used to decide is... rather difficult.








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Another proposal.

[Buddha Buck]

John H. Robinson, IV wrote:

Raul Miller wrote:


That's the way I read his suggestion, also.  And that's what I was saying
is bad.  I don't think you understood my objection.

Here's the problem: a vote against an option can cause quorum to be met
and therefore cause the option to win.  This discourages sincere votes
against the option.



i don't buy that logic. the case is true, and having X>Q votes causes
the vote to be binding.


I agree with John.


i can see two major outcomes when X

I'd sort of be willing to see 3) the ballot, and all proposals on it, 
are dismissed without prejudice (meaning they can be proposed again). 
This is different than "Further Discussion".

the whole supermajority thing i feel would make people vote insincerely.
the ony way to avoid it, as i see it, is to _remove entirely_ the Quorum
and Supermajority requirements.


I don't see Quorum requirements as a problem, as long as they don't 
apply differently to different ballot options.

There is a goal of making some actions (like modifying the constitution 
and/or Social Contract and/or the DFSG) harder than others (like issuing 
a resolution).  This goal is traditionally met with supermajority 
requirements.

If we drop the supermajority requirements, how would you meet the stated 
goal?



-john









--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Another proposal.

[Buddha Buck]

Matthias Urlichs wrote:

Hi,

John H. Robinson, IV:


i had always understood quorum as the minimum number of participants to
conduct business. 

[Matthias's comments rearranged...]


Sorry, but I don't like that. With a quorum, the people against a proposal
need to actively solicit support for their objection if they want to
defeat it. That's good democracy. Defeating the proposal by walking out
is bad democracy.


In parliamentary terms, "conducting business" means "making decisions by 
vote".  Normally, a measure can't be defeated by lack of quorum.  If 
there is a lack of quorum, no vote can be held -- or if a vote is held 
before quorum is determined to be lacking, the vote isn't binding.

Bringing this quorum principle over to Debian, the most straight forward 
rule would be that if there aren't enough participants in the balloting, 
then the status is reset to what it was before the vote -- i.e., nothing 
is defeated, nothing is passed, nothing is decided.  Another ballot is 
advertised and distributed (perhaps after a short period), and another 
vote is held.

That may not be the best option -- there may be better solutions, like 
dimising the ballot options without prejudice, requiring the proposers 
to repropose them (if the proposals were dead, that shouldn't be 
possible), or defaulting to "further discusion", etc.

> OK. Let's say we have a quorum of 90 and a supermajority of 2:1.
70 people are for the proposal, 30 against => the proposal wins.
70 people are for the proposal, 10 against, the remaining 20 refuse to
vote => the proposal fails. 

What do you mean "the proposal fails"?  Is it dead, and can't be 
resurrected?  Is it up for "further discusion", with a future revote?  I 
feel that a lack of quorum shouldn't be able to kill a measure, but 
forcing another vote on the issue after further discussion is fine, IMHO.


IMHO.








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Another proposal.

[Buddha Buck]

Raul Miller wrote:

Raul Miller wrote:


Here's the problem: a vote against an option can cause quorum to be met
and therefore cause the option to win.  This discourages sincere votes
against the option.



John H. Robinson, IV wrote:


i don't buy that logic. the case is true, and having X>Q votes causes
the vote to be binding.



On Tue, Nov 19, 2002 at 03:50:10PM -0500, Buddha Buck wrote:


I agree with John.



Can you explain what he's saying in a meaningful fashion?  [It looks to me
like he's contradicting himself, but apparently you have a self-consistent
way of interpreting what he's saying?]


Sure.

In the case you mentioned, sentiment is for the proposal, so the option 
should win -- assuming the vote is binding.  If there are enough total 
ballots to meet quorum, the vote is binding.  If there aren't enough 
total ballots to meet quorum, the vote shouldn't be binding.

Quorum is traditionally a way to determine if there is sufficient 
participation in the deliberations to make any decision binding on the 
organization making the decision.  If too few people actually return a 
ballot, then too few people participated in the decision-making process 
for the decision to be valid.

You (and Matthias) seem to be assuming that if quorum isn't reached, 
then the ballot measures should be shot down.  I and John are saying 
that if quorum isn't reached, then the trigger hasn't been pulled yet 
(to stretch a metaphor).

But that is making a binding decision based on a lack of quorum.  That 
goes against what quorum is usually used for.

You are also applying quorum requirements to individual options on the 
ballot, rather than the vote as a whole.  I've rarely seen that use of a 
quorum in the past.

Would you be satisfied if the too-small minority were unable to get 
their way by not voting, but would only serve to delay the final 
approval of the supermajority option, by forcing another vote?

In otherwords, if X (the number of ballots) < Q (quorum), then the 
results of the vote is non-binding.  It doesn't even need to be 
computed, since it doesn't matter which option won.

If X > Q, then the vote is binding, and we go with whatever option won 
after applying supermajority and Condorcet/CpSSD procedures.

That is in line with how I would normally interpret a quorum.





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: supermajority options

[Buddha Buck]

Raul Miller wrote:

Here's some thoughts about how we might implement supermajority:

[1] 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.


It would certainly be easiest to implement, but it would make it as easy 
to amend the Constitution as to pass a resolution.  There is some sense 
in making it harder to amend the governing documents.

[2] Discard the election if the winner doesn't meet supermajority.
Perhaps, if the ballot has nondefault options with differing supermajority
ratios, immediately hold another election using only the options with
a lesser supermajority ratio.  I'm leaning towards this at the moment.


This is underspecified.  Define "winner doesn't meet supermajority.".

Once that definition is made to my satisfaction, I like this option, or 
one of these two variants:

[2a] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Default option (Further Discussion) wins by default.  New election to 
be held after appropriate discussion period.

[2b] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Hold an "instant runoff" using all the remaining options and the same 
ballots.  Repeat until a winner is found.

I used to favor [2b], but I think I like [2a] best right now.

[3] (current draft) Only consider supermajority in terms of defeating
the default option.  This gets a bit confusing to think about in the
context of transitive defeats.

[4] (my old hobby horse) Consider supermajority in every comparison
involving an option with a supermajority requirement.  This gets a bit
confusing to think about in the context of transitive defeats.

[5] (Nov 16 and earlier drafts) Discard options which don't satisfy
supermajority before considering transitive defeat.  This gets a bit
confusing to think about in the context of transitive defeats.

Suggestion?  Comments?  Incoherent ramblings?

[Note: I'm not going to be around much tomorrow.  Maybe you'll have
everything solved for me when I get back?]

Thanks,








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: supermajority options

[Buddha Buck]

Matthias Urlichs wrote:

Hi,

Buddha Buck:


[2a] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Default option (Further Discussion) wins by default.  New election to 
be held after appropriate discussion period.

[2b] Discard the result if the CpSSD winner doesn't meet supermajority. 
 Hold an "instant runoff" using all the remaining options and the same 
ballots.  Repeat until a winner is found.

I used to favor [2b], but I think I like [2a] best right now.


... but what if the second vote fails too? 

I'd prefer [2b], with a mandatory "do nothing" option on the ballot. That
way, people can indicate whether further discussion or something else
(or nothing at all) should take place, should the supermajority option
fail.

Except in the case of an election, there should always be a "reject all 
options" choice on the ballot.  Assuming the simple case of a single 
resolution option, we'd want the ballot to look like:

[  ] ACCEPT resolution declaring Buddha Buck a forbidden interloper
[  ] REJECT resolution declaring Buddha Buck a forbidden interloper
[  ] FURTHER DISCUSSION

It makes no sense to have no way to reject a proposal or an amendment.







--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Nov 19 draft of voting amendment

[Buddha Buck]

Branden Robinson wrote:



Yes, it does.  See the flamewar about non-free on debian-devel.  Giving
people their opportunity to explicitly express their preference for the
status quo (", damnit!") is a good thing, if someone can be bothered to
propose that as an amendment to the proposed GR, and if it acquires
enough seconds live on its own.

"FURTHER DISCUSSION" is not highly communicative.  When ranked first, it
tells you relatively little about the voter's intent.

I am wondering if it is really a good idea to always have a do-nothing,
futher-discussion option that is the default.  It may be better to make
these get proposed and seconded like any other option, and make them
have to fight for victory just like every other option.


Hmmm, so if I make a suggested amendment to the Debian Constitution 
(such as "Replace all instances of the word 'Concorde' in connection 
with the voting system with the word 'Condorcet'.  Rationale:  This was 
clearly a misspelling or mistake in the original drafting of the 
Constitution"), that no one on Debian-Vote appears to object to, the 
ballot should look like this:


Rank all options in order of preference.  Unranked options will be 
considered equal to each other and ranked lower than any ranked options.

[   ]  AMEND the Constitution as per Proposed Amendment I, above.

Sign your completed ballot with your Debian PGP key, and send it to


My opinion is that that is a stupid ballot.  There should always be a 
method to reject a proposal, unless there is some good reason not to.

What would be a good reason not to?  Imagine the following resolution, 
hypothetically enacted:


Be it RESOLVED, that the Debian Project shall adopt a mascot, and that 
the Debian Project Leader shall appoint five Debian Developers to review 
and select at least five candidate mascots by no later than three months 
 from the date of this reolution.  The Debian Developers shall select, 
by vote, a mascot from among the selected candidate mascots.
-

This is a case where I can see there being no default option, no 
none-of-the-above, and no "further discussion" either.

But that's an exception, because the decision to do something was 
already made, the only thing remaining is a choice over what to do. 
When the decision to do something hasn't been made, there needs to be a 
"do nothing" choice of some sort.

If we retain a quorum requirement in terms of a minimum number of
ballots that have to be received before the result will be formally
tabulated, then "FURTHER DISCUSSION default options" are even less
necessary because people can just "indifference" a proposal to death.








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: supermajority options

[Buddha Buck]

Raul Miller wrote:

Once that definition is made to my satisfaction, I like this option, or 
one of these two variants:

[2a] Discard the result if the CpSSD winner doesn't meet supermajority. 
Default option (Further Discussion) wins by default.  New election to 
be held after appropriate discussion period.

[2b] Discard the result if the CpSSD winner doesn't meet supermajority. 
Hold an "instant runoff" using all the remaining options and the same 
ballots.  Repeat until a winner is found.

I used to favor [2b], but I think I like [2a] best right now.


I'm thinking a version of 2b could work quite well.

What's your reason for disliking instant runoff?  [Let's assume we
only use it for cases where all options in schwartz set had a majority
requirement greater than 1:1].


I didn't say I didn't like instant runoff -- I think I was one of the 
original proposers of an instant-runnoff idea in the past.  I said I 
liked 2a better than 2b.  2b works, but in my opinion not as well as 2a.

The rationale for the my opinion is something like the following:

The CpSSD process, in some sense, determines what, in the collective 
opinion of the voters, is the "best" option.  Both 2a and 2b try to, at 
first pass, determine what the overall "best" option is.  The 
supermajority requirement, on top of that, says that some options need 
extraordinary support to be adopted.  The difference between 2a and 2b 
happens when the "best" option doesn't have the extraordinary support it 
needs.

One choice (2a) is to keep discussing the issue until a workable "best 
option" can be found.  In this schenario, it may take more time, but 
eventually an electable "best" option will be found.  Proponents of an 
amendment (the "best" option found so far) may gather more support. 
Proponents of another option may sway opinion so that when the next vote 
comes, some other option is now regarded as the "best", and that option 
will win.  If you want to get the best option, 2a says "settle for 
nothing less than the best".

Another choice (2b) says to find a winning option in one vote, without 
further discussion.  If the "best" option is unelectable because it 
lacks necessary extraordinary support, try to find the 2nd best option. 
 If that is also unelectable, go for 3rd best.  Every vote will have a 
decided winner (even if that winner does turn out to be "further 
discussion").  In a sense, 2b says "If we can't get the best, take what 
we can get now".

Naturally, I'd prefer to select the best option, not what we can get, 
even if it takes more time.  Things are rarely so pressing that making a 
 decision to change the constitution must be made immediately.

As to why I prefer (2) over the rest...  CpSSD is well-defined and 
reasonably well studied when all votes are counted equally.  I find the 
idea of scaling votes involving particular options to change it enough 
that its properties become unknown and unpredictable.  It may be 
severely broken in ways that CpSSD isn't.  I'd rather have the core be 
something we know is good.  That means that I have legitimate FUD with 
[3] and [4].

CpSSD does not satisfy the Independence from Irrelevant Alternatives 
criterion.  It's possible to create a set of ballots with amendment A 
such that resolution B wins, but when A is dropped form the ballot, 
resolution C wins:  create a ballot where C>>B>>A>>C, and C>>B is the 
weakest defeat in the cycle.  I have done it in the past, it's not hard. 
   As such, I feel there is a loss of information, a loss of 
expressiveness in the ballots by dropping an option before we know that 
doing so won't hurt the election.  Dropping a "best" option that is 
unelectable will obviously change the outcome of the election, but 
that's what we want in that case (2b).  But dropping early raises doubts 
that we are really following the voters will.  So that's my problem with 
[5] and any other option that tries to eliminate options before 
performing CpSSD.

Unlike Branden, I would like some issues to be hard to change -- things 
like the Social Contract and the DFSG.  I think it's one of Debian's 
strenghts that we take a principled stand, and have not waivered on 
those principles (at least, in principle) since we stuck our necks out 
and said "this is what we believe".  Debian has, by example, said "It's 
not good enough to be best, it's important to do the right thing, as 
well".  I feel the fact that the Open Source Definition has changed to 
be a weakness of the OSD, compared to the DFSG.  The Social Contract is 
older still, and it, too, has been steadfast.  It should be hard to 
change, and it's important that we don't forget why we are doing what we 
are doing.  I don't want it to be as easy to change these things as it 
is to pass a technical policy statement.  As such, I do not believe it 
is right to drop the supermajority requirement as stated in option [1].

(You might be able to tell from the above political rant that I align 
myself closer to the

Re: supermajority options

[Buddha Buck]

Branden Robinson wrote:

On Fri, Nov 22, 2002 at 12:39:27PM -0600, Manoj Srivastava wrote:


	Interesting. However, that paper makes a number of assumptions

  May (1952) shows that majority rule is the only positively
  responsive voting rule that satisfies anonymity (all voters are
  treated equally) and neutrality (all alternatives are treated
  equally).  If we use a system other than majority rule, then we
  lose either anonymity or neutrality.

	Eh? this obviously does not apply.



It isn't even the central thesis of the paper, so I'm not sure what
you're really establishing here.

Our voting system does not have anonymity, except in Project Leader
elections (well, in theory anyway[1]), which are already conducted under
a simple majority requirement and wouldn't be impacted by a proposal to
eliminate supermajority requirements from the Constitution.

So, the remaining question is, do we lose "neutrality"?


Obviously -- The paper defines "neutrality" as "all options are treated
the same".  If we are asserting a supermajority requirement on certain
actions, like constitutional amendments, then we are not treating all
options the same, and therefore lose neutrality.

The remaining question:  Do we want "neutrality"?

"Neutrality" isn't always a desirable condition.


Additionally, the core of the argument is about bargaining powers,



No, it isn't.  The core of the argument is that supermajorities prevent
consensus from being expressed through minorities' defense of their
positions.

	Our thinking about majority rule has been considerably sharpened
	by formal social choice theory.  As already noted, May (1952)
	shows that majority rule is the only positively responsive
	decision rule satisfying anonymity and neutrality.  In a similar
	vein, Rae (1969) and Taylor (1969) show that majority rule is
	the decision rule that minimizes the probability that an agent
	votes for something that is not enacted or votes against
	something that is.  Straffin (1977) shows that majority rule is
	the decision rule that maximizes responsiveness to individual
	preferences.  Social choice theory has demonstrated that
	majority rule is prone to cycles (Condorcet 1788/1955; Arrow
	1952; Plott 1967; McKelvey 1976, 1979; Schofield 1978).  The
	conditions under which this applies to super-majoritarian
	decision rules has been explored by Nakamura (1979), Greenberg
	(1979) and Schofield et al.  (1988). Miller (1980) and McKelvey
	(1986) show there are strict limits to majority rule cycling
	under normal institutional settings, and Miller (1983) argues
	that the instability produced by cycling may actually beneficial
	to systemic stability by assuring that there are no permanent
	losers.  Laing and Slotznick (1987) show that under
	super-majoritarian rules, it may be strategically rational for
	blocking minorities to defend extreme status quo positions, even
	though they would like to see them replaced.

Note especially the last sentence.  Is insincerity really a feature we
want in our voting system?


Defend against what?  Replaced by what?  If the proposed alternative to
an extreme status-quo is an extreme in the opposite direction, and my
real position is that the status quo is in the right direction but too
extreme, I'd defend the status quo over the proposed alternative.


A point directly rebutted by the paper.

"With super-majority voting, the status quo is privileged­if there is no
alternative for which a super-majority votes, the status quo is
maintained.  Following Rae's (1975) argument, given that the status quo
is more desirable to some voters than to others, some voters are
effectively privileged.  It is certainly the case that super-majority
rules can privilege (protect, if you prefer) some voters.
Unfortunately, it is not possible to privilege every group over every
other group. If super-majority rules create a privileged group, there
must be a corresponding under-privileged group."


This argument seems circular.  The "priviledged group" is the group that
supports the status quo over a proposed alternative.  This "priviledged
group" has no other definition, and can't be identified except by voting
records.

That the group of voters who prefer the status quo have their voting
power enhanced by a supermajority system is obvious.  In fact, I'd say
it's a *design goal* of supermajority systems.  Similarly, that the
groups of voters who desire change have more work to do, more support to
gain in a supermajority system is also , in my opinion, a design goal of
supermajorities.

Claiming that this is a problem requires more proof than simply stating
that there is are privileged and underprivileged groups, as if this is
an apriori bad thing.  Especially when the privileged and
underprivileged groups change silently with each proposed change.


"Using some simple examples, we can illustrate some of the problems that
super-majoritarian rules can produce.  Such rules can lead to the
complete exclusion of minorities, to im

Re: supermajority options

[Buddha Buck]

Jochen Voss wrote:

Hello,

On Fri, Nov 22, 2002 at 10:16:27AM -0500, Buddha Buck wrote:

I agree with this.  But doesn't the same argument apply
to at least [5]?


Very possibly.  (I'm out of town at the moment, and don't remember 
exactly what [5] was).  But I had other issues with [5] as well which 
discounted it.



Jochen





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: supermajority options

[Buddha Buck]

Please forgive my late reply.  I'm on vacation, and haven't had access 
to email since Friday.  I should bow out of this discussion until I am 
back from vacation and have more reliable email access.

Branden Robinson wrote:
On Fri, Nov 22, 2002 at 03:42:12PM -0500, Buddha Buck wrote:


Obviously -- The paper defines "neutrality" as "all options are treated
the same".  If we are asserting a supermajority requirement on certain
actions, like constitutional amendments, then we are not treating all
options the same, and therefore lose neutrality.

The remaining question:  Do we want "neutrality"?

"Neutrality" isn't always a desirable condition.



I argue that we do want neutrality.  It's the same thing as arguing
against supermajorities.


In which case, arguing against supermajorities because of neutrality is 
fairly circular, don't you think?

Personally, I think it should be harder to change the DFSG, the Social 
Contract and the Constitution than to do most other tasks that can be 
done by the General Resolution process.  As such, I do not favor 
neutrality (i.e., treating all possible options equally), but 
specifically *want* to treat certain options more differently.

(Nota Bene:  I am certain that supermajority procedure implies a lack of 
neutrality, but I'm not certain that a lack of neutrality implies 
supermajority procedure.  But it may be a matter of definition.  If a 
non-Amendment GR passes if it is the CpSSD winner, but an Amendment is 
required to be the Condorcet winner (vote to be held again, after a 
discussion period, if an Amendment is the CpSSD winner but not the 
Condorcet winner), is that a supermajority procedure?  It is definitely 
a non-neutral procedure).

Most of my argument you quoted below was directly related to the McGann 
paper, and not customized to deal with Debian Politics at all.

"Can lead...to" is very open-ended, wishy-washy words.



You should read the whole paper, including the examples.



Likewise majority-rules can lead to situations where there is no
stability, and adapted positions flip-flop back and forth between
extremes.



Why would they flip-flop between in extremes under our system, where we
can have multiple options on the ballot, and rank-ordering by the voter?


My statement was intended to be taken as a similar open-ended 
wishy-washy statement as McGann's, conveying an equally true issue, but 
contrary to McGann's thesis.

It is very likely that Debian's ability to have lots of ballot options 
on one ballot, and using rankings for all the options by each voter 
individually to determine the outcome will sucessfully short-circuit 
extreme positions -- if people are aware of how easy it is the place 
amended version of a ballot on the ballot against the original proposal.

On the otherhand, it might also short circuit debate and compromise, 
since there is less impetus to convince people of your version over 
another before the ballot is drawn up.  I suspect that that won't be a 
problem with Debian, but you never know.  I have been tempted to simply 
suggest to you that you propose the "neutral majority rule" version of 
the changed voting procedures as another ballot option running against 
whatever the supermajoritarians finally suggest.

Witness, for instance, the recent US Congressional elections, and the
declared "conservative mandate" from a very narrow majority for the
majority party.



You're claiming this is evidence for what, exactly?


In support of my wishy-washy, open-ended claim that majority rule can 
cause a rapid flip-flop from extreme position to extreme position without.

Actually, it is stronger evidence against McGann's thesis, that majority 
rule provides the best protection for the minority.  As you point out, 
if the majority can, before the minority opposition has a chance to 
reorganize into a majority, entrench its position, then the problems 
caused by the majority can be long-lasting.  Since there is no recall 
provisions for Senators and Congresscritters in the US system, there 
will be no way for the voters to effectively challenge what the very 
slim majority in Congress does for two years.  If the opinions of the 
voters change based on the actions of Congress, acting on their 
illusionary "Mandate", the new majority can't "promptly repeal" those 
actions.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Hybrid Theory

[Buddha Buck]

Raul Miller wrote:

On Thu, Dec 12, 2002 at 04:29:49AM +1000, Anthony Towns wrote:


Sorry, I don't buy this.



Ok.

I'm wondering if other people agree.  [I wish Buddha wasn't
on vacation, this was his example.]


Sorry...  I'm back, but my computer at home is having some problems (old 
power supply was advertised at 300W, but rated for 160W continuous; new 
power supply (installed last night) is rated at 350W continuous, but now 
I need to rebuild my system), so I've been limited to reading from work 
-- where I should be working rather than arguing debian politics.

My argument was in support of late-dropping of unwinnable supermajority 
options.  I felt that we should leave the mechanics of CpSSD alone, and 
decide after a winner had been chosen if the winner has supermajority 
support.  If not, punt, in some way.  Most likely by eliminating that 
supermajority candidate and running CpSSD again.

THe other option to modifying the mechanics of CpSSD is to early-drop 
unwinnable supermajority options.  This leaves the behavior of CpSSD, 
and its properties, intact for the possible winning options.

The case where the two would give different results is when there is no 
Condorcet winner, and a supermajority option is in the Schwartz set in a 
loop with the potential winners, yet CpSSD does not select either the 
supermajority option or the option it defeats.  The example I gave led 
to the following loop:

A->b->c->A

where A is a supermajority option, and b, c are normal options and the 
b->c defeat was the weakest.

With late-dropping, the CpSSD procedure would have declared c the 
winner.  With early-dropping, the CpSSD procedure would have declared b 
the winner.

To decide which of these two procedures makes the most sense, compare 
these two statements:

(late-dropping): c won, because we discounted the votes of the people 
that preferred b over c, but counted the votes of the people that 
preferred A over b, even though B couldn't have won.  This is unfair and 
counterintutive.

(early-dropping): b won, but only because A was a supermajority option. 
 If A had been a normal option, c would have won.  Why is it that 
making A harder to win shifted the result from one winner to another? 
This is unfair and counterintuitive.

Which of those two statements is the most convincing?




Define "like Condorcet".


Same outcome as Condorcet for the same votes.


Heh. Condorcet doesn't produce a winner for the case you give;



Sorry, I should have been saying CpSSD.

Thanks,








--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: February 17th Voting GR draft

[Buddha Buck]

Sam Hartman wrote:

Would someone mind giving me a few examples of how this works in practice?

Let's say I propose a GR and get seconds and it comes to a vote with
no amendments.

Would the two options on the ballot be my GR and a default option of
more discussion?


I think that, under the proposal as made, this is correct.  I think 
that, as a matter of voting, it should be wrong.  I hold the position 
that there should always be an option to reject, without more 
discussion, a GR.

When this has been brought up in the past, I believe that it has been 
recommended that a reject/status-quo amendment be proposed by someone 
who wants to reject the GR (and gets it seconded) as a way of getting a 
"reject" option on the ballot.  It has also been mentioned that because 
of the way that GRs are proposed, there is little practical difference 
between "reject" and "further discussion".  I don't agree with either of 
these.

I realize this is a simplistic example; my actual question has to do
with how supermajorities work, but answering this question is
sufficient to answer my real question.


Ask your actual question, then.






--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Moshe Zadka ] Independent Count

[Buddha Buck]

Martin Schulze wrote (publically to Moshe Zadka):

If you can't trust Manoj, who else can you trust in this project?

And do you really believe that people want you as DPL when you are
apparently unable to compress an IRC log to the relevant "offensive"
messages, but send a 300 lines IRC logfile instead?
Er, in fairness to Moshe, the impression I got from reading the 300 
lines of IRC logfile was that the log was added, unedited, by Manoj.

The log includes comments from Moshe that he had already emailed the 
DPL, inquiries from Manoj about the legitimacy of posting #debian-devel 
IRC logs to the lists (in case the policy was that it was private, like 
debian-private email list email), and Manoj stating that he wasn't going 
to let the accusations of impartiality stand without the evidence of 
where they came from, and statements from Moshe that he was going to 
summarize the IRC log.

I have not seen Moshe's summary yet, though.


Regards,

	Joey







--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: integrity of elections

[Buddha Buck]

Hamish Moffatt wrote:
On Wed, Mar 26, 2003 at 02:18:45PM +1100, Glenn McGrath wrote:

And why do you think this should be allowed?
Because they are a part of the debian community, and probably have a
reasonable understanding of debian politics.


That's true of some of our users too. There would be a few who have been
around longer than most of our developers. Some who have contributed
more than some of our developers, too.
True, but we don't get a vote, either.  And that's OK by me.

Debian has, in general, been very, very good about letting anyone who 
has a valid point participate in the political and policy debates, 
regardless of status -- sometimes at fairly high levels, too.  There was 
at least one non-voting user on the committee tasked to develop the new 
proposed voting method.

Hamish






--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Project Leader Election 2003 Results

[Buddha Buck]

Manoj Srivastava wrote:
On Mon, 31 Mar 2003 15:35:15 +0100,
Matthew Wilcox <[EMAIL PROTECTED]> said: 


 > I believe the method for choosing the hash that allows one to
 > identify one's vote is flawed.  Since all components of the string
 > to be fed to md5sum are chosen by the secretary or known well in
 > advance, it would be possible for a malicious secretary to stuff
 > the ballot box.  If it is possible for the secretary to choose two
 > strings which hash to the same value, the secretary can replace one
 > of the votes with a vote of their choosing.  This is admittedly
 > rather hard, but the secretary has an unlimited amount of time to
 > work in to achieve this result.
If I could find a means of two strings (of the same size) that
 gasg to the same vlaue in md5sum, I'd be too busy raking in money to
 bother stuffing debian ballots.
If you voted, please take the rest of the year trying to come
 up with another string that would hash to _your_ md5sum. If you can
 come up with something even remotely reproducible, we'll have a majot
 math paper on out hands, and I;ll happily change things around.
Speaking hypothetically, I'd like to point out that the FAQ on the 
RSA.com web site about various hash algorithms, including MD5, cites a 
1994 paper estimating that a machine built for brute-forcing MD5 hash 
collisions could probably be made for US$10M out of 1994 technology and 
1994 dollars that would find a hash collision in 24 days on average.

Moore's Law would suggest that such a machine would cost on the order of 
US$150K.

Doing some quick orders-of-magnitude calculations, I can't see how they 
would do it in that time-frame as "brute force", though.



	manoj






--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for the Condorcet/Clone proof SSD voting methodsGR

[Buddha Buck]

Hamish Moffatt wrote:

For the benefit of the average non-voting-geek Debian developer,

could the proponents of this amendment please explain what problem
it attempts to solve, with real life examples?
The main problem is that the existing voting system as described in the
Debian Constitution is poorly defined, with some inherent
contradictions.  It wasn't looked at too closely when the Constitution
was first developed.  Among other problems:  It tries to implement a
Condorcet-based voting system, but calls it "Concorde" instead; it has
the property that if there is no clear winner (what Condorcet proponents
would call an "ideal democratic winner" or a "Condorcet winner", then
all the options are rejected before a winner is chosen from the
"remaining" options, etc.
There were also severe questions as to how the supermajority
requirements should be implemented.
These issues came to a head when a GR was proposed a modification to the
Social Contract that would eliminate the commitment by Debian to support
the "non-free" section.  It became clear that any ballot would contain
an amendment to the SC (viewed as requiring a supermajority to change),
a proposed policy statement (viewed as requiring only a simple
majority), and the "default" option.
A review of the constitution to figure out how to conduct such a vote
provided more confusion than answers.  So the secretary decided to
shelve the non-free GR until the voting issues were cleared up.  It's
been a while, however.
An explanation of why we need such a complicated system at all would be
interesting too.
Simple reason:  When you get more than two choices to vote for, all
election methods suck (lookup "Arrow's Theorem" for a proof of this),
but some suck more than others.   We want to find an election method
that has a minimal amount of suckiness for our goals.
More complicated reason:  While normal voting methods and procedures are
sufficient for deliberation in person, where everything can be settled
by multiple procedural votes, online deliberations have more complicated
requirements, requiring more complicated voting procedures.
We have the following complications:

1) We want to have as few votes as possible to settle an issue, since
each vote requires two weeks to run in order to get the most input.
This means that we can't follow a traditional procedural amendment
process -- each vote has to have all proposed (and seconded) amendments
on it, and the procedure has to select from among them.
2) We want to be conservative, and err towards continuing discussion, if
we can't achieve some sense of "consensus" on an issue.  As such, we
want to require continuing discussion to always be a ballot option
3) Very often more than a yes/no or either/or choice -- 3+-way decisions
are the norm and possibly required.  This is because of the multiple
variant issue mentioned in (1) above, and because of the "continue
discussion" option mentioned in (2).
4) Some options must be approved by a supermajority.  Other options
don't.  So some votes will be a mixture of supermajority requirements.
5) And we want some justifiable semblance of majoritarian rule.

The most common method, where everyone gets to vote for one (and only
one) option, and the option with the most votes wins suck big-time,
because in the presence of lots of options, the vote tends to get split
to the point where it's hard to justify saying any particular option has
a majority.
The methods chosen by Debian, both in the current constitution and in
the proposed constitutional amendment, are variants on a method
developed by a scientist named Condorcet over 200 years ago in France.
Condorcet was trying to answer the question "what does majoritarian rule
mean when there are three or more candidates in an election?".   In a
two-way election, it's easy to see what "majority rule" was -- whoever
got the most votes would win.  But in a three-way race, it's possible
for no candidate to get the majority of votes.  He proposed the
principle that if there was a single candidate who, when pitted against
all others in two-candidate, one-on-one races, would win all those other
races, then that single candidate should be the winner.  Both the
current and proposed election methods are at least supposed to have that
property.
But Condorcet's principle doesn't say anything about what to do when
there is no single candidate that would be undefeated against all other
candidates one-on-one.  Some evidence (via simulated elections) seems to
show that in 95% of elections there will be a "Condorcet winner", but in
5% there won't.  Hence any election method has to be enhanced to deal
with that issue.  The particular technique proposed here is called
"Cloneproof Schwartz Sequential Dropping" (cSSD), which refers to some
specific properties of the technique -- it is impervious to certain
types of election strategy.
Standard cSSD solves many problems; it allows for as many ballot options
as we choose, including a default "keep tal

Re: Call for votes for the Condorcet/Clone proot SSD voting methodsGR

[Buddha Buck]

Sam Hartman wrote:

"John" == John H Robinson, IV <[EMAIL PROTECTED]> writes:
   

   John> but is it a lack of interest in an issue at large, or a lack
   John> of interest in a particular response to an issue that you
   John> are worried about?
Before I thought about voting, I would have said lack of interest in
the issue at large.  Now, I see the arguments and believe that for
Debian it is lack of interest in a particular option.
What argument changed your mind?

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFD: amendment of Debian Social Contract

[Buddha Buck]

Branden Robinson wrote:
On Sat, Nov 08, 2003 at 08:28:54PM -0500, Raul Miller wrote:

On Sat, Nov 08, 2003 at 06:56:15PM -0500, Branden Robinson wrote:

Anthony's example splits a potential "change social contract" 
supermajority into two, and yours splits it into three.

This pretty much ensures the defeat of any option that requires a
 3:1 majority, and makes it extremely difficult even to satisfy a
 propostion that requires only a simple majority.
This doesn't make sense.


Of course it does.  Consider:

[   ] Choice 1: Remove Clause 5 of the Social Contract(, Keep Debian 
Swirl Red) [   ] Choice 2: Remove Clause 5 of the Social Contract, 
Make Debian Swirl Green [   ] Choice 3: Remove Clause 5 of the Social
 Contract, Make Debian Swirl Blue [   ] Choice 4: Further Discussion

250 ballots ranking 1234 250 ballots ranking 2314 250 ballots ranking
 3124 250 ballots ranking 2221
Choices 1, 2, and 3 require a 3:1 majority to pass, of course.

What happens?  Our voting system does not give us the ability to 
reach the common-sense conclusion that 3 out of every 4 voters wanted
 to remove clause 5 from the Social Contract.  Instead, "further 
discussion" wins.  Is that because the proposition to remove clause 5
 from the Social Contract failed to persuade 3 out of 4 developers 
that it was a good idea?  That doesn't follow from interpretation of 
the results.
It follows from a correct interpretation of how the consititution
results.  The voting system is designed to be cloneproof, so that the
vote-splitting strategy doesn't work.
"3:1 Majority", in this case, is defined in relation to the "default
option", which is Choice 4.  To test the supermajority requirement,
choices 1, 2 and 3 are not compared with each other.  Check section
A.6.3 of the Debian Constitution (available at
)
I assume, from your further comments, that you think this vote should
mean that a supermajority of the voters support removing Clause 5, and
the addition of choices 2 and 3 spoilt the result.  This example is
flawed, in that even without choices 2 and 3, further discussion would
have won, since the Constitution says that the votes in favor of option
1 over option 4 must be "strictly greater" than three times the votes in
favor of option 4 over option 1 (section A.6.3.2).  Since 750 people
preferred option 1 over option 4, and 250 preferred option 4 over option
1, the ratio of those two votes is exactly 3, not strictly greater than
3.  Option 1 would fail.
I think your thesis was not intending to be dependent on such
edge-cases, but rather merely on the thesis that irrelevant options
"split the vote", as it were, and dilute the supermajority.  So I'm
going to assume, for the sake of argument, six additional voters, three
of whom voted 2314, two voting 1234 and one more voting 3124:
252 ballots ranking 1234
253 ballots ranking 2314
251 ballots ranking 3124
250 ballots ranking 2221
And I'm going to walk this through the entire voting counting procedure,
step by step:
# A.6.1 Each voter's ballot ranks the options being voted on. Not all
#   options need be ranked.  Ranked options are considered preferred
#   to all unranked options. Voters may rank options equally.
#   Unranked options are considered to be ranked equally with one
#   another. Details of how ballots may be filled out will be
#   included in the Call For Votes.
We have the ballots above.

# A.6.2 If the ballot has a quorum requirement R any options other than
#   the default option which do not receive at least R votes ranking
#   that option above the default option are dropped from
#   consideration.
I think it is reasonable to assume that since all three options 1, 2 and
3 received over 500 votes more votes ranking those options above the
default option than ranking the default option over any of those
options, that any sensible quorum requirement has been met.
# A.6.3 Any (non-default) option which does not defeat 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 defeats the default option D by a majority ratio N,
#  if V(A,D) is strictly greater than 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.
We have three non-default options to consider here: "R", "G", and "B",
all of which have a supermajority of 3:1, and thus a majority ratio of 3.
We have:
   V(R,D) = 756 > 3* V(D,R) = 3 * 250 = 750 so R is not eliminated
   V(G,D) = 756 > 3* V(D,G) = 3 * 250 = 750 so G is not eliminated
   V(R,D) = 756 > 3* V(D,B) = 3 * 250 = 750 so B is not eliminated
# A.6.4 From the list of undropped options, we generate a list of
#   pairwise defeats.
#
#   1. An option A defeats an option B, if V(A,B) is strictly greater
#  than V(B,A).
We have the 

Re: RFD: amendment of Debian Social Contract

[Buddha Buck]

Manoj Srivastava wrote:
On Tue, 11 Nov 2003 19:47:23 -0500, Branden Robinson <[EMAIL PROTECTED]> said: 


On Sat, Nov 08, 2003 at 08:28:54PM -0500, Raul Miller wrote:

On Sat, Nov 08, 2003 at 06:56:15PM -0500, Branden Robinson wrote:

Anthony's example splits a potential "change social contract"
supermajority into two, and yours splits it into three.
This pretty much ensures the defeat of any option that requires a
3:1 majority, and makes it extremely difficult even to satisfy a
propostion that requires only a simple majority.
This doesn't make sense.


Of course it does.  Consider:


	I don't think you understand the voting system.



[   ] Choice 1: Remove Clause 5 of the Social Contract(, Keep Debian Swirl Red)
[   ] Choice 2: Remove Clause 5 of the Social Contract, Make Debian Swirl Green
[   ] Choice 3: Remove Clause 5 of the Social Contract, Make Debian Swirl Blue
[   ] Choice 4: Further Discussion
250 ballots ranking 1234
250 ballots ranking 2314
250 ballots ranking 3124
250 ballots ranking 2221


Choices 1, 2, and 3 require a 3:1 majority to pass, of course.


What happens?  Our voting system does not give us the ability to
reach the common-sense conclusion that 3 out of every 4 voters
wanted to remove clause 5 from the Social Contract.  Instead,


	Which, in a 3:1 majority, is barely enough.
The language in the Constitution is "strictly greater", so it is barely 
not enough.



"further discussion" wins.


Wrong.  I think that this is where the disconnect is; this
 example represents a profound misunderstanding of our voting system.
Well, "further discussion" does win, since 750:250 is not "strictly 
greater" than 3:1.

But, modulo that edge case,  I agree this example represents a profound 
misunderstanding of our voting system.

Option 1 passes Majority.   3.000 (750/250) > 3
Option 2 passes Majority.   3.000 (750/250) > 3
Option 3 passes Majority.   3.000 (750/250) > 3
For the sake of argument, let's say 3.000 > 3 instead of 3.000 == 3.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The "Free" vs. "Non-Free" issue

[Buddha Buck]

Michael Banck wrote:
On Wed, Jan 07, 2004 at 09:21:50AM +0100, Sven Luther wrote:

(It is not part of debian, we were told in the past. Opponents of the 
suggested GR seem to forget that and talk of things like removing from 
debian, or phasing out from debian.) What's your suggested plan for 
I don't really care if it is part of debian or not, what we are speaking
about here is the debian infrastructure. If we were to move non-free to
a virtual non-free host or something, pointing to the real debian
infrastructure, this would be fine with me, but seriously, i don't see
what would be gained by it.


I see only one vital point for having those packages on the "real Debian
infrastructure", instead of a mere copy of it: You could continue to
reassign bugs from non-free to main.
Anything else I missed?
Yes.  The web of trust issue.

I've used Debian for 9 years now.  I've watched it grow, mature, etc.  I 
trust Debian.  As an example of my level of trusting Debian, I allow 
arbitrary Debian Developers run scripts and other programs on my machine 
with root priviledges.  Because that's what installing a .deb requires.

I also know that the thousand or so Debian developers sign their uploads 
to the Debian servers, so every package in the Debian archives has been 
uploaded by someone willing to sign their name to it.  This helps 
enforce and confirm my trust in Debian.

I don't have many packages from non-free on my machine -- most of them 
are documentation, fonts, and Java -- and could probably eliminate half 
without any noticable loss.  But I use a decent amount from contrib -- 
Eclipse, ant, other Java-based tools, etc -- and I would be loathe to 
get rid of them.

If non-free went away, I'd lose the web of trust.  I'd be forced to get 
the tools I need from non-trusted sources.  That is a major problem I 
see with getting rid of non-free.

It is not Debian's historical policy to make things harder solely to 
pursue a political goal.  Even the KDE issue wasn't about politics, but 
legalities.  Let's not make things harder to pursue political goals now.

As far as the Java stuff goes, Sun won't free their JDK, but there are 
other free JDKs out there.  The packages I'm interested don't work with 
them; which is why they are in contrib and I use the non-free Sun SDK. 
In my opinion, encouraging the free Java SDKs to become better so that 
Eclipse, et alia, can move to main is a more important goal than 
dropping support for Eclipse, etc.




Michael




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Results for future handling of the non free section GR

[Buddha Buck]

Debian Project Secretary wrote:
Hi,

At this point, with 563 ballots resulting in 491 votes from
 482  developers, "Choice 2: Re-affirm support for non-free" has
 carried the day. "Choice 1: Cease active support of non-free [3:1
 majority needed]" failed to even win simple majority (more people
 preferred further discussion than option 1).
The list of voters  is available at:
 http://master.debian.org/~srivasta/gr_non_free_voters.txt
And the tally sheet is available for review at:
 http://master.debian.org/~srivasta/gr_non_free_tally.txt
	manoj
I'd just like to comment that I find the output of the below list hard 
to read, and I'm one of the folks who helped recommend our current 
voting procedure.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Starting results calculation at Mon Mar 22 00:03:07 2004
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
  Option
  1 2 3
===   ===   ===
Option 1  169   199
Option 2303 304
Option 3260   156
I think a format for the defeats table like:

Option 2 defeats Option 1 by 303 votes to 169 votes
Option 2 defeats Option 3 by 304 votes to 156 votes
Option 3 defeats Option 1 by 260 votes to 199 votes
would have been easier to read.

While a similar table does appear later on, it doesn't give the vote 
counts, only the margins of victory.  I have issues with that table, as 
well




Looking at row 2, column 1, Choice 2: Re-affirm support for non-free
received 303 votes over Choice 1: Cease active support of non-free [3:1 majority 
needed]
Looking at row 1, column 2, Choice 1: Cease active support of non-free [3:1 majority 
needed]
received 169 votes over Choice 2: Re-affirm support for non-free.
Even with this explanation, I had trouble reading the table above.
Option 1 Reached quorum: 199 > 45.1995575199581
Option 2 Reached quorum: 304 > 45.1995575199581
Dropping Option 1 because of Majority.  0.765 (199/260) <= 3
Option 2 passes Majority.   1.949 (304/156) > 1
  Option 2 defeats Option 1 by 134
  Option 3 defeats Option 1 by 61
  Option 2 defeats Option 3 by 148
If Option 1 was dropped because of Majority, why is it listedin this table?

For that matter, since Option 2 is clearly the Condorcet winner

The Schwartz Set contains:
 Option 2 "Choice 2: Re-affirm support for non-free"
...why are we looking at the Schwartz set?



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
 Option 2 "Choice 2: Re-affirm support for non-free"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Social Contract GR's Affect on sarge

[Buddha Buck]

Hamish Moffatt wrote:

Good for you. But admit that some people disagree, at least.

Perhaps next time the subject of the CFV could make no comment on the
proposal at all. Call it "SC changes", rather than "SC editorial
changes". The secretary's opinion is irrelevant to the project so please
leave it out of the CFV.
I don't like Manoj's tone in this thread.  It's harsh, accusatory, and 
somewhat rude.  It seems like he is reacting defensively, as if he feels 
people are blaming him for the results they don't like.  I don't think 
he was responsible for the results, just for running the vote.

Comments like this don't help.  This directly accuses him of mislabeling 
the proposal to support his own position.  In otherwords, accuses Manoj 
of malfeance of office as Debian Secretary.

In my opinion, that's libelous (or slandarous, I'm not sure which 
applies to emails like this).  It defames Manoj, and it's blatantly 
false, as the record will show.  This proposal has a long and 
complicated history, dating back over several years of discussion.  Only 
recently was it put into the current form, and was debated since 
December as "editorial" changes.  Manoj didn't put that label on it, and 
it was called "editorial" in the subject line of Andrew Suffield's 
original official proposing of it.



Hamish


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

First Draft proposal for modification of Debian Free Software Guidelines:

[Buddha Buck]

A few things first:

1.  I am not a Debian Developer, so I can not formally propose a GR or a 
foundational document amendment.  I have, however, had a long-time 
involvement in the project, and have assisted in project-related 
activities, such as developing the current standard resolution process. 
 So while I'm not able to formally do anything, I'm not coming 
completely out of left field.

2.  This is a very first draft.  There will likely be suggested changes; 
there will likely be complete overhauls.  I'm not committed to the form, 
 just the principles.  Given good arguments, it's probable that my 
stand on the principles can be modified.  I'd rather see a version we 
all can like go forward than stubbornly stand behind a flawed proposal.

3.  I've been reading too much GrokLaw lately.  It seems like it's had 
an effect on my writing style.  If you don't like numbered paragraphs, I 
apologise


(Draft) Proposal for Modification of the DSFG to allow certain forms of 
documentation, fonts, and other matters that don't conform to the 
existing DSFG into Debian.

I propose that the DSFG be amended by the addition of the following 
numbered sections.  Comments in brackets [like this] are not part of the 
amendment, but rather clarify references in the proposal:

 Additions to the DSFG 
11. Documentation and other written materials.
  Documentation and other written materials that are not programs are
  not required to meet guideline 3 [Derived works] fully.
  a.  Certain other types of written materials may restrict derivative
  works, but must allow repackaging or reformatting in ways that do
  not change their written content:
 (i)   Standards documents, such as IETF RFC documents, published
   star catalogs, and certification test suites.
 (ii)  Legal documents, such as licenses, contracts, judicial
   opinions
 (iii) Opinion documents, such as the GNU Manifesto or position
   papers that have no technical content
  If a document contains multiple sections that only some of fall under
  the exception above, only those sections may be exempt from allowing
  Derived works.
  In particular, documents (or sections of documents) which describe
  the operation or function of other software must allow creation and
  distribution of derivative works as per guideline 3 to the extent
  that the describes software does.
12.  Images, fonts, and sounds.

  Images, fonts, and sounds do not have to comply with guideline 2
  [source code] fully.  (This is a compromise.  The Debian Group
  encourages all authors to provide source code for all software,
  including images, fonts, and sounds).
Special Exception for Non-Free Firmware provided with the Linux Kernel.

  As a specific exception to the above guidelines, The Debian Project
  recognises that some Linux Kernel hardware drivers contain firmware
  and other software that is not Free Software by these guidelines.
  Many of these drivers are included with the standard Linux Source
  distribution.  Strict adherence to these guidelines would prevent us
  from including the unmodified upstream source code for the Linux
  Kernel, and would require us to remove support critical to many of our
  users.
  Therefore, we allow into the Debian Project any non-free software
  included in the standard Linux Kernel distribution solely for use
  within Debian as part of the Linux Kernel.
--- End Additions to the DFSG ---

Because this resolution changes a foundation document, it requires 3:1 
majority approval

--- End Draft Proposed GR -
--- Memorandum in Support of Proposed GR Amending the DSFG ---
Memorandum In Support of the Proposed GR Amending the DSFG to allow 
certain non-modifiable documents into the Debian Distribution.

I. Overall purpose and justification for amending the DSFG

1.  The Debian Project's Social Contract commits Debian to distributing 
Free Software, but rightly defers the definition of what is "Free 
Software" to the Debian Free Software Guidelines.  As such, when 
controversy arises over Debian's ability to keep that commitment, 
attention should not be directed at the Social Contract, but rather to 
the Debian Free Software Guidelines.

2.  In the past, the issue of documentation, fonts, images, sound files, 
and other non-program type files was "dealt with" by treating them as if 
they weren't "software".  Recent changes in the Debian Social Contract 
clarified the issue by making it clear that everything in the main 
Debian Distribution was "software", forcing all documentation, fonts, 
images, sound files, and other non-program type files that did not 
conform with the DSFG to be removed before release (at least, in the 
opinion of the release manager.

3.  Since the issue of the "freeness" of documentation, fonts, images, 
sound files, and other non-program type files is now clearly a 
"software" issue, it makes sense to cle

Re: Ready to vote on 2004-003?

[Buddha Buck]

Raul Miller wrote:
Scripsit Raul Miller <[EMAIL PROTECTED]>
Or do you just want him to restate his opinion that the new social
contract forbids some interpretations which were ok under the old version?

On Wed, May 19, 2004 at 07:11:47PM +0100, Henning Makholm wrote:
If would be nice if he would reveal whether one of the proposed
resolutions would *not* result in a situation where he would be
comfortable with releasing sarge with non-free firmware blobs in
main.

The major difference between most of them as to do with expiration of
that this "not result in a situation" condition. 
I think I understand what you are trying to say here, but I cannot parse 
this sentence at all.  I get a little further in parsing it if I assume 
that "as" should be "has", but I get stuck again later in the sentence.

But is that what people
are asking about?

As far as a straightforward reading goes, each of the current
proposals (except "further discussion") appears to address the trouble
that the RM has described, therefore allowing a quick release of
sare. However, that is *my* kind of straightforward, which others may
or may not share. And the RM's reluctance to confirm that he shares
such an interpretation seems to strongly suggest that he doesn't. Is
it too much to ask that he explains how his understanding differs from
(say) mine, rather than expecting people to telepathically discover
which option it is that would not change his view of the situation?

Is "a quick release of sarge" the only issue?  Do we care about
maintenance of sarge?  Do we care about release management in the context
of future GRs which modify foundation documents?  Is "quick release"
more or less important than "simple philosophically"?  When does this
change, and why?
It almost sounds like you're expecting AJ to intuit the frame of reference
you're asking the questions from.  Moreso, since expressing those frames
of reference would answer many of the "reasonable sorts of questions"
which are being asked.
I think he's saying "I'll do what you guys tell me" and he's being asked
"what will you do?".  There's a fundamental disconnect here, but since
he's given a lot of specifics and the people asking have not, I don't
think the disconnect is on his side of the fence.
You are probably right that there is such a disconnect.  The problem 
with "I'll do what you tell me to do" is that the existing situation 
arose in part because there was a significant disagreement among the 
voting developers as to what they thought they were telling Anthony to 
do.  It appears that many, including Anthony, read the changes in the 
Social Contract as telling Anthony that Sarge had to be purged of 
non-Free documentation, images and sound without source code, etc, that 
prior to the Social Contract change Anthony had tentatively accepted as 
allowable.  Many other people, on the otherhand, did not see, or did not 
think, that the proposed changes in the Social Contract significantly 
altered it's instructions ot the Release Manager as to what was 
acceptable or not in a release.

If the developers instructions were unclear, and interpreted in a 
reasonable but perhaps disagreeable manner, I don't think it's 
unreasonable to for the developers to ask how their (proposed) 
instructions will be interpreted so that there isn't further 
miscommunication.

It is entirely the case that Anthony's interpretations could lead to 
another series of changes to the proposals to better reflect the will of 
the developers.  I think it better that that happen now, when the 
proposals are easy to change, than later, when it takes a 3:1 majority 
to change the Foundation Documents again.

> In other words, I think the questions being posed are, at best, too
> vague.
OK, how about:
Anthony, assuming Raul is correct in that you are saying "I'll do what 
you guys tell me", and you are being asked "What will you do?", what do 
you think the various resolutions instruct the Release Manager to do?

Specifically:
1) Which options do you interpret as allowing the RM to release Sarge 
with substantially the same content and schedule as it would have had if 
the Social Contract hadn't been modified earlier this year?

2) Which of the options given in your answer to (1) do you interpret as 
allowing the RM to authorize maintenance (point) releases of Sarge until 
a new stable release is made?

3) Which options do you interpret as preventing the RM from authorizing 
maintenace (point) releases of Woody until Sarge is released?

(Not on the list of questions related to this set of resolutions, but 
for my own interest:  Are point releases of pre-Woody releases being 
made?  Or has their support lifetime ended?  What is the general policy 
of the support lifetime of old releases?)

4) Which options do you interpret as allowing the RM to release 
post-Sarge stable releases with the same sort of contentious material 
(GFDL'd manuals, source-code-less images and sound, etc) in the same way 
that such cont

Re: DRAFT amendment to "Release sarge with amd64": "Freeze architecture support for sarge"

[Buddha Buck]

On Thu, 15 Jul 2004 09:11:29 +0200, Sven Luther <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 14, 2004 at 09:06:18PM -0500, Manoj Srivastava wrote:
> > On Thu, 15 Jul 2004 00:52:20 +0200, Robert Millan <[EMAIL PROTECTED]> said:
> > > Regardless of what person is in charge, I think this person should
> > > _only_ be in charge for evaluating what the consensus of the
> > > developers is.
> >
> >   You want a release manager who is a mere rubber stamp for a
> >  large group of people who can't ever agree on anything unless beating
> >  each other on the head with a GR? And you think this shall somehow
> >  result in the best OS in the world? What planet do you come from?
> 
> Manoj, please explain to me how you can achieve the best OS in the
> world, if part of the project refuse to communicate with other peoples,
> and sometimes on things vital to the further progress of the project.

I think it is entirely possible to have someone as a release manager,
ftp-master, or any other position of responsibility who is good at
communicating and who nevertheless exhibits their own judgement and
makes decisions independent of the consensus of the developers.  Not
being a rubber-stamp, not limiting the decision-making process to
consensus evaluation, does not equate to refusal to communicate.

My reaction to Robert's suggestion was similar to Manoj's -- that
having an RM who is not allowed to make decisions, just evaluate
consensus is a bad idea.  Someone has to make the decision to ship or
not to ship.

To be effective, responsibility needs to be balanced with authority. 
Giving the RM the responsibility of managing releases, but removing
the authority to make release decisions doesn't work.



> 
> Friendly,
> 
> Sven Luther
> 
> 
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Parliamentary Questions...

[Buddha Buck]

Mr. Secretary,

I have a series of questions concerning recent proposals for the Debian 
Project.  I am a long-time user of Debian, but not a developer.  While 
I understand and accept that I have no official standing in Debian's 
decision making system and have no vote, I feel that my long-term use 
and commitment to Debian gives me a legitimate interest in the status 
and outcome of these proposals.

1.  John Goetzen recently made a proposed General Resolution, to which 
Anthony Townes suggested an amendment.  Both the original proposal and 
the amendment have had various developers post seconds to them.  The 
web site http://www.debian.org/vote does not list the proposal or 
amendment yet.  What is the current parliamentary status of the 
proposal by John Goetzen and the amendment by Anthony Townes?

2.  The proposal by John Goetzen calls for a modification of the Debian 
Social Contract.  Some have suggested that such a modification is 
allowed by Clause 4.1.5 of the Debian Constitution ("Issue nontechnical 
policy documents and statements"), while others claim that that 
particular clause does not apply to amending the Social Contract -- and 
that there is no Constitutionally valid method of amending the Social 
Contract.  It has also been suggested that amending the DSC is 
equivilant to amending the Debian Constitution, and thus falls under 
4.1.2, and requires a 3:1 supermajority.  As far as I have seen, most 
are agreed that the Project Secretary's opinion should decide.

What Constitutional authority, if any, is there for amending the Social 
Contract?  What level of majority or supermajority is needed to enact an
amendment to the Debian Social Contract?

3.  If the original proposal requires a supermajority and the amendment 
(which does not amend the DSC) requires only a majority, how will the 
vote counting and determination of the results of the ballots be done?

I hope to receive a reply to these questions soon.  

Thank you,
  Buddha Buck
  
-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Parliamentary Questions...

[Buddha Buck]

> 
> On Wed, Jun 14, 2000 at 12:24:17AM -0400, Buddha Buck wrote:
> > 1.  John Goetzen recently made a proposed General Resolution, to which 
> > Anthony Townes suggested an amendment.  Both the original proposal and 
> > the amendment have had various developers post seconds to them.  The 
> > web site http://www.debian.org/vote does not list the proposal or 
> > amendment yet.  What is the current parliamentary status of the 
> > proposal by John Goetzen and the amendment by Anthony Townes?
> See above.

Fair enough...  Congratulations on your new child.  And what lousy 
timing for a massive flamewar/Debian vote, eh?

 > > 2.  The proposal by John Goetzen calls for a modification of the 
Debian
> > Social Contract.  Some have suggested that such a modification is 
> > allowed by Clause 4.1.5 of the Debian Constitution ("Issue nontechnical 
> > policy documents and statements"), while others claim that that 
> > particular clause does not apply to amending the Social Contract -- and 
> > that there is no Constitutionally valid method of amending the Social 
> > Contract.  It has also been suggested that amending the DSC is 
> > equivilant to amending the Debian Constitution, and thus falls under 
> > 4.1.2, and requires a 3:1 supermajority.  As far as I have seen, most 
> > are agreed that the Project Secretary's opinion should decide.
> >
> > What Constitutional authority, if any, is there for amending the Social 
> > Contract?  What level of majority or supermajority is needed to enact an
> > amendment to the Debian Social Contract?
> > 
> Oh boy, this will be fun.  I will have to look at the issues closely and
> will not venture an official answer at this time.

Thanks.  On the whole, I think I would prefer a careful, considered 
interpretation rather than a snap judgement anyway.

> >
> > 3.  If the original proposal requires a supermajority and the amendment 
> > (which does not amend the DSC) requires only a majority, how will the 
> > vote counting and determination of the results of the ballots be done?
> Per section A of the constitution :)  The answer to this will, obviously,
> have to wait for a determination of point 2.
> > 
> > I hope to receive a reply to these questions soon.  
> Please wait a bit longer, I will be back into circulation Monday.

Waiting is...

> > 
> > Thank you,
> >   Buddha Buck
-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: An ammendment (Re: Formal CFV: General Resolution to Abolish Non-Free)

[Buddha Buck]

> On Thu, Jun 15, 2000 at 01:34:20PM -0400, Branden Robinson wrote:
> > On Tue, Jun 13, 2000 at 06:31:50PM +1000, Hamish Moffatt wrote:
> > > Obviously you have no problem with throwing out the social contract on a
> > > whim.
> > 
> > Please explain to where the proposed GR mandates this.
> > 
> > I see an amendement of its language, but no blanket repeal of the document.
> 
> The GR proposes a fundamental shift in the social contract:
> it wants to emphasise free software at the expense of utility
> for some of our users. It's not a minor change.

The GR also seeks, intentionally or not, to establish a precedent that 
the Social Contract can be changed by a simple majority(*).  This, too, 
is also a fundamental shift in the Social Contract.

The supporters of this amendment claim it is calling for the 
strengthening of our committment to Free Software.  I would hate to see 
this precedent turned against them later and have a weakening of our 
committment to Free Software pass through a simple GR.

(*) It's possible that this amendment could pass without a majority 
voting for it.  Unlikely, but possible.  I hardly think that this 
amendment would be a suitable "compromise" between "Do Nothing", "Keep 
Talking" and Anthony Towns' alternative.

> 
> 
> Hamish
> -- 
> Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: CFV: Non-free archive removal

[Buddha Buck]

> John Goerzen writes:
>  > -BEGIN PGP SIGNED MESSAGE-
>  > Hash: SHA1
>  > 
>  > The requisite discussion period having been entertained, I therefore
>  > formally call for a vote on this topic, on the Resolution which I
>  > originally posted on June 7, 2000, a copy of which is included below.
> 
> Shouldn't we be voting on the ammendment at the same time?

The Debian Project Secretary should be drawing up the official ballots, 
which should include the amendment at the same time.

> 
> Matthew
> 
> -- 
> "At least you know where you are with Microsoft."
> "True. I just wish I'd brought a paddle."
> http://www.debian.org
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Manoj's and Branden's proposed amendments

[Buddha Buck]

The most recent Debian Weekly News mentioned a proposed amendment by 
Manoj Srivastava.  This was news to me, even though I am subscribed and 
read debian-vote, where proposals are supposed to be posted and 
discussed.

The Project Secretary has let it known (at http://www.debian.org/vote/ho
wto_proposal) that proposals (and seconds) which aren't either mailed 
to him directly or posted on debian-vote will not be recognised.  Since 
neither Manoj's original proposal, nor the amendment to that proposal 
by Branden Robinson were ever posted to debian-vote, I am assuming that 
they have not been officially recognised.

Could both Manoj and Branden formally send their amendments to 
debian-vote for official recognition.


-- 
     Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: CFV: Non-free archive removal

[Buddha Buck]

At 01:49 PM 8/23/00 -0400, Peter S Galbraith wrote:


I just assumed the proposal originator decided it wasn't going to
pass anyway and let's just spare the project the agony of going
through it.  Just speculation on my part.  Seemed like a good
decision if that was the case.


My interpretation was that the original proposal raised some constitutional 
questions which the Project Secretary hasn't answered yet.  vote.debian.org 
still lists the needed quorum as "Due to the uniqueness of the situation, 
quorum is yet to be determined".


I had thought that John had wanted this voted on (hence the CFV), but 
ballots haven't been made yet, nor a vote done.






--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-free Proposal

[Buddha Buck]

At 09:42 AM 9/25/00 -0500, Chris Lawrence wrote:

On Sep 24, John Goerzen wrote:
> "Darren O. Benham" <[EMAIL PROTECTED]> writes:
> > We will have to conduct two separate ballots.  The first question is the
> > acceptance or rejection of the amendment.  The outcome of that vote will
> > determine if the proposal is voted under the General Resolution quorum or
> > the Important Documents (constitution) quorum.
>
> This seems inconsistent.  The quorum is specified by the
> Constitution.  Why, therefore, should the acceptance or rejection of a
> mere GR amendment, which has yet had no actual force let alone one of
> modifying the Constitution, have the effect of modifying voting
> procedures?  The Constitution lays out specific rules for voting.  It
> does not specify in any way that the result of a vote on a GR
> amendment can act as an exception to voting procedure.
>
> Additionally, why should the question of the quorum
> required for a vote be considered the presumed result from voting on a
> different amdendment?  It is possible that people might be in favor of
> requiring the Important Documents quorum but against aj's amendment.

My understanding of Darren's argument is that the original proposal
(removal of non-free) would modify the Social Contract, which is
considered to be "constitutional" in nature (and thus requires the 3-1
majority to be modified).  However, if aj's amendment were approved,
the proposal would no longer amend the Social Contract and would be
considered a normal general resolution subject to the GR rules.


This is exactly as I view it.  I considered Darren's reply to settle the 
three questions I formally asked him in 
http://lists.debian.org/devian-vote-0006/msg00080.html.


In summary, those questions were:

1.  What is the current parliamentary status of the proposal by John 
Goetzen and the amendment by Anthony Townes?


2. What Constitutional authority, if any, is there for amending the Social 
Contract? What level of majority or supermajority is needed to enact an 
amendment to the Debian Social Contract?


3. If the original proposal requires a supermajority and the amendment 
(which does not amend the DSC) requires only a majority, how will the vote 
counting and determination of the results of the ballots be done?


His most recent reply answered 2 and 3, as well as settled 1.

While it did not address the Constitutional authority question (and in fact 
stated that the Constitution was mute on the issue), he stated that the SC 
should enjoy at least as much protection as the Constitution itself, and 
thus requires a supermajority to modify.


As such, the third question (what proceedure) was also stated:  Vote to 
amend the proposal first, then vote on the (possibly amended) 
proposal.  That way, the necessary for the main proposal is clear at the 
time of the vote on the proposal.





Chris
--
Chris Lawrence

Titles/affiliations at http://www.lordsutch.com/chris/info.html
Office: 662-915-5949  Email: [EMAIL PROTECTED] / [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-free Proposal

[Buddha Buck]

At 10:45 AM 9/25/00 -0400, Robert D. Hilliard wrote:

OOPS - I intended to send this to the list, but it went to gecko only,

"Darren O. Benham" <[EMAIL PROTECTED]> writes:

> I wish to give everybody the chance to read the initial exchange and
> familiarize themselves with the issue again.

 The URLs cited all return "Not Found".  To "give everybody the
chance to read the initial exchange and familiarize themselves with
the issue again" the original proposals should be reposted.


The following URLs seem to work:

Since the proposed amendment introduced in the email archived at:

http://lists.debian.org/debian-vote-0006/msg00018.html

And seconded by these messages:

http://lists.debian.org/debian-vote-0006/msg00031.html
http://lists.debian.org/debian-vote-0006/msg00035.html
http://lists.debian.org/debian-vote-0006/msg00039.html
http://lists.debian.org/debian-vote-0006/msg00037.html
http://lists.debian.org/debian-vote-0006/msg00038.html

changes the text of the original proposal found at
http://lists.debian.org/debian-vote-0006/msg0.html

and seconded by:
http://lists.debian.org/debian-vote-0006/msg5.html
http://lists.debian.org/debian-vote-0006/msg00013.html
http://lists.debian.org/debian-vote-0006/msg00056.html
http://lists.debian.org/debian-vote-0006/msg00019.html
http://lists.debian.org/debian-vote-0006/msg00011.html


The original proposal and amendments are also available at 
http://www.debian.org/vote/2000/vote_0008


Hope that helps.



Bob
--
   _
  |_)  _  |_   Robert D. Hilliard  <[EMAIL PROTECTED]>
  |_) (_) |_)  1294 S.W. Seagull Way   <[EMAIL PROTECTED]>
   Palm City, FL  USA   PGP Key ID: A8E40EB9

--KAA16848.969893130/ns1.greenbush.com--


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-Constitutional Voting Procedure

[Buddha Buck]

At 02:28 PM 9/27/00 +0200, Santiago Vila wrote:

> The problem is:
>
>   (a) A group of developers don't think the social contract can
>   legally (according to the constitution) be modified
>   (b) A group of developers think modification of the social contract
>   should require a supermajority
>   (c) A group of developers think modification of the social contract
>   by simple majority is perfectly reasonable and legal under the
>   constitution

So, the real problem is:

* Our constitution is incomplete because there is not a constitutional
way to determine whether something is constitutional or not. We would need
to amend it and create a "constitutional court of justice".


What about Article 7, Section 1, Clause 3?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-Constitutional Voting Procedure

[Buddha Buck]

At 11:34 AM 10/2/00 +0200, Sven LUTHER wrote:

Well, because you have no use for most of the stuff in non-free, it don't mean
that other people have not need of it.

Even if the people needing it are just a few one.

That said, maybe we could make a survey or something such, to see what
packages are in non-free, who uses them, and if it would be possible to use a
free replacement.


I would say, without such a survey taking place, that for each package in 
non-free, there is at least one person who:


* has stated agreement with the DSC and DFSG
* uses the package, or at least believes others do
* feels strongly about the package enough to package and maintain it

Shouldn't those be good reasons to keep the package?

Just because there is a "free replacement" doesn't mean that we should drop 
the non-free version.  Yes, there are free replacements for Navigator, 
including Mozilla among others.  But as a user, I'm familiar with 
Navigator, comfortable with it.  None of the others have quite the same 
feel and ease of use for me.  So I use Navigator[1] -- and I'm not 
alone.  True, I'd not lose Navigator if non-free disappeared, but I'd lose 
the BTS, I'd lose the painless install/updates, I'd potentially lose the 
integration, etc.


If I am forced to switch to a free replacement because of a policy 
decision, especially if it is against the wishes of the developer who is 
packaging Navigator, then that's political blackmail.


It would be different if the developer involved decided that maintaining it 
was no longer worth his time -- that happens with lots of packages, and if 
people really want it, another developer could pick up the ball.  It isn't 
Debian trying to make a political statement by hurting its users.


I'm interested in knowing how non-free and contrib compares (sizewise, or 
number of packages) with main, and over time (is non-free/contrib 10% of 
Debian?  5%?  How fast is this growing/shrinking?  Is non-free/contrib 
growing or shrinking in absolute size?)


Later,
  Buddha

[1] The real reason I use Navigator is for secure sites, sites with 
Java/Javascript, etc.  If Mozilla allowed me to do my online banking, play 
the daily crossword puzzle at www.dictionary.com, and a few other similar 
things, I'd go for it.

Re: Non-Constitutional Voting Procedure

[Buddha Buck]

> On Mon, Oct 02, 2000 at 10:02:46AM -0400, Buddha Buck wrote:
> > I would say, without such a survey taking place, that for each package
> > in non-free, there is at least one person who:
> > * has stated agreement with the DSC and DFSG
> > * uses the package, or at least believes others do
> > * feels strongly about the package enough to package and maintain it
> 
> Actually, that's not true: the following non-free i386 packages have 
> debian-qa listed as the maintainer:

OK, I was thinking of packages which were actively maintained, not 
orphaned.

> Maybe we should move all these to project/orphaned? There doesn't seem
> much point keeping non-free stuff around if no one's interested enough
> to maintain it.

Maybe they should be dropped altogether?  After all, not only does no 
one seem interested in maintaining them, but their licensing status is 
contrary to Debian's goals.

I would say that an official policy of purging non-maintained non-free 
packages more aggressively than non-maintained free packages would be 
right in line with the DSC, myself.

> 
> Cheers,
> aj
-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: PROPOSED: [CONSTITUTIONAL AMENDMENT] Alternate disambiguation of 4.1.5

[Buddha Buck]

> -BEGIN PGP SIGNED MESSAGE-
> 
> Hi,
> 
>   Indeed, I had proposed this in -project on the 19th of
>  July. This addresses the same ambiguity that Brandon does in his
>  proposal, but in a distincly different fashion. I would suggest that
>  this should be offered as an alternative to Brandon's proposal, if it
>  comes to a vote (if the rules lawyers deem that permissible). If not,
>  this may stand on its own (leaving open the possibility that both,
>  almost opposite, amendments may be accepted). 

Sigh...  I really need to get off my duff and start working on a 
package one of these days.  If I -were- a Developer, I'd second this 
one.

As it is, the inner Parliamentarian in me (doesn't everyone have an 
inner Parliamentarian) cringes at the idea of having two similar but 
incompatable proposals made nearly simultaneously that both require 3:1 
supermajorities to pass.

If they are placed on the same ballot, there's a very good chance that 
one or the other will get a majority of the votes, either directly or 
through the Condorcet procedure, but fail to get a 3:1 supermajority.

If they are placed on separate ballots, which one gets voted on first?  
Do we vote on the second if the first is accepted?  What if they -both- 
win?

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: [Notice] Social Contract Change Vote

[Buddha Buck]

At 09:40 AM 10/10/00 -0700, Darren O. Benham wrote:

What would you like to see?


If I were a developer (is that a version of "I am not a developer, but..." 
which was derided a while ago?)...


I'd love to see something like:

---
The main proposal under discussion is by John Goerzen, and can be found here:
[LINK].  In summary, this proposal would AMEND the Debian Social Contract 
to eliminate the commitment to support for non-free on Debian's FTP servers.


An amendment to that proposal was made by Anthony Towns, and can be found 
here: [LINK] In summary, this proposal would replace John Goerzen's 
proposal with a GENERAL RESOLUTION reaffirming Debian's commitment to Free 
Software over non-free.


This vote is on accepting Anthony Towns' amendment to John Goerzen's 
Amendment.  There will be a later vote on the main proposal, who's form 
will depend on the outcome of this ballot.


If this amendment is ACCEPTED, then the vote on the main proposal will be 
treated as a General Resolution, using the text provided by Anthony 
Towns.  The main proposal would require a majority vote to accept.


If this amendment is REJECTED, then the vote on the main proposal will be 
treated as an Amendment to the Social Contract, using the text provided by 
John Goerzen.  The main proposal would require a 3:1 supermajority to accept.


If FURTHER DISCUSSION is called for, then this amendment will neither be 
ACCEPTED nor REJECTED, and a second vote on the amendment will take place 
after further discussion.


Ballot:

[ ] ACCEPT Anthony Towns' amendment to John Goerzen's proposal
[ ] REJECT Anthony Towns' amendment to John Goerzen's proposal
[ ] FURTHER DISCUSSION

---

I think that that information is clear as to what is going on.  Much better 
than "Yes"/"No"




On Tue, Oct 10, 2000 at 10:57:05AM -0400, Dale Scheetz wrote:
> The '[BALLOT] Social Contract Change' message was completely confusing. I
> have listened to the discussion on the list, and no one there seems to
> know how to mark the ballot either, although there is plenty of opinion
> about what the ballot "means".
>
> It is unclear what is actually being voted upon. I see that CHOICE 1 is
> "associated" with item 1 on the ballot which says simply "Yes". Does a
> mark here mean that I agree with CHOICE 1? Also CHOICE 2 is said to be
> associated with item 2 on the ballot, which simply says "No". Does a mark
> here mean that I do _not_ want CHOICE 2?
>
> It is my understanding, from my own reading of the Debian Constitution
> that the secretary decides how the vote will be structured and will
> produce a ballot. Since it isn't clear what I am being asked to vote for
> or against, this latest attempt by the Secretary seems to fall short of a
> ballot.
>
> Since I can't figure out what the vote is about, I can't produce a
> completed ballot, so I have no choice but to refuse to vote. I hope there
> are at least 20 other developers as confused as I am, so we have the
> required number of "Developers" to block any action resulting from this
> ... vague ballot.
>
> While there _is_ an indication that there is a second ballot, there is no
> indication of what is being decided by the content of the first, so I
> don't see how a second ballot can clear up my confusion.
>
> Waiting is,
>
> Dwarf
> --
> _-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-
>
> aka   Dale Scheetz   Phone:   1 (850) 656-9769
>   Flexible Software  11000 McCrackin Road
>   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308
>
> _-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-
>
>
>
>

--
Please cc all mailing list replies to me, also.
* http://benham.net/index.html<[EMAIL PROTECTED]>   <><  *
* Debian: Software in the Public Interest:  *
*   Project Secretary   Treasurer   *
*   Webmaster Team  *
*   BTS Team  siteROCK: *
*   Lintian TeamLinux Infrastructure Engineer   *

Re: Summary of voting irregularities

[Buddha Buck]

At 03:15 PM 10/10/00 -0500, you wrote:

WRT the resolution proposing the removal of non-free, the following
irregularities have occured with the process.

1. The Secretary has made a decision by fiat stating that a 3:1
supermajority is required for its passage, despite contradictory
language in the Constitution.


In my opinion, based on my following of the discussions that lead up to the 
Secretary's decision, there was considerable disagreement concerning the 
meaning and intent of the "contradictory language".


Personally, I agree that the constitution does not explicitly provide for a 
3:1 supermajority to modify the Social Contract.  But it doesn't explicitly 
provide for -any- method to modify the Social Contract.  It explicitly 
provides for a 3:1 majority to modify the Constitution, and it explicitly 
provides for the "issuing" of new non-technical documents.  I see four 
possible ways to interpret that:


1. The Social Contract cannot be modified under the Debian Constitution.
2. Modifying the Social Contract is implicitly issuing a new Social 
Contract, and thus allowed with "simple" majority.
3. Modifying the Social Contract is implicitly modifying the Constitution, 
and thus allowed with a 3:1 supermajority
4. Modifying the Social Contract is implicitly allowed via some other 
clause in the Constitution no one has mentioned yet, and the voting 
requirements thus determined by that clause.


It's a hard choice to make.  Good arguments could be made, and were, for 1, 
2 or 3 (dunno about 4, though).  Because of the ambiguity, Branden and 
Manoj have both proposed amendments that would clarify the issue -- not 
necessarily change it, but to remove the ambiguity.


The Secretary chose 3.


2. Confusion has surrounded the ballot regarding aj's amendment.


There has been that.  I don't know how -that's- gonna be resolved.


3. There has been a suggestion that because of the Secretary's
inaction, the proposal and the amendment have expired.  This places us
in unknown territory since the Secretary already issued a ballot.
Furthermore, it leaves us in a nasty situation whereby a single person
can kill any resolution by ignoring it.


My personal opinion is that the suggestion is untenable on it's 
face.  True, there has been considerable time with no debate on the 
proposal, but a Call for Votes was made, indicating that people were ready 
to vote and bring closure.  The failure of a parliamentary officer to 
perform his duties should not kill a valid proposal.



4. During the Secretary's absence, the Constitution specifies that the
chairman of the Technical Committee should step up in his place.
However, that person is Ian Jackson and he failed with this duty.  The
Technical Committee have failed to replace him with someone more
active in the Project.

--
John Goerzen <[EMAIL PROTECTED]>   www.complete.org
Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com
#include  <[EMAIL PROTECTED]>


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The constitution and the social contract

[Buddha Buck]

> 
>   I beg to differ. Becoming a secretary does not mean one gives
>  up ones right to an opinions (indeed, if it does, I'll strongly
>  exhort people never to step up and volunteer for such a
>  disenfranchising post).

The Debian Secretary plays a role similar to the traditional role of the
Chair.  Like the Debian Secretary, the chair is responsible for 
recognizing legitimate motions, ensuring the rules of debate are 
followed, conducting votes, and reporting the results.  The chair is
also the arbiter of the rules under which the organization operates
(subject to potential appeal to the floor), similar to the Debian
Secretary's role as final arbiter of the Debian Constitution.

Traditionally, the Chair is also supposed to maintain at least the 
appearance of impartiality.  The Chair does not speak for or against a 
motion, nor does the Chair vote, unless a) it is a closed-ballot vote 
or b) the vote would materially effect the outcome.  This 
"disenfranchisement" and gag order are expected and come with the job.  
Since all Debian votes are conducted via closed balloting, I don't see 
disenfranchisement as being an issue.  The only remaining question is 
the impartiality and "gag-order" rule.
 
>   I think it is insulting to imply that the secretary can't keep
>  his different hats separated enough to allow his own opinions to
>  taint his performance as an office bearer in the project.

The problem with the Chair isn't so much as allowing his own opinions 
to taint his performance, as allowing his own opinions from unduly 
influencing the debate.  I'm not so certain that that is such a problem 
with the Debian Secretary, as long as the secretary is good about being 
clear when he is speaking as a developer, and when he is speaking as 
Secretary.  The Secretary certainly doesn't seem to have the same sort of power 
and influence as a meeting Chair would have.

>   I am saddened to note that we have fallen to this level of distrust.

I'm not sure it's a level of distrust, as much as a desire for a sense 
of impartiality.  Raul, in conducting this vote, would have -three- 
hats to juggle: developer, Chair of the Technical Committee, and Acting 
Secretary.  As developer, he should be able to speak his opinion and 
participate 
freely.  As Chair of the Tech Comm, he should speak only the decided 
opinion of the Tech Comm, and as Secretary, his opinion shouldn't be a 
factor.

It's not just if Raul can juggle those three hats, but if the rest of 
us can understand when he is or isn't.

It's already been mentioned that -anything- Darren is likely to say now 
is going to be taken as coming from the Secretary, so his ability to 
state his own opinion separate from his official position is shot.  Can 
we avoid putting Raul into that same unfortunate position.

> 
>   manoj
> -- 
>  If I'd known computer science was going to be like this, I'd never
>  have given up being a rock 'n' roll star. Hirst
> Manoj Srivastava   <[EMAIL PROTECTED]>  <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
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: The constitution and the social contract

[Buddha Buck]

> Hi,
> >>"Buddha" == Buddha Buck <[EMAIL PROTECTED]> writes:
> 
>  Buddha> Traditionally, the Chair is also supposed to maintain at
>  Buddha> least the appearance of impartiality.  The Chair does not
>  Buddha> speak for or against a motion, nor does the Chair vote,
>  Buddha> unless a) it is a closed-ballot vote or b) the vote would
>  Buddha> materially effect the outcome.  This "disenfranchisement" and
>  Buddha> gag order are expected and come with the job.  Since all
>  Buddha> Debian votes are conducted via closed balloting, I don't see
>  Buddha> disenfranchisement as being an issue.  The only remaining
>  Buddha> question is the impartiality and "gag-order" rule.
>  
>   Show me. Show me the gag order that apparently comes with this
>  job. The constitution is open to all of us. Chapter and verse, please.

OK, since the "gag order" of which I speak above is part of the 
traditional job of the Chair, I'll quote Chapter and verse from the 
Book of Rules that are Roberts (Newly Revised edition): Section 42, 
subsection 6 (Rule Against Chair's Participation in Debate:

# If the presiding officer is a member of the society, he has -- as an 
# individual -- the same _rights_ in debate as any other member; but 
# the impartiality required of the chair in an assembly precludes his 
# exercising these rights while he is presiding.  Normally, especially 
# in a large body, he should have nothing to say on the merits of 
# pending questions. On certain occasions -- which should be extremely 
# rare -- the presiding officer may believe that a crucial factor 
# relating to such a question may have been overlooked and that his 
# obligation as a member to call attention to the point outweighs his 
# duty to preside at that time.  To participate in debate, he must 
# relinquish the chair ... The presiding officer who relinquished the 
# chair then should not return to it until the pending main question 
# has been disposed of, since he has shown himself to be a partisan as 
# far as that particular matter is concerned.  Indeed, unless the 
# presiding officer is extremely sparing in leaving the chair to take 
# part in debate, he may destroy members' confidence in the 
# impartiality of his approach to the task of presiding.

As a general rule, I tried to be -very- careful separating the role of 
Debian Secretary and the traditional role of Chair in my earlier reply. 
The two positions have many similarities, but they also have many 
differences.   I know that Debian does not follow Robert's Rules of 
Order, nor do I believe that Robert's Rules are directly applicable to 
email-based debate and decision making.  At best, the general 
principals apply.

>   I contend that there is a long standing tradition in Debian of
>  people wearing multiple hats -- Ian J even had different email
>  addresses ([EMAIL PROTECTED]) when he was speaking ex cathedra (if I
>  may say without offence to the catholics amongst us). I alkso suggest
>  that we are a) inteligent enough to recignize the difference between
>  Raul speaking his opinion, and raul acting as a vote taker, and b)
>  even if the secreatry, or, even, horrors, the DPL, actually voice
>  (for shame) opinions, we can still hold up under the pressures and
>  still, incredibly, hold an opinion of our own.

As I said below, I'm uncertain whether the traditional requirement for 
impartiality on the part of the Chair should carry over to the Debian 
Secretary.

I certainly would be much more comfortable with it if the Secretary 
used some convention for distinguishing the roles.  
"[EMAIL PROTECTED]" for ex officio announcements would be a 
reasonable method.

>   If someone out there can't do that, please send me your name
>  in private email; there are a lot of ballots I would like to stuff in
>  the future, and your name would be very nice to have. 
> 
>  >> I think it is insulting to imply that the secretary can't keep
>  >> his different hats separated enough to allow his own opinions to
>  >> taint his performance as an office bearer in the project.
> 
>  Buddha> The problem with the Chair isn't so much as allowing his own
>  Buddha> opinions to taint his performance, as allowing his own
>  Buddha> opinions from unduly influencing the debate.  I'm not so
> 
>   That, sir, is an insult to the members of this forum. I have
>  enough brains to be able to judge a situation on its merits, thank
>  you very much, and am uhnlikely to succumb to blind puppy worship of
>  the granduer attached to the job of the Debian secretary.

Please note that I was talking about the Chair, who is the one 
traditionally gagged.  And while I would expect Members of Parliament 
to b

Re: well?

[Buddha Buck]

> 
> Are we all now clear on why ballots must be understandable, and why
> transparency of process is important?

As an observer, and not a developer (note to self:  you've been hanging 
out on the debian developers lists for 4+ years now, get off your ass 
and become a developer already!), I think there were a number of 
problems, only one of which was unclear ballots (unless, of course, 
you are talking about Palm Beach, Florida).

1st, we had a proposal die not because of a lack of interest, but 
because of what amounts to a clerical issue.  After the debate/flame 
war had continued for the requisite time, the proposer(s) called for a 
vote.  The debate continued until everyone was burned out and 
thoroughly knew the issue and their opinion on it.  Then people waited 
for 2 months for a vote to happen -- only to have it invalidated 
because people waited for 2 months instead of arguing for that time.

Darren obviously wasn't in a position to conduct the vote then, but 
that should be better now.  In addition, Raul is going to get trained 
in how to conduct the vote, so the official fall-back person can be 
fallen back upon if needed.  Hopefully, this will fix this problem in 
the future.

2nd, we had a strange situation where (in the view of several people, 
especially the secretary) a proposal and its amendment required 
different majorities to win.

Darren probably made the right call to have two separate ballots, but 
it's still an edge-case in our voting procedure.

3rd, we had the "can the Debian Social Contract be modified, and if so, 
how?" issue.  Luckily, things are in the works to resolve that.

4th, we had the unclear ballots when they finally got here.

Hopefully, we can learn from this whole list of problems...

> 
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5

[Buddha Buck]

At 08:35 AM 11/9/00 -0600, Manoj Srivastava wrote:

>>"Peter" == Peter Makholm <[EMAIL PROTECTED]> writes:

 >> 4. The Developers by way of General Resolution or election
 >>
 >> 4.1. Powers
 >>
 >> Together, the Developers may:

 >> 2. Amend this constitution, provided they agree with a 3:1 majority.

 >> +   5.2 Initially, the list of foundation Documents consists
 >> +   of this document, The Debian Constitution, as well as the
 >> +   documents known as the Debian GNU/Linux Social Contract and the
 >> +   Debian Free Software Guidelines. The list of the documents
 >> +   that are deemed to be "Foundation Documents" may be changed
 >> +   by the developers provided they agree with a 3:1 majority.

 Peter> Is it wise to let amendments to the constitution be regulated by two
 Peter> rules? Why not drop the first rule to improve maintainability.

Where do you see two rules to regulate constitutional
 amendments? One rules is for the constitution, the other rule is on
 how to amend a totally separate list of Foundation documents.


Rule 2 says that developers can change the Debian Constitution with a 3:1 
majority.


Proposed Rule 5.2 says that developers can change certain "Foundation 
Documents" with a 3:1 majority.  The first "Foundation Document" listed is 
is the Debian Constitution.


Both rules cover modifying the Debian Constitution.  Rule 2 under the 
context of the Debian Constitution; Proposed Rule 5.2 under the context of 
Foundation documents.





manoj

Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5

[Buddha Buck]

> Hi,
> >>"Buddha" == Buddha Buck <[EMAIL PROTECTED]> writes:
> 
> 
>  Buddha> Proposed Rule 5.2 says that developers can change certain "Foundation
>  Buddha> Documents" with a 3:1 majority.  The first "Foundation Document"
>  Buddha> listed is is the Debian Constitution.
> 
>   Ah. My mistake. Should we just not list the constituion under
>  foundation documents, then? Or leave it in, for now, since the
>  supermajority is exactly the same, and any changes to that would
>  require amending the constitution anyway, and we can deal with it if
>  it ever happens. 
> 
>   It kinda feels right having the constitution listed under
>  foundation docs ...

How about placing the DSC/DFSG in Rule 2, rather than in Rule 5.2?  

For a hand-diff, how about something like:

--
   4.1. Powers
   
Together, the Developers may:
 1. Appoint or recall the Project Leader.
-2. Amend this constitution, provided they agree with a 3:1 majority.
+2. Amend the Foundation Documents of the Debian Project, provided
+   they agree with a 3:1 majority
+2.1 The Foundation Documents are the Debian Social Contract, the
+Debian Free Software Guidelines, and this document, the
+Debian Constitution.
3. Override any decision by the Project Leader or a Delegate.
4. Override any decision by the Technical Committee, provided they
   agree with a 2:1 majority.
-5. Issue nontechnical policy documents and statements.
+5. Issue, modify, and withdraw nontechnical policy documents and
+   statements.
These include documents describing the goals of the project, its
relationship with other free software entities, and nontechnical
policies such as the free software licence terms that Debian
software must meet.
They may also include position statements about issues of the day.
+   This does not include the Foundation Documents.
 6. Together with the Project Leader and SPI, make decisions about
property held in trust for purposes related to Debian. (See
s.9.1.)

   
> 
>   manoj
> -- 
>  A language that doesn't have everything is actually easier to program
>  in than some that do. Dennis M. Ritchie
> Manoj Srivastava   <[EMAIL PROTECTED]>  <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
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: PROPOSED: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5

[Buddha Buck]

> -BEGIN PGP SIGNED MESSAGE-
> 
>   A suggested ballot for the secretary to consider is:
> - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  [ ] YES to proposal A: Foundation + issue/modify/withdraw
>Amend the constitution to introduce Foundation Documents, allow
>the  developers  to issue, modify and withdraw  them with a 3:1
>super majority,  and to allow the  developers to issue,  modify
>and  withdraw all other non technical  documents  with a simple
>majority   
>  [ ] YES to proposal B  issue/modify/withdraw only
>Amend the constitution to allow the developers to issue, modify
>and withdraw all non technical documents with a simple majority
>  [ ] Further discussion
> - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Shouldn't this include a "No" option as well as "Further Discussion"?

I'd also like a description of the process that will be followed to 
determine the outcome of the vote.  The Condorcet method specified in 
the Constitution is clear about such things in the case of a GR, where 
only a majority is required.  How does it work when two of the ballot 
options require a supermajority to pass?

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5

[Buddha Buck]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> "MS"  => Manoj Srivastava <[EMAIL PROTECTED]>
> "CMC" => C.M. Connelly <[EMAIL PROTECTED]>
> 
> CMC> I've made the following changes:
> 
> CMC> 1. Added a 2:1 majority requirement to issue, modify, or
> CMC>withdraw nontechnical policy documents.
> 
> MS> I formally reject this change to my proposal. You shall
> MS> need to create your own amendment and get seconds
> MS> separately if you wish for this to be voted upon.
> 
> That's fine.  I would love to see some discussion before I went to
> the trouble of putting together an amendment, however.

I'm not sure you meant it, but a "2:1 majority" requirement looks like 
a supermajority requirement -- twice as many supporters as opponents.

Right now, a nontechnical policy document or statement can be issued 
with a simple majority (modulo the fact that the Condorcet method isn't 
as simple as "simple majority").  It does not require a supermajority.  
Requiring a 2:1 majority is a major change, and one that does not tie 
in well with Manoj's or Branden's proposals.

Did you mean to create a supermajority requirement, or simply a 
majority requirement?

> 
>CMC
> 
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>  Behind the counter a boy with a shaven head stared vacantly into space, 
>  a dozen spikes of microsoft protruding from the socket behind his ear.
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>C.M. Connelly   [EMAIL PROTECTED]   SHC, DS
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.5 and GNU Privacy Guard 
> <http://www.gnupg.org/>
> 
> iD8DBQE6C3zzzrFKeh3cmQ0RAgzOAJ41wzIGE73+ifLsT4UeUFNqyU+NCgCfUh3X
> lNSYBbm9vZ3jcf5uyW8lD6Q=
> =+1f6
> -END PGP SIGNATURE-
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5

[Buddha Buck]

> Hi,
> >>"Buddha" == Buddha Buck <[EMAIL PROTECTED]> writes:
> 
>  Buddha> How about placing the DSC/DFSG in Rule 2, rather than in Rule 5.2?  
> 
>  Buddha> For a hand-diff, how about something like:
> 
>  Buddha> --
>  Buddha>4.1. Powers
>
>  Buddha> Together, the Developers may:
>  Buddha>  1. Appoint or recall the Project Leader.
>  Buddha> -2. Amend this constitution, provided they agree with a 3:1 
> majority.
>  Buddha> +2. Amend the Foundation Documents of the Debian Project, 
> provided
>  Buddha> +   they agree with a 3:1 majority
>  Buddha> +2.1 The Foundation Documents are the Debian Social Contract, the
>  Buddha> +Debian Free Software Guidelines, and this document, the
>  Buddha> +Debian Constitution.
> 
>   This does not clarify that the foundation documents can be
>  issued, modified, or withdrawn, and they need the same super majority
>  to do so.

In order to issue or withdraw a Foundation Document, clause 2.1 would 
have to be modified.  Since that is a change to the Debian 
Constitution, that would require a 3:1 majority.

I see no reason why these two closely tied issues couldn't be part of 
the same proposals:

--Example Follows, not a serious proposal
I propose

  that the Debian Social Contract be withdrawn as no longer 
applicable to the goals and ideals of the current set of Debian 
Developers; and

  that the Debian Constitution be amended, removing the mention of the 
Debian Social Contract from Section 4.1.2.1.

This proposal is covered by Section 4.1.2 of the Debian Constitution, 
and requires a 3:1 supermajority to pass
--Example Precedes, not a serious proposal-

Since even under your proposal, issuing or withdrawing a Foundation 
Document would require a similar a similar amendment to the Debian 
Constitution, I don't see it as an issue.

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5

[Buddha Buck]

At 08:26 AM 11/10/00 -0500, Joseph Carter wrote:

On Thu, Nov 09, 2000 at 04:17:07PM -0800, C.M. Connelly wrote:
>
> "BB" => Buddha Buck <[EMAIL PROTECTED]>
>
> How about this modification?
[.. 2:1 majority required for all non-technical documents ..]


Er, please be careful with your attributions.  In this case, on first 
reading, I thought I (not C.M.) was being accused of requiring a 2:1 
majority for non-technical documents.


I certainly didn't, nor would I support such a proposal.

Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

> Since we're already using a Condorcet-base scheme, it's probably best to
> keep doing that (ie, keeping the "foo DOMINATES bar"). From the latter
> URL, it seems that "Tideman" and "Schulze" are probably the most suitable
> (they're not vulnerable to most of the nasty strategies). Mike Ossipoff
> listed a whole bunch of related systems in his letters too.
> 
  
> 
> I presume the best way to handle different possiblities on ballots is
> just to vote on them at once (eg, "Remove non-free // We love non-free! //
> Status-quo // Further discussion") and have whichever one wins (according
> to the voting rules, and any supermajority requirements), win.

Could someone explain to me, in simple terms, how Condorcet-based 
voting schemes work in the face of a supermajority requirement?

My understanding of Condorcet is that a ballot like Anthony Towns used 
as an example ("Remove non-free // We Love non-free! // Status-quo // 
Further discussion") would be, during the first analysis, treated as if 
it were 6 separate 1-on-1 votes, with each of the four choices paired 
against each of the remaining 3.  If any of the four wins all three of 
the 1-on-1 votes it's part of, it wins the full balloting.  Otherwise, 
we use a fall-back resolution method (of which there are several 
varieties in the literature to choose in advance from).

This works fine if all the options required a plurality to win (note:  
I'm not even sure if "majority" or "plurality" are appropriate
descriptions of the victory condition in Condorcet-based schemes).  The 
system is balanced. 

But if one of the choices explicitly requires a 3:1 supermajority to work, I 
don't see how it works quite so well.

Can someone clear this up for me?

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

It seems, listening to this discussion, that there are some problems 
with ambiguity and lack of clarity with regards to Appendix A and the 
"Concorde" voting method and how it works.

I wouldn't mind seeing a omnibus amendment that replaces Appendix A 
with a clearer version, based on our experiences and the issues we've 
seen.  First suggestion for the omnibus amendment:  Replace all 
occurrences of "Concorde" in the Constitution with "Condorcet".  
Rational: The original name "Concorde" appears to be a mistake, and 
"Condorcet" is what was intended.  This simply fixes it.

If I find time this week, I'd be willing to write something up, but if 
I propose it, I gotta have six seconds, not five (not being a Debian 
Developer and all).

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

At 01:44 AM 11-29-2000 +1000, you wrote:


Why not simply define the terms as they are used by the people who care
about these things, and then clearly express the procedure by which ties
should be dealt with, rather than defining them out of existance?

A.6(2) An option A is said to Dominate another option B, if
   there are more votes which rank option A above option B
   than there are votes which rank option B above option A.


Can we include a clause here to handle the case where there are an equal 
number of ballots ranking A above B and B above A?  My opinion is that for 
the purposes of this procedure, then A would Dominate B, and B would 
Dominate A, rather than neither dominating each other.


That would have the nice property that for any distinct options A, B, we 
have at least one of "A Dominates B" and "B Dominates A".



A.6(2a) The Smith Set of options in a vote is the smallest
   non-empty set of options, each of which Dominates every
   option not in the Smith Set.


Or equivilantly, with the suggestion above, "The Smith Set of options in a 
vote is the smallest non-empty set of options, none of which are dominated 
by any option not in the Smith Set."


Or, since "domination" is a hard concept to fathom, how about:

The Smith Set of options is the smallest non-empty set of options, none of 
which lose in any pair-wise elections against any option outside the Smith Set.


or

The Smith Set of option is the smallest non-empty set of options which lose 
in pair-wise contests only to other members of the Smith Set,



A.6(3) If there is only one option in the Smith Set, it is
   the winner.

This still leaves the more important problem of how to handle related
(opposing) options in a single vote unaddressed, however. I'm further
inclined to suspect that using Single Transferable Vote to choose the
winner from the Smith Set isn't ideal, but I don't know enough about
the alternatives to give a basis for that suspicion.


The voting-methods pages have lots of suggestions.

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

At 10:52 AM 11-28-2000 -0800, you wrote:

Buddha Buck <[EMAIL PROTECTED]> writes:

So, then, the procedure will be:

1) Amend the Constitution to fix up the voting procedure, especially when
   supermajorities are needed.

2) Vote to decide what the threshhold will be for amendments to the
   Social Contract.

3) Vote on the amendment to the Social Contract.


It was not my intention to attempt to push the vote to amend the Social 
Contract back any further than necessary.


At least one of the above votes will have to be conducted under the current 
supermajority voting rules.  I see no procedural reason why (2) and 
possibly (3) (depending on the outcome of (2)) can't be done that way as 
well, saving my suggested clarification amendment for last.


Since The Manoj/Branden proposals have actually been made, and the 
clarification amendment is still in the formulation stages, I would say 
that (2) has seniority, and should take place before (1) anyway.  The 
Goerzen/Towns proposals (i.e., (3)) have been ruled "not current", so are 
in limbo like the clarification amendment.

Problems with Appendix A

[Buddha Buck]

Giving a quick read-through of Appendix A, I see several problems:

1) Every resolution that has amendments is supposed to have two votes: 
A.3.1) A vote to decide which amendments to apply, including "Further 
Discussion"; and A.3.2) A vote to accept or reject (or keep discussing) the 
final form of the resolution.


This in my mind defeats the strength of the Condorcet voting method, which 
should be able to find the best compromise out of many options.  Since the 
process of actually voting seems to be the largest source of grief 
recently, requiring multiple formal votes on an issue should only increase 
the grief.


I'd even be tempted to replace the discussion of "amendments" entirely with 
"alternate proposals".  The distinction being that an amendment is a change 
to the original proposal, while an alternate proposal is a separate 
proposal covering the same issue.  This would change A.1 somewhat, as well.


2) In several places, a distinction between the proposer and the sponsors 
leads to wordy work-arounds to indicate that both the proposer and sponsors 
have similar powers and responsibilities (A.1.2 and A.1.3 together require 
that the proposer and sponsors all agree to accept a formal amendment; A.4 
is just plain messy along those lines).  Sponsors do not appear to have any 
powers and responsibilities that the proposer lacks.  If the proposer could 
be considered a sponsor, then this verbiage could be simplified.


3) The situation with the Goerzen/Towns proposals demonstrated the problem 
with the Expiry section (A.5).  This needs to be fixed.


4) What is the intent of A.6.3 ("All options which are Dominated by at 
least one other option are discarded, and references to them in ballot 
papers will be ignored.")  This would seem to imply that if there is no 
unambiguous winner (if the Smith Set is not singleton), then all the 
options will be discarded.  Obviously, that's not right.


5) A.6.8 is using "quorum" to have a strange meaning.  A quorum normally 
describes the minimum total number of voters, not the minimum margin of 
victory.


6) Single Transferrable Vote among the Smith Set is one way to decide the 
winner, but it isn't necessarily the best.


Raul Miller suggested a possible rewording of A.6 that clarifies the 
current procedure, but leaves some of it's warts in place.  Why not take 
this opportunity to fix some of the problems while we are at it?

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

> > > Single Transferable Vote biases the selection in favor of first
> > > preferences at the expense of other preferences. Can you think of a
> > > better kind of criteria for making the selection?
> >
> > Other methods can be found at the URLs I cited at the start of the
> > thread. "Reversing the fewest and weakest pairwise defeats" (ie, using
> > the smallest possible casting vote) is probably another reasonable
> > alternative. But, as I said, I don't profess to know enough about
> > cycle breakers to really say.
> 
> But: I'm not asking "are there other methods", I'm asking "what's a
> better criteria?" and "why?"

Whether one criteria is better than another is of course a matter of 
opinion.  

Above, you prefer Single Transferable Vote (which also appears to be 
called "Instant Runoff Voting" or "IRV" on most of the voting method 
websites) because it "biases selection in favor of first preferences 
at the expense of other preferences".  Obviously, you think this is a 
good thing.

Others may prefer other methods because they reverse the preferences of 
the fewest number of voters.  This is a different criteria.  Is it 
better?  I think so, and so do others.  You may not.  Most of the 
"traditional" Condorcet resolution methods favor this criteria.
 
I think the best we can do is list a bunch of alternatives, with 
explanations and descriptions of their advantages and disadvantages, 
and discuss from there.

> 
> I'll note that the URL you cited doesn't have anything equivalent to
> Single Transferrable Vote.  [So it's not comprehensive.]  I don't think
> "my favorite web site doesn't mention this system" somehow makes the
> systems it proposes to be somehow superior.

The URL I'm looking at does not discuss IRV under Condorcet resolution 
methods, but it does discuss IRV as a technique for general elections 
(i.e., an alternative to Condorcet).  I'm looking at http://
www.electionmethods.org/, which does have some faults (it has an 
-extreme- bias towards Condorcet and against plurality and IRV, for 
instance).

> The nice thing about Single Transferrable Vote is that it automatically
> makes first preference votes more important than second preference votes
> (and so on).  There are few systems at the URL you cited which even
> attempt this.

Most of the Condorcet resolution methods I've seen don't attempt that 
because they don't see it as a valid criteria.  They see overruling the 
fewest number of votes to be a valid criteria.

Actually, I did find one description of a voting concern that does 
severely impact IRV.  IRV requires the multiple examination of every 
ballot, which can be prohibitive if the number of ballots is huge, or 
fragile, etc.  Since most voting reform sites are concerned with reform 
of real-world elections, where there may be millions of voters, this is 
a bigger concern for them than it is for us.  And this is a valid 
criteria for them to consider.  The Condorcet resolution methods 
normally discussed can all be computed solely from the aggregate voting 
data, not needing to further examine individual ballots.

> 
> > This sort of situation happens no matter how you resolve a cyclic tie,
> > though. You pretty much have to be "unfair" in some sense to choose a
> > winner. As I said, I'm inclined to suspect that there other means are
> > likely to be more optimal, although I'm not clear exactly how.
> 
> It really sounds more as if you want to find faults in the constitution
> than you've thought this through and have a better alternative to propose.

No voting system is going to be 100% "fair" to all voters.  The 
question remains, however:  How do we determine "fairness" to evaluate 
different methods?

> 
> That's not in and of itself a bad thing, but it does lead to a lot
> of talk.
> 
> Thanks,
> 
> -- 
> Raul
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

At 10:07 AM 11-29-2000 -0500, Raul Miller wrote:

>That's one question.  Another question is: what problem are we trying

to solve?


Last things first...  This is a -very- important question that I don't know 
the full answer to.


The main problem:  The current "Standard Resolution Procedure" as written 
in Appendix A of the Debian Constitution is confusing and ambiguous.


There are (at least) two ways of addressing this issue.  The first way is 
to amend Appendix A so that the current procedure is made unambiguous and 
clear.  The advantage of this is that it causes the minimal amount of 
change to the actual process.  The disadvantage is that if the main problem 
is real, there are multiple interpretations as to what the proper 
unambiguous method is.


The second way is to look for what the faults are in the current process 
are, and amend Appendix A with a better procedure that is also unambiguous 
and clear.  I think I prefer this way.


What I would consider ideally unambiguous for a replacement for A.6 would 
be pseudocode for determining the election, rather than the poorly-written 
english we have now.  Something that most of the Debian Developers could 
probably be able to sit down, code in their favorite language, and get all 
get the same answers.




On Wed, Nov 29, 2000 at 07:28:44AM -0500, Buddha Buck wrote:
> Whether one criteria is better than another is of course a matter of
> opinion.

Agreed.  Still, consensus is possible.

> Above, you prefer Single Transferable Vote (which also appears to be
> called "Instant Runoff Voting" or "IRV" on most of the voting method
> websites) because it "biases selection in favor of first preferences
> at the expense of other preferences". Obviously, you think this is a
> good thing.

Sure -- but logically, if I'm a voter, and I indicate a second and third
preference on a ballot, that shouldn't weaken the strength of my first
preference.


I was going to say that I would consider that a valid criteria to consider 
for a voting system, but then I realized that I don't understand what you 
mean.  Could you elaborate?


I don't know if IRV has the problem that your 2nd or 3rd choice votes could 
cause your 1st vote choice to lose, but IRV does have the problem that in 
certain cases, your 2nd choice vote could cause your 3rd choice to 
win.  The http://www.electionmethods.org/ site describes this.



> Others may prefer other methods because they reverse the preferences of
> the fewest number of voters.  This is a different criteria.  Is it
> better?  I think so, and so do others.  You may not.  Most of the
> "traditional" Condorcet resolution methods favor this criteria.

Sure -- mediocracy tends to be easy to agree on.


Again, I don't understand what you mean...

Here's what I meant...

In a Condorcet vote, if there is one choice which pairwise defeats all 
other choices, then that choice wins.  That's a pretty good indication that 
that choice is well supported.  However, if there is no choice that 
pairwise defeats all other choices, then you must have a cycle(s) of some 
sort:  More people prefer A to B, more B to C, more C to A, in the simplest 
of cycles.  To claim an absolute victor, the cycle(s) needs to be broken, 
effectively reversing one or more of the pair-wise contests.  Such a 
reversal is effectively overriding voters expressed preferences,




> I think the best we can do is list a bunch of alternatives, with
> explanations and descriptions of their advantages and disadvantages,
> and discuss from there.

I'm willing (see above :).

> > I'll note that the URL you cited doesn't have anything equivalent to
> > Single Transferrable Vote.  [So it's not comprehensive.]  I don't think
> > "my favorite web site doesn't mention this system" somehow makes the
> > systems it proposes to be somehow superior.
>
> The URL I'm looking at does not discuss IRV under Condorcet resolution
> methods, but it does discuss IRV as a technique for general elections
> (i.e., an alternative to Condorcet).  I'm looking at http://
> www.electionmethods.org/, which does have some faults (it has an
> -extreme- bias towards Condorcet and against plurality and IRV, for
> instance).

Turns out I'd missed the cite.

> > The nice thing about Single Transferrable Vote is that it
> > automatically makes first preference votes more important than
> > second preference votes (and so on). There are few systems at the
> > URL you cited which even attempt this.
>
> Most of the Condorcet resolution methods I've seen don't attempt that
> because they don't see it as a valid criteria. They see overruling the
> fewest number of votes to be a valid criteria.

Right, but that's method, and

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

Er, I hit "send" by accident, please wait for my complete reply before 
replying

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

At 10:07 AM 11-29-2000 -0500, Raul Miller wrote:

>That's one question.  Another question is: what problem are we trying

to solve?


Last things first...  This is a -very- important question that I don't know 
the full answer to.


The main problem:  The current "Standard Resolution Procedure" as written 
in Appendix A of the Debian Constitution is confusing and ambiguous.


There are (at least) two ways of addressing this issue.  The first way is 
to amend Appendix A so that the current procedure is made unambiguous and 
clear.  The advantage of this is that it causes the minimal amount of 
change to the actual process.  The disadvantage is that if the main problem 
is real, there are multiple interpretations as to what the proper 
unambiguous method is.


The second way is to look for what the faults are in the current process 
are, and amend Appendix A with a better procedure that is also unambiguous 
and clear.  I think I prefer this way.


What I would consider ideally unambiguous for a replacement for A.6 would 
be pseudocode for determining the election, rather than the poorly-written 
english we have now.  Something that most of the Debian Developers could 
probably be able to sit down, code in their favorite language, and get all 
get the same answers.




On Wed, Nov 29, 2000 at 07:28:44AM -0500, Buddha Buck wrote:
> Whether one criteria is better than another is of course a matter of
> opinion.

Agreed.  Still, consensus is possible.

> Above, you prefer Single Transferable Vote (which also appears to be
> called "Instant Runoff Voting" or "IRV" on most of the voting method
> websites) because it "biases selection in favor of first preferences
> at the expense of other preferences". Obviously, you think this is a
> good thing.

Sure -- but logically, if I'm a voter, and I indicate a second and third
preference on a ballot, that shouldn't weaken the strength of my first
preference.


I was going to say that I would consider that a valid criteria to consider 
for a voting system, but then I realized that I don't understand what you 
mean.  Could you elaborate?


I don't know if IRV has the problem that your 2nd or 3rd choice votes could 
cause your 1st vote choice to lose, but IRV does have the problem that in 
certain cases, your 2nd choice vote could cause your 3rd choice to 
win.  The http://www.electionmethods.org/ site describes this.



> Others may prefer other methods because they reverse the preferences of
> the fewest number of voters.  This is a different criteria.  Is it
> better?  I think so, and so do others.  You may not.  Most of the
> "traditional" Condorcet resolution methods favor this criteria.

Sure -- mediocracy tends to be easy to agree on.


Again, I don't understand what you mean...

Here's what I meant...

In a Condorcet vote, if there is one choice which pairwise defeats all 
other choices, then that choice wins.  That's a pretty good indication that 
that choice is well supported.  However, if there is no choice that 
pairwise defeats all other choices, then you must have a cycle(s) of some 
sort:  More people prefer A to B, more B to C, more C to A, in the simplest 
of cycles.  To claim an absolute victor, the cycle(s) needs to be broken, 
effectively reversing one or more of the pair-wise contests.  Such a 
reversal is effectively overriding voters expressed preferences.


Methods of choosing a winner in the presence of such cycles can be judged 
based on how few voters preferences are overridden.  That is a standard 
criteria which is used to judge.



> I think the best we can do is list a bunch of alternatives, with
> explanations and descriptions of their advantages and disadvantages,
> and discuss from there.

I'm willing (see above :).


OK, here are some choices:

Definitions from http://www.barnsdle.demon.co.uk/vote/vote.html

Defn: An "unbeaten set" is a set of options none of which is beaten [in a 
pairwise contest] by anyone outside that set.


Defn: A "small unbeaten set" is an unbeaten set that doesn't contain a 
smaller unbeaten set.


Defn: The "Schwartz set" is the set of options which are in small unbeaten 
sets.


Defn: The "Smith set" is the smallest set of options such that every option 
in the set beats every option outside the set.  Note:  In some cases, the 
Smith Set can contain the entire set of options.



Given:  A set of preferential ballots, modifed by eliminating all options 
that are not in the Smith set.


Option:  Plurality

Examine the 1st choice on all ballots.  The choice with the highest vote 
total wins.


Advantages:  Easy to understand.
Disadvantages: Does not take into account complete knowledge of voters 
preferences.  Requires re-examination of the ballots after the initial tally.
Other factors: Strongly favors first choice preferenc

Twice now...

[Buddha Buck]

Twice now, when composing a reply to Raul in the "Condorcet Voting" thread, 
I've hit C-E to move to the end of the line, and Eudora has interpreted 
that as "Send Immediately", and sent incomplete replies  Sorry about that.


The last reply actually has most of the "meat" of what I was going to say, 
and if I try again, I'll just reply to the parts I didn't before.  I won't 
be using Eudora to do it, either...


later,
  Buddha

Voting Methods

[Buddha Buck]

it represents the will of the voters better
than any PC, SC, SD, or SSD.  I have not yet found any online
theoretical discussions that say why, though.

Disadvantages:  Is not guaranteed to find unique winner in face of
tied pairwise voting.

Other factors:  This is the only method discussed that was developed
specifically for Condorcet that isn't based on PC.

-

Apparantly, Tideman's is considered the best method among people who have 
studied voting methods.  David Barnsdale's site above lists some criteria 
that people feel are important.

http://www.fortunecity.com/meltingpot/harrow/124/ describes a large
number of election methods, as well as a large number of possible
criterion.  Not much detail is given into the
advantages/disadvantages, however.

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

At 02:23 PM 11-30-2000 -0500, Raul Miller wrote:

[third pass]

On Thu, Nov 30, 2000 at 02:00:57PM +1000, Anthony Towns wrote:
> Surely you agree that a minority of people being able to subvert the
> resolution procedure to get what they want instead of what the majority
> want is a bad thing?

I think I agree with your underlying point -- that this kind of
discrepancy in the voting system indicates a flaw.


This sounds like what the www.electionmethods.com site calls the "Strong 
Defensive Strategy Criterion":  "If a majority of the voters prefer 
candidate A to candidate B, then they should have a way of voting that will 
ensure that B cannot win, without any member of that majority reversing a 
sincere preference for one candidate over another or insincerely voting two 
candidates equal."




I disagree with your emotional loading (e.g. the use of words like
"subvert"), but you still have a valid point.


Is the wording of the SDSC better?




Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

I'm about to leave town for the weekend, so I don't have time to answer 
too many of these in detail.  For now, I'll respond to one comment by 
Raul:

> I'm uncomfortable saying if I've agreed to this.  The Smith/Condorcet
> criteria that Buddha posted is not something I've agreed to.  So,
> discussion could happen here, to make sure we were using the same
> terminology.

Yes, let's be clear on terminology.  The Smith/Condorcet METHOD I 
posted is not a criterion, but a method of choosing a victor (in 
non-supermajority situations).  It happens to be a method that meets 
both the Condorcet Criterion and the Smith Criterion:

Condorcet Criterion: If there is an undefeated option (in pairwise 
contests), that option should be the winner.

Smith Criterion:  The winner should come from the Smith set.  The Smith 
Criterion implies the Condorcet Criterion, because if there is an 
undefeated option, the Smith set consists solely of that option.

Do you have a problem with these criteria in NON-Supermajority 
elections?

The Smith/Condorcet method (as well as Sequential Dropping, Schwartz 
Sequential Dropping, Tideman) all meet both of the above criteria.  
Plurality and IRV limited to the Smith set also meet both criteria.  

In a Supermajority situation, the big question becomes: What does a 
"supermajority" mean in a multi-option election?  In a single-option 
election, it's easy:  More "yeas" than "nays" by a supermajority.  I can even 
see that 
extended to an Approval voting system:  an option -can- win by a N:M 
supermajority if the ratio of "Approved" votes to "Not approved" votes 
is at least N:M.  This leads to another possible criterion:

Supermajority Criterion:  If any option requires a N:M supermajority, 
then if more than M/N of the ballots disapprove of the option, then it 
should not win.

Does that sound reasonable?  Please keep in mind that I haven't defined 
what "approved" and "disapproved" means on a preferential ballot.

One suggestion I've heard recently says that to vote "sincerely" in an 
Approval election one should vote "approved" on any option one prefers 
to the incumbent (which would be the status quo) and "not approved" on 
any option one prefers the incumbent to.  This is obviously debatable, 
and I don't know if I accept it myself.  It can, however, be turned on its 
head and used to get an Approval election out of a preferential 
election.  It is unclear of the "status quo" option should be "No" or 
"Further Discussion".  This is also debatable.

How about this Supermajority Election proceedure:

1) Find a winner using some method that meets both the Smith and 
Condorcet Criteria (exact method still under debate).

2) If the winner has a supermajority requirement, compare the winner 
with the "status quo" option.  If it defeats the status quo by the 
supermajority requirement, then it wins, otherwise "default" wins.

Now I really must be going...

Later,
  Buddha
 


-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)

[Buddha Buck]

> > On Fri, Dec 01, 2000 at 06:54:32AM -0500, Raul Miller wrote:
> > > However, with the 3:1 supermajority which affects A, you get:
> > > 10: 0  B:C
> > >  3 1/3: 0  A:B
> > >  3 1/3: 0  A:C
> > > B wins.
> 
> On Fri, Dec 01, 2000 at 10:24:41PM +1000, Anthony Towns wrote:
> > This isn't correct: A wins by being preferred to all other options (A >
> > B, 3.3 to 0 and A > C, 3.3 to 0). The strengths of the victories don't
> > come into play unless you have a cycle.
> 
> I was talking about the smith/condorcet mechanism.

You may have been talking about it, but you didn't apply it properly.  
The SC method I described said "drop the weakest defeat from the Smith 
set until there is an undefeated option".

The Smith Set is defined as the smallest set of options that are not 
defeated by any option outside the Smith Set.

In your example, even after Supermajority scaling, you have A defeating 
B and C, so the Smith Set contains the sole option A.  

Option A is undefeated in the Smith set (trivially) so the SC method would 
declare 
A the victor, not B.

In fact, A would be the victor in any of the methods I mentioned, 
simply because it is an undefeated option.  Even after supermajority 
scaling. 


-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice