On Fri, Nov 22, 2002 at 10:16:37PM -0500, Raul Miller wrote: > 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? > > 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. 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? > 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. > > 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. > 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. 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". > > 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. > > 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. 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). 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. I'm willing to be persuaded that I'm mistaken. > 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. 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. > > 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. > > 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 -- G. Branden Robinson | When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. branden@debian.org | -- Robert Anton Wilson http://people.debian.org/~branden/ |
Attachment:
pgpnsDGtGBNM7.pgp
Description: PGP signature