Hello,

As I stated already, I'd like to propose the single transferable ballot with either the Droop or H-B quota. What happened to the thing I said about KISS? Well, although the two other alternatives I presented *are* more simple it also sacrifices the traits that make (IMHO) STV so favourable. STV is a preferential, proportional representative voting system that is relatively simple, allows us to minimize wasted votes, scales well to the multi-member task, and even provides us with an easy way to replace individuals (when more candidates then seats run) who aren't able to fill their entire term.

Anyhow, I didn't origianlly intend for this e-mail to be this long so I do hope someone reads it, lol. Maybe I'll transfer the gist of it to a blog post.

Cheers,

--
Cody A.W. Somerville
Software Engineer
Red Cow Marketing & Technologies, Inc.
Office: 506-458-1290
Toll Free: 1-877-733-2699
Fax: 506-453-9112
Cell: 506-449-5899
Email: cody-/7qCs+C5DW73fQ9qLvQP4Q@public.gmane.org
http://www.redcow.ca

<div>
<p>Hello,<br><br></p>
<div class="gmail_quote">On Tue, Jul 1, 2008 at 6:21 PM, Emilio Pozuelo Monfort &lt;<a href="mailto:pochu@...">pochu <at> ubuntu.com</a>&gt; wrote:<br><blockquote class="gmail_quote">
Hi all,<br><div class="Ih2E3d">
<br>
Emilio Pozuelo Monfort wrote:<br>
&gt; First draft for a policy for motu-{sru,release} membership:<br><br>
</div>Sorry for the long delay. I've had a look again at the proposal and at the<br>
comments, let's see if I can summarise them.</blockquote>
<div>
<br>Thanks for getting the ball rolling again. I've been doing some thinking about this and so I'm going to jot down some ideas to share :)<br>&nbsp;</div>
<blockquote class="gmail_quote">
<br><div class="Ih2E3d">
<br><br>
&gt; 0/ The term of service for the motu-sru and motu-release teams is of one release<br>
&gt; cycle (six months).<br><br>
</div>It's been said this is too short, and that 1 or 2 years would be better. It's<br>
also been proposed that we could have a long term (e.g. 2 years) but with<br>
"pings" from time to time (e.g. 6 months) to see who is not active and then<br>
replace inactive members. That way you don't change the entire team at the same<br>
time.<br><br>
I personally think 2 years is too much, but one year would be fine with me.<br><br>
And I don't think there will be problems regarding to changing the entire teams,<br>
as I expect some of the old members to reapply and be re-elected.</blockquote>
<div>
<br>It seems to me that it would be beneficial to define the terms in relationship to certain milestones in the release cycle instead of just saying "six months" or "one release cycle". This would ensure that we have individuals in place in case dates for said milestones change. For example, if a release cycle were to ever be extended again (like the first LTS), we don't want to be dealing with an election while we're trying desperately to wrap up a release. It would also give us tentative yet concrete dates to work with - no need to guess when "six months" or "two years" is up as we'd say: "ok, two weeks after the official release date we need to call election for xyz".<br><br>As for length, I feel that members should serve for two release cycles. This will tie into my reply to Sherman's post in a minute. <br><br>I also think the ping inbetween the two releases would be a good idea incase someone goes missing.<br><br>
</div>
<blockquote class="gmail_quote">
<br><div>
<div></div>
<div class="Wj3C7c">
<br>
&gt;<br>
&gt; 1/ When the nominating time starts, people may nominate themselves (with a mail<br>
&gt; to ubuntu-motu <at> ). There's no restriction as to how many terms someone can<br>
&gt; participate, but they need to reapply after each term ends.</div>
</div>
</blockquote>
<div>
<br>I think this should be clarified. Does this mean once elected, the individual can serve as many terms as they'd like as long as they "reapply" (ie. express their intention) or do they have to be re-elected? I think you mean the latter and I agree. <br>
&nbsp;</div>
<blockquote class="gmail_quote"><div><div class="Wj3C7c">
<br>
&gt;<br>
&gt; 2/ When the nominating time ends, assuming there's any (even just 1, (s)he may<br>
&gt; be rejected) candidature, the MC sets the polls in Launchpad (yes, it has a poor<br>
&gt; interface, we need to file bugs if there aren't yet...), and the MOTU team is<br>
&gt; given a week to vote.</div></div></blockquote>
<div>
<br>One week to vote seems fair and I think that having the election date in relation to a milestone as I propose above will help ensure we see optimal participation at the polls.<br><br>Also, what does it mean to be rejected or approved? What voting system will we use? Are the candidates with the highest number of votes added until the team reaches capacity? Is it possible to vote *against* a candidate? Do candidates require a majority to be approved?<br>
&nbsp;</div>
<blockquote class="gmail_quote"><div><div class="Wj3C7c">
<br>
&gt;<br>
&gt; 3/ The MC adds the accepted candidates to the appropriate teams.</div></div></blockquote>
<div>
<br>Yup.<br>&nbsp;<br>
</div>
<blockquote class="gmail_quote">
<div><div class="Wj3C7c">
<br>
&gt;<br>
&gt; 4/ If all the vacancies haven't been fulfilled, another call for members may be<br>
&gt; done, after a time of one week.<br>
&gt;</div></div>
</blockquote>
<div>
<br>I think this point needs more clarification as well. Is the team allowed to move forward without a full "load"? What if the community at large doesn't think there is another willing candidate suitable and how would that be expressed/measured? What role does the MOTU council play in this situation?<br><br>It seems to me that if there is no willing candidate to step forward then the team will simply have to proceed. With the exception being that I think maybe we should also set minimums and maximums for teams - ie. if a minimum number of candidates can not be found then the team does not form and an alternate system is employed (or some other reactive process/measure comes into play) and the flip-side being that the number of members in respective team can not exceed a certain value without getting consensus from MOTU at large like we are now for this specification (or maybe some other process). In addition to a minimum and maximum, there should be a nominal value which if not met would mean the team is still open to the addition of new members (ie. maybe MOTU xyz becomes not so busy in the middle of the release and would like to join MOTU-SRU then they may have their candidacy voted upon). If the nominal value IS met then no second call is met and the team is considered finalized. The purpose would be to help ensure the system/processes employed remains effective and efficient.<br><br>Along with my above (strawman) proposal, I'd like to propose the following initial values (which may be moot/inappropriate if we employ an idea I describe below):<br><br>MOTU-Release:<br>&nbsp;Minimum: 3<br>&nbsp;Nominal: 5<br>
&nbsp;Maximum: 7<br><br>MOTU-SRU:<br>&nbsp;Minimum: 2<br>&nbsp;Nominal: 3<br>&nbsp;Maximum: 8<br><br>Also, what do people feel about the MOTU council (either as a monolithic entity or individual members) being able to fill in as an acting member (or members) in situations where the minimum is unable to be reached? What about the MOTU council being able to extend an existing member's term to cover the same situation even if his or her re-election was unsuccessful (or, to clarify, maybe didn't meet the normal qualifying conditions which will be dependent on the voting system we decide to use). What ever your opinion, I feel this specification should enable the motu council the ability through certain processes to help push tough, stalled situations into moving, productive situations.<br><br>
</div>
<blockquote class="gmail_quote"><div><div class="Wj3C7c">
<br>
&gt;<br>
&gt; Things that aren't clear yet in that draft:<br>
&gt; - When the nomination period starts for each team (one week after the release<br>
&gt; for motu-release and just after FeatureFreeze for motu-sru?).</div></div></blockquote>
<div>
<br>Although I've already given a few example dates/time lines in my discussion above, I feel is important that when deciding that the desire be to have these teams ready *for* action instead of becoming ready *in* reaction. To help facilitate this, I'd like to make the following proposal. Please allow me to quote Stephan Hermann's e-mail which came in as worked on this reply:<br><div>
<br>On Wed, Jul 2, 2008 at 3:48 AM, Stephan Hermann &lt;<a href="mailto:sh@...">sh@...</a>&gt; wrote:<br>
</div>
<blockquote class="gmail_quote">
Good Morning,<br><div class="Ih2E3d">
<br>
On Fri, 23 May 2008 19:26:40 +0200<br>
Stefan Potyra &lt;<a href="mailto:sistpoty@...">sistpoty@...m</a>&gt; wrote:<br><br>
&gt; Hi,<br>
&gt;<br>
&gt; as evolved by the discussion for motu-sru members, I guess it might<br>
&gt; make sense to have a good general policy.<br><br>
</div>I would like to see a policy for:<br><br>
motu-sru / motu-release:<br><br>
 &nbsp; &nbsp; &nbsp; &nbsp;* Changing Members every release cycle<br><br>
Why? It would be a good practice for newer MOTUs to step up and learn<br>
the "hard release work".<br><br>
Merging, fixing bugs, syncing for the actual development release is<br>
good and gives knowledge, but knowing how hard some decisions are is<br>
much better. Sure, re-elections of older members is possible, but I<br>
really want to see young blood.</blockquote>
<br>I agree with Stephan that is important for us to get "young blood" up to the task with the "hard release work"(sic.) but I also feel that it is important the team remains effective at all times as I feel is the rationale behind other's desire for longer terms. I feel that both scenarios are possible via what I might call "rolling" (and also a process I think other bodies in Ubuntu already use). If we were to set the term at two releases (as I proposed earlier), we could elect a "minimum set" (this is where my idea for min, max, and nominal get messy) but at the end of the first release cycle we could elect even more individuals (ie. "new blood") to bring it up to a "nominal" (or a little bit above nominal). These new individuals would then have an opportunity to learn the tricks of the trade with the more senior, experienced members already settled in (giving them more time to help the more junior members). At the end of the second release cycle, the more senior members will be able to re-apply or retire knowing there is still a number of individuals serving who have came to know what they're doing. Furthermore, an added benefit would be in the case of some sort of electoral issue we aren't left high and dry.<br><br>=== Benefits ===<br><br>&nbsp;* Teams change every release cycle but not the entire team which will minimize disruption and provide full coverage.<br>&nbsp;* There will always be a set of experienced individuals on the team.<br>
&nbsp;* Allow for proper transition (ie. if someone plans to retire, they don't have to wait until the last minute to pass things off)<br>&nbsp;* Allow for new individuals to get involved and get trained "on the job" by individuals with appropriate experience.<br>
&nbsp;* Date of the elections is less important - allows for it be scheduled at the most convenient time for everyone instead of last minute, omgz we need them but we're super omgz omgz ponies busy with this something else.<br><br>=== Drawbacks ===<br><br>&nbsp;* There would be a little bit of disruption when the new members are added but very pale to the one that is occurring now where huge reshuffles can and do occur.<br>&nbsp;* Guarantee of overhead at the end of each release but pale in comparison of trying to re-elect entire teams at larger intervals.<br>
&nbsp;</div>
<blockquote class="gmail_quote"><div><div>
<br>
&gt; - How the voting works.</div></div></blockquote>
<div>
<br>Above I asked:<br><br><blockquote class="gmail_quote">what does it mean to be rejected or approved? What voting
system will we use? Are the candidates with the highest number of votes
added until the team reaches capacity? Is it possible to vote *against*
a candidate? Do candidates require a majority to be approved? <br>
</blockquote>
<br>This is probably the toughest part to figure out: "How the voting works". If I understand correctly, the reason we elect these individuals is to legitmize a trusted body to make tough decisions as it is understood to be more effective then alternatives such as a free-for-all. Although similar rationale is the basis for today's governments, I think we should probably adhere to the KISS principle which will be a substantially easier task for us ;]. With that being said, I don't feel the rationale for adopting a system should be that it is the only one (or the only one acceptable) that launchpad can support. If launchpad doesn't support the system we pick, I feel we should move forward with it regardless and utilize our launchpad ambassador (a role I believe recently changed hands - can the new hand wave? &lt;grin&gt;) to communicate that need to the launchpad team. By the time the first election roles around, hopefully launchpad will have had time to facilitate or we can just employ our own interim solution (I'm sure launchpad will have had enough time by the second election (hopefully)). Anyhow, my point is to discourage people from disliking an idea based on the perception it won't be possible with the current launchpad voting/polls system.<br><br>Now, as to actual system (originally I was going to simply ask above questions but I figured it would probably be more appreciated if I actually started to flesh something more concrete out) it is important to note that the system we use will have an affect on
the outcome, especially when there is no clear majority preference. We *do* have several options, with the highest level of distinction being: majority rule, proportional representation, and plurity voting. Fortunately for us, we don't have "parties" which eliminate a lot of the different specific systems. Furthermore, we're looking to elect multiple individuals instead of determining a single winner which further narrows our choices down (infact, it completely wipes out plurity voting by definition).<br><br>=== Single Transferable Vote ===<br><br><div>I'd like to propose the Singe Transferable Vote (STV) with either the Hagenbach-Bischoff quota or the droop quota (most common for STV elections). STV is a preferential voting system which will minimize wasted votes, not require us to vote multiple times, and provides proportional representation. Basically, a candidate requires a certain minimum number of votes to be elected (the quota part). STV will allocate your vote to your most
preferred candidate, subsequently transferring unneeded or unused
votes after candidates are either elected or eliminated, according to your stated preferences.<br><p>An STV election proceeds according to the following steps:</p>
<ol>
<li>Voters cast their ballot where they rank every candidate by preference.</li>
<li>A quota is calculated and any candidate who has reached or exceeded the required quota is declared elected.</li>
<li>If not enough candidates have been elected then the surplus of the elected candidates are transferred to other candidates according to the next preference on each voter's ballot.</li>
<li>If still no one meets the quota, the candidate with the fewest votes is eliminated and their votes are transferred.&nbsp;</li>
<li>This continues from step 2 until enough candidates are elected.</li>
</ol>So, how is the quota determined? If we go with the droop quota (which is always rounded down), it looks like this:<br><br>( Total Valid Votes / (Seats + 1) ) + 1<br><br>The H-B quota is very similar to droop but theoretically makes it possible for more candidates to reach quota (Normally, it is considered a tie and a candidate is picked at random to be disqualified. In our case, we might just elect all of them since it would occur so rarely?) than there are seats whereas with droop it is mathematically impossible. Some argue this formula should be preferred over droop because it is possible with the droop quota to produce a seemingly undemocratic result. However, that argument has more to do with party representation and so the decision should probably be based on if we want the situation of more winners then seats to be able to occur.<br><br>( Total Valid Votes / (Seats + 1) )<br><br>So lets say we have an election with 120 votes, five seats, and six candidates: Andrea, Carter, Brad, Delilah, Scott, and Jennifer. The Droop Quota is 21 and the H-B Quota would be 20. <br><br>31 Voters vote: Andrea, Carter, Brad, Delilah, Scott, Jennifer<br>30 Voters vote: Carter, Andrea, Brad, Scott, Delilah, Jennifer<br>1 Voter votes: Brad, Andrea, Carter, Jennifer, Delilah, Scott<br>1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah<br>
20 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea<br>20 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea<br>17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad<br><br>This would give the following tally:<br><br>Andrea: 31<br>Carter: 30<br>Brad: 2<br>Delilah: 20<br>Scott: 20<br>Jennifer: 17<br><br>When first preferences are tallied Andrea and Carter have reached the quota and are declared winners. With droop, Andrea has 10 surplus votes and Carter 9. These surplus votes would go to Brad as Brad is the next available preference listed. This would give us the following tally:<br><br>Brad: 2 + Andrea's surplus (10) + Carter's Surplus (9) = 21<br>Delilah: 20<br>Scott: 20<br>Jennifer: 17<br><br>Brad has now reached a quota and is declared elected. He has no surplus
so Jennifer, who this time has the fewest votes, is excluded. Because
only Delilah and Scott are left in the count, and there are only two
seats left to fill, they are both declared elected. The result being that Andrea, Carter, Brad, Delilah, and Scott get elected.<br><br>If we instead go with the B-H quota (which we determined earlier to be 20), then the election would be a different story. The original tally is:<br><br>Andrea: 31<br>
Carter: 30<br>Brad: 2<br>
Delilah: 20<br>
Scott: 20<br>
Jennifer: 17<br><br>Andrea, Carter, Delilah, and Scott would all be declared winners in the first tally. Andrea's (11) and Carter's (10) surplus (21) would still go to Brad. Delilah and Scott do not have a surplus. This would give the following tally:<br><br>Brad: 23<br>Jennifer: 17<br><br>Brad has met the quota and is declared a winner. The result of the election is Andrea, Carter, Delilah, Scott, and Brad being elected (the same as with the Droop quota). However, what about a situation where all six get elected? Same scenario, different votes:<br><br>28 Voters vote: Andrea, Carter, Brad, Delilah, Scott, Jennifer<br>30 Voters vote: Carter, Andrea, Brad, Scott, Delilah, Jennifer<br>1 Voter votes: Brad, Andrea, Carter, Jennifer, Delilah, Scott<br>1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah<br>
22 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea<br>21 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea<br>17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad<br><br>Andrea, Carter, Delilah, and Scott are declared winners in the first tally. Andrea and Carter have a surplus of 16 which goes to Brad. Delilah and Scott have a surplus of 3 which ends up going to Jennifer. This gives us the following second tally:<br><br>Brad: 20<br>Jennifer: 20<br><br>Either both are declared winners or STV calls for one to randomly be selected.<br><br>To prove that Droop doesn't allow this, note that the Droop quota is 21 and not 20. This means that although Andrea, Carter, Delilah, and Scott are still declared winners the first tally. The surplus to Brad would instead be 16 and the surplus for Jennifer would be 1, resulting in the following: <br><br>Brad: 2 + 16 = 18<br>Jennifer: 17 + 1 = 18 <br><br>Oh, whats this?! A tie? Yes, but neither meet the quota. In this case, either tie procedures come into place or (my preference) we decide that neither candidate is elected since they didn't meet the quota.<br><br>=== Single Non-Transferable Vote ===<br><br>An alternate to STV would be Single *non*-transferable vote where we would only vote once for the individual most preferred. Candidates would be given available seats in order of number of votes. So if we have three seats and five candidates (a, b, c, d, and e) and there are 100 votes cast with the a - 30, b - 20, c - 19, d - 21, and e - 10 then candidates a, d, and b would be declared the winners. This only provides semi-proportional representation by definition but would be less likely in our case due to small scale we're dealing with.<br><br>=== Block Approval Voting ===<br><br>A third alternative would be block approval voting -  a simple variant on block voting
where each voter can select an unlimited number of candidates and the
candidates with the most approval votes win - where you would vote yes or no for each candidate. This does not provide proportional representation and is subject to the <a href="http://en.wikipedia.org/wiki/Burr_dilemma" title="Burr dilemma">Burr dilemma</a>, among other problems. Although approval voting is the system we've used in the past, it is really an abuse of the approval system as approval voting is not meant to be multi-member.<br>
</div>
<br>
</div>
<blockquote class="gmail_quote"><div><div class="Wj3C7c">
<br><br>
</div></div></blockquote>
<blockquote class="gmail_quote">Emilio<br>
</blockquote>
</div>
<br>As I stated already, I'd like to propose the single transferable ballot with either the Droop or H-B quota. What happened to the thing I said about KISS? Well, although the two other alternatives I presented *are* more simple it also sacrifices the traits that make (IMHO) STV so favourable. STV is a preferential, proportional representative voting system that is relatively simple, allows us to minimize wasted votes, scales well to the multi-member task, and even provides us with an easy way to replace individuals (when more candidates then seats run) who aren't able to fill their entire term. <br><br>Anyhow, I didn't origianlly intend for this e-mail to be this long so I do hope someone reads it, lol. Maybe I'll transfer the gist of it to a blog post.<br><br>Cheers,<br><br>-- <br>Cody A.W. Somerville<br>Software Engineer<br>
Red Cow Marketing &amp; Technologies, Inc.<br>Office: 506-458-1290<br>Toll Free: 1-877-733-2699<br>Fax: 506-453-9112<br>Cell: 506-449-5899<br>Email: <a href="mailto:cody@...">cody@...</a><br><a href="http://www.redcow.ca">http://www.redcow.ca</a>
</div>

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).

