[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sponsor this



On Tue, Dec 19, 2000 at 03:26:31PM +1000, Anthony Towns wrote:
> On Mon, Dec 18, 2000 at 04:19:52PM -0500, Raul Miller wrote:
> > [1] The current constitutional vote tallying mechanism is ambiguous about
> > what to do for circular ties
> 
> ...which tend not to come up, haven't so far, and require three or more
> options that are all fairly popular to be an issue.
> 
> > [2] The debian mechanism for handling supermajorities is unique.
> 
> ...however, there is a constitutionally compatible method that everyone
> (well, Raul and I, so everyone who said anything :) agrees is reasonably
> functional if awkward: first decide on a single proposal to make by
> simple majority; then have a second vote, and ensure Yes beats every
> other option by the necessary amount).
> 
> > [3] The debian balloting mechanism is ambiguous for final ballots
> > which are combined with amendment ballots.
> 
> ...which the secretary isn't obliged to do.
> 
> > While we're voting on fixing the balloting mechanism, let's use A.3(1)
> > and A.3(2) to vote.  In other words, we pick one choice and then have a
> > final ballot to decide if it's acceptable.  That will avoid the balloting
> > ambiguity, and is likely to avoid the vote tallying ambiguities.  And,
> > we hope that we don't run into a balloting ambiguity (about a 95% chance,
> > according to Norman Petry).
> 
> (I'd say a much higher chance considering Debian's biasses)
> 
> > Once we've got the voting system fixed, we can tackle the DFSG issue
> > (Manoj and Branden have some proposals to make).
> 
> And with all the above, I don't see any need to wait. It'd be nice to
> have all this non-free friction get actually resolved.
> 
> > I believe that Anthony agrees with this voting mechanism, except for
> > the handling of supermajority. 
> 
> I definitely disagree with the handling of supermajority.
> 
> I don't think the change to A.3(3) makes it any clearer at all: what's
> the difference between a "voting message" and a "ballot", since they're
> separated? If there is a different, what's the difference in the end
> process if I combine them in a "voting message" rather than a "ballot"?
> I'm fairly sure this wasn't in your earlier proposals, and I don't see
> why it was introduced now, either. So I disagree with that too.
> 
> I also don't understand the method you describe, and I've little idea
> what properties it has. Certainly, it meets the Condorcet criterion (well,
> ignoring quorum and supermajority of course), but it's not entirely clear
> that it satisifies the Smith criterion, in spite of it being called a
> "Condorcet/Smith" method. I don't think this is necessarily a bad thing,
> but it seems odd to choose a method that hasn't been studied when there
> are plenty of methods out there that *have* been studied.
> 
> The way it's described is also fairly complicated, and it's already been
> found to be buggy a couple of times. There also hasn't been any attempt
> to clean that up, or to analyse it and ensure it works how everyone
> thinks it works.

What about writing some kind of code that resolve the vote in some kind of
easy to prove language, and then do some program property proofs on it ?

Friendly,

Sven Luther



Reply to: