Debian-EM Joint Committee
orce serialised decisionmaking, by preventing alternate proposals from appearing on the same ballot. If this loophole is exploited, it transforms even the best pairwise method into nothing more than Roberts Rules (perhaps not even that). Sponsors should *not* have this power, since it can prevent developers from reliably choosing the best compromise proposals, and slows down decisionmaking. See A.2.2 9. PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY: Currently ,the Secretary or his stand-in (chair of technical committee) can kill any motion by not distributing ballots to voters within the 4-week interval prior to automatic expiry (yes, this has happened). Should the secretary have this power, or should it be restricted in some way? See A.5 10. STATE INTERPRETATION OF TRUNCATED BALLOTS: The constitution currently allows voters to truncate their ballot, ie: leave some options unranked. However, it does not specify how these unranked options are to be interpreted. Based on my analysis of previous results, it appears that Debian is using the correct interpretation (all unranked candidates are treated as though they had been ranked equally last), but this is unspecified. This interpretation should be clearly stated, since even the project secretary was not aware that this was how truncated ballots were counted. See A.6.1 11. EXPLICITLY ALLOW EQUAL RANKINGS: The constitution does not specify whether or not voters can assign the same ranking to more than one candidate. Since doing so causes no problems with interpretation or vote counting when a pairwise method is used, this should be explicitly permitted. See A.6.1 12. RESOLVE CIRCULAR TIE PROBLEM: The Concorde voting method is indecisive when confronted with a circular tie. As the rules are currently written, the specified tiebreaker (A.6.5) is ineffective, because A.6.3 eliminates all candidates. A more effective pairwise method, and more carefully written definition should be adopted to resolve this problem. 13. SIMPLIFY AND IMPROVE TIEBREAKER: The current voting method uses STV as a tiebreaker to choose a single winner when the pairwise method fails to choose a single winner. Due to A.6.3, this tiebreaker will only resolve pairties (not circular ones), so its usefulness is very limited. A much simpler, more effective tiebreaker could be adopted, which would add important strategy-free guarantees, clone independence, etc. for cases where there is no Condorcet winner. STV is undesireable because it is needlessly complex, requires ballots to be recounted (rather than just using pairwise totals), is not monotonic, etc. See A.6.5 14. CONSIDER FINAL TIEBREAKER: Currently, the Project Leader can cast a final, 'casting' vote to break pairties. This is probably the right choice, but alternatives should be considered (random ballot?) . See A.6.6 15. RESOLVE SUPERMAJORITY PROBLEMS: Currently, supermajority requirements can only be met if the two-stage ballot process is used. It would be desireable to rewrite supermajority rules to allow competing options, perhaps having different majority requirements to be considered simultaneously in a single vote. See A.6.7 16. DISCUSS QUORUM REQUIREMENTS: The existing quorum requirements are probably OK, but this should be discussed. It is likely the quorum rules will need to be rewritten to accomodate a new pairwise method. Also, in A.6, the quorum requirement should perhaps be listed first, rather than last, since it is normally impossible to consider motions if quorum isn't met. Therefore, it is logical to check for that first. See A.6.8 17. 3:1 SUPERMAJORITY EXCESSIVELY HIGH: Mike Ossipoff writes: "3:1 sounds like an awfully difficult supermajority. It does seem that it could cause dissatisfaction if it prevents 74% of the members from being able to change the Constitution. But maybe changing the supermajority requirement would be too controversial to include in the overall proposal." * The current members of the committee are: Anthony Towns, [EMAIL PROTECTED] (Debian developer) Buddha Buck, [EMAIL PROTECTED] (Debian user) Mike Ossipoff, [EMAIL PROTECTED] (EM List) Norman Petry, [EMAIL PROTECTED] (EM List, Debian user) Rob Lanphier, [EMAIL PROTECTED] (EM List) Steve Greenland, [EMAIL PROTECTED] (Debian developer) If you are interested in participating in the work of this committee, please write to me and I will add your name to our list of members. However, if you do NOT share the goals of the committee, or have only a mild interest in voting systems, please do NOT join. We need a fairly small group which shares common goals if we are to come up with a coherent proposal in a reasonable time-frame. All of the committee's e-mail correspondence, together with our final report and recommendations will be offered to Debian once the proposal is complete. Therefore, you may instead want to wait until the committee's work is done, and th
Re: Debian-EM Joint Committee
Raul Miller wrote: >On Mon, Dec 18, 2000 at 03:41:21PM -0600, Norman Petry wrote: >> ... we have formed a joint committee to develop a proposal, which we >> will probably present to Debian for internal discussion in about a >> month's time (I'm just guessing on the timeframe; we haven't discussed >> this). > >This looks pretty good, overall. A month is an awful long time for us >to wait, however -- we're already a couple levels down in indirection, >postponing one issue to handle another. > Please don't postpone important decisions waiting for the results of this committee work! I don't see anything in the existing constitution that is an insurmountable obstacle to making important decisions *now*. The current rules have always worked fine in the past (and they're still vastly better than what most organisations have to work with). Sure, there is a remote chance that you'd hit one of the 'bugs' we've found in those rules, but I think the likelihood of that happening within the next few months is very remote. With regard to the committee's proposal, I'd prefer to carry out a thorough review, and come up with a really good recommendation. For this to happen the committee members need to spend whatever time is required to get things *right*, without worrying about the possibility that we might be delaying internal decisions. In fact, the reason we waited so long in putting together this committee is because we wanted to see the 'remove non-free' issue resolved *under the existing rules* before suggesting constitutional fixes. Steve Greenland, Mike Ossipoff, Rob Lanphier and I actually talked about forming this committee back in June, but postponed the work because we were concerned that the non-free issue and our proposal for a constitutional amendment would become entangled in the minds of voters. The two are completely unrelated, and we wanted the developers to be able to consider the constitutional issues dispassionately, and not suspect ulterior motives in the proposed changes. Unfortunately, those decisions never got made, and all the recent discussion of voting systems on debian-vote forced us to get moving on this. I *still* think it would be better for Debian to deal with its important internal issues now, and then deal with the constitutional issues in a careful, measured way later -- they're not short-term problems, and therefore DON'T require short-term solutions. >Is it possible to split your proposal into two pieces, so that we can >get around to modifying the constitution to explicitly state how to >deal with DFSG requirements a bit sooner? You've got some open-ended >questions in there, and not everything is relevant to the DFSG issue. > True. Some of the issues in that list are trivial, some are controversial, some are important. Some of the more controversial proposed changes will probably get tossed out by the committee in order to devise a more winnable proposal. It is also possible that more than one proposal will come out of the work of the committee. Oh, and I hope that *none* of what we'll be discussing is directly relevant to the dfsg issue. That's one of those urgent internal matters that's not related to the decision-making process, and therefore is outside the scope of the committee's work. I'd hope that the question of authority to amend the dfsg would be dealt with separately, now, under the existing rules (Isn't that what Manoj's and Branden's proposals are attempting to do?) >Also, while it's great that you have formed a separate group to keep the >traffic off of debian-vote (I'm kind of embarrassed about the volume I >had a part in), I think it would be very appropriate for you to keep us >updated (maybe once a week) about your progress: > This is a good idea. Now that you've joined this committee, perhaps you'd be interested in writing these status reports for debian-vote :) >[1] It would allow feedback from people who don't have time to get >heavily into the discussion, and > >[2] It would help keep the discussion live, so we don't have to worry >about official timeouts from lack of discussion. > I don't think 'official timeouts' apply at all to the work of this ad-hoc committee (which is not internal to Debian, or official in any way). Officially, discussion won't even *begin* until the work of our committee is complete, and our recommendations are sponsored by the required number of developers. Then, the *internal* process of discussion, amendment, counterproposals, flamewars, etc. will begin (or perhaps not) and you can begin watching for timeouts. -- Norm Petry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor this
Raul Miller wrote: >Drats. > >I guess that means I should either change the name (pull out smith) >or change the mechanism. Straw poll (mostly I'm interested in hearing >what people who have sponsored the proposal think): should I go for the >quick fix (change name from Smith/Condorcet to Condorcet, limit ballots >to less than five distinct options), or should I go for the real fix >(supplement step the new A.6(6) with smith criteria)? > This shows clearly why it is risky to invent new voting methods. They're hard to get right, so it is a good idea to adopt a method which is well studied, and has known properties. The problem isn't a shortage of good methods; if anything, there are too many of them. However, the number of bad methods out there is infinitely greater. Please work with us on the committee to choose a good method. The problem with voting systems is that there are an *infinite* number of possible systems. This whole area can become a morass to wade into, if you don't have a clearly defined set of properties that you'd like the method to satisfy. We discovered a long time ago on EM that the only way to have a rational discussion about the merits of one method over another was to define "criteria", which are precise yes/no tests of some property or other, and then see which methods pass or fail the criteria. Then, a method can be chosen by deciding what criteria are important, and picking the method which satisfies most of them. In the final report our committee will be making to debian, we will list the criteria the proposed method(s) satisfy, and why they may be important. This will give voters a set of guarantees that they can rely upon when voting and sponsoring motions. I think it is better if the method described in the constitution is defined in functional terms, rather than in the form of an algorithm. Not only is that form of description briefer and easier to understand, but it allows the bugs in the implementation to be fixed. If every bug in the algorithm used to implement the voting method requires a constitutional amendment to change, it's going to be a real PITA to maintain. For example, the Smith criterion can be unambiguously stated in one or two sentences. If you want to use Smith as a voting method, rather than just a criterion the method satisfies (which would be better, imho), if you define it in the constitution then a later discovery that your algorithm doesn't actually implement smith could easily be fixed. I wouldn't worry about implementation at this stage -- most pairwise methods require under 100 lines or so to implement, and there are algorithms that are already available for Smith* and Schwartz set calculations, as well as many complete methods. I have implemented a large number of these methods in Python (GPLed code) in order to carry out simulations of their properties, and these could easily be adapted to carry out the counting of future votes in an automated way. -- Norm Petry p.s. *As an aside, one way to implement Smith that was proposed on EM a long time ago is to begin by creating a list of (n) candidates. Find the candidate(s) with the fewest number of defeats, and place them at the beginning of the list, since they are guaranteed to be members of Smith. Then scan through the (n-1) candidates remaining, and if a candidate pairwise beats or ties any member of the current smith set, move it to the next position at the beginning of the list. Keep scanning through the remaining candidates until none of them beat or tie any member of the current smith set, and then you're done. Here's my Python implementation: def smithWinners(p): "Given a pairwise matrix, return the list of candidates in the Smith Set" # Based on Steve Eppley's elegant Smith set algorithm from EM 28AP96 candidates = len(p[0]) candidateList = range(candidates) minDefeats = candidates for row in range(candidates): defeats = 0 for col in range(candidates): if (p[row][col] < p[col][row]): defeats = defeats+1 if (defeats <= minDefeats): if (defeats < minDefeats): minDefeats = defeats smithSetSize = 0 candidateList[row] = candidateList[smithSetSize] candidateList[smithSetSize] = row smithSetSize = smithSetSize+1 c1 = 0 while (c1 < smithSetSize): row = candidateList[c1] for c2 in range(smithSetSize,candidates): col = candidateList[c2] if (p[row][col] <= p[col][row]): temp = candidateList[smithSetSize] candidateList[smithSetSize] = candidateList[c2] candidateList[c2] = temp smithSetSize = smithSetSize+1 c1 = c1+1 result = candidateList[0:smithSetSize] result.sort() return result However, you can see that writing out this algorithm in the Constitution is going to be a lot more cumbersome than simply defining what the Smith set *is* in one or two sentences. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An ammendment (Re: Formal CFV: General Resolution to Abolish Non-Free)
detail is made explicit. Whereas the current definition of the method merely states: A.6. Concorde Vote Counting This is used to determine the winner amongst a list of options. Each ballot paper gives a ranking of the voter's preferred options. (The ranking need not be complete.) This should probably be changed to something like: A.6. CONDORCET Vote Counting This is used to determine the winner amongst a list of options. Each ballot paper gives a ranking of the voter's preferred options. (The ranking need not be complete; UNRANKED OPTIONS WILL BE TREATED AS THOUGH THEY HAD BEEN RANKED EQUALLY LAST.) The tiebreaker specified in A.6.5 also needs some work, but I won't go into that now :-) I am not a Debian developer (merely a satisfied user), but would be pleased to assist with drafting an amendment that would address the minor problem identified above and clarify the use of the tiebreaker, etc. if anyone considers it worth the effort. In any case, the Debian Project is to be commended for having chosen such an excellent system for making group decisions. For those of us on the EM list (http://www.eskimo.com/~robla/em/) who study these things, Condorcet's method is widely regarded as the best single-winner method available. We are very pleased that there is at least one organisation in the real world that's putting it to good use. Cheers, Norman Petry
Re: An ammendment (Re: Formal CFV: General Resolution to Abolish Non-Free)
Darren O. Benham wrote: >> >> Except that Chris Lawrence is mistaken as to how Condorcet's method is >> implemented within the Debian Project. Yesterday he wrote: >> >Chris is not mistaken. That's strange... in my post I gave an example from one of Debian's previous elections proving (I think) that all ranked options score a vote against each unranked option. I double-checked my initial result and cannot find any errors in my analysis, which suggests that one of the following must be true: 1) Debian's implementation has changed since the Vote 0002 ballots were counted, so the results no longer apply. 2) Debian's implementation of the Concorde method is not working as intended, or as you believe it to be working (although it does work as it should, imho) 3) I'm still overlooking something, and my analysis is wrong. Here's another example which shows why I think explicitly ranked options score a vote against each unranked candidate: Suppose we have 3 ballots: Option: ABC Voter #1 [1--] Voter #2 [-1-] Voter #3 [2-1] To determine which options are dominated, and by whom, we can construct a 'pairwise matrix' such that P(row,col) contains the total number of votes for the 'row' option against the 'col' option. If we assume that explicitly ranked options score one vote each against all unranked options, the pairwise matrix (P) looks like this: P A B C --- --- --- A | X | 2 | 1 | --- --- --- B | 1 | X | 1 | --- --- --- C | 1 | 1 | X | --- --- --- Note that there are a total of 7 votes in the pairwise matrix. If instead we assume that explicitly ranked candidates *do not* score votes against unranked candidates, then the pairwise matrix looks like this: P A B C --- --- --- A | X | 0 | 0 | --- --- --- B | 0 | X | 0 | --- --- --- C | 1 | 0 | X | --- --- --- C scores a single vote against A from ballot 3. The first 2 ballots yield no pairwise votes. In this case, there is a total of 1 pairwise vote in the matrix. If we now count the number of 1st, 2nd, and 3rd place rankings in the ballots, we get: A-B-C Total 1st preferences 1-1-13 2nd preferences 1-0-01 3rd preferences 0-0-00 no preference1-2-25 If explicitly ranked candidates *do* score votes against unranked candidates, the corresponding number of pairwise votes (in a 3-way contest) should equal: 2*total_1st_preferences + total_2nd_preferences = 2*3+1 = 7 votes -- check. If they do not, total pairwise votes will be somewhat less than that. Carrying out this check with one of Debian's actual elections, I found that the totals match, which can only mean that ranked candidates are scoring votes against unranked candidates (unless the implementation has changed since that time). Please note that this is a *desireable* outcome, in my opinion -- because people will commonly truncate a ranked ballot after ordering only a few of the more important choices, it is important that unranked choices are treated as though they had been ranked lower, otherwise unpopular/unimportant alternatives will gain an unintended advantage. It is not a flaw in the method or the implementation, but merely an unstated assumption that is apparently causing confusion, which is why I raised the matter after Chris had commented on it. If there is something I've overlooked which makes this conclusion incorrect, please let me know. Norm Petry p.s. Congratulations on the new baby! I'm sure you've got more pressing matters to deal with right now than voting methods trivia, so please reply at your leisure (you may not have any for the next few months, if what they say about newborn infants is true...)
'Concorde' Voting Method and Circular Ties
ations of our preferred methods in both Perl and Python that could probably be adapted to your existing system of vote-counting, if a constitutional amendment is approved. If you or any other Debian developers agree that this is a problem that should be fixed, please contact either me or Mike Ossipoff, and we will help you choose a suitable tiebreaker and develop the wording for a proposed constitutional amendment that would implement the changes. We have already discussed the matter amongst ourselves, and have selected one or two first-rate methods that we would recommend for Debian, as well as some simpler approaches that would probably also be adequate. It would probably be best if one or two interested Debian members discuss this matter with us privately, and help us develop a single, polished proposal that could then be taken back to Debian as a whole for consideration (to avoid boring everyone here with a subject that's probably not of much interest or direct relevance to the Debian project). Please let us know if you are interested in working on this. Sincerely, Norman Petry
Re: 'Concorde' Voting Method and Circular Ties
I just noticed that I made (at least) one error in my description of pairwise methods. I wrote: >Unfortunately, it would be very tedious/impractical to >hold a series of separate two-way elections between all the available >options, since the number of elections needed is equal to the square of the >number of options under consideration (10 options -> 100 elections). Of course, this is incorrect -- when there are n options, a total of n*(n-1)/2 pairwise elections are required. Not much point in having candidates run against themselves, or holding each election twice! Sorry about that. Norm Petry
RE: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)
Steve Greenland wrote: > I'm not sure it really makes any sense to have alternatives with > different majority requirements[1]. The recent case of an ammendment > that had an (arguably) different requirement than the original GR came > from two issues: I agree with you that supermajority requirements don't make much sense when using the 'Concorde' (Condorcet's) method. Usually, a supermajority requirement is used to prevent drastic flip-flops in the basic policies of an organisation. If an organisation is divided into two large factions with opposing views, standard 'winner-take-all' (plurality) voting will result in one group or the other becoming dominant, and changing everything their way. A shift of a few votes in a subsequent election can cause a dramatic reversal, and this can destabilise/destroy an organisation. However, Condorcet's method always allows a range of policy options to be considered (rather than just two), and it will *always* choose the best compromise. Therefore, provided a good compromise is proposed by someone, there should never be any radical changes in policy, merely gradual evolution. In this case, supermajority requirements simply undermine the democratic character of an organisation, by giving the supporters of the status quo much more political power than those who prefer change. That said, if you do want to maintain a supermajority requirement, the cleanest and most effective way of implementing it is to have voters cast their ballots normally, ranking the no change/status quo alternative (what you call FURTHER DISCUSSION) along with all the other options. However, for any proposal to actually win its pairwise contest against (dominate) the status quo, it must do so against 3-1 odds (or whatever). Therefore, to determine the winner, just multiply the votes for the status quo by 3 against every alternative before comparing. For example, suppose we have the following pair of vote totals: Proposal X: 55 Further Discussion: 20 Then Further Discussion will win this particular pairing if there is a supermajority requirement of 3:1, since 20*3 > 55. For Proposal X to win overall, it must therefore achieve a 3:1 supermajority against the status quo, and a simple majority against all other alternatives. The same is true for any other proposal, of course. > 1. Confusion about whether the constitution even allowed modification of the > document in question. > > 2. An "ammendment" that was basically a refutation of the original GR. > > Manoj and Branden are trying to resolve #1, and a little more care in > the GRs and ammendments we propose and second will solve #2. > > Or perhaps the best answer is to require seperate votes on such issues > (modifications of the Constitution and other issues that require > super-majorities: Obviously, votes on general resolutions (which require a simple majority) cannot be combined with constitutional amendments that require a supermajority, since the different majority requirements make it impossible to compare them. This is true even if they both address the same issues in different ways. If a constitutional amendment is proposed, the Secretary should require any other counter-proposals or amendments to *also* be worded as constitutional amendments, or else rule them out of order. Of course, if these counter-proposals do not require constitutional changes, they can be proposed later as ordinary GRs (in which case other proposals which *also* don't require a constitutional amendment could be considered). Opponents of the constitutional amendment(s) who think the matter should be addressed through a GR should simply vote for Further Discussion, of course. > 1. First vote to determine what combination of GR+ammendment(s) will be > considered (using a simple Condorcet winner). > > 2. Vote on whether to accept the final proposal. Since this is a simple > yes/no, determining a super-majority is trivial. I've noticed that there is a tendency among participants on debian-vote to propose solutions which 'serialise' decision-making, rather than using using the existing mechanisms. I think this is a result of people's experience with organisations which use Robert's Rules of Order. For example, when John Goertzen proposed his GR to amend the DSC, an 'amendment' to his GR was proposed that eliminated the entire text of the original resolution, and replaced it with what was described by its proponents as a compromise. Under Robert's rules, this *would* normally be implemented as an amendment, since it is only possible to choose between two alternatives at a time (yes/no) using a simple majority vote. Those who are hostile to the main motion, but fear that it might be preferred by a majority to the status quo will therefore propose a compromise amendment, leading to a series of votes: 1. Amendment - YES/NO 2. Main Motion - YES/NO This is the only way under Robert's Rules that a group *can* choose from among three alternatives (Amended Ma
RE: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)
Buddha Buck wrote:
> The Smith Set is defined as the smallest set of options that are not
> defeated by any option outside the Smith Set.
This definition of the Smith set is incorrect. Suppose we have:
A>B, B>C, A=C, A>D, B>D, C>D. ('>' means 'dominates', or beats pairwise)
Then by your definition, the Smith set would consist of only {A}, whereas in
fact the Smith set contains three members: {A,B,C}. In other words, any
candidate which is tied with a member of the Smith set is also a member of
that set. The corrected definition would be something like:
"The Smith Set is defined as the smallest set of options that defeat
('dominate') all options outside the set."
I mention this, because a number of messages posted recently to debian-vote
contain this subtle error, and if an incorrect definition was used in a
constitutional amendment, it could affect the interpretation of results in
certain elections. Your incorrect definition has a name, too -- it's called
the 'Schwartz Set'. In large-scale public elections, where pairties are
very rare, the Smith and Schwartz sets are the same. However, for committee
voting, or decisions made by other small groups (like Debian), pairties can
easily occur during vote counting. In the above example, if the winners are
restricted to being members of the Schwartz set, then there is a single
winner; if the Smith set is used, then a tiebreaker procedure (STV?) would
need to be invoked to determine the winner, which might not be A.
Note that I am *NOT* saying the Schwartz set is preferable to Smith, or that
either one should necessarily be used as part of any voting procedure Debian
might adopt (I'd recommend against it, in fact -- it is better to just use a
method which satisfies the Smith criterion, than use Smith as a method).
I'm merely pointing out how easy it is to make mistakes like this, so it is
important to word any proposed constitutional amendments *very* carefully.
--
Norm Petry
RE: Constitutional voting, definition of cummulative prefererence
Raul Miller wrote:
> I would like to know if anyone have a specific problem with the following
> concept of cumulative preference:
>
> An individual ballot prefers option A to option B, if:
>
> (*) Option A is mentioned at some preference, and option B is not
> mentioned at all, or
> (*) Option A is mentioned at a lower cannonical preference number than
> option B. [For example: 1st is a lower cannonical number than
> 5th, so a ballot which rated option A as its 1st preference and
> option B as its 5th preference would prefer option A to option B.]
>
This is a clear definition of 'prefers', which is better than the existing
constitutional wording in that it indicates how truncated ballots should be
handled. Clarifying this is a good idea if the constitution is amended, and
your interpretation is the same as the one that Debian is currently using,
based on my analysis of previous voting results. Treating unranked
candidates the same as if they had been ranked equally in last place is also
the assumption we always make on the Election-Methods list. It is always
desireable to assume this meaning with pairwise methods, otherwise a voter
who truncates will not effectively indicate any preference between his
ranked and unranked choices, and this will have unintended results. For
example, it would be generally unreasonable to assume that if someone votes:
A>B>C
out of five candidates {A,B,C,D,E}
that s/he actually considers E to be as good as A, yet that's how this vote
will be treated if the method doesn't assume the ranked candidates are
preferred to unranked! In other words, interpreting this ballot to mean:
A>B>C>(D=E)
would be sensible; interpreting it as:
A>B>C, (A=D=E), (B=D=E), (C=D=E)
would not. This would have no effect in a method like STV, but for pairwise
methods it is a critical issue. Fortunately, it appears that Debian has
been handling this correctly all along.
One point though -- I recommend that you avoid reference to numerical
rankings in the constitutional wording. So long as ballots are submitted by
e-mail, it may make sense for voters to number the options. In the future,
however, you might use a web interface or some other technique for ordering
candidates in which the options don't even have visible numbers, but are
ordered graphically, with preferred options at the top, and disliked options
at the bottom. If Debian is saddled with restrictive language that requires
preferences to be numbered, the constitution might need to be changed again
to accommodate the different method(s) of expressing a ranking (or
nitpickers might challenge results, etc.). I think it would be better to
just use general terms like 'ranked higher' and 'ranked lower', and leave
the specifics to an ordinary voters' guide, rather than embed these details
in the constitution.
> A set of ballots cumulatively prefers option A to option B if:
>
> * more individual ballots individually prefer option A to option B than
> prefer option B to option A, or
> * There is an option C, where A is cumulatively preferred to option C,
> and option C is cumulatively preferred to option B.
>
I am not exactly sure why you are defining 'cumulatively preferred' to
indicate transitive majority preference between options, so I can't say for
certain whether or not this is a good idea, because I don't know what you
intend to use it for. However:
1) Almost all pairwise methods deal exclusively with whether one option A is
preferred/beats/defeats/dominates another, but this is a simple option-pair
comparison that does not imply any sort of transitivity. To define most
pairwise methods, it is important to precisely define this simple
relationship and label it; Debian's existing term, 'dominates' is as good as
any.
2) The term 'cumulative' implies an additive rather than transitive
relationship, so it would probably be better to say 'transitively preferred'
rather than cumulatively preferred. Another reason to avoid the term
'cumulative' is that it is frequently used in connection with an inferior
multi-winner voting method called 'cumulative voting', in which each voter
gets an equal parcel of votes (usually 3 or so), and allocates these as they
desire among the candidates (3 on one candidate, 1 each on 3 candidates,
etc.) Using this term in connection with pairwise voting may result in
confusion if voters are familiar with the cumulative voting method, and
think this has something to do with Debian's count rules.
3) It is not necessary to define 'cumulatively preferred' unless it is used
as part of a voting method definition, and I'd need to see the whole method
in order to judge the merits of your system. I am aware of only one (truly
excellent) pairwise method which makes use of a similar concept called
'beatpaths', that may interest you. One possible definition of Schulze's
beatpath method is as follows:
*
Schulze's Method (brief definition):
Candidate A "beats" candidate B if more voters rank A over B
Re: Constitutional voting, definition of cummulative prefererence
Raul Miller wrote: > >Hmm.. the constitution already states that votes are cast by email. >[Which makes a lot of sense, when you think about the technologies >involved -- email queues, web doesn't, and signing of email is a well >established technology.] And, personally, I'm not comfortable with >"ranked higher" as a circumlocation. But it's an interesting point >you raise. I agree that right now, the best way to collect ballots is to use an e-mail interface. However, amending the constitution requires major effort, so it seems better to me to have terms and procedures defined with as much generality as possible, while still remaining clear and unambiguous, in order to minimise the need for future changes. However, if an e-mail ballot procedure is described in the Constitution as the only way to carry out balloting, then this would also need to be changed for a more general wording to be worthwhile -- I hadn't noticed that. >> I am not exactly sure why you are defining 'cumulatively preferred' to >> indicate transitive majority preference between options, so I can't say for >> certain whether or not this is a good idea, because I don't know what you >> intend to use it for. > >I'm aiming for a "minimal change" fix for the apparent ambiguity of the >current constitution. I'm thinking about proposing an amendment to the >constitution where "Dominates" is defined as strict cumulative preference >(A is cumulatively prefered to B and B is not cumulatively prefered to A). > The only ambiguity I see with the current constitution is that it cannot cope with circular ties. Fortunately, these are rare, so this has never been an issue for Debian (all previous elections have had a Condorcet winner). One thing I do as part of my involvement in the EM list is to carry out simulation studies of voting methods, and these suggest that circular ties will occur naturally about 5% of the time, so this isn't that big an issue. It's a minor bug which could result in some embarrassment and confusion at some point, but it is not likely to affect anything in the short run. A minimal fix for this problem is to replace A.6.3 with A.6.4, and then create a new A.6.4 which uses the Smith set to restrict the group of potential winners that are then subjected to the STV count rule (or for something even simpler, just leave it out entirely, in which case *all* the candidates would be selected from using STV, if there is no Condorcet winner). This doesn't address the issue of mixing options with different supermajority requirements, but I think Debian's existing rules can unambiguously cope with that -- they're sub-optimal, but serviceable. I don't see anything wrong with the quota requirements as they're written. [...] >> 3) It is not necessary to define 'cumulatively preferred' unless it is >> used as part of a voting method definition, and I'd need to see the >> whole method in order to judge the merits of your system. > >As I indicated above, I'm considering the implications of explicitly >specifying that an option "Dominates" another only where the first >option is transitively preferred to the second, but the second is not >transitively preferred to the first. > >[I'm aware that there are many alternate voting methods. But, I think >we need to at least consider options based on the "don't fix what >ain't broke" approach. If we completely rewrite large sections of the >constitution we may create future problems which we won't notice for a >year or two.] I disagree with this approach. If you redefine the underlying concepts used in pairwise voting, you may be able to make minimal wording changes yet create profound changes in voting results. On the other hand, major changes in wording can have little or no effect on outcomes. Consider: The existing 'Concorde' voting rule is a pairwise method which satisfies the Condorcet Winner criterion. The Schulze method (as well as almost all other pairwise methods) also satisfy this criterion, and since there is a Condorcet winner about 95% of the time, all these methods will agree on results to the same degree. Therefore, a change to Schulze would eliminate the ambiguity without having any noticeable effect on outcomes (except in the remaining 5% of cases, where Schulze would yield a winner, and Concorde would leave people scratching their heads). However, if you redefine the pair-comparison relationship to mean something else, this could profoundly affect results in *all* cases, not just when there are circular ties -- your new method might not even satisfy the Condorcet criterion, and all of its other properties would be completely unknown. This *would* be a major, and probably undesireable change. It seems to me, given that: 1) Amending the constitution is a major undertaking, and 2) There is no urgent need for constitutional change it is better to look at all the issues related to voting closely and carefully, pick the *best* solutions after thorough discussion
Debian-EM Joint Committee
orce serialised decisionmaking, by preventing alternate proposals from appearing on the same ballot. If this loophole is exploited, it transforms even the best pairwise method into nothing more than Roberts Rules (perhaps not even that). Sponsors should *not* have this power, since it can prevent developers from reliably choosing the best compromise proposals, and slows down decisionmaking. See A.2.2 9. PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY: Currently ,the Secretary or his stand-in (chair of technical committee) can kill any motion by not distributing ballots to voters within the 4-week interval prior to automatic expiry (yes, this has happened). Should the secretary have this power, or should it be restricted in some way? See A.5 10. STATE INTERPRETATION OF TRUNCATED BALLOTS: The constitution currently allows voters to truncate their ballot, ie: leave some options unranked. However, it does not specify how these unranked options are to be interpreted. Based on my analysis of previous results, it appears that Debian is using the correct interpretation (all unranked candidates are treated as though they had been ranked equally last), but this is unspecified. This interpretation should be clearly stated, since even the project secretary was not aware that this was how truncated ballots were counted. See A.6.1 11. EXPLICITLY ALLOW EQUAL RANKINGS: The constitution does not specify whether or not voters can assign the same ranking to more than one candidate. Since doing so causes no problems with interpretation or vote counting when a pairwise method is used, this should be explicitly permitted. See A.6.1 12. RESOLVE CIRCULAR TIE PROBLEM: The Concorde voting method is indecisive when confronted with a circular tie. As the rules are currently written, the specified tiebreaker (A.6.5) is ineffective, because A.6.3 eliminates all candidates. A more effective pairwise method, and more carefully written definition should be adopted to resolve this problem. 13. SIMPLIFY AND IMPROVE TIEBREAKER: The current voting method uses STV as a tiebreaker to choose a single winner when the pairwise method fails to choose a single winner. Due to A.6.3, this tiebreaker will only resolve pairties (not circular ones), so its usefulness is very limited. A much simpler, more effective tiebreaker could be adopted, which would add important strategy-free guarantees, clone independence, etc. for cases where there is no Condorcet winner. STV is undesireable because it is needlessly complex, requires ballots to be recounted (rather than just using pairwise totals), is not monotonic, etc. See A.6.5 14. CONSIDER FINAL TIEBREAKER: Currently, the Project Leader can cast a final, 'casting' vote to break pairties. This is probably the right choice, but alternatives should be considered (random ballot?) . See A.6.6 15. RESOLVE SUPERMAJORITY PROBLEMS: Currently, supermajority requirements can only be met if the two-stage ballot process is used. It would be desireable to rewrite supermajority rules to allow competing options, perhaps having different majority requirements to be considered simultaneously in a single vote. See A.6.7 16. DISCUSS QUORUM REQUIREMENTS: The existing quorum requirements are probably OK, but this should be discussed. It is likely the quorum rules will need to be rewritten to accomodate a new pairwise method. Also, in A.6, the quorum requirement should perhaps be listed first, rather than last, since it is normally impossible to consider motions if quorum isn't met. Therefore, it is logical to check for that first. See A.6.8 17. 3:1 SUPERMAJORITY EXCESSIVELY HIGH: Mike Ossipoff writes: "3:1 sounds like an awfully difficult supermajority. It does seem that it could cause dissatisfaction if it prevents 74% of the members from being able to change the Constitution. But maybe changing the supermajority requirement would be too controversial to include in the overall proposal." * The current members of the committee are: Anthony Towns, aj@azure.humbug.org.au (Debian developer) Buddha Buck, [EMAIL PROTECTED] (Debian user) Mike Ossipoff, [EMAIL PROTECTED] (EM List) Norman Petry, [EMAIL PROTECTED] (EM List, Debian user) Rob Lanphier, [EMAIL PROTECTED] (EM List) Steve Greenland, [EMAIL PROTECTED] (Debian developer) If you are interested in participating in the work of this committee, please write to me and I will add your name to our list of members. However, if you do NOT share the goals of the committee, or have only a mild interest in voting systems, please do NOT join. We need a fairly small group which shares common goals if we are to come up with a coherent proposal in a reasonable time-frame. All of the committee's e-mail correspondence, together with our final report and recommendations will be offered to Debian once the proposal is complete. Therefore, you may instead want to wait until the committee's work is done, and th
Re: Debian-EM Joint Committee
Raul Miller wrote: >On Mon, Dec 18, 2000 at 03:41:21PM -0600, Norman Petry wrote: >> ... we have formed a joint committee to develop a proposal, which we >> will probably present to Debian for internal discussion in about a >> month's time (I'm just guessing on the timeframe; we haven't discussed >> this). > >This looks pretty good, overall. A month is an awful long time for us >to wait, however -- we're already a couple levels down in indirection, >postponing one issue to handle another. > Please don't postpone important decisions waiting for the results of this committee work! I don't see anything in the existing constitution that is an insurmountable obstacle to making important decisions *now*. The current rules have always worked fine in the past (and they're still vastly better than what most organisations have to work with). Sure, there is a remote chance that you'd hit one of the 'bugs' we've found in those rules, but I think the likelihood of that happening within the next few months is very remote. With regard to the committee's proposal, I'd prefer to carry out a thorough review, and come up with a really good recommendation. For this to happen the committee members need to spend whatever time is required to get things *right*, without worrying about the possibility that we might be delaying internal decisions. In fact, the reason we waited so long in putting together this committee is because we wanted to see the 'remove non-free' issue resolved *under the existing rules* before suggesting constitutional fixes. Steve Greenland, Mike Ossipoff, Rob Lanphier and I actually talked about forming this committee back in June, but postponed the work because we were concerned that the non-free issue and our proposal for a constitutional amendment would become entangled in the minds of voters. The two are completely unrelated, and we wanted the developers to be able to consider the constitutional issues dispassionately, and not suspect ulterior motives in the proposed changes. Unfortunately, those decisions never got made, and all the recent discussion of voting systems on debian-vote forced us to get moving on this. I *still* think it would be better for Debian to deal with its important internal issues now, and then deal with the constitutional issues in a careful, measured way later -- they're not short-term problems, and therefore DON'T require short-term solutions. >Is it possible to split your proposal into two pieces, so that we can >get around to modifying the constitution to explicitly state how to >deal with DFSG requirements a bit sooner? You've got some open-ended >questions in there, and not everything is relevant to the DFSG issue. > True. Some of the issues in that list are trivial, some are controversial, some are important. Some of the more controversial proposed changes will probably get tossed out by the committee in order to devise a more winnable proposal. It is also possible that more than one proposal will come out of the work of the committee. Oh, and I hope that *none* of what we'll be discussing is directly relevant to the dfsg issue. That's one of those urgent internal matters that's not related to the decision-making process, and therefore is outside the scope of the committee's work. I'd hope that the question of authority to amend the dfsg would be dealt with separately, now, under the existing rules (Isn't that what Manoj's and Branden's proposals are attempting to do?) >Also, while it's great that you have formed a separate group to keep the >traffic off of debian-vote (I'm kind of embarrassed about the volume I >had a part in), I think it would be very appropriate for you to keep us >updated (maybe once a week) about your progress: > This is a good idea. Now that you've joined this committee, perhaps you'd be interested in writing these status reports for debian-vote :) >[1] It would allow feedback from people who don't have time to get >heavily into the discussion, and > >[2] It would help keep the discussion live, so we don't have to worry >about official timeouts from lack of discussion. > I don't think 'official timeouts' apply at all to the work of this ad-hoc committee (which is not internal to Debian, or official in any way). Officially, discussion won't even *begin* until the work of our committee is complete, and our recommendations are sponsored by the required number of developers. Then, the *internal* process of discussion, amendment, counterproposals, flamewars, etc. will begin (or perhaps not) and you can begin watching for timeouts. -- Norm Petry
Re: Sponsor this
Raul Miller wrote: >Drats. > >I guess that means I should either change the name (pull out smith) >or change the mechanism. Straw poll (mostly I'm interested in hearing >what people who have sponsored the proposal think): should I go for the >quick fix (change name from Smith/Condorcet to Condorcet, limit ballots >to less than five distinct options), or should I go for the real fix >(supplement step the new A.6(6) with smith criteria)? > This shows clearly why it is risky to invent new voting methods. They're hard to get right, so it is a good idea to adopt a method which is well studied, and has known properties. The problem isn't a shortage of good methods; if anything, there are too many of them. However, the number of bad methods out there is infinitely greater. Please work with us on the committee to choose a good method. The problem with voting systems is that there are an *infinite* number of possible systems. This whole area can become a morass to wade into, if you don't have a clearly defined set of properties that you'd like the method to satisfy. We discovered a long time ago on EM that the only way to have a rational discussion about the merits of one method over another was to define "criteria", which are precise yes/no tests of some property or other, and then see which methods pass or fail the criteria. Then, a method can be chosen by deciding what criteria are important, and picking the method which satisfies most of them. In the final report our committee will be making to debian, we will list the criteria the proposed method(s) satisfy, and why they may be important. This will give voters a set of guarantees that they can rely upon when voting and sponsoring motions. I think it is better if the method described in the constitution is defined in functional terms, rather than in the form of an algorithm. Not only is that form of description briefer and easier to understand, but it allows the bugs in the implementation to be fixed. If every bug in the algorithm used to implement the voting method requires a constitutional amendment to change, it's going to be a real PITA to maintain. For example, the Smith criterion can be unambiguously stated in one or two sentences. If you want to use Smith as a voting method, rather than just a criterion the method satisfies (which would be better, imho), if you define it in the constitution then a later discovery that your algorithm doesn't actually implement smith could easily be fixed. I wouldn't worry about implementation at this stage -- most pairwise methods require under 100 lines or so to implement, and there are algorithms that are already available for Smith* and Schwartz set calculations, as well as many complete methods. I have implemented a large number of these methods in Python (GPLed code) in order to carry out simulations of their properties, and these could easily be adapted to carry out the counting of future votes in an automated way. -- Norm Petry p.s. *As an aside, one way to implement Smith that was proposed on EM a long time ago is to begin by creating a list of (n) candidates. Find the candidate(s) with the fewest number of defeats, and place them at the beginning of the list, since they are guaranteed to be members of Smith. Then scan through the (n-1) candidates remaining, and if a candidate pairwise beats or ties any member of the current smith set, move it to the next position at the beginning of the list. Keep scanning through the remaining candidates until none of them beat or tie any member of the current smith set, and then you're done. Here's my Python implementation: def smithWinners(p): "Given a pairwise matrix, return the list of candidates in the Smith Set" # Based on Steve Eppley's elegant Smith set algorithm from EM 28AP96 candidates = len(p[0]) candidateList = range(candidates) minDefeats = candidates for row in range(candidates): defeats = 0 for col in range(candidates): if (p[row][col] < p[col][row]): defeats = defeats+1 if (defeats <= minDefeats): if (defeats < minDefeats): minDefeats = defeats smithSetSize = 0 candidateList[row] = candidateList[smithSetSize] candidateList[smithSetSize] = row smithSetSize = smithSetSize+1 c1 = 0 while (c1 < smithSetSize): row = candidateList[c1] for c2 in range(smithSetSize,candidates): col = candidateList[c2] if (p[row][col] <= p[col][row]): temp = candidateList[smithSetSize] candidateList[smithSetSize] = candidateList[c2] candidateList[c2] = temp smithSetSize = smithSetSize+1 c1 = c1+1 result = candidateList[0:smithSetSize] result.sort() return result However, you can see that writing out this algorithm in the Constitution is going to be a lot more cumbersome than simply defining what the Smith set *is* in one or two sentences.
Re: An ammendment (Re: Formal CFV: General Resolution to Abolish Non-Free)
detail is made explicit. Whereas the current definition of the method merely states: A.6. Concorde Vote Counting This is used to determine the winner amongst a list of options. Each ballot paper gives a ranking of the voter's preferred options. (The ranking need not be complete.) This should probably be changed to something like: A.6. CONDORCET Vote Counting This is used to determine the winner amongst a list of options. Each ballot paper gives a ranking of the voter's preferred options. (The ranking need not be complete; UNRANKED OPTIONS WILL BE TREATED AS THOUGH THEY HAD BEEN RANKED EQUALLY LAST.) The tiebreaker specified in A.6.5 also needs some work, but I won't go into that now :-) I am not a Debian developer (merely a satisfied user), but would be pleased to assist with drafting an amendment that would address the minor problem identified above and clarify the use of the tiebreaker, etc. if anyone considers it worth the effort. In any case, the Debian Project is to be commended for having chosen such an excellent system for making group decisions. For those of us on the EM list (http://www.eskimo.com/~robla/em/) who study these things, Condorcet's method is widely regarded as the best single-winner method available. We are very pleased that there is at least one organisation in the real world that's putting it to good use. Cheers, Norman Petry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An ammendment (Re: Formal CFV: General Resolution to Abolish Non-Free)
Darren O. Benham wrote: >> >> Except that Chris Lawrence is mistaken as to how Condorcet's method is >> implemented within the Debian Project. Yesterday he wrote: >> >Chris is not mistaken. That's strange... in my post I gave an example from one of Debian's previous elections proving (I think) that all ranked options score a vote against each unranked option. I double-checked my initial result and cannot find any errors in my analysis, which suggests that one of the following must be true: 1) Debian's implementation has changed since the Vote 0002 ballots were counted, so the results no longer apply. 2) Debian's implementation of the Concorde method is not working as intended, or as you believe it to be working (although it does work as it should, imho) 3) I'm still overlooking something, and my analysis is wrong. Here's another example which shows why I think explicitly ranked options score a vote against each unranked candidate: Suppose we have 3 ballots: Option: ABC Voter #1 [1--] Voter #2 [-1-] Voter #3 [2-1] To determine which options are dominated, and by whom, we can construct a 'pairwise matrix' such that P(row,col) contains the total number of votes for the 'row' option against the 'col' option. If we assume that explicitly ranked options score one vote each against all unranked options, the pairwise matrix (P) looks like this: P A B C --- --- --- A | X | 2 | 1 | --- --- --- B | 1 | X | 1 | --- --- --- C | 1 | 1 | X | --- --- --- Note that there are a total of 7 votes in the pairwise matrix. If instead we assume that explicitly ranked candidates *do not* score votes against unranked candidates, then the pairwise matrix looks like this: P A B C --- --- --- A | X | 0 | 0 | --- --- --- B | 0 | X | 0 | --- --- --- C | 1 | 0 | X | --- --- --- C scores a single vote against A from ballot 3. The first 2 ballots yield no pairwise votes. In this case, there is a total of 1 pairwise vote in the matrix. If we now count the number of 1st, 2nd, and 3rd place rankings in the ballots, we get: A-B-C Total 1st preferences 1-1-13 2nd preferences 1-0-01 3rd preferences 0-0-00 no preference1-2-25 If explicitly ranked candidates *do* score votes against unranked candidates, the corresponding number of pairwise votes (in a 3-way contest) should equal: 2*total_1st_preferences + total_2nd_preferences = 2*3+1 = 7 votes -- check. If they do not, total pairwise votes will be somewhat less than that. Carrying out this check with one of Debian's actual elections, I found that the totals match, which can only mean that ranked candidates are scoring votes against unranked candidates (unless the implementation has changed since that time). Please note that this is a *desireable* outcome, in my opinion -- because people will commonly truncate a ranked ballot after ordering only a few of the more important choices, it is important that unranked choices are treated as though they had been ranked lower, otherwise unpopular/unimportant alternatives will gain an unintended advantage. It is not a flaw in the method or the implementation, but merely an unstated assumption that is apparently causing confusion, which is why I raised the matter after Chris had commented on it. If there is something I've overlooked which makes this conclusion incorrect, please let me know. Norm Petry p.s. Congratulations on the new baby! I'm sure you've got more pressing matters to deal with right now than voting methods trivia, so please reply at your leisure (you may not have any for the next few months, if what they say about newborn infants is true...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
'Concorde' Voting Method and Circular Ties
ntations of our preferred methods in both Perl and Python that could probably be adapted to your existing system of vote-counting, if a constitutional amendment is approved. If you or any other Debian developers agree that this is a problem that should be fixed, please contact either me or Mike Ossipoff, and we will help you choose a suitable tiebreaker and develop the wording for a proposed constitutional amendment that would implement the changes. We have already discussed the matter amongst ourselves, and have selected one or two first-rate methods that we would recommend for Debian, as well as some simpler approaches that would probably also be adequate. It would probably be best if one or two interested Debian members discuss this matter with us privately, and help us develop a single, polished proposal that could then be taken back to Debian as a whole for consideration (to avoid boring everyone here with a subject that's probably not of much interest or direct relevance to the Debian project). Please let us know if you are interested in working on this. Sincerely, Norman Petry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 'Concorde' Voting Method and Circular Ties
I just noticed that I made (at least) one error in my description of pairwise methods. I wrote: >Unfortunately, it would be very tedious/impractical to >hold a series of separate two-way elections between all the available >options, since the number of elections needed is equal to the square of the >number of options under consideration (10 options -> 100 elections). Of course, this is incorrect -- when there are n options, a total of n*(n-1)/2 pairwise elections are required. Not much point in having candidates run against themselves, or holding each election twice! Sorry about that. Norm Petry -- 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)
Steve Greenland wrote: > I'm not sure it really makes any sense to have alternatives with > different majority requirements[1]. The recent case of an ammendment > that had an (arguably) different requirement than the original GR came > from two issues: I agree with you that supermajority requirements don't make much sense when using the 'Concorde' (Condorcet's) method. Usually, a supermajority requirement is used to prevent drastic flip-flops in the basic policies of an organisation. If an organisation is divided into two large factions with opposing views, standard 'winner-take-all' (plurality) voting will result in one group or the other becoming dominant, and changing everything their way. A shift of a few votes in a subsequent election can cause a dramatic reversal, and this can destabilise/destroy an organisation. However, Condorcet's method always allows a range of policy options to be considered (rather than just two), and it will *always* choose the best compromise. Therefore, provided a good compromise is proposed by someone, there should never be any radical changes in policy, merely gradual evolution. In this case, supermajority requirements simply undermine the democratic character of an organisation, by giving the supporters of the status quo much more political power than those who prefer change. That said, if you do want to maintain a supermajority requirement, the cleanest and most effective way of implementing it is to have voters cast their ballots normally, ranking the no change/status quo alternative (what you call FURTHER DISCUSSION) along with all the other options. However, for any proposal to actually win its pairwise contest against (dominate) the status quo, it must do so against 3-1 odds (or whatever). Therefore, to determine the winner, just multiply the votes for the status quo by 3 against every alternative before comparing. For example, suppose we have the following pair of vote totals: Proposal X: 55 Further Discussion: 20 Then Further Discussion will win this particular pairing if there is a supermajority requirement of 3:1, since 20*3 > 55. For Proposal X to win overall, it must therefore achieve a 3:1 supermajority against the status quo, and a simple majority against all other alternatives. The same is true for any other proposal, of course. > 1. Confusion about whether the constitution even allowed modification of the > document in question. > > 2. An "ammendment" that was basically a refutation of the original GR. > > Manoj and Branden are trying to resolve #1, and a little more care in > the GRs and ammendments we propose and second will solve #2. > > Or perhaps the best answer is to require seperate votes on such issues > (modifications of the Constitution and other issues that require > super-majorities: Obviously, votes on general resolutions (which require a simple majority) cannot be combined with constitutional amendments that require a supermajority, since the different majority requirements make it impossible to compare them. This is true even if they both address the same issues in different ways. If a constitutional amendment is proposed, the Secretary should require any other counter-proposals or amendments to *also* be worded as constitutional amendments, or else rule them out of order. Of course, if these counter-proposals do not require constitutional changes, they can be proposed later as ordinary GRs (in which case other proposals which *also* don't require a constitutional amendment could be considered). Opponents of the constitutional amendment(s) who think the matter should be addressed through a GR should simply vote for Further Discussion, of course. > 1. First vote to determine what combination of GR+ammendment(s) will be > considered (using a simple Condorcet winner). > > 2. Vote on whether to accept the final proposal. Since this is a simple > yes/no, determining a super-majority is trivial. I've noticed that there is a tendency among participants on debian-vote to propose solutions which 'serialise' decision-making, rather than using using the existing mechanisms. I think this is a result of people's experience with organisations which use Robert's Rules of Order. For example, when John Goertzen proposed his GR to amend the DSC, an 'amendment' to his GR was proposed that eliminated the entire text of the original resolution, and replaced it with what was described by its proponents as a compromise. Under Robert's rules, this *would* normally be implemented as an amendment, since it is only possible to choose between two alternatives at a time (yes/no) using a simple majority vote. Those who are hostile to the main motion, but fear that it might be preferred by a majority to the status quo will therefore propose a compromise amendment, leading to a series of votes: 1. Amendment - YES/NO 2. Main Motion - YES/NO This is the only way under Robert's Rules that a group *can* choose from among three alternatives (Amended M
RE: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)
Buddha Buck wrote:
> The Smith Set is defined as the smallest set of options that are not
> defeated by any option outside the Smith Set.
This definition of the Smith set is incorrect. Suppose we have:
A>B, B>C, A=C, A>D, B>D, C>D. ('>' means 'dominates', or beats pairwise)
Then by your definition, the Smith set would consist of only {A}, whereas in
fact the Smith set contains three members: {A,B,C}. In other words, any
candidate which is tied with a member of the Smith set is also a member of
that set. The corrected definition would be something like:
"The Smith Set is defined as the smallest set of options that defeat
('dominate') all options outside the set."
I mention this, because a number of messages posted recently to debian-vote
contain this subtle error, and if an incorrect definition was used in a
constitutional amendment, it could affect the interpretation of results in
certain elections. Your incorrect definition has a name, too -- it's called
the 'Schwartz Set'. In large-scale public elections, where pairties are
very rare, the Smith and Schwartz sets are the same. However, for committee
voting, or decisions made by other small groups (like Debian), pairties can
easily occur during vote counting. In the above example, if the winners are
restricted to being members of the Schwartz set, then there is a single
winner; if the Smith set is used, then a tiebreaker procedure (STV?) would
need to be invoked to determine the winner, which might not be A.
Note that I am *NOT* saying the Schwartz set is preferable to Smith, or that
either one should necessarily be used as part of any voting procedure Debian
might adopt (I'd recommend against it, in fact -- it is better to just use a
method which satisfies the Smith criterion, than use Smith as a method).
I'm merely pointing out how easy it is to make mistakes like this, so it is
important to word any proposed constitutional amendments *very* carefully.
--
Norm Petry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Constitutional voting, definition of cummulative prefererence
Raul Miller wrote:
> I would like to know if anyone have a specific problem with the following
> concept of cumulative preference:
>
> An individual ballot prefers option A to option B, if:
>
> (*) Option A is mentioned at some preference, and option B is not
> mentioned at all, or
> (*) Option A is mentioned at a lower cannonical preference number than
> option B. [For example: 1st is a lower cannonical number than
> 5th, so a ballot which rated option A as its 1st preference and
> option B as its 5th preference would prefer option A to option B.]
>
This is a clear definition of 'prefers', which is better than the existing
constitutional wording in that it indicates how truncated ballots should be
handled. Clarifying this is a good idea if the constitution is amended, and
your interpretation is the same as the one that Debian is currently using,
based on my analysis of previous voting results. Treating unranked
candidates the same as if they had been ranked equally in last place is also
the assumption we always make on the Election-Methods list. It is always
desireable to assume this meaning with pairwise methods, otherwise a voter
who truncates will not effectively indicate any preference between his
ranked and unranked choices, and this will have unintended results. For
example, it would be generally unreasonable to assume that if someone votes:
A>B>C
out of five candidates {A,B,C,D,E}
that s/he actually considers E to be as good as A, yet that's how this vote
will be treated if the method doesn't assume the ranked candidates are
preferred to unranked! In other words, interpreting this ballot to mean:
A>B>C>(D=E)
would be sensible; interpreting it as:
A>B>C, (A=D=E), (B=D=E), (C=D=E)
would not. This would have no effect in a method like STV, but for pairwise
methods it is a critical issue. Fortunately, it appears that Debian has
been handling this correctly all along.
One point though -- I recommend that you avoid reference to numerical
rankings in the constitutional wording. So long as ballots are submitted by
e-mail, it may make sense for voters to number the options. In the future,
however, you might use a web interface or some other technique for ordering
candidates in which the options don't even have visible numbers, but are
ordered graphically, with preferred options at the top, and disliked options
at the bottom. If Debian is saddled with restrictive language that requires
preferences to be numbered, the constitution might need to be changed again
to accommodate the different method(s) of expressing a ranking (or
nitpickers might challenge results, etc.). I think it would be better to
just use general terms like 'ranked higher' and 'ranked lower', and leave
the specifics to an ordinary voters' guide, rather than embed these details
in the constitution.
> A set of ballots cumulatively prefers option A to option B if:
>
> * more individual ballots individually prefer option A to option B than
> prefer option B to option A, or
> * There is an option C, where A is cumulatively preferred to option C,
> and option C is cumulatively preferred to option B.
>
I am not exactly sure why you are defining 'cumulatively preferred' to
indicate transitive majority preference between options, so I can't say for
certain whether or not this is a good idea, because I don't know what you
intend to use it for. However:
1) Almost all pairwise methods deal exclusively with whether one option A is
preferred/beats/defeats/dominates another, but this is a simple option-pair
comparison that does not imply any sort of transitivity. To define most
pairwise methods, it is important to precisely define this simple
relationship and label it; Debian's existing term, 'dominates' is as good as
any.
2) The term 'cumulative' implies an additive rather than transitive
relationship, so it would probably be better to say 'transitively preferred'
rather than cumulatively preferred. Another reason to avoid the term
'cumulative' is that it is frequently used in connection with an inferior
multi-winner voting method called 'cumulative voting', in which each voter
gets an equal parcel of votes (usually 3 or so), and allocates these as they
desire among the candidates (3 on one candidate, 1 each on 3 candidates,
etc.) Using this term in connection with pairwise voting may result in
confusion if voters are familiar with the cumulative voting method, and
think this has something to do with Debian's count rules.
3) It is not necessary to define 'cumulatively preferred' unless it is used
as part of a voting method definition, and I'd need to see the whole method
in order to judge the merits of your system. I am aware of only one (truly
excellent) pairwise method which makes use of a similar concept called
'beatpaths', that may interest you. One possible definition of Schulze's
beatpath method is as follows:
*
Schulze's Method (brief definition):
Candidate A "beats" candidate B if more voters rank A over B
Re: Constitutional voting, definition of cummulative prefererence
Raul Miller wrote: > >Hmm.. the constitution already states that votes are cast by email. >[Which makes a lot of sense, when you think about the technologies >involved -- email queues, web doesn't, and signing of email is a well >established technology.] And, personally, I'm not comfortable with >"ranked higher" as a circumlocation. But it's an interesting point >you raise. I agree that right now, the best way to collect ballots is to use an e-mail interface. However, amending the constitution requires major effort, so it seems better to me to have terms and procedures defined with as much generality as possible, while still remaining clear and unambiguous, in order to minimise the need for future changes. However, if an e-mail ballot procedure is described in the Constitution as the only way to carry out balloting, then this would also need to be changed for a more general wording to be worthwhile -- I hadn't noticed that. >> I am not exactly sure why you are defining 'cumulatively preferred' to >> indicate transitive majority preference between options, so I can't say for >> certain whether or not this is a good idea, because I don't know what you >> intend to use it for. > >I'm aiming for a "minimal change" fix for the apparent ambiguity of the >current constitution. I'm thinking about proposing an amendment to the >constitution where "Dominates" is defined as strict cumulative preference >(A is cumulatively prefered to B and B is not cumulatively prefered to A). > The only ambiguity I see with the current constitution is that it cannot cope with circular ties. Fortunately, these are rare, so this has never been an issue for Debian (all previous elections have had a Condorcet winner). One thing I do as part of my involvement in the EM list is to carry out simulation studies of voting methods, and these suggest that circular ties will occur naturally about 5% of the time, so this isn't that big an issue. It's a minor bug which could result in some embarrassment and confusion at some point, but it is not likely to affect anything in the short run. A minimal fix for this problem is to replace A.6.3 with A.6.4, and then create a new A.6.4 which uses the Smith set to restrict the group of potential winners that are then subjected to the STV count rule (or for something even simpler, just leave it out entirely, in which case *all* the candidates would be selected from using STV, if there is no Condorcet winner). This doesn't address the issue of mixing options with different supermajority requirements, but I think Debian's existing rules can unambiguously cope with that -- they're sub-optimal, but serviceable. I don't see anything wrong with the quota requirements as they're written. [...] >> 3) It is not necessary to define 'cumulatively preferred' unless it is >> used as part of a voting method definition, and I'd need to see the >> whole method in order to judge the merits of your system. > >As I indicated above, I'm considering the implications of explicitly >specifying that an option "Dominates" another only where the first >option is transitively preferred to the second, but the second is not >transitively preferred to the first. > >[I'm aware that there are many alternate voting methods. But, I think >we need to at least consider options based on the "don't fix what >ain't broke" approach. If we completely rewrite large sections of the >constitution we may create future problems which we won't notice for a >year or two.] I disagree with this approach. If you redefine the underlying concepts used in pairwise voting, you may be able to make minimal wording changes yet create profound changes in voting results. On the other hand, major changes in wording can have little or no effect on outcomes. Consider: The existing 'Concorde' voting rule is a pairwise method which satisfies the Condorcet Winner criterion. The Schulze method (as well as almost all other pairwise methods) also satisfy this criterion, and since there is a Condorcet winner about 95% of the time, all these methods will agree on results to the same degree. Therefore, a change to Schulze would eliminate the ambiguity without having any noticeable effect on outcomes (except in the remaining 5% of cases, where Schulze would yield a winner, and Concorde would leave people scratching their heads). However, if you redefine the pair-comparison relationship to mean something else, this could profoundly affect results in *all* cases, not just when there are circular ties -- your new method might not even satisfy the Condorcet criterion, and all of its other properties would be completely unknown. This *would* be a major, and probably undesireable change. It seems to me, given that: 1) Amending the constitution is a major undertaking, and 2) There is no urgent need for constitutional change it is better to look at all the issues related to voting closely and carefully, pick the *best* solutions after thorough discussion
