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 decided. 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 point. > > > 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 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. 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 besides. > > 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 preference. > > 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 preferences*. > 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