So what *is* the "Condorcet method", well it isn't actually *a* method but a set of criteria. When people refer to the Condorcet method, they are talking about any single-winner election method that meets the Condorcet criterion. What is the criterion? Basically that the system has to always selects the Condorcet winner. What is the Condorcet winner? It is he candidate who would beat each of the other candidates in a run-off election (there is actually a few different types of run-off elections to boot but in this context I would describe it as the guy who gets the majority votes if everyone voted on only those two people) . In modern examples, voters rank candidates in order of preference but things get very tricky from there as there is need to resolve circular ambiguities. This situation emerges when, once all votes have been added up, the preferences of voters with respect to some candidates form a circle in which every candidate is beaten by at least one other candidate. An example borrowed from wikipedia is if there are three candidates, Alex, Cody and David, there will be no Condorcet winner if voters prefer Alex to Cody and Cody to David, but also David to Alex. Frustratingly, depending on the context in which elections are held, circular ambiguities may or may not be a common occurrence .

Now, if the Condorcett method is meant to elect a single member only how would we use it? Well, it will actually produce a list and I'd suppose we'd pick the number the highest ranking individuals? Erm... maybe? I suppose it depends on the exact system used. Earlier I said that Debian uses the Condorcet method but now you must be wondering which method they *really* use now that you know what Condorcet is really all about. The name is "the Schulze method", aka Schwartz Sequential Dropping (SSD), Cloneproof Schwartz Sequential Dropping (CSSD), Beatpath Method, Beatpath Winner, Path Voting, and Path Winner. In this system, each ballot contains a complete list of all candidates and the individual voter ranks this list in order of preference. Generally, ascending numbers are used, whereby the voter places a '1' beside the most preferred candidate, a '2' beside the second-most preferred, and so forth. Sounds like how one might vote on a Single Transferable Ballot, no? Just wait... it isn't so simple. Voters may give the *same* preference to more than one candidate and *may keep candidates unranked*. If the latter occur (ie. doesn't rank all candidates) then it is assumed that all ranked candidates are strictly preferred to those that he or she did not rank and indifferent between the non-ranked candidates. Then to determine the actual winner (this is a single-member system remember), it determines the "strongest path". The following is from wikipedia:

