On Fri, Nov 22, 2002 at 03:49:46PM -0500, Raul Miller wrote: > > > [3] Is competence an issue? Why or why not? > > > > I'd say this is addressed by our NM system. > > Are you claiming that NM is our only criteria for determining relevant > competence on all issues? What do you propose? Isn't the scope of the discussion our voting system? Do you propose to limit suffrage within the Debian Project? > > > [4] Is involvement an issue? Why or why not? > > > > I'd say this is addressed either by quorum requirements, or by the > > simple self-selection process that compels people to vote at all. > > How about on issues we don't vote on? As above; isn't the scope of the discussion our voting system? > > Is it your suggestion that Debian should limit voting rights even > > further than we already have? > > "Majority rule" would tend to limit voting rights more than the current > "tyranny by supermajority" (I'm deliberately using the terms of that > paper). I'm not currently suggesting that we make this switch. I do not understand your assertion. How does majority rule limit voting rights? Your reasoning is not clear to me. > Or, to answer your question in the way you've phrased it: no, that's > not my suggestion. Okay. I don't understand how majority rule "limits voting rights". > > If not, I don't understand the point you are making. > > I'm trying to talk about the underlying assumptions and value judgements > which would lead to making an informed decision about supermajority. And I'm trying to talk about how those underlying assumptions may be neither true, nor actually supportive of the value judgements cited. > > If we're adopting the Condorcet method without being confident in its > > properties, then I suggest we hold our horses and not vote on adopting > > it without proper understanding. > > This is good advice. > > However, it's not "the condorcet method" whose properties are in question > here. For that matter, there are a variety of "condorcet methods". Sorry, I abbreviated excessively. Concorcet/CSSD. The "default option", quorums, and supermajorities are complications we have added ourselves. > I think a good place to start on this endeavor would be in establishing > a proper understanding of the issues we're making decisions about. Okay. I would expect this sort of statement to be followed with some development, but you provide none. > > This is quite apart from the supermajority/quorum business. What I'm > > asking is whether or not we agree that pure Condorcet with Cloneproof > > Schwartz Sequential Dropping is resistant to strategic voting. > > Why are you asking this? This has nothing to do with what I wrote, > nor is this question of yours particularly relevant to the paragraph I > was responding to. Here's that paragraph again: > > . . . Condorecet seems pretty resilient to insincere voting. for each method > . . . of counting Supermajorities, it has been shown to where it possible, in > . . . some cases almost trivial, for an insincere vote to change the result of > . . . an election. that appears to defeat the whole purpose of using Condorcet > . . . to begin with. > > Perhaps you thought I was only responding to the first seven words of > that paragraph? If that's what you thought, I could see why you're > asking about our confidence in Condorcet. 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 The problem with 2) is that we'll still have to cope with strategic/insincere voting, and for the issues that may be the most important. Some people may think this is a feature; I think it's a bug. 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). V: 1342 072dadd9a7a83453125635e4eb11c331 V: --12 a737083853e8ac5eb98d830d61c83775 V: 3142 057358b9c1964a5f34350f85c0662976 V: 1432 e0205714459e65d30f091e1a7c9969ab V: 1342 2e05b5f03c0a7ccc263a635c011061c8 V: --12 65f0c64fe0c39df0a5e7033ea9d98a89 V: 4312 521e038040e61ccceafba9b018ce96f6 V: --12 226b08d94919508c82f66fe20d8f954f V: 1432 2013ff7b4ae009076cb4c246db121293 V: --12 f2faaa3e6f1295fbf439c2e2a92545bb V: 1342 970babc3d4f893fc67c03aeec9691f7c V: 3412 975f4225b49be03918b7015aa730fd97 V: 4312 8b57dfb45d9e792aa91d2699da11d05d ...and so forth. We could solve this by dropping the none of the above option from the ballot and letting ourselves go leaderless for an additional nine weeks if we have a quorum requirement and fail to meet it (let the lack of turnout reflect a lack of confidence in the slate of candidates). > > > That said: Debian 3:1 supermajority is LESS OF A CONSTRAINT than a > > > requirement that a majority of the voting population agree. > > > > I don't follow. It's either equivalently constraining, in the sense > > that it can be expressed as a simple statement, or it's more > > constraining, in that the Project cannot take action on a proposal > > without a greater number of people being in agreement. > > With our current rules, and 2000 developers, 45 people can satisfy a > 3:1 supermajority requirement. With a "majority rule" system, you'd > have to have 1001. Eh? Where do you get that? A majority typically means a majority of the ballots cast, not a majority of the eligible voters. No one has proposed mandatory voting; such a proposal would be doomed to failure. We can't even get some developers to test their packages before uploading them, or convince them to not break binary compatiblity in shared libraries without bumping the shared object version; expecting them to fill out a tedious ballot and return it in a timely manner is certainly beyond the pale. > > Would a 1:3 minority requirement also be "LESS OF A CONSTRAINT"? If > > not, why not? > > Getting a small minority of interested people to agree unanimously (or > nearly unanimously) is not as hard as getting a majority of all voters > to be interested. I don't understand where you're getting "all voters" from. -- G. Branden Robinson | Debian GNU/Linux | "Bother," said Pooh, as he was branden@debian.org | assimilated by the Borg. http://people.debian.org/~branden/ |
Attachment:
pgp9Y_2Vc3s4y.pgp
Description: PGP signature