Raul Miller wrote: >Well, no one has sponsored my proposal to amend the constitution. >And, no one has issued any other proposals to fix the ambiguities >of the constitution.
I thought I should mention now that some members of Debian, together with a few of us from the Election Methods (EM) list, are working on developing a comprehensive proposal to amend Debian's constitution, and developers may wish to see the results of our work before proceeding further. About two weeks ago, I invited a few people to form this committee and begin developing a proposal to address the flaws in the decision-making process. On December 8th, I wrote to Anthony Towns, stating that: "I did think carefully about what the best forum for this type of discussion would be. Debian-vote is where it is happening now, but I am very reluctant to have us (particularly non-developers) begin flooding that list with the technical minutiae of voting methods. I think it would really annoy the developers if: 1) they might be forced to unsubscribe from debian-vote because of all the EM related traffic. I think most people probably subscribe to that list to get announcements of votes, etc., and probably could care less about what they consider arcane trivia related to voting methods. 2) a bunch of outsiders from EM seem to be making decisions about what Debian's voting system should be. It's important to maintain a clear distinction between the development of this proposal, and Debian's internal consensus process. Proposals can come from anywhere (provided there is at least some internal support), but the final deliberation and decisionmaking must be made solely by developers. If the EM members start debating the proposals along with all of the developers on debian-vote, I am concerned that this distinction will be lost, and our participation will be resented." For these reasons, 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). ***** The goals of the committee are to: 1) Develop a *comprehensive* set of recommendations that address all the problems with decision-making process that we are able to identify in the current constitution. We will be looking at everything that relates to decision-making, and not merely the voting system in isolation (although the core of the proposed changes will deal with the voting system, of course). 2) The voting system that we will be recommending will be a pairwise method (as is Debian's current 'Concorde' voting method). Therefore, the character of the voting system will not change significantly. In almost all cases (> 90%), all pairwise methods choose the same winner, so there will be no radical changes in the types of _outcomes_ that would result from adopting our proposal (wording may be substantially changed, however). It is quite likely that the final recommendation will be for one of a few methods that have been extensively studied on EM, and therefore have well-known properties. ***** Our first task as a committee was for each member to review the constitution and develop a list of problems that we should discuss. We completed that task on Sunday, and are currently ordering our committee's agenda based on these issues. To give you some idea of the scope of the proposal we will be developing, I've included a list of the issues that are currently on the agenda. Note though, that not necessarily all of these will be dealt with in the final recommendations, and the comments below indicate one person's opinion as to why they think this is a problem -- these are NOT the opinions of the committee! Also, these are in no particular order: 1. SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY: The constitution always requires a 3:1 supermajority for amendment. Currently, Debian developers are choosing between two different ways of eliminating an ambiguity in the existing constitution. (the current debate is over whether or not developers have the authority to amend policies issued under 4.1.5). Unless one of the two proposed options receives a supermajority in the final vote, the ambiguity will remain. Suppose there is a 60:40 split among developers between the two options, and each side strongly opposes the other, and votes in the final ballot against the proposal that wins initially. Then, the ambiguity will remain no matter which alternative wins, which is highly undesireable. The constitution should be amended to allow a simple majority of developers to amend the constitution when all the proposals are intended to eliminate ambiguity. The authority to eliminate the 'default' option in these types of votes should rest with the secretary. In all other cases, there should always be *exactly one* status-quo (default) option. See 4.1.2, 7.1 2. ELIMINATE TWO-STAGE VOTING: The existing voting system requires a two-stage process consisting of an initial ballot showing all the options. A single winner is chosen from these options using Debian's pairwise count rule, and then a final ratification vote is taken, where the options are Yes/No/Further Discussion. This procedure is suboptimal in many ways: a) It does not appear that previous votes have actually followed this procedure, instead using a single round of ballots with no final ratification vote. An organisation should not have rules which are ignored. b) The ratification vote is unnecessary, since equally good results can be obtained using a single ballot. As it is, Debian's developers are reluctant to use the voting system as a means to resolve issues, and having a 2-stage process makes decisions needlessly cumbersome. There is provision for combining the initial and final votes on a single e-mail, but using this simplification requires developers to submit 1 ranked ballot and n ratification ballots, where n is the number of options on the initial ballot. c) Even if a ratification ballot is to be used, a simple yes/no ballot should be used. The 'No' and 'Further Discussion' options are equivalent in practice, so the final 3-way pairwise votes are another needless complication. See A.3.2, A.3.3 3. CLARIFY REPORTING REQUIREMENTS: The constitution requires the Project secretary to provide a list of 'all the votes cast'. This is ambiguous, since it could be argued that it refers either to pairwise totals, or to individual ballots. This requirement has not been systematically followed, since some previous elections did not report all the submitted ballots. It is however, a desireable practice, since it ensures transparency of the voting process and allows verification of outcomes by anyone. A further question is whether the ballots (if they should be revealed) should be anonymous, or have names beside them (or perhaps unique, private identifiers). These issues should be clarified. See 4.2.3 4. ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY: The Secretary has the authority to terminate the voting period when 'the outcome of a vote is no longer in doubt'. This authority is open to abuse, since the outcome of a vote is never in doubt unless there are ties. Therefore, technically the Secretary could terminate voting after only a handful of ballots had been submitted, at a point when the outcome would be the position favoured by the Secretary. Why does the Secretary have this power? The *minimum* voting period should be of fixed duration. Furthermore, changing of votes should be permitted until the voting period terminates, since this allows voters to move towards consensus positions more easily. See 4.2.3, A.3.4 5. CHOOSE NAME OF NEW VOTING METHOD: 'Concorde' voting is referred to at a few points within the constitution to refer to Debian's count procedure. Assuming the procedure is changed, should this name be retained? It is likely that no matter what basic method is chosen, Debian will have a unique variant, so it is perhaps appropriate to retain a unique name for their method. Did the 'Concorde' method come from somewhere else, or had the person who proposed the method been mistaken about the name, confusing 'Concorde' with 'Condorcet'? See 5.2.7, 6.1.7, A.6 6. CREATE GLOSSARY OF VOTING TERMS: The 'default option' should be defined and always specified as such wherever it is referred to. It would probably be desireable to add a glossary to the constitution to clearly define terms like 'default option', 'supermajority', 'is preferred', 'simple majority', 'beats', or any other technical terms related to the voting process that are used. See 5.2.6, 5.2.7, A.6, etc. (combine to eliminate redundancy). 7. TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS: Amendments and original proposals are treated differently, with different passing rules required for each. This complicates the decisionmaking process and the constitution significantly. These distinctions are a holdover from Robert's rules of order, and they are inappropriate when ranked ballots are used to choose a single winner from multiple options simultaneously. The concept of an 'amendment' is only appropriate in systems of serialised, yes/no decisionmaking. The procedures should be rewritten to treat all amendments as modified, competing proposals. The secretary should merge the text of the amendment with the proposal being amended, and offer both the original and the amended version to the voters as options. Define 'proposal' in glossary to explain this usage? See A.1.3, A.1.4, A.2.2, A.2.4, A.3.1, A.4 8. REQUIRE SIMULTANEOUS DECISIONS: The constitution currently allows the sponsors of a proposal to force 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 then participate in the INTERNAL discussion and debate that will follow over this and (presumably) competing proposals. As a member of the Election Methods list, and a non-developer, I hope to stay out of that internal discussion as much as possible! Again, please write to me if you'd like to join our committee. -- Norm Petry