Procedure

Suppose d[V,W] is the number of voters who strictly prefer candidate V to candidate W.

A path from candidate X to candidate Y of strength p is a sequence of candidates C(1),...,C(n) with the following properties:

1. C(1) = X and C(n) = Y.
2. For all i = 1,...,(n-1): d[C(i),C(i+1)] > d[C(i+1),C(i)].
3. For all i = 1,...,(n-1): d[C(i),C(i+1)] ≥ p.

p[A,B], the strength of the strongest path from candidate A to candidate B, is the maximum value such that there is a path from candidate A to candidate B of that strength. If there is no path from candidate A to candidate B at all, then p[A,B] : = 0.

Candidate D is better than candidate E if and only if p[D,E] > p[E,D].

Candidate D is a potential winner if and only if p[D,E] ≥ p[E,D] for every other candidate E.

Confused? No worries. This system actually comes with a tutorial (albeit in German).

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.

Cheers,

--
Cody A.W. Somerville
Software Engineer
Red Cow Marketing & Technologies, Inc.
Office: 506-458-1290
Toll Free: 1-877-733-2699
Fax: 506-453-9112
Cell: 506-449-5899
Email: cody <at> redcow.ca
http://www.redcow.ca

<div>
<br><div class="gmail_quote">On Wed, Jul 2, 2008 at 5:29 PM, Scott Kitterman &lt;<a href="mailto:ubuntu <at> kitterman.com">ubuntu <at> kitterman.com</a>&gt; wrote:<br><blockquote class="gmail_quote">
<div>
<div></div>
<div class="Wj3C7c">On Wednesday 02 July 2008 07:29, Cody A.W. Somerville wrote:<br>
&gt; Hello,<br>
</div>
</div>
</blockquote>
<div>
<br>&lt;snip&gt;<br>&nbsp;<br>
</div>
<blockquote class="gmail_quote">
<div><div class="Wj3C7c">
<br>
</div></div>
<div class="Ih2E3d">
<br>
&gt;<br>
&gt; This is probably the toughest part to figure out: "How the voting works".<br><br>
</div>... &nbsp;snip<br><br>
Actuall I think it's not. &nbsp; There is a lot of research supporting &nbsp;the<br><a href="http://en.wikipedia.org/wiki/Condorcet_method" target="_blank">http://en.wikipedia.org/wiki/Condorcet_method</a> and services that support it.<br>
It's a little complex in the theory, but actual voting is just ranking your<br>
preferences.<br><div>
<div></div>
<div class="Wj3C7c">
<br>
Scott K<br>
</div>
</div>
</blockquote>
</div>
<br>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. <br><br>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).<br><br>So what *is* the "Condorcet method", well it isn't actually *a* method but a set of criteria. When people refer to the Condorcet method, they are talking about any single-winner election method that meets the Condorcet criterion. What is the criterion? Basically that the system has to always selects the Condorcet winner. What is the Condorcet winner? It is he candidate who would beat each of the other candidates in a run-off
election (there is actually a few different types of run-off elections to boot but in this context I would describe it as the guy who gets the majority votes if everyone voted on only those two people) . In modern examples, voters rank candidates in order of
preference but things get very tricky from there as there is need to resolve circular ambiguities. This situation emerges when, once all votes have been added up, the
preferences of voters with respect to some candidates form a circle in
which every candidate is beaten by at least one other candidate. An example borrowed from wikipedia is if there are three candidates, Alex, Cody and David,
there will be no Condorcet winner if voters prefer Alex to Cody and Cody to David, but also David to Alex. Frustratingly, depending on the context
in which elections are held, circular ambiguities may or may not be a
common occurrence .<br><br>Now, if the Condorcett method is meant to elect a single member only how would we use it? Well, it will actually produce a list and I'd suppose we'd pick the number the highest ranking individuals? Erm... maybe? I suppose it depends on the exact system used. Earlier I said that Debian uses the Condorcet method but now you must be wondering which method they *really* use now that you know what Condorcet is really all about. The name is "the Schulze method", aka Schwartz Sequential Dropping (SSD), Cloneproof Schwartz Sequential Dropping (CSSD), Beatpath Method, Beatpath Winner, Path Voting, and Path Winner. In this system,
each ballot contains a complete list of all candidates and the
individual voter ranks this list in order of preference. Generally, ascending numbers are
used, whereby the voter places a '1' beside the most preferred
candidate, a '2' beside the second-most preferred, and so forth. Sounds like how one might vote on a Single Transferable Ballot, no? Just wait... it isn't so simple. Voters
may give the *same* preference to more than one candidate and *may keep
candidates unranked*. If the latter occur (ie. doesn't rank all candidates)
then it is assumed that all ranked candidates are strictly preferred to those that he or she did not rank and indifferent between the non-ranked candidates. Then to determine the actual winner (this is a single-member system remember), it determines the "strongest path". The following is from wikipedia:<br><br><blockquote class="gmail_quote">Procedure<br><p>Suppose d[V,W] is the number of voters who strictly prefer candidate V to candidate W.</p>
<p>A path from candidate X to candidate Y of strength p is a sequence of candidates C(1),...,C(n) with the following properties:</p>
<ol>
<li>C(1) = X and C(n) = Y.</li>
<li>For all i = 1,...,(n-1): d[C(i),C(i+1)] &gt; d[C(i+1),C(i)].</li>
<li>For all i = 1,...,(n-1): d[C(i),C(i+1)] &ge; p.</li>
</ol>
<p>p[A,B], the strength of the strongest path from candidate A
to candidate B, is the maximum value such that there is a path from
candidate A to candidate B of that strength. If there is no path from
candidate A to candidate B at all, then p[A,B]&nbsp;: = 0.</p>
<p>Candidate D is better than candidate E if and only if p[D,E] &gt; p[E,D].</p>
<p>Candidate D is a potential winner if and only if p[D,E] &ge; p[E,D] for every other candidate E.</p>
</blockquote>Confused? No worries. This system actually comes with a tutorial (albeit in German). <br><br>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.<br><br>I should also note there is already software out there to calculate both STV and SSD.<br><br>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.<br><br>Cheers,<br><br>-- <br>Cody A.W. Somerville<br>Software Engineer<br>Red Cow Marketing &amp; Technologies, Inc.<br>Office: 506-458-1290<br>Toll Free: 1-877-733-2699<br>Fax: 506-453-9112<br>Cell: 506-449-5899<br>Email: <a href="mailto:cody <at> redcow.ca">cody <at> redcow.ca</a><br><a href="http://www.redcow.ca">http://www.redcow.ca</a>
</div>