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

Re: Hybrid Theory

Anthony Towns wrote


Here's a start:

	(0) The default option should be to leave the vote unresolved;
	    if people wish to actively preserve the status quo, they should
	    ensure that is listed as a separate option on the ballot.
This is interesting. But how is the default option different to the status quo? I assumed the default option would always be the status quo, although the status quo may not be the default option. An unresolved vote means the status quo is maintained. The only difference I can think of is the timing of a revote. Most of my examples treat the default option as any other. I suspect it is possible to subsitute the status quo with the default option (correct me if I'm wrong), in my examples, including http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00066.html. 


	(1) We want a voting system that handles quorums.
	(1a) Quorums are handled on a per-option basis.
	(1b) Electors are counted toward the quorum if they vote, and if they
	     rank the option above the default option.
I haven't thought much about quorum requirements yet, other than they should not break monotonicity, and not discourage people from voting. I will make the suggestion that if the quorum is X, and Y votes are recieved, where Y is less than X, assume there is an additional (X - Y) votes for the default option only, and resolve normally. 



	(2) We want a voting system that handles supermajorities.
	(2a) An option requiring an N:1 supermajority means that 1/(N+1) of
	     the voters may block that option from passing.
	(2b) An option that does not meet its supermajority requirement does
	     not affect the outcome of the vote.
	(2c) Options with a supermajority requirement should be treated as
	     similarly to other options as possible.
	(2c.i) The supermajority requirement should be satisfied by more
	       than N/(N+1) voters ranking that option above the default
	       option.
	(2c.ii) All other comparisons, including transitive comparisons,
		should not be scaled.


Heres a brief overview of the criteria above with respect to CCSSD.

(2) CCSSD handles supermajorities.
(2a) In CCSSD, 1/(N+1) votes may block a supermajority option from passing, by ranking a non-supermajority option X in front of supermajority option Y in 1/(N+1) votes. (actually, CCSSD currently requires more than 1/(N+1) votes, thats easily changed by changing 'challenge' to 'defeat' though. (2b) This is true in CCSSD, as these options are dropped before CSSD is performed. (2c) In CCSSD, they are treated identically (as long as they pass supermajority requirements). No scaling is performed.and possibly incorrect (2c.i) This, I disagree with, due to reasoning in http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00066.html. However, the version IDLTVOCCSSD I proposed in http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00035.html does pass this criteria, but I don't like this version as it falls to my own critisim in http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00066.html. 
(2c.ii) As above, no scaling is performed in CCSSD.


Raul Miller wrote


Interestingly enough, the problem which has lead to all these voting
mechanics proposals very much has to do with the conflict expressed here
between (2b) and (2c).
I don't see the conflict. Its easy to drop options that don't meet supermajority requirements, and perform plain (or my proposed default protected) CSSD on the ones that do. However, if the method only compares supermajority requirements to the default option, in my humble opinion, it will produce strategy problems that would allow a supermajority option to be elected without a supermajority via insincere voting, a weak dummy option, and two elections, as in http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00066.html.
I have published a version that does in my opinion satisfy this criteria, IDLTVOCCSSD, although I don't like it, there doesn't seem to be a conflict. And both CCSSD and DPCCSSD both pass (2b) and (2c), just not (2c.i) 

--
I'll summerise my two proposals in a few lines, as the definitions are long and verbose, though I think they are correct, history shows otherwise. This is their intent.
CCSSD (Definition: http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00020.html) 

Drop options that do not meet supermajority requirements.
Perform plain CSSD on remaining options.
DPCCSSD (Favours default options) (Definition: http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00035.html) 

Drop options that do not meet supermajority requirements.
Perform plain CSSD on remaining options, with the exception that all cycles resolve in the favour of the default option.
Option X meets the supermajority requirement if option X, (for both CCSSD and DPCCSSD).
(a) superdefeat all options with supermajority requirements less than option X. 
OR
(b) Superdefeat an option Y which has met its supermajority requirements and has supermajority requirements greater or equal to option X. 

Notes
- Superdefeats are actually superchallenges in current defintions, though I have no real reason for choosing one over the other. Superdefeats would be fine. - In (b) in recently posted definitions, only a defeat/challenge is required. I think a superdefeat my be better. 

Brief Rational.
(a) This it to prevent strategy explained in http://lists.debian.org/debian-vote/2002/debian-vote-200212/msg00066.html. (b) This is to prevent identical repeated elections producing different results due to changes in default option to status quo (I've called this consistancy, though no example I've posted yet addresses the consistancy reasoning of (b) involving supermajorities.) 

---

Thanks

Clinton
Reply to: