Debian-EM Joint Committee
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, aj@azure.humbug.org.au (Debian developer)
Buddha Buck, bmbuck@14850.com (Debian user)
Mike Ossipoff, nkklrp@hotmail.com (EM List)
Norman Petry, npetry@accesscomm.ca (EM List, Debian user)
Rob Lanphier, robla@eskimo.com (EM List)
Steve Greenland, stevegr@debian.org (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
Reply to: