Re: supermajority options
On Fri, Nov 22, 2002 at 09:13:28PM -0500, Branden Robinson wrote:
> > > What do you propose? Isn't the scope of the discussion our voting
> > > system? Do you propose to limit suffrage within the Debian Project?
On Fri, Nov 22, 2002 at 10:16:37PM -0500, Raul Miller wrote:
> > At the moment, I'm proposing the implementation of supermajority which
> > Anthony Towns presented in his most recent proposal.
> >
> > This requires something approaching universal accord when changing
> > our meta-rules.
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).
[2] I'm saying that our constitution is an example of our meta-rules.
However, these are not the most crucial issues in this context.
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".
Our reason for adopting supermajority was to give us a stable system to
rely on when making decisions.
> > Issues which come to a vote result from our informal non-voting
> > procedures.
>
> 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.
> > > 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.
> > Or are you saying that you don't understand this?
>
> I guess so, since the scope of the paper is confined to those methods
> which rely on balloting to determine the desire of the group in
> question.
>
> 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.
> The paper seems to me to be implying general suffrage when talking about
> general social issues, but mainly confines its scope to those who
> actually vote. When it says "minority" in general, in means a group
> whose voted for an option that did not prevail in a ballot contest.
> Not, say, "black people".
Sure.
> > > If Condorcet/CSSD is resistant to strategic/insincere voting, and we
> > > aren't clever enough to think of a way of introducing supermajority
> > > requirements to the process without sacrificing an important property of
> > > Condorcet/CSSD, we have two choices:
> > >
> > > 1) drop supermajority requirements
> > > 2) use a differeng voting system for anything that requires a
> > > supermajority
> >
> > 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.
> > > We've already seen what is probably insincere voting in the DPL
> > > elections (a lot of people ranked the default option second, which means
> > > "my guy or nobody" -- I doubt any *two* of the candidates provoked that
> > > much antipathy).
> >
> > What's your reason for deciding that this is insincere?
>
> 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. Instead, they were claiming that of those people on the
ballot they felt only one was qualified.
> 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?
> 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.
> I'm willing to be persuaded that I'm mistaken.
As am I.
> > What's your reason for deciding that this is relevant to the supermajority
> > issue?
>
> 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.
> 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.
> > > Eh? Where do you get that? A majority typically means a majority of
> > > the ballots cast, not a majority of the eligible voters.
> >
> > In this context, I'm not talking about "typically". I'm talking about
> > a system which is based the arguments presented in the paper John
> > H. Robinson referred to.
>
> 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".
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.
> > > I don't understand where you're getting "all voters" from.
> >
> > I'm getting it from the repeatedly expressed argument that a majority's
> > views should take precedence over a minority's. That argument is moot
> > if you're using it to advocate a system which allows an active minority
> > to make decisions for the majority.
>
> We can lead the eligible voters to the polls; we can't force them to
> cast ballots. Given that constraint, I am content to let the majority
> of the people who actually vote determine the future of the Project even
> if voter turnout is so low that such people are technically a numerical
> minority of the eligible voters. It's common knowledge that we have a
> lot of inactive voters on our rolls, many of whom are also inactive
> Developers. Bdale Garbee called this fact a "red herring"[2] when I
> raised it in the last DPL campaign; do you suggest that it not only
> isn't one, but is a vitally important design consideration for our
> overhaul of the voting mechanism?
>
> [1] words that will come back to haunt me later, I'm sure </joke>
> [2] http://www.ringworld.org/~dieman/debian-debate.txt
Here's what you said:
|> Also, I disagree with Bdale that package quality is the only thing
|> that can suffer due to maintainer inactivity. It can also damage our
|> internal procedures by messing with our Standard Resolution Procedure.
|> I am just as concerned with preserving Debian's social structure as its
|> technical quality.
Here's what Bdale said:
|> I also think Branden's point about the SRP being degraded by inactive
|> maintainers is a red herring, as the drafters of our constitution went
|> to great lengths to ensure that the processes would work well in the
|> face of inactivity on the part of a great many of our participants.
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.
Thanks,
--
Raul
Reply to: