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

Re: supermajority options

On Mon, Nov 25, 2002 at 11:41:53AM -0500, Raul Miller wrote:
> On Sun, Nov 24, 2002 at 10:53:11PM -0500, Branden Robinson wrote:
> > I don't undertand what you're trying to tell me here.
> > Are you saying dropping supermajority handling from the proposed A.6
> > will sink the proposal, regardless of its other merits?
> That's not what I'm saying.
> [1] I'm saying that the proposed supermajority requirement in A.6
> approximates a requirement for near unanimous agreement when changing
> the our meta-rules (our rules about rules).

I think it is self-deluding that a 3:1 supermajority, let alone a 2:1
supermajority, is an accurate "approximation" of "unanimity".

If we have 1000 developers, this means up to 250 or 333 developers,
respectively, may be strongly opposed to a proposal, and yet it will be
passed anyway.

I say, call a spade a spade.  Supermajority requirements don't
approximate unanimity unless they are very high (I find myself in
basic agreement with Manoj's definition of 9:1 or better, though not his
desire to apply it to our voting system).

The types of supermajorities we have are basically mechanisms for
overriding the veto of one-fourth or one-third of the voters.

> [2] I'm saying that our constitution is an example of our meta-rules.

Okay.  The arguments in the McGann paper apply just as well to
"meta-rules" as they do to votes on what we shall have for lunch.  In
each application, the McGann paper describes the relative impact on the
minority, particularly when coalitions form, as may happen if similar
issues come to a vote time and again.  The degree of privilege afforded
to the victors is in proportionality to the weight of the issues being

So I don't really see why we should find it more desirable to privilege
a status quo minority over an activist minority when it comes to
meta-rules.  (I'm assuming that there is a group of neutral voters in
the middle.)

> However, these are not the most crucial issues in this context.

I agree.

> The crucial issue is that www.democ.uci.edu/democ/papers/McGann02.pdf
> presents what is for us a strawman argument.  McGann02.pdf argues that
> supermajority rule does not protect minorities as well as majority rule.
> But our reason for adopting supermajority rule was never "to protect
> minorities".

"Protecting minorities", once we've stripped that term of its ethnic
and/or sexual connotations, simply means "functioning democracy".

It was my understanding that the whole purpose of the Constitution was
to establish a democratic system for Debian, instead of vesting all
authority in a Project Leader.

> Our reason for adopting supermajority was to give us a stable system to
> rely on when making decisions.

And yet now we're finding that we need to make changes in it, even to
fix problems that can be objectively identified as flaws.  Seems we were
a bit hasty in pouring the cement.

Ultimately, I think we have to rely on people, not documents that can
only be changed with a 3:1 supermajority, to give us stability.

> > The Standard Resolution Procedure seems fairly formal to me.  It's
> > certainly codified.
> Certainly.  The issues themselves, however, are not codified.  Not until
> after we approve them through voting.

Okay, granted.  I guess I don't understand your point.  That we codify
no issue before its time strikes me as a feature, not a bug.  When a
proposed GR comes up for discussion, I think it's a good thing that
alternative proposals can battle for a spot on the ballot.  I think that
mechanism, combined with Condorcet/SSD holds tremendous potential for
damping the cyclic effect feared by supermajoritiarians.

Intuitively, it seems that a cycle would only occur if some people
"snuck through" a change via a GR, in which case we pay the price for
our inattentiveness and may have to rectify it, or if a GR has
consequences we didn't forsee, in which case it seems a good thing if we
can revisit the issue without having to muster a supermajority.

I'll further note that inattentive voters are going to cause problems
for any voting system (as inattentive developers cause problems in the
package quality department), not just one that abandons
supermajoritarianism, so that flaw is not unique to my proposal.

> > > > I do not understand your assertion.  How does majority rule limit voting
> > > > rights?  Your reasoning is not clear to me.
> > > 
> > > Majority rule, as described in that paper, refers to a majority of all
> > > people [as opposed to a majority of interested specialists].
> > 
> > No, it seems to me to be referring to a majority of all people who
> > bother to vote.
> Then it offers no protection to that minority of of people who do not
> vote.

And supermajoritarianism *does*?  The only argument that it would must
be unfalsifiable, unless we can construct polling and surveying
mechanisms that are A) accurate and B) achieve better participation that
the voting system itself, in which case I wonder why we don't just focus
our efforts on convincing people to vote.

I find "silent majority"-style arguments specious and unpersuasive.
Proof by assertion is no proof at all.  The "silent" majority must cast
its ballots just as the "activist" minority is expected to.

In a democracy, each voter has a voice, which must be exercised or it
will be ignored.

Now, if you suggest that Debian's model of governance is not well
described by the term "democratic", then I suggest we start a new
thread, probably on -project, in which you lay out your premises.  I'd
be quite interested to hear them.  (I don't argue that democracy is a
priori the best model of governance for Debian; just that it appears to
be the one we have under our Constitution.)

> > Clearly "majority rule" doesn't serve the population as a whole when the
> > only people empowered to vote are some sort of specialized cabal.
> In that sense, you could say that Debian is an elitist organization,
> since only developers get a vote -- debian users who haven't gone
> through the NM process are not entitled to vote.

Okay.  I'm not arguing that we alter the suffrage requirements for
Debian, so I'm really only interested in Developers/eligible voters as
the scope for the current argument.

...in which case, your arguments along these lines seem beside the

> > > I don't agree with your assumption that we're not clever enough to think
> > > of a way of introducing supermajority requirements without sacrificing
> > > an important property of CpSSD.
> > 
> > I wasn't making an assumption.  I said "If...we aren't clever enough".
> > Please do not distort my statements.
> I wasn't taking your "If...we aren't clever enough" statement in isolation
> -- I was taking it in context with other statements you've made about
> supermajority which were not expressed as conditional.

I'm being an advocate for a position, but it is not true that:

1) I've seen a proposal for supermajoritian Condorcet/CpSSD that isn't
   easily susceptible to strategic voting;
2) That I think strategic voting is a good thing, or something we should
3) That there are any properties of Condorcet/CpSSD that I am aware of
   which I value less than whatever benefits supermajoriatianism
   purportedly gives us.

So it may be the case that there are properties of Condorcet/CpSSD that
I consider important which you don't, and which you think are worthy of
exchange for a supermajority implementation.

My participation in this subthread arose because I think Condorcet/CpSSD
has very "cool" properties, if you will, and I don't perceive
supermajoritariansim as necessarily providing any more valuable
properties.  That is, I think Condorcet/CpSSD can give us the stability
that supermajoritarianism claims to, and a lot of other nice things

> > I find it implausible that as many people felt only one person was
> > sufficiently qualified to be Project Leader at all.  Some people who
> > ranked me first in the last election, for instance, voted this way, and
> > placed both Bdale and Rapha?l below the default option.
> This seems irrelevant to me:  They are not claiming that they
> felt only one person was sufficiently qualified to be Project Leader
> at all.

That's not what I meant.

> Instead, they were claiming that of those people on the ballot they
> felt only one was qualified.

Right.  I find that an implausible position for as many voters as voted
that way.

> > I'm fairly certain that not that many of my supporters felt I was the
> > *only* qualified candidate.  I don't think I command an unthinking,
> > uncritical horde of followers, and even if I did, I was on record as
> > saying that I felt both Bdale and Rapha?l were qualified for the job.
> > I think it is likely that voters figured out that this was how
> > best to assure their favorite candidate's chances of winning the
> > election (or forcing the election to be re-run, reopening the campaign
> > period as described in the Constitution).
> You seem to be suggesting that people who thought you were qualified
> should agree with you about the qualifications of other people?

