Re: supermajority options
On Mon, Nov 25, 2002 at 02:42:17PM -0500, Branden Robinson wrote:
> 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).
When contrasted with a simple 1:1 majority requirement -- and that's been
our context in our previous messages -- I see no problem with calling 3:1
(or even 2:1) supermajority an approximation of unanimity.
You might argue that it's not a good enough of an approximation, but
I'll wait until I've seen your reasons for arguing that.
> > [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.
They do if the context is one where "protection of minorities" is
a significant issue.
> > 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".
Are you saying that supermajorities would cause debian to not function
as a group? Are you saying that supermajorities cause debian to not
function as a 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.
The purpose of the constitution was to formalize project leadership,
to keep our leaders from burning out.
The constitution was explicitly designed with debian as an elitist
group, with most responsibilities assigned to individuals (the package
maintainers) and with democracy as a fallback mechanism for when
everything else fails.
> > 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.
Huh? If the constitution didn't include a procedure for introducing
changes to itself I could follow this argument.
> 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.
Ultimately, we are relying on people. Not majority. Not supermajority.
Not documents. Not packages. Not committees. Etc. That doesn't
make these other concepts useless, however.
> > > 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.
My point was that there's more to our decision process than simple
majority. This ties back to our technocratic/elitist views [such as:
a small group of us are providing technical support for a large variety
of users].
If we were dealing with life and death issues or in some other way
were more significant, this elitism would be a bad thing. However,
most of what we deal with is of only passing interest for most people,
which means that most of the time we can only muster interest from a
small self-selected group of individuals.
> 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.
You've left out carelessness, inattention, focus on other issues and
so on.
> 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 never claimed that that flaw was unique to your proposal.
I do, however, claim that supermajority better insulates us from this
potential lack of interest.
> > Then it offers no protection to that minority of of people who do not
> > vote.
>
> And supermajoritarianism *does*?
Not in the general case of minority, no.
However, for the specific case of people that just want a system that
works and that they don't have to keep addressing: yes, it protects that
group whether or not they're a minority.
> 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.
And they must cast those ballots again and again?
Why do you want to have debian focus so much of its attention on
the constitution [as opposed to on technical issues]?
> 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.)
If you think this is an important discussion, feel free to start the
thread. If you're actually interested in the thinking that went into
the constitution, those threads are already archived.
> > 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
> point.
Only if you're unwilling to see the obvious: that our established
procedures are not democratic.
> > 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
> encourage;
> 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.
I'm going to interpret this as a blanket statement that you feel simple
majority is superior to all other decision making mechanisms in all cases.
In my opinion that's obviously false, but I'll let you tell me why that's
not what you're trying to say here.
> 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.
Apparently.
> 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
> besides.
Except that the McGann article that you've been using to justify your
position argues that the protection simple majority offers to minorities
which supermajority is because simple majority has the property of being
less stable.
> > > 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 don't find that an implausible position. While I ultimately didn't
vote that way there were times during the discussion where I felt I
couldn't trust some of the candidates as debian leaders.
> > > 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?
So?
> (As it happens, I don't think I did or do have any "followers" at all.)
Ok.
> > 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
> preference.
That's one issue, and that's one trick for attaining that end, yes.
> > > 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.
Which is a better, a floppy disk or a plate of mashed potatoes?
> > "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.
Given a series of elections, how many elections does a person have to
vote in to be a voter?
> > 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
> preferences*.
In other words, you don't feel that people should be able to take the
constitution as stable -- you feel that it's important for them all to
give up a chunk of the time they'd spend on their packages so that they
can participate in the wonderfully informative discussions on debian-vote.
> > 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.
People focus their attention on the unusual. For example, consider the
most likely causes of deaths and compare this to the news.
How many reports do you get from the users of your packages that
everything is working well? How many reports do you get from these users
that there are problems with the package? Do you think that you should
sacrifice what's working well to fix the bugs because there aren't many
users "participating in the process" who think things are working well?
--
Raul
Reply to: