policy for membership in MOTU key teams

[Scott Kitterman]

On Wednesday 02 July 2008 18:31, Cody A.W. Somerville wrote:
> On Wed, Jul 2, 2008 at 5:29 PM, Scott Kitterman <ubuntu at kitterman.com>
>
> wrote:
> > On Wednesday 02 July 2008 07:29, Cody A.W. Somerville wrote:
> > > Hello,
>
> <snip>
>
> > > This is probably the toughest part to figure out: "How the voting
> > > works".
> >
> > ...  snip
> >
> > Actuall I think it's not.   There is a lot of research supporting  the
> > http://en.wikipedia.org/wiki/Condorcet_method and services that support
> > it.
> > It's a little complex in the theory, but actual voting is just ranking
> > your preferences.
> >
> > Scott K
>
> For those not familiar, the Condorcet method is the method used by Debian.
> Personally, I'm not overly familiar myself but I've attempted to do some
> research for the benefit of the crowd.
>
> What benefits does the Condorcet method provide over Single Transferable
> Vote? From what I see, both systems are preferential voting systems however
> the Condorcet method is exceedingly more complex than STV and is classed as
> a single member system (ie. engineered to elect one member) where STV is
> classified as a multi-member system. Although STV suffers from the issue of
> sequential exclusions (meaning that sometimes STV eliminates at an early
> stage in the count a candidate who might have gone on to be elected later
> had they been allowed to remain in the contest), there have been a number
> of recent refinements to STV such as CPO-STV and Sequential STV which solve
> the problem by incorporating elements of the Condorcet methods into STV.
> Alternatively, a method known as BTR-STV deals with the problem with a
> completely different (but exceedingly more simple than the other systems)
> solution by simply making sure no candidate could possible be eliminated.
> On the other hands, a neat feature of Condorcet is that it is possible for
> a candidate to be the most preferred *overall* without being the first
> preference of on any of the ballots yielding a compromise candidate whom
> the largest majority will find to be the least disagreeable even if not
> their top pick. This may or may not be desired (I'm not sure).

I think this is a very Ubuntu feature.  

In general, Condorcet methods are more resistant to strategic voting and will 
tend to produce a fairer result.  The only downside is the complexity, but I 
don't think it matters since we aren't going to figure it out by hand.

...snip

> I'll just stop here (lots on Wikipedia you can read though). So, why am I
> still leaning in favor of the Single Transferable Vote (or a refined
> version that sees that STV meets the monotonic criterion)? Because it is a
> *multi-member*, proportional representative, preferential electoral system
> and is *significantly simpler* then any of the Condorcet methods. Do we
> really care that Schwartz Sequential Dropping meets Condorcet loser, clone
> independence, reversal symmetry, polynomial time, and local independence of
> irrelevant alternatives criterion when it is so complicated that a lengthy
> manual is required to actual determine who is the winner not to mention
> further complex circular ambiguity resolutions using yet another voting
> system? Besides, according to Wikipedia, Condorcet methods are not
> currently in use in government elections anywhere in the world - although a
> Condorcet method known as Nanson's method was used in city elections in the
> U.S. town of Marquette, Michigan in the 1920s, and today Condorcet methods
> are used by a number of private organisations (Debian, Wikimedia
> Foundation, Gentoo Foundation all use SSD) . If you've seen some of the
> vote pages for Debian, you'll see all sorts of lovely matrices and graphs
> and what not and hey, it might look nice but I think we'll get desired
> results with a much simpler to understand system that is actually geared
> towards what we're dong. Maybe in the future when our numbers are larger
> and we run into some of the electoral corner cases SSD (or something else)
> would be more appropriate but for now STV seems to serve the purpose rather
> well.
>
> I should also note there is already software out there to calculate both
> STV and SSD.
>
> Just to clarify, this e-mail isn't a vote *against* SSD or anything like
> that, just me expressing that SSD seems like overkill for now.
>
In my experience Condercet methods work quick well with multiple selection 
votes too and retain their resistance to strategic voting.  In either case we 
wouldn't count it by hand, so the complexity of counting isn't a significant 
factor.

Yes, Debian does like the fancy charts to prove they got a correct result.  
Here is an example (another election I was in) that shows how easy it is:

http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_8e5a1ca7f86a5d5d

I'd rather just use the best system to begin with rather than have to worry 
about when we need to change.

Scott K