I'm saying that if I had unthinking, uncritical, devoted followers, why
should they choose to break with me on that one issue?

(As it happens, I don't think I did or do have any "followers" at all.)

> > We could turn back to the 2000 DPL election, though, and ask people
> > point-blank why they voted the way they did, since the ballots were made
> > public and not anonymous.
> *blush* [mumble, yeah, my mistake]
> I would not object to you polling people and presenting the results of
> that poll.  I hope people's memories are accurate.

Even if they are, we can't be sure that their representations will be.
Some people might think that there is some sort of "taint" to insincere
voting.  In my opinion, there isn't.  Our voting system should be
resistant to insincere voting as a practical matter, not to protect
ourselves against "immoral" insincere voters.

Of course people want their vote to do as much good for their most
desired outcome as it can.  That's only natural.  The trick, as
Condorcet and others have explored, is to come up with a voting system
that doesn't put that goal in tension with a sincere expression of

> > Debian Developers aren't stupid.[1]  If they can discern a way to vote
> > strategically, they probably will.  After all, it is their self-interest
> > to do so, to raise a point Manoj made on debian-devel recently.
> Another way of looking at this is that real preferences are not the
> simple A is better than B expressions which we rely on in voting.
> The voting process introduces simplifications so that we have something
> we can act on.

What definition of "preference" would you say applies to "real
preferences"?  I always thought that, given two options A and B, I
either "preferred" A to B, B to A, or I had no preference.  With that
simple test, an arbitrarily complex ballot can be filled out.

> > While I don't think there is much we can do to avoid strategic voting in
> > the DPL election without giving up some attributes that we find more
> > valuable (such as the privacy of the ballots after they are cast), that
> > doesn't mean we shouldn't try to avoid it in our other votes.
> You are correct: that is not what this means.

I get the impression there is something you are leaving unstated here.

> > I cannot find support within the paper for your interpretation of
> > "majority", as the term is generally applied in the paper.
> "May (1952) shows that majority rule is the only positively responsive
> voting rule that satisfies anonymity (all voters are treated equally)
> and neutrality (all alternatives are treated equally)."
> The problem we're having here comes from the ambiguity of this kind of
> statement.  I was taking voters as "people who are eligible to vote in
> elections", you appear to be taking voters as "people who submit votes
> in a specific election".

That's right.  "Voters" are the people who vote, as opposed to "eligible
voters", who are people who are eligible to vote.

> We seem to have drawn the same conclusion [that majority rule doesn't
> protect people who don't vote], but we express this conclusion in
> different ways.

Supermajorities or no, I think the only minorities than can be protected
are those who actually vote.

I suggest that it is reckless to speculate about the preferences of
people who don't express their preferences, *especially* in the Debian
Project where we have no reliable surveying mechanisms (at least, none
that are actually in use).  As mails by Adam McKenna on debian-devel
suggested, opposing groups must either argue from principle, or hurl
anecdotes at each other.

...Or they can vote under the Debian Constituion and *express their

> Yes, I'm suggesting that low participation is an important design
> consideration for our overhaul of the voting mechanism.  And I'm saying
> that this was also a significant design consideration in the original
> design of our constitution.
> That's what Bdale was saying, too.

I think it is a big leap to go from "our Constitution was designed to
give us a decision process that would be robust in the face of
widespread inactivity" to "widespread inactivity indicates a mandate in
favor of the status quo".  I find this sort of argument a non sequitur,
and I believe I'm hearing a little bit of it from you and whole lot of
it from some other people.

Feel free to assuage my fears, though.

G. Branden Robinson                |    It's like I have a shotgun in my
Debian GNU/Linux                   |    mouth, I've got my finger on the
branden@debian.org                 |    trigger, and I like the taste of
http://people.debian.org/~branden/ |    the gunmetal. -- Robert Downey, Jr.

Attachment: pgp7J5x5imELw.pgp
Description: PGP signature

Reply to: