From jlundell@greens.org Sun Dec 18 03:52:44 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 12847 invoked from network); 18 Dec 2005 03:52:43 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 18 Dec 2005 03:52:43 -0000 Received: (qmail 66339 invoked by uid 0); 18 Dec 2005 03:52:39 -0000 Received: from unknown (HELO ?68.26.75.130?) (unknown) by unknown with SMTP; 18 Dec 2005 03:52:39 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: Date: Sat, 17 Dec 2005 19:52:30 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SC-cochair-WG] SC election bylaws Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: [repost for the archive] The current SC election bylaws (used for the 2004 and 2005 SC elections): >ARTICLE IV. THE STEERING COMMITTEE > >The Steering Committee (SC) of the Green Party of the United States >shall be composed of nine members: seven co-chairs, a Secretary, and >a Treasurer. Co-chairs shall be selected from and elected by the >National Committee (NC) of the Green Party of the United States for >terms of two years, with a limit of two consecutive terms. >The secretary and the treasurer shall be drawn from the membership >of the affiliated state Green Parties and shall serve two year terms >without term limits. >ARTICLE VI. SELECTION, ELECTION, AND REMOVAL OF OFFICERS >At least two months before a national Green Party gathering, the >Secretary of the GPUS shall ask members of the National Committee >for nominations for the various offices. One month shall be given >for all nominations to be submitted. Once all the nominations have >been received by the secretary, candidates shall submit a short >biography online for all delegates to read at least two weeks before >the convening of the next Green Party gathering. Nominations will >reopen at a specified part of the Agenda at the Annual National >Committee Meeting. The official nomination and announcement of >candidates and the elections will be held on separate days during >the Green Party annual meeting. > >Any vacancy in the offices of co-chair, treasurer or secretary shall >cause the SC to call for an on line election to be held immediately >upon confirmation of the vacancy, to be completed within six weeks >of the call for election, with a nomination period of three weeks to >be followed by a two-week discussion period and a one-week vote. > >SC co-chairs shall be elected using choice voting, with a fractional >Droop threshold (one divided by the number of seats to be filled >plus one: 1/(seats+1)) and fractional transfers. A candidate must >pass the Droop threshold in order to be elected. The secretary and >treasurer shall be elected using seperate IRV elections. The SC election bylaws in effect before the 2004 SC election: >ARTICLE IV. OFFICERS, LEGAL SERVICES, CLEARINGHOUSE SUPPORT > >The Steering Committee of the Green Party of the United States shall >be composed of seven members: five co-chairs, a Secretary, and a >Treasurer. The co-chairs shall be selected from and elected by the >Coordinating Committee of the Green Party of the United States for a >term of two years. Each member may serve an additional term, after >which he or she shall rotate off with the understanding that after a >period of two or more years, he or she may offer to serve again. In >the initial election, two members shall be elected for a one year >term, and the other two members shall be elected for a two-year >term. All subsequent elections shall be for two year terms. In an >effort to ensure gender equity, there will be a minimum of two women >and two men serving as co-chairs on the Steering Committee, at all >times. > >The Secretary and the Treasurer shall be drawn from the several >State Green Party members of the Green Party of the United States. >In the initial election the Treasurer will be elected for a one year >term and the Secretary for a two year term. Subsequent elections >shall be for two year terms. Thus in the future there will always be >a continuing Treasurer or a continuing Secretary in office. >ARTICLE VI. SELECTION, ELECTION, AND REMOVAL OF OFFICERS > >At least two months before a national Green Party gathering, the >secretary shall ask members of the Coordinating Committee for >nominations for the various offices. One month shall be given for >all nominations to be submitted. Once all the nominations have been >received by the secretary, candidates shall submit a short biography >on-line for all delegates to read at least two weeks before the >convening of the next Green Party gathering. Nominations may be >reopened at the meeting of the Coordinating Committee if there were >insufficient nominations. The official announcement of candidates >and the elections will be held on separate days during the Green >Party gathering. Election of officers will be conducted by >preferential voting. For the position of co-chair the individual >with the fourth highest vote total will automatically become the >alternate and automatically assume the office of co-chair if a >vacancy occurs between Green Party gatherings. -- /Jonathan Lundell. From jlundell@greens.org Sun Dec 25 00:29:24 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 19489 invoked from network); 25 Dec 2005 00:29:23 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 00:29:23 -0000 Received: (qmail 69704 invoked by uid 0); 25 Dec 2005 00:29:17 -0000 Received: from unknown (HELO ?10.2.3.25?) (unknown) by unknown with SMTP; 25 Dec 2005 00:29:17 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: Date: Sat, 24 Dec 2005 16:29:04 -0800 To: GPUS SC Election WG From: Jonathan Lundell Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SC-cochair-WG] just the facts Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: This is an attempt to outline the facts relating to the disputed SC election in Tulsa. BRPP proposed, and the NC approved, a bylaws change relating to SC elections between the 2003 and 2004 (Milwaukee) SC elections. I've posted the before-and-after bylaws on this list. The day before the 2004 SC election in Milwaukee, it became clear that nobody had made a provision to count the upcoming election according to the new bylaws. I was in Milwaukee as a California delegate, and happened to have a counting program that I had written as a pedagogical aid (to myself) along on my computer, so I volunteered to use it to count the election. It went smoothly. (I've since published the software online as open source and used it to count several GPCA elections.) I was not present in Tulsa for the 2005-07-24 SC election, but my software was used again. Phil, who is on this list, was there and can fill in details as necessary. When the 2005 election was counted, only three of the four open seats were filled. Our rules state that, to win a seat, a candidate must pass the Droop threshold (ballots/(open seats+1)). With 4 open seats and 94 ballots, the Droop threshold was 18.8. However, the threshold was overridden during the count and set to 19, under the mistaken belief that we were using an integer threshold. By a rather bizarre twist of fate, the difference between 18.8 and 19 made the difference. The last candidate to be eliminated, Tom Sevigny, had 18.887140973141 votes, not enough to pass the specified threshold of 19. There ensued a debate over how to fill the empty seat. I won't go into details here, because I was not party to most of these discussions. However, I was curious about the counting, and asked Phil to send me a copy of the ballot file, which he did on 3 August. I noticed the threshold error, re-ran the count with the correct threshold, and notified Phil that Tom should have been elected to the fourth seat. Again, because I was not part of most of the discussions, I don't know the details. But I gather that it was not clear that Tom would accept the seat, having made other plans. I re-ran the election count with Tom excluded, and found that Budd Dickinson won the fourth seat in that case. Meanwhile, others counted the election using a different counting algorithm, generally known as Meek's Method. Without going into details, suffice it to say that Meek's method differs from the more traditional STV counting method in the way it distributes transferred votes. Under Meek's method, because of the difference in the treatment of transfers, the fourth seat was filled by (IIRC) Kris Olson. It's worth noting that Meek's method is not the only proposed improvement to the "traditional" STV counting method. While I tend to favor Meek's method myself, there is currently no generally accepted "best" STV method. Moreover, Meek's method as generally implemented does not comply with our bylaws, in that it lowers the election threshold until all open seats are filled, rather than using a fixed mandatory threshold of election. This problem did not come into play in counting the Tulsa election because all four seats were filled at the Droop threshold of 18.8, which Meek's method shares with our bylaws. So now we had at least three claimants to the fourth seat: Tom Sevigny, winner under our "traditional" counting method; Budd Dickinson, the "traditional" winner with Tom excluded, and Kris Olson, the Meek's winner. I gather that this trio raises interesting factional disputes. I'm not familiar enough with them to know the details, but strong feelings have arisen, making it impossible to come to a consensus solution. Other sources of STV counting software include DemoChoice , which uses the "traditional" transfer method, and pSTV , which supports a variety of algorithms. Another description of "traditional" STV counting can be found here: . Meek's paper is available here: . Our first task is to "review" the Tulsa election, but (apparently and fortunately for us) not to fix it. I'm not sure that there's much to review, at this point. I see three mistakes: the bylaws should have been more explicit, the correct threshold should have been used, and we need a more organized way of counting elections generally. The first and third are within our mandate. Fixing the threshold was easy enough, but that has not solved the Tulsa election problem, and in any event we are not charged with fixing it. Our second task is to disambiguate the SC-election bylaws, presumably by more precisely specifying an STV counting method. This would, I assume, result in a proposal for a bylaws change, and would not retroactively affect the Tulsa outcome. Our third task is to propose the establishment of a standing elections team. Our fourth task is to deliver a report on the above to the SC, no later than the first of this month. -- /Jonathan Lundell. From prindle@greens.org Sun Dec 25 00:33:00 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 20054 invoked from network); 25 Dec 2005 00:33:00 -0000 Received: from vms042pub.verizon.net (206.46.252.42) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 00:33:00 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS1005V92UD7FH3@vms042.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Sat, 24 Dec 2005 18:32:38 -0600 (CST) Date: Sat, 24 Dec 2005 19:32:21 -0500 From: "Eric J. Prindle" X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051224191623.045b4350@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [SC-cochair-WG] FairVote Review Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: Well, for those who haven't seen it, the character of the members of this working group is being called into question before we've even really started our work, so I guess we'd might as well start it. Looking at the proposal the NC adopted, it appears that they want an independent review of the 2005 SC election, not just a review of our work product as has already been discussed. Since the NC listed FairVote as its apparent preferred organization to do the review, I'd suggest that we contact them and ask if they'd be willing to do it in-house or farm it out to one of their affiliated consultants. I'd also suggest that we ask them very specific questions so that they can focus on a constructive review of what happened. Here's what I would ask, supplying all the necessary documentation for them to come up with answers, of course: 1. In your opinion, was the vote count performed by the GPUS Steering Committee's ad hoc "Elections Team" and communicated to the National Committee on July 24, 2005 consistent with the GPUS bylaws? 2. In your opinion, was the revised vote count performed by the GPUS Steering Committee's ad hoc "Elections Team" and communicated to the National Committee on August 9, 2005 consistent with the GPUS bylaws? 3. In your opinion, was the vote count performed by Roger Snyder and communicated to the National Committee on August 10, 2005 consistent with the GPUS bylaws? 4. Are you aware of other Single Transferable Vote counting methods that are consistent with the GPUS bylaws? 5. In your opinion, are the GPUS bylaws and rules regarding the election of Steering Committee Co-Chairs and members of the Coordinated Campaign Committee consistent with the principles of proportional representation and the Single Transferable Vote? 6. What improvements, if any, would you suggest to make the above referenced bylaws and rules unambiguous, efficient, and effective? ------------------------- - Eric Prindle http://prindle.blogspot.com From prindle@greens.org Sun Dec 25 00:38:02 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 20684 invoked from network); 25 Dec 2005 00:38:02 -0000 Received: from vms046pub.verizon.net (206.46.252.46) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 00:38:02 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS100KVE33AWOD3@vms046.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Sat, 24 Dec 2005 18:37:58 -0600 (CST) Date: Sat, 24 Dec 2005 19:37:42 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] just the facts In-reply-to: X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051224193256.04ada190@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: Well it looks like we had the same idea. >Our first task is to "review" the Tulsa election, but (apparently and >fortunately for us) not to fix it. I'm not sure that there's much to >review, at this point. I see three mistakes: the bylaws should have been >more explicit, the correct threshold should have been used, and we need a >more organized way of counting elections generally. The first and third >are within our mandate. Fixing the threshold was easy enough, but that has >not solved the Tulsa election problem, and in any event we are not charged >with fixing it. I guess one question about our "review" of the Tulsa election is whether we're expected to review only the election itself or look at the various post-hoc proposals to solve the problems it presented, none of which were adopted. I do not really think we need to delve into the latter, but I thought I'd see if others disagreed. >Our fourth task is to deliver a report on the above to the SC, no later >than the first of this month. So I guess our first real task is to ask for an extension. How do we feel about March 1? ------------------------- - Eric Prindle http://prindle.blogspot.com From jlundell@greens.org Sun Dec 25 01:16:16 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 23291 invoked from network); 25 Dec 2005 01:16:16 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 01:16:16 -0000 Received: (qmail 73617 invoked by uid 0); 25 Dec 2005 01:16:12 -0000 Received: from unknown (HELO ?10.2.3.25?) (unknown) by unknown with SMTP; 25 Dec 2005 01:16:12 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.1.0.6.0.20051224193256.04ada190@mail.nyu.edu> References: <6.1.0.6.0.20051224193256.04ada190@mail.nyu.edu> Date: Sat, 24 Dec 2005 17:16:08 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] just the facts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 7:37 PM -0500 12/24/05, Eric J. Prindle wrote: >>Our fourth task is to deliver a report on the above to the SC, no >>later than the first of this month. > >So I guess our first real task is to ask for an extension. How do we >feel about March 1? Lynne sounded like she'd be out of touch until January. At 9:41 PM -0600 12/15/05, hhart@blue.weeg.uiowa.edu wrote: >The original due date of Dec. 1 has long since passed. The SC didn't discuss >a new timeline on our call, but we thought the first order of business should >be to get the group together in the coming week and come up with a more >realistic timeline to bring back to the SC. Our next conference call will be >1/2/06. > >This needs to be completed by early 2006, so any proposals have an opportunity >to work their way through the voting process far in advance of the summer >elections. It sounds like sooner is better. I'm fine with March 1. Holly, have you heard from all the members yet? -- /Jonathan Lundell. From jlundell@greens.org Sun Dec 25 01:24:07 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 23630 invoked from network); 25 Dec 2005 01:24:06 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 01:24:06 -0000 Received: (qmail 74301 invoked by uid 0); 25 Dec 2005 01:23:57 -0000 Received: from unknown (HELO ?10.2.3.25?) (unknown) by unknown with SMTP; 25 Dec 2005 01:23:57 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.1.0.6.0.20051224191623.045b4350@mail.nyu.edu> References: <6.1.0.6.0.20051224191623.045b4350@mail.nyu.edu> Date: Sat, 24 Dec 2005 17:23:50 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] FairVote Review Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 7:32 PM -0500 12/24/05, Eric J. Prindle wrote: >5. In your opinion, are the GPUS bylaws and rules regarding the >election of Steering Committee Co-Chairs and members of the >Coordinated Campaign Committee consistent with the principles of >proportional representation and the Single Transferable Vote? There's a question I'd like to address more explicitly, and that's the issue of setting a mandatory threshold for SC election. I'm sympathetic with the underlying idea, to exclude candidates with minimal support, it's worth asking where the line is between minority support and insufficient support for election. Setting the threshold too high can leave an empty seat to be filled, presumably, by the current majority, which isn't entirely consistent with the goals of PR. And that leads to part 2 of this question: what's the proper way to fill SC vacancies? I have views on these subjects, but I'm primarily interested in getting them addressed in our ultimate report. Recall is a related issue (how does recall work in a PR body?), but it's not of immediate relevance since the GPUS bylaws don't provide for recall (or at least I don't think they do). -- /Jonathan Lundell. From hhart@blue.weeg.uiowa.edu Sun Dec 25 03:36:21 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 28773 invoked from network); 25 Dec 2005 03:36:20 -0000 Received: from night.its.uiowa.edu (128.255.56.106) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 03:36:20 -0000 Received: from localhost (webmail1-maint.its.uiowa.edu [128.255.56.153]) by night.its.uiowa.edu (8.12.10/8.12.9/ns-mx-1.17) with ESMTP id jBP3aH1T035518 for ; Sat, 24 Dec 2005 21:36:17 -0600 Received: from 66.133.71.29 ([66.133.71.29]) by webmail1.its.uiowa.edu (IMP) with HTTP for ; Sat, 24 Dec 2005 21:36:17 -0600 Message-ID: <1135481777.43ae13b127aee@webmail1.its.uiowa.edu> Date: Sat, 24 Dec 2005 21:36:17 -0600 From: hhart@blue.weeg.uiowa.edu To: sc-cochair-wg@gp-us.org Subject: Re: [SC-cochair-WG] just the facts References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 66.133.71.29 Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: I can fill in a little more detail, although it may not be all that relevant here. See below - Holly Quoting Jonathan Lundell : ... > > Again, because I was not part of most of the discussions, I don't > know the details. But I gather that it was not clear that Tom would > accept the seat, having made other plans. I re-ran the election count > with Tom excluded, and found that Budd Dickinson won the fourth seat > in that case. What happened right after the Tulsa meeting, in fairly rapid succession: just after the Tulsa meeting, the SC called for nominations to fill the vacancy we thought we had. Tom Sevigny was one of the nominees, but wrote that he was thinking of not running. Then, Phil notified us of the error with the threshold, and that the proper count showed Tom had won the fourth seat. With Tom stepping out, the seat would have gone to Budd, but the SC reasoned that Tom had not withdrawn from the race, but stepped aside after it was completed. The SC planned to continue the election, but Tom decided to accept the seat. The SC agreed we were bound to announce this to the NC, announce Tom as the winner of the fourth seat and cancel (void, nullify, whatever term you want to use) the current election. This drew complaints from some delegates. Roger Snyder then announced his results through the method he'd used. In the ensuing discussion, several proposals were put out to effect various results: seat Tom; seat Tom and Kristen both; hold a new election for the fourth seat. None got the required amount of support from the NC to pass. Meanwhile, the SC was also getting requests from delegates to check with Fairvote (or some similar organization) to get advice on what should be done. At this time, the idea for this working group is more to get advice, information and suggestion(s) for a plan for the next election, and I believe it's open as to what method is used, whether STv or something else. I'm guessing it's a given that some form of preference voting will be wanted, but beyond that, the question is what to use; if STV is the best method; if so, what form of STV would be recommended? Holly From hhart@blue.weeg.uiowa.edu Sun Dec 25 03:44:03 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 29529 invoked from network); 25 Dec 2005 03:44:02 -0000 Received: from day.its.uiowa.edu (128.255.56.107) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 03:44:02 -0000 Received: from localhost (webmail1-maint.its.uiowa.edu [128.255.56.153]) by day.its.uiowa.edu (8.12.10/8.12.9/ns-mx-1.17) with ESMTP id jBP3hxMw068264 for ; Sat, 24 Dec 2005 21:43:59 -0600 Received: from 66.133.71.29 ([66.133.71.29]) by webmail1.its.uiowa.edu (IMP) with HTTP for ; Sat, 24 Dec 2005 21:43:59 -0600 Message-ID: <1135482239.43ae157f9c558@webmail1.its.uiowa.edu> Date: Sat, 24 Dec 2005 21:43:59 -0600 From: hhart@blue.weeg.uiowa.edu To: sc-cochair-wg@gp-us.org Subject: Re: [SC-cochair-WG] just the facts References: <6.1.0.6.0.20051224193256.04ada190@mail.nyu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 66.133.71.29 Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: I think March 1 seems reasonable. Perhaps one or more of you would be willing to be on the next SC conference call (Jan 2)? That would give you a chance to touch base with the full SC, and for both the SC and this group get an idea of how you would proceed. Yes, I've heard back from all members of this working group, and all are subscribed to this list. Lynne will be away for a couple weeks, but said she'll try to check her mail every so often during this time. I think Eric is right, I never got the sense of a request for a review of the NC proposals that were put forth as various attempts to resolve the election; that might be worth a brief review, though, if you think it would be worthwhile. Thank you for getting this started! Holly Quoting Jonathan Lundell : > At 7:37 PM -0500 12/24/05, Eric J. Prindle wrote: > >>Our fourth task is to deliver a report on the above to the SC, no > >>later than the first of this month. > > > >So I guess our first real task is to ask for an extension. How do we > >feel about March 1? > > Lynne sounded like she'd be out of touch until January. > > At 9:41 PM -0600 12/15/05, hhart@blue.weeg.uiowa.edu wrote: > >The original due date of Dec. 1 has long since passed. The SC didn't > discuss > >a new timeline on our call, but we thought the first order of business > should > >be to get the group together in the coming week and come up with a more > >realistic timeline to bring back to the SC. Our next conference call will > be > >1/2/06. > > > >This needs to be completed by early 2006, so any proposals have an > opportunity > >to work their way through the voting process far in advance of the summer > >elections. > > It sounds like sooner is better. I'm fine with March 1. > > Holly, have you heard from all the members yet? > -- > /Jonathan Lundell. > _______________________________________________ > SC-cochair-WG mailing list > SC-cochair-WG@gp-us.org > http://lists.gp-us.org/mailman/listinfo/sc-cochair-wg > From hhart@blue.weeg.uiowa.edu Sun Dec 25 03:46:42 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 29793 invoked from network); 25 Dec 2005 03:46:42 -0000 Received: from night.its.uiowa.edu (128.255.56.106) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 03:46:42 -0000 Received: from localhost (webmail1-maint.its.uiowa.edu [128.255.56.153]) by night.its.uiowa.edu (8.12.10/8.12.9/ns-mx-1.17) with ESMTP id jBP3kd1T035348 for ; Sat, 24 Dec 2005 21:46:39 -0600 Received: from 66.133.71.29 ([66.133.71.29]) by webmail1.its.uiowa.edu (IMP) with HTTP for ; Sat, 24 Dec 2005 21:46:39 -0600 Message-ID: <1135482399.43ae161f255df@webmail1.its.uiowa.edu> Date: Sat, 24 Dec 2005 21:46:39 -0600 From: hhart@blue.weeg.uiowa.edu To: sc-cochair-wg@gp-us.org Subject: Re: [SC-cochair-WG] just the facts MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 66.133.71.29 Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: I think March 1 seems reasonable. Perhaps one or more of you would be willing to be on the next SC conference call (Jan 2)? That would give you a chance to touch base with the full SC, and for both the SC and this group get an idea of how you would proceed. Yes, I've heard back from all members of this working group, and all are subscribed to this list. Lynne will be away for a couple weeks, but said she'll try to check her mail every so often during this time. I think Eric is right, I never got the sense of a request for a review of the NC proposals that were put forth as various attempts to resolve the election; that might be worth a brief review, though, if you think it would be worthwhile. Thank you for getting this started! Holly Quoting Jonathan Lundell : > At 7:37 PM -0500 12/24/05, Eric J. Prindle wrote: > >>Our fourth task is to deliver a report on the above to the SC, no > >>later than the first of this month. > > > >So I guess our first real task is to ask for an extension. How do we > >feel about March 1? > > Lynne sounded like she'd be out of touch until January. > > At 9:41 PM -0600 12/15/05, hhart@blue.weeg.uiowa.edu wrote: > >The original due date of Dec. 1 has long since passed. The SC didn't > discuss > >a new timeline on our call, but we thought the first order of business > should > >be to get the group together in the coming week and come up with a more > >realistic timeline to bring back to the SC. Our next conference call will > be > >1/2/06. > > > >This needs to be completed by early 2006, so any proposals have an > opportunity > >to work their way through the voting process far in advance of the summer > >elections. > > It sounds like sooner is better. I'm fine with March 1. > > Holly, have you heard from all the members yet? > -- > /Jonathan Lundell. > _______________________________________________ > SC-cochair-WG mailing list > SC-cochair-WG@gp-us.org > http://lists.gp-us.org/mailman/listinfo/sc-cochair-wg > From rogersnyder@pobox.com Sun Dec 25 16:57:50 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 32654 invoked from network); 25 Dec 2005 16:57:50 -0000 Received: from mta3.srv.hcvlny.cv.net (167.206.4.198) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 16:57:50 -0000 Received: from [10.0.1.6] (ool-182dbaa2.dyn.optonline.net [24.45.186.162]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IS2005ZLCFMKCIQ@mta3.srv.hcvlny.cv.net> for sc-cochair-wg@gp-us.org; Sun, 25 Dec 2005 11:57:22 -0500 (EST) Date: Sun, 25 Dec 2005 11:57:20 -0500 From: Roger Snyder Subject: Re: [SC-cochair-WG] just the facts In-reply-to: <1135482399.43ae161f255df@webmail1.its.uiowa.edu> To: sc-cochair-wg@gp-us.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Microsoft-Entourage/11.1.0.040913 Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: On 12/24/05 22:46, "hhart@blue.weeg.uiowa.edu" wrote: > Yes, I've heard back from all members of this working group, and all are > subscribed to this list. Yes, I'm also on the list and observing in case there is a question. -- Roger From jlundell@greens.org Sun Dec 25 17:26:22 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 1533 invoked from network); 25 Dec 2005 17:26:22 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 17:26:22 -0000 Received: (qmail 16614 invoked by uid 0); 25 Dec 2005 17:26:12 -0000 Received: from unknown (HELO ?10.2.3.25?) (unknown) by unknown with SMTP; 25 Dec 2005 17:26:12 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <1135482399.43ae161f255df@webmail1.its.uiowa.edu> References: <1135482399.43ae161f255df@webmail1.its.uiowa.edu> Date: Sun, 25 Dec 2005 09:25:58 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] just the facts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 9:46 PM -0600 12/24/05, hhart@blue.weeg.uiowa.edu wrote: >I think Eric is right, I never got the sense of a request for a review of the >NC proposals that were put forth as various attempts to resolve the election; >that might be worth a brief review, though, if you think it would be >worthwhile. We could do that, yes. I don't have a comprehensive idea of the various proposals, but we could certainly try to collect them. Here's a start, with some of the variations I've heard. 1. Recount the election with the "traditional" algorithm and the correct threshold (elects Tom Sevigny). 2. Recount the election with Meek's method (elects Kris Olson). 3. Variations on seat-sharing with Tom and Kris. 4. Specify a counting method and hold a new election for all four seats. 5. Treat the fourth seat as a normal vacancy, and fill it with an IRV election. No doubt there are more. For example, if Tom had declined the seat, the traditional algorithm elects Budd Dickinson in his place. But if both Tom and Kris are ready and willing to take the seat, I don't see that we need to look at variations that assume otherwise. -- /Jonathan Lundell. From hhart@blue.weeg.uiowa.edu Sun Dec 25 17:40:24 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 2167 invoked from network); 25 Dec 2005 17:40:24 -0000 Received: from night.its.uiowa.edu (128.255.56.106) by cesarchavez.cagreens.org with SMTP; 25 Dec 2005 17:40:24 -0000 Received: from localhost (webmail3-maint.its.uiowa.edu [128.255.56.158]) by night.its.uiowa.edu (8.12.10/8.12.9/ns-mx-1.17) with ESMTP id jBPHeN1T043962 for ; Sun, 25 Dec 2005 11:40:23 -0600 Received: from 66.133.71.29 ([66.133.71.29]) by webmail3.its.uiowa.edu (IMP) with HTTP for ; Sun, 25 Dec 2005 11:40:23 -0600 Message-ID: <1135532423.43aed9870527a@webmail3.its.uiowa.edu> Date: Sun, 25 Dec 2005 11:40:23 -0600 From: hhart@blue.weeg.uiowa.edu To: sc-cochair-wg@gp-us.org Subject: Re: [SC-cochair-WG] just the facts References: <1135482399.43ae161f255df@webmail1.its.uiowa.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 66.133.71.29 Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: You can find the three proposals in question here: http://green.gpus.org/cgi-bin/vote/voteresults Scroll down to # 172, 173, 174 The proposals were close to what you're describing. No recounts were involved, however. One proposal acknowledged the original count with Tom Sevginy as the winner. Another had both Tom and Kristin Olson sharing the seat in some way (details to be worked out); the third declared a vacancy and a new election to fill the fourth seat. Holly Quoting Jonathan Lundell : > At 9:46 PM -0600 12/24/05, hhart@blue.weeg.uiowa.edu wrote: > >I think Eric is right, I never got the sense of a request for a review of > the > >NC proposals that were put forth as various attempts to resolve the > election; > >that might be worth a brief review, though, if you think it would be > >worthwhile. > > We could do that, yes. I don't have a comprehensive idea of the > various proposals, but we could certainly try to collect them. Here's > a start, with some of the variations I've heard. > > 1. Recount the election with the "traditional" algorithm and the > correct threshold (elects Tom Sevigny). > > 2. Recount the election with Meek's method (elects Kris Olson). > > 3. Variations on seat-sharing with Tom and Kris. > > 4. Specify a counting method and hold a new election for all four seats. > > 5. Treat the fourth seat as a normal vacancy, and fill it with an IRV > election. > > No doubt there are more. For example, if Tom had declined the seat, > the traditional algorithm elects Budd Dickinson in his place. But if > both Tom and Kris are ready and willing to take the seat, I don't see > that we need to look at variations that assume otherwise. > -- > /Jonathan Lundell. > _______________________________________________ > SC-cochair-WG mailing list > SC-cochair-WG@gp-us.org > http://lists.gp-us.org/mailman/listinfo/sc-cochair-wg > From jlundell@greens.org Mon Dec 26 23:37:02 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 18685 invoked from network); 26 Dec 2005 23:37:01 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 26 Dec 2005 23:37:02 -0000 Received: (qmail 13363 invoked by uid 0); 26 Dec 2005 23:36:57 -0000 Received: from unknown (HELO ?10.2.3.25?) (unknown) by unknown with SMTP; 26 Dec 2005 23:36:57 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <1135532423.43aed9870527a@webmail3.its.uiowa.edu> References: <1135482399.43ae161f255df@webmail1.its.uiowa.edu> <1135532423.43aed9870527a@webmail3.its.uiowa.edu> Date: Mon, 26 Dec 2005 15:36:55 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SC-cochair-WG] comments on proposals 170, 173, 174 Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 11:40 AM -0600 12/25/05, hhart@blue.weeg.uiowa.edu wrote: >You can find the three proposals in question here: > >http://green.gpus.org/cgi-bin/vote/voteresults > >Scroll down to # 172, 173, 174 Thanks. Minor correction: it's 170, 173, 174. >The proposals were close to what you're describing. No recounts were >involved, however. One proposal acknowledged the original count with Tom >Sevginy as the winner. That's all I meant by a recount: redoing the original count with the correct threshold. >Another had both Tom and Kristin Olson sharing the >seat in some way (details to be worked out); the third declared a vacancy and >a new election to fill the fourth seat. #170 proposed to seat both Tom & Kris until the 2006 SC election, with a "temporary amendment" to the bylaws. #173 proposed a retabulation with the correct threshold, electing Tom. #174 proposed a special election to fill the fourth seat. #194 appears to be in effect a rehash of #170. I can't find the actual vote results for these proposals, but all four failed. As Holly has said, it's not clear that we're mandated to review these NC proposals, but to the extent that it might be useful, here goes. #170/194, seating both Kris and Tom, is problematical. Aside from needing a suspension of the bylaws, it has the effect of double-counting ballots cast for both Tom and Kris, of which there were many, though it's next to impossible to quantify this effect. I can elaborate on this further, but it's hard to see how seating both candidates represents the intent of a PR election. It would be perhaps easier to justify as a political compromise if the two candidates had essentially disjoint sets of supporters, but they clearly do not. Consequently, many of the ballots that end up electing Tom or Kris under the two transfer methods end up counting twice. Furthermore, the two methods for which we have results are not the only two methods of counting STV elections. To be consistent, we'd have to evaluate the results of all counting methods that comply with the bylaws, and seat every candidate who was elected under any method. #174, special election for the fourth seat. This solution would be consistent with the bylaws, assuming that there was an empty fourth seat. It's less than ideal, since the resulting single-seat election gives the fourth seat to the majority of the NC, who we may presume are not the same voters who would have chosen the fourth seat in the original STV election. Furthermore, as far as we know, any counting method that complies with the bylaws elects a fourth candidate. The seat may be over-full, but it's not empty. #173, re-tabulate original election with "traditional" method and correct threshold. The main drawback to this solution is that it did not pass the NC. Nobody has argued that the method conflicts with the bylaws, and it has the virtue of precedent, having been used without objection in 2004. This would have been my choice, with the additional provision that we'd evaluate STV counting methods for future elections, and specify ours more precisely. While I'm the author of the "traditional" counting software, I'm not (according to me, anyway) biased in its favor, in general. When we recommend a going-forward counting method, I'll probably go with Meek's, with a suitable variation for our fixed threshold, and subject to our discussion. But Meek's is not the only STV counting method that has been advanced as an improvement on the "traditional" one, and has no absolute claim to being the one true method. Consequently, I adopt the principle of least surprise, and prefer the "traditional" method because of precedent until a new method is agreed to. -- /Jonathan Lundell. From phil@mcleancountygreens.org Tue Dec 27 18:40:54 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 13453 invoked from network); 27 Dec 2005 18:40:54 -0000 Received: from webmail1.sd.dreamhost.com (@66.33.201.159) by cesarchavez.cagreens.org with SMTP; 27 Dec 2005 18:40:54 -0000 Received: from webmail.mcleancountygreens.org (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id D29132C208 for ; Tue, 27 Dec 2005 10:40:39 -0800 (PST) Received: from 216.201.119.126 (SquirrelMail authenticated user phil@mcleancountygreens.org) by webmail.mcleancountygreens.org with HTTP; Tue, 27 Dec 2005 12:40:39 -0600 (CST) Message-ID: <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> In-Reply-To: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> Date: Tue, 27 Dec 2005 12:40:39 -0600 (CST) Subject: Re: [SC-cochair-WG] just the facts From: "Phil Huckelberry" To: sc-cochair-wg@gp-us.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: I've finally managed to catch up on this discussion (and others, for that matter) and it seems like there's a pretty good sense of the situation. I don't think the group should dive into the 2005 election, except that so many odd things happened that we need to be clear in addressing these things in the future: 1. The bylaws specify STV, but do not specify how transfers should be conducted (Hare or Meek). I've used the pSTV software and have found from it that there are actually more than two variations, and the final bylaw should explicitly state what algorithm will be used. 2. Initially when the corrected results were reported to the SC, there was no clarity as to whether Tom would "accept" the seat. I argued then that withdrawing was not an appropriate option under our bylaws; if Tom was elected, then he should have been seated, and if he wanted to "decline", he would have needed to _resign_. Jonathan brought up at that point the concept of rerunning the numbers with Tom removed so as to preserve the proportionality of the original vote. I think what Jonathan suggested was reasonable and sensible, but inconsistent with the current bylaws. So regardless of whether a "withdrawal" happens pre- or post- being seated, the bylaws need to be clear on whether the numbers will be re-run or not. 3. The bylaws should clearly state how ties are to be broken. Primarily via Proposal 194, the NC was subjected to what in my opinion was a highly fragmented debate about what proportional representation actually means and how to best uphold it. I thought the idea of splitting the seat was actually highly violative of PR in two respects - one, you don't change the nature of the body after an election; and two, the bylaws specifically allow for a vacancy to be a suitable outcome of an election. This latter point is something that's going to have to be resolved... Jonathan has talked about using Meek's Method with dynamic thresholds, which would eliminate the possibility of an election ending in a vacancy. I very strongly believe that this is not a good idea. The contentious debate about the 2005 election has given me occassion to think a great deal about how PR deals with minority blocs. In a nutshell, I think that the party's advocacy for None of the Above as a viable option is too significant to be tossed aside, and if NOTA "wins" a seat, then that's a reasonable outcome. It's more violative of PR to allow a minority candidate with insufficient support to cross a static threshold to be seated than to declare a vacancy and move to an IRV election, in my opinion. Maybe there is a way to split that divide. I also think there are other little points that should be addressed. For example, I think it is unwise to have the SC election be the last item on the ANM agenda. I think delegates should know who their new SC is before they depart, among other things. The silver lining of the 2005 debacle is that so many little things went awry that I think the eventual bylaw is going to be able to be air tight. - Phil From prindle@greens.org Tue Dec 27 19:39:31 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 19428 invoked from network); 27 Dec 2005 19:39:31 -0000 Received: from vms040pub.verizon.net (206.46.252.40) by cesarchavez.cagreens.org with SMTP; 27 Dec 2005 19:39:31 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS60026Z99SJDOM@vms040.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Tue, 27 Dec 2005 13:39:29 -0600 (CST) Date: Tue, 27 Dec 2005 14:39:24 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] comments on proposals 170, 173, 174 In-reply-to: X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051227143751.04d52c90@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: <1135482399.43ae161f255df@webmail1.its.uiowa.edu> <1135532423.43aed9870527a@webmail3.its.uiowa.edu> Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: A couple notes: 1) In accordance with the NC's mandate for an independent review, I think we should focus on coming up what we will propose to FairVote before any discussion of our own views. 2) Since our mandate is to review the Tulsa election, which was held under a particular set of bylaws, I don't think we need to review any of the proposed solutions that would have constituted suspension or temporary amendment of those bylaws -- most notably the vote-splitting proposals. 3) With regard to proposed solutions that intended to interpret the existing bylaws, I think we should take a very minimal approach, asking only whether they were consistent with a reasonable interpretation of the bylaws. I don't think this working group was tasked with placing the crown of righteousness on the head of any faction (and if FairVote has any sense, it won't take on that task either). The last thing I want to do is issue a report that makes any claim about what "should have happened." >At 11:40 AM -0600 12/25/05, hhart@blue.weeg.uiowa.edu wrote: >>You can find the three proposals in question here: >> >>http://green.gpus.org/cgi-bin/vote/voteresults >> >>Scroll down to # 172, 173, 174 > >Thanks. Minor correction: it's 170, 173, 174. > >>The proposals were close to what you're describing. No recounts were >>involved, however. One proposal acknowledged the original count with Tom >>Sevginy as the winner. > >That's all I meant by a recount: redoing the original count with the >correct threshold. > >>Another had both Tom and Kristin Olson sharing the >>seat in some way (details to be worked out); the third declared a vacancy and >>a new election to fill the fourth seat. > > >#170 proposed to seat both Tom & Kris until the 2006 SC election, with a >"temporary amendment" to the bylaws. > >#173 proposed a retabulation with the correct threshold, electing Tom. > >#174 proposed a special election to fill the fourth seat. > >#194 appears to be in effect a rehash of #170. > >I can't find the actual vote results for these proposals, but all four failed. > >As Holly has said, it's not clear that we're mandated to review these NC >proposals, but to the extent that it might be useful, here goes. > > >#170/194, seating both Kris and Tom, is problematical. Aside from needing >a suspension of the bylaws, it has the effect of double-counting ballots >cast for both Tom and Kris, of which there were many, though it's next to >impossible to quantify this effect. > >I can elaborate on this further, but it's hard to see how seating both >candidates represents the intent of a PR election. It would be perhaps >easier to justify as a political compromise if the two candidates had >essentially disjoint sets of supporters, but they clearly do not. >Consequently, many of the ballots that end up electing Tom or Kris under >the two transfer methods end up counting twice. > >Furthermore, the two methods for which we have results are not the only >two methods of counting STV elections. To be consistent, we'd have to >evaluate the results of all counting methods that comply with the bylaws, >and seat every candidate who was elected under any method. > > >#174, special election for the fourth seat. This solution would be >consistent with the bylaws, assuming that there was an empty fourth seat. >It's less than ideal, since the resulting single-seat election gives the >fourth seat to the majority of the NC, who we may presume are not the same >voters who would have chosen the fourth seat in the original STV election. > >Furthermore, as far as we know, any counting method that complies with the >bylaws elects a fourth candidate. The seat may be over-full, but it's not >empty. > > >#173, re-tabulate original election with "traditional" method and correct >threshold. The main drawback to this solution is that it did not pass the >NC. Nobody has argued that the method conflicts with the bylaws, and it >has the virtue of precedent, having been used without objection in 2004. >This would have been my choice, with the additional provision that we'd >evaluate STV counting methods for future elections, and specify ours more >precisely. > >While I'm the author of the "traditional" counting software, I'm not >(according to me, anyway) biased in its favor, in general. When we >recommend a going-forward counting method, I'll probably go with Meek's, >with a suitable variation for our fixed threshold, and subject to our >discussion. > >But Meek's is not the only STV counting method that has been advanced as >an improvement on the "traditional" one, and has no absolute claim to >being the one true method. Consequently, I adopt the principle of least >surprise, and prefer the "traditional" method because of precedent until a >new method is agreed to. > >-- >/Jonathan Lundell. >_______________________________________________ >SC-cochair-WG mailing list >SC-cochair-WG@gp-us.org >http://lists.gp-us.org/mailman/listinfo/sc-cochair-wg ------------------------- - Eric Prindle http://prindle.blogspot.com From jlundell@greens.org Tue Dec 27 19:41:20 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 19684 invoked from network); 27 Dec 2005 19:41:20 -0000 Received: from relay02.pair.com (209.68.5.16) by cesarchavez.cagreens.org with SMTP; 27 Dec 2005 19:41:20 -0000 Received: (qmail 35857 invoked by uid 0); 27 Dec 2005 19:41:15 -0000 Received: from unknown (HELO ?10.2.3.25?) (unknown) by unknown with SMTP; 27 Dec 2005 19:41:15 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> Date: Tue, 27 Dec 2005 11:41:15 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] just the facts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 12:40 PM -0600 12/27/05, Phil Huckelberry wrote: >I've finally managed to catch up on this discussion (and others, for that >matter) and it seems like there's a pretty good sense of the situation. > >I don't think the group should dive into the 2005 election, except that so >many odd things happened that we need to be clear in addressing these >things in the future: > >1. The bylaws specify STV, but do not specify how transfers should be >conducted (Hare or Meek). I've used the pSTV software and have found from >it that there are actually more than two variations, and the final bylaw >should explicitly state what algorithm will be used. Yes (and there are more variations not supported by pSTV, some of them quite intriguing). A side note: I'll be adding an option to my counting program to create a ballot file that pSTV can read. One of the drawbacks of pSTV is that its ballot file format is distinctly unfriendly. >2. Initially when the corrected results were reported to the SC, there >was no clarity as to whether Tom would "accept" the seat. I argued then >that withdrawing was not an appropriate option under our bylaws; if Tom >was elected, then he should have been seated, and if he wanted to >"decline", he would have needed to _resign_. Jonathan brought up at that >point the concept of rerunning the numbers with Tom removed so as to >preserve the proportionality of the original vote. I think what Jonathan >suggested was reasonable and sensible, but inconsistent with the current >bylaws. So regardless of whether a "withdrawal" happens pre- or post- >being seated, the bylaws need to be clear on whether the numbers will be >re-run or not. Again, yes. We should hash this out at greater length, but it seems to me that a re-run of the original election is appropriate within some time period (3-6 months?) of the election, because it yields a more "PR" result than a majority-rule vacancy election. It's always possible, of course, that a rerun of the election will not produce a threshold-crossing winner. More interestingly, I believe that it's in principle possible that after eliminating (say) Tom, that a rerun of the election is not guaranteed to elect the original three candidates. That was not the case here, but it could be, and that possibility needs to be accounted for. >3. The bylaws should clearly state how ties are to be broken. Yes. My algorithm, like Meek's, makes a (pseudo-)random choice. I believe that's the best alternative, but it should be specified. >Primarily via Proposal 194, the NC was subjected to what in my opinion was >a highly fragmented debate about what proportional representation actually >means and how to best uphold it. I thought the idea of splitting the seat >was actually highly violative of PR in two respects - one, you don't >change the nature of the body after an election; and two, the bylaws >specifically allow for a vacancy to be a suitable outcome of an election. >This latter point is something that's going to have to be resolved... And it needs more discussion. Under the rules, the vacancy throws the seat to the NC majority. Is that what we intend? >Jonathan has talked about using Meek's Method with dynamic thresholds, >which would eliminate the possibility of an election ending in a vacancy. >I very strongly believe that this is not a good idea. To be clear: Meek's method has a dynamic threshold, period. My observation is that we'd need to modify Meek's to comply with our threshold requirement. >The contentious >debate about the 2005 election has given me occassion to think a great >deal about how PR deals with minority blocs. In a nutshell, I think that >the party's advocacy for None of the Above as a viable option is too >significant to be tossed aside, and if NOTA "wins" a seat, then that's a >reasonable outcome. It's more violative of PR to allow a minority >candidate with insufficient support to cross a static threshold to be >seated than to declare a vacancy and move to an IRV election, in my >opinion. Maybe there is a way to split that divide. I find the interpretation of an explicit NOTA (or NOC) vote to be highly problematic in an STV context. A voter who votes A-NOTA means (by NOTA) "nobody but A", whereas a B-NOTA voter means "nobody but B". I'm not convinced that it's proper to conflate those two NOTA votes. I'm also unclear how an explicit NOTA could leave more than one seat empty, which presumably we'd want as a possibility. >I also think there are other little points that should be addressed. For >example, I think it is unwise to have the SC election be the last item on >the ANM agenda. I think delegates should know who their new SC is before >they depart, among other things. Was that what happened at Tulsa? We had to really scramble in Milwaukee, but we did manage to report results back before adjournment. From the point of view of a counter, I'd like to see the election happen at or near the end of the first day of a two-day meeting. >The silver lining of the 2005 debacle is that so many little things went >awry that I think the eventual bylaw is going to be able to be air tight. I hope so. I'd like to see a provision made, though, for a method of resolving future ambiguities when and if they arise. -- /Jonathan Lundell. From prindle@greens.org Tue Dec 27 19:48:46 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 20303 invoked from network); 27 Dec 2005 19:48:46 -0000 Received: from vms048pub.verizon.net (206.46.252.48) by cesarchavez.cagreens.org with SMTP; 27 Dec 2005 19:48:46 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS6003TF9P6WZ11@vms048.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Tue, 27 Dec 2005 13:48:43 -0600 (CST) Date: Tue, 27 Dec 2005 14:48:38 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] just the facts X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051227143927.04d51620@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: >1. The bylaws specify STV, but do not specify how transfers should be >conducted (Hare or Meek). I've used the pSTV software and have found from >it that there are actually more than two variations, and the final bylaw >should explicitly state what algorithm will be used. I agree, and I also note that many people have expressed a concern that they don't trust a computer program to operate as a black box. People want an election method that they have at least a reasonable chance of understanding, and I think our ability to translate whatever we come up with into explicit bylaws language is a good litmus test for that. >It's more violative of PR to allow a minority candidate with insufficient >support to cross a static threshold to be seated than to declare a vacancy >and move to an IRV election, in my opinion. Maybe there is a way to split >that divide. I think there is. I would argue that the threshold should be dynamic to a "floor" of half the initial threshold (plus a nominal offset). That way, NOTA only "wins" if it effectively gets _more_ votes than the last remaining unelected candidate. ------------------------- - Eric Prindle http://prindle.blogspot.com From phil@mcleancountygreens.org Tue Dec 27 19:55:22 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 20950 invoked from network); 27 Dec 2005 19:55:22 -0000 Received: from webmail1.sd.dreamhost.com (@66.33.201.159) by cesarchavez.cagreens.org with SMTP; 27 Dec 2005 19:55:22 -0000 Received: from webmail.mcleancountygreens.org (localhost [127.0.0.1]) by webmail1.sd.dreamhost.com (Postfix) with ESMTP id 0A5AD2C209 for ; Tue, 27 Dec 2005 11:55:12 -0800 (PST) Received: from 216.201.119.126 (SquirrelMail authenticated user phil@mcleancountygreens.org) by webmail.mcleancountygreens.org with HTTP; Tue, 27 Dec 2005 13:55:12 -0600 (CST) Message-ID: <2699.216.201.119.126.1135713312.squirrel@webmail.mcleancountygreens.org> In-Reply-To: References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> Date: Tue, 27 Dec 2005 13:55:12 -0600 (CST) Subject: Re: [SC-cochair-WG] just the facts From: "Phil Huckelberry" To: sc-cochair-wg@gp-us.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: Jonathan writes: > And it needs more discussion. Under the rules, the vacancy throws the > seat to the NC majority. Is that what we intend? I think it is what was *intended*, and I think such an intention *is* consistent with the basic tenets and common practice of proportional representation. I have not seen a good argument _against_ this as an intention. I've seen people slam this as an outcome, but the argument was always pejorative and not explanatory. For some people "throwing the seat to the NC majority" is some sort of a sin, but there's been no actual discussion of whether this is or is not consistent with principles and logic of proportional representation! >> Jonathan has talked about using Meek's Method with dynamic thresholds, >> which would eliminate the possibility of an election ending in a vacancy. >> I very strongly believe that this is not a good idea. > > To be clear: Meek's method has a dynamic threshold, period. My > observation is that we'd need to modify Meek's to comply with our > threshold requirement. Further clarity on two related points: 1. The tabulation method Roger presented to the NC did not use dynamic thresholds, but did use Meek-style transfers. 2. The pSTV software allows for different options to be selected when choosing Meek STV. One option is a choice between dynamic and static thresholds. There was a lot of confusion when Roger presented his findings because Meek's Method in and of itself would have been inconsistent with the bylaws, but the Meek-transfers algorithm with a static Droop threshold was not. I believe, Jonathan, that you had commented something along the lines that you weren't really sure that was an appropriate way to do things, but you couldn't think of any specific reason why it was inappropriate, either, it just wasn't something you'd ever seen employed before. > I find the interpretation of an explicit NOTA (or NOC) vote to be > highly problematic in an STV context. A voter who votes A-NOTA means > (by NOTA) "nobody but A", whereas a B-NOTA voter means "nobody but > B". I'm not convinced that it's proper to conflate those two NOTA > votes. I'm also unclear how an explicit NOTA could leave more than > one seat empty, which presumably we'd want as a possibility. The way the ballots were cast in Tulsa, NOTA was implicit, not explicit, based on where people stopped ranking. This was a point I stressed with the NC, because some people were clearly uncomfortable with not having NOTA available, but were assuaged by the idea of an implicit NOTA. >> I also think there are other little points that should be addressed. For >> example, I think it is unwise to have the SC election be the last item on >> the ANM agenda. I think delegates should know who their new SC is before >> they depart, among other things. > > Was that what happened at Tulsa? We had to really scramble in > Milwaukee, but we did manage to report results back before > adjournment. From the point of view of a counter, I'd like to see the > election happen at or near the end of the first day of a two-day > meeting. More than half of the NC was long gone before tabulation was completed. In part this was because the redundancy of the tabulation took a long time. We need to have a better system for producing ballots and making the ballots easier to evaluate. (This is something Jo and I talked about when we saw how long it was taking to do things like *sort* the ballots.) - Phil From prindle@greens.org Tue Dec 27 20:00:50 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 21552 invoked from network); 27 Dec 2005 20:00:50 -0000 Received: from vms046pub.verizon.net (206.46.252.46) by cesarchavez.cagreens.org with SMTP; 27 Dec 2005 20:00:50 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS600KZLA96WK3B@vms046.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Tue, 27 Dec 2005 14:00:43 -0600 (CST) Date: Tue, 27 Dec 2005 15:00:37 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] just the facts X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051227145758.04d82eb0@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: >I have not seen a good argument _against_ this as an intention. I've seen >people slam this as an outcome, but the argument was always pejorative and >not explanatory. For some people "throwing the seat to the NC majority" >is some sort of a sin, but there's been no actual discussion of whether >this is or is not consistent with principles and logic of proportional >representation! Under a static threshold, a single voter exhausting his or her ballot (an implicit NOTA vote) could in some situations throw the seat to the NC majority. In that scenario, NOTA is not the "will of the voters" but rather one person's veto. It is unlikely to happen, but three or four voters (out of a total of more than 100) could definitely exercise such a veto in many elections. That's why I don't think it's consistent with the principles of proportional representation. ------------------------- - Eric Prindle http://prindle.blogspot.com From jlundell@greens.org Tue Dec 27 21:49:11 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 27789 invoked from network); 27 Dec 2005 21:49:10 -0000 Received: from relay01.pair.com (209.68.5.15) by cesarchavez.cagreens.org with SMTP; 27 Dec 2005 21:49:10 -0000 Received: (qmail 54567 invoked by uid 0); 27 Dec 2005 21:47:07 -0000 Received: from unknown (HELO ?68.26.198.121?) (unknown) by unknown with SMTP; 27 Dec 2005 21:47:07 -0000 X-pair-Authenticated: 68.26.198.121 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.1.0.6.0.20051227143927.04d51620@mail.nyu.edu> References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <6.1.0.6.0.20051227143927.04d51620@mail.nyu.edu> Date: Tue, 27 Dec 2005 13:38:33 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] just the facts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 2:48 PM -0500 12/27/05, Eric J. Prindle wrote: >>1. The bylaws specify STV, but do not specify how transfers should >>be conducted (Hare or Meek). I've used the pSTV software and have >>found from it that there are actually more than two variations, and >>the final bylaw should explicitly state what algorithm will be used. > >I agree, and I also note that many people have expressed a concern >that they don't trust a computer program to operate as a black box. >People want an election method that they have at least a reasonable >chance of understanding, and I think our ability to translate >whatever we come up with into explicit bylaws language is a good >litmus test for that. I'm not sure I agree, or at least not entirely. Most of the pushback I get on PR generally, and STV in particular, is that it's too complicated and hard to understand. I'd settle for being able to independently audit the software being employed. The more-or-less "standard" description of Meek's method (Algorithm 123) runs to some six pages, plus a couple more of a proof that the algorithm results in a unique solution. If we end up agreeing that Meek's method (for example) is the one we want to use going forward, is there really a percentage in having that much detail in the bylaws? Do we want to settle for a less good method simply because it's easier to describe? After all, approval voting is much easier to describe and count than STV, but it's totally majority-take-all. >>It's more violative of PR to allow a minority candidate with >>insufficient support to cross a static threshold to be seated than >>to declare a vacancy and move to an IRV election, in my opinion. >>Maybe there is a way to split that divide. > >I think there is. I would argue that the threshold should be dynamic >to a "floor" of half the initial threshold (plus a nominal offset). >That way, NOTA only "wins" if it effectively gets _more_ votes than >the last remaining unelected candidate. Yes, I think it's important to recognize that we can set a floor on a dynamic threshold that can be lower than the Droop threshold. I'd like to note, though, that with a mandatory threshold, votes for NOTA (or rather for NOC) are implicit; there need be no explicit "votes for NOTA". -- /Jonathan Lundell. From phil@mcleancountygreens.org Wed Dec 28 02:25:00 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 8969 invoked from network); 28 Dec 2005 02:25:00 -0000 Received: from knife.dreamhost.com (postfix@66.33.219.6) by cesarchavez.cagreens.org with SMTP; 28 Dec 2005 02:25:00 -0000 Received: from important.mcleancountygreens.org (12-221-104-128.client.insightBB.com [12.221.104.128]) by knife.dreamhost.com (Postfix) with ESMTP id 28666FB87D for ; Tue, 27 Dec 2005 18:24:51 -0800 (PST) Message-Id: <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> X-Sender: huckelberry@mail.mcleancountygreens.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 Dec 2005 20:24:33 -0600 To: sc-cochair-wg@gp-us.org From: Phil Huckelberry Subject: Re: [SC-cochair-WG] just the facts In-Reply-To: <6.1.0.6.0.20051227145758.04d82eb0@mail.nyu.edu> References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: I'm quoting Eric replying to me from two separate messages. I want to make sure I'm understanding the arguments correctly. >>It's more violative of PR to allow a minority candidate with insufficient >>support to cross a static threshold to be seated than to declare a >>vacancy and move to an IRV election, in my opinion. Maybe there is a way >>to split that divide. > >I think there is. I would argue that the threshold should be dynamic to a >"floor" of half the initial threshold (plus a nominal offset). That way, >NOTA only "wins" if it effectively gets _more_ votes than the last >remaining unelected candidate. But this is precisely the case when using a Droop threshold, right? If there are [S] seats available, when the last STV round is reached, assuming there is one candidate left standing and [S-1] seats have been filled, and also assuming a fractional Droop threshold [D] that must be passed, there will be [D*2] votes left, split between the last standing candidate and "exhausted". If the candidate has more than [D] votes, she is elected. If not, then there were more exhausted votes than votes for [D] at that point; therefore, (implicit) NOTA only "won" when NOTA had more votes than the last remaining unelected candidate. In essence, isn't using a Droop threshold as opposed to a Hare threshold already a "split of the divide"? >Under a static threshold, a single voter exhausting his or her ballot (an >implicit NOTA vote) could in some situations throw the seat to the NC >majority. In that scenario, NOTA is not the "will of the voters" but >rather one person's veto. It is unlikely to happen, but three or four >voters (out of a total of more than 100) could definitely exercise such a >veto in many elections. That's why I don't think it's consistent with the >principles of proportional representation. Why is this considered a veto? Either the last standing candidate has sufficient support or he does not. If the last standing candidate has less overall support than (implicit) NOTA, in essence, the controlling bloc at this point - the bloc of voters with exhausted ballots whose votes are implicitly for NOTA - are not vetoing the other candidate, but are affirmatively choosing a vacancy, and therefore an IRV vote, over that other candidate. That might be little more than a veto, but it might also be a legitimate sentiment for NOTA, in that they want someone who wasn't running. Part of what I'm trying to understand is why throwing a seat back to a majority-of-the-body vote is so violative of PR in a situation like this. My understanding all along has been that one of the things that's great about STV is that it ensures minority representation but also protects the majority by avoiding a situation where candidates with insufficient support get elected because somebody has to get elected. Now, I have a related question about this. Consider the original incorrect results of the Tulsa election that ended in the vacancy. More than three candidates received approval votes exceeding 50%... would it have been violative of PR to have retabulated the results, removing the three candidates already elected, so as to use the existing ballots instead of having a re-vote? I'm not saying this is a good route, but I'm trying to get more of a philosophical/theoretical understanding for what we mean by PR and how we can best secure it. - Phil From jlundell@greens.org Wed Dec 28 20:22:35 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 26275 invoked from network); 28 Dec 2005 20:22:34 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 28 Dec 2005 20:22:34 -0000 Received: (qmail 37182 invoked by uid 0); 28 Dec 2005 20:22:31 -0000 Received: from unknown (HELO ?192.168.0.3?) (unknown) by unknown with SMTP; 28 Dec 2005 20:22:31 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> Date: Wed, 28 Dec 2005 12:20:50 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] just the facts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 8:24 PM -0600 12/27/05, Phil Huckelberry wrote: >Part of what I'm trying to understand is why throwing a seat back to >a majority-of-the-body vote is so violative of PR in a situation >like this. My understanding all along has been that one of the >things that's great about STV is that it ensures minority >representation but also protects the majority by avoiding a >situation where candidates with insufficient support get elected >because somebody has to get elected. The question becomes, what constitutes "sufficient support"? And a related question: is the implication of using a Droop (or Hare) threshold that "sufficient support" is a function of the number of open seats a valid one? I understand, of course, that Droop is the minimum threshold that guarantees that not more than the number of open seats can be elected. But it doesn't follow that we should be willing to lower the threshold if necessary to fill the seat(s)? Or alternatively, what's the smallest minority bloc we're willing to give representation to, as long as the number of open seats isn't exceeded? A frequent problem arises when an odd-numbered body is elected in staggered elections. We get (say) alternating elections of 3 and 4 seats, and of 25% and 20% thresholds. If 20% is enough to earn a seat in the 4-seat election, why not in the 3-seat election (as long as only 3 seats are elected)? One argument might be that if we think that (say) 10% minorities ought to be represented, then we ought to have a (roughly) 10-member body, so that such representation can be consistently earned. And that's the argument for using a Droop threshold: in setting the body (or election) size, we're also defining the size of minority can can be guaranteed representation. That is, the Droop threshold isn't an accident; it's implicit in our determination of the correct body size. If we mean to extend representation to 10% minorities, then it's a mistake to have a 7-member board (or to have staggered elections, for that matter). >Now, I have a related question about this. Consider the original >incorrect results of the Tulsa election that ended in the vacancy. >More than three candidates received approval votes exceeding 50%... >would it have been violative of PR to have retabulated the results, >removing the three candidates already elected, so as to use the >existing ballots instead of having a re-vote? I'm not saying this >is a good route, but I'm trying to get more of a >philosophical/theoretical understanding for what we mean by PR and >how we can best secure it. I made an improvement to my counting software, post-Tulsa, that tries to address this issue. Suppose that 19 had been the correct threshold (that there had been one more ballot, let's say for the sake of the argument voting only for non-contenders, and so exhausted early on). After the third seat is filled, the new version recognizes that Tom, with a residual approval of only 18.8+, cannot possibly cross the threshold of 19. (Residual approval is the approval on ballots still in play.) Therefore, Tom is eliminated as "hopeless", and one of the remaining candidates (in this election Budd Dickinson) is elected. Without this "hopeless" calculation, Tom ends up eliminating all remaining candidates on the basis of top-choice votes until he's the last candidate standing, and is eliminated himself for not crossing the threshold. This is clearly inconsistent with voter intent. If I rank an ultimately unelectable candidate T ahead of candidate B, it should not hurt candidate B's chances, assuming that candidate T is not elected. STV is something of a blunt instrument, and we can't prevent all such anomalies (and hence the interest in variations such as Meek's, Warren's, multi-round Meek's, etc). -- /Jonathan Lundell. From phil@mcleancountygreens.org Thu Dec 29 07:38:11 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 29549 invoked from network); 29 Dec 2005 07:38:11 -0000 Received: from whisk.dreamhost.com (205.196.208.4) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 07:38:11 -0000 Received: from important.mcleancountygreens.org (12-221-104-128.client.insightBB.com [12.221.104.128]) by whisk.dreamhost.com (Postfix) with ESMTP id A47467F0CB for ; Wed, 28 Dec 2005 23:38:04 -0800 (PST) Message-Id: <5.1.0.14.2.20051228204125.02f60008@mail.mcleancountygreens.org> X-Sender: huckelberry@mail.mcleancountygreens.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 Dec 2005 01:38:01 -0600 To: sc-cochair-wg@gp-us.org From: Phil Huckelberry Subject: Re: [SC-cochair-WG] just the facts In-Reply-To: References: < <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: >The question becomes, what constitutes "sufficient support"? And a related >question: is the implication of using a Droop (or Hare) threshold that >"sufficient support" is a function of the number of open seats a valid one? I don't see why making "sufficient support" a function of the number of open seats isn't a valid implication. >A frequent problem arises when an odd-numbered body is elected in >staggered elections. We get (say) alternating elections of 3 and 4 seats, >and of 25% and 20% thresholds. If 20% is enough to earn a seat in the >4-seat election, why not in the 3-seat election (as long as only 3 seats >are elected)? What is the most sensible way to resolve this? I am also curious about a related issue. I have long maintained that an electorate - be it the voting public or be it a body like the NC - should retain the right to recall an elected official. Is there a way to make recall consistent with STV without making the recall threshold incredibly high (say, above 80%?) I imagine this is somewhat outside the purview of this group, but I'm wondering if there's already a littany of arguments behind it... >Without this "hopeless" calculation, Tom ends up eliminating all remaining >candidates on the basis of top-choice votes until he's the last candidate >standing, and is eliminated himself for not crossing the threshold. > >This is clearly inconsistent with voter intent. If I rank an ultimately >unelectable candidate T ahead of candidate B, it should not hurt candidate >B's chances, assuming that candidate T is not elected. In other words, there are yet more nuances to STV available, which means it is all the more important to explicitly specify a particular universally defined algorithm, right? - Phil From scooter@guisarme.net Thu Dec 29 17:19:42 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 27331 invoked from network); 29 Dec 2005 17:19:42 -0000 Received: from blade.guisarme.net (HELO guisarme.net) (144.202.242.217) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 17:19:42 -0000 Received: from localhost (unknown [127.0.0.1]) by guisarme.net (Postfix) with ESMTP id 57148100092 for ; Thu, 29 Dec 2005 12:17:52 -0500 (EST) Received: from guisarme.net ([127.0.0.1]) by localhost (blade.guisarme.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14218-01-4 for ; Thu, 29 Dec 2005 12:17:51 -0500 (EST) Received: by guisarme.net (Postfix, from userid 1006) id C090C100093; Thu, 29 Dec 2005 12:17:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by guisarme.net (Postfix) with ESMTP id BDD9A100092 for ; Thu, 29 Dec 2005 12:17:51 -0500 (EST) Date: Thu, 29 Dec 2005 12:17:51 -0500 (EST) From: Steve Kramer To: sc-cochair-wg@gp-us.org Subject: Re: [SC-cochair-WG] just the facts In-Reply-To: <5.1.0.14.2.20051228204125.02f60008@mail.mcleancountygreens.org> Message-ID: References: < <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> <5.1.0.14.2.20051228204125.02f60008@mail.mcleancountygreens.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at guisarme.net Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: On Thu, 29 Dec 2005, Phil Huckelberry wrote: [snip] > I am also curious about a related issue. I have long maintained that an > electorate - be it the voting public or be it a body like the NC - should > retain the right to recall an elected official. Is there a way to make > recall consistent with STV without making the recall threshold incredibly > high (say, above 80%?) I imagine this is somewhat outside the purview of > this group, but I'm wondering if there's already a littany of arguments > behind it... > There is a possible problem with recall as a device in a body elected by STV. For example, in the case of an eight person panel, it is assumed that a 12.5% level of support in the electorate is sufficient to elect a single representative. However, even in the case of a 80% hurdle to clear for recall, that 12.5% support would not be sufficient to keep them in office in a singular recall vote. -- Steve Kramer || scooter (at) guisarme dot net || _____________________ =================================================== | __/^\__ ,-^,| |/~ \_ { / | "The problem with the world is that \/\ |! | everyone is a few drinks behind." / / ) |___ (_ \ \ / Humphrey Bogart ~v^ ?_,-' From jlundell@greens.org Thu Dec 29 17:46:08 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 28766 invoked from network); 29 Dec 2005 17:46:08 -0000 Received: from relay03.pair.com (209.68.5.17) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 17:46:08 -0000 Received: (qmail 91210 invoked by uid 0); 29 Dec 2005 17:46:04 -0000 Received: from unknown (HELO ?192.168.0.3?) (unknown) by unknown with SMTP; 29 Dec 2005 17:46:04 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: Date: Thu, 29 Dec 2005 09:45:47 -0800 To: GPUS SC Election WG From: Jonathan Lundell Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SC-cochair-WG] Voting Matters Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: Those of you who aren't already reading Voting Matters, and are interested in STV, ought to start right now. http://www.mcdougall.org.uk/VM/MAIN.HTM Of particular interest in the latest issue are the Meek/Warren article and the sequential STV article (and its 2002 predecessor). But it's all good.... -- /Jonathan Lundell. From jlundell@greens.org Thu Dec 29 17:46:02 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 28705 invoked from network); 29 Dec 2005 17:46:02 -0000 Received: from relay03.pair.com (209.68.5.17) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 17:46:02 -0000 Received: (qmail 91172 invoked by uid 0); 29 Dec 2005 17:45:58 -0000 Received: from unknown (HELO ?192.168.0.3?) (unknown) by unknown with SMTP; 29 Dec 2005 17:45:58 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <5.1.0.14.2.20051228204125.02f60008@mail.mcleancountygreens.org> References: < <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> <5.1.0.14.2.20051228204125.02f60008@mail.mcleancountygreens.org> Date: Thu, 29 Dec 2005 09:34:21 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] just the facts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 1:38 AM -0600 12/29/05, Phil Huckelberry wrote: >>The question becomes, what constitutes "sufficient support"? And a >>related question: is the implication of using a Droop (or Hare) >>threshold that "sufficient support" is a function of the number of >>open seats a valid one? > >I don't see why making "sufficient support" a function of the number >of open seats isn't a valid implication. As below, when the number of open seats varies. Or, I suppose (not our current problem) when there are so many seats that the threshold becomes too low, especially if there's a paucity of viable candidates. >>A frequent problem arises when an odd-numbered body is elected in >>staggered elections. We get (say) alternating elections of 3 and 4 >>seats, and of 25% and 20% thresholds. If 20% is enough to earn a >>seat in the 4-seat election, why not in the 3-seat election (as >>long as only 3 seats are elected)? > >What is the most sensible way to resolve this? One way would be to have an even number of seats (I don't really buy the tie-breaking argument in our environment), or 0 mod 3 seats and 3-year staggered terms. I think it's a problem we can live with. But the effect is likely more significant than the choice of STV counting method. >I am also curious about a related issue. I have long maintained >that an electorate - be it the voting public or be it a body like >the NC - should retain the right to recall an elected official. Is >there a way to make recall consistent with STV without making the >recall threshold incredibly high (say, above 80%?) I imagine this >is somewhat outside the purview of this group, but I'm wondering if >there's already a littany of arguments behind it... I'm curious about the same thing. Recall seems inconsistent with STV--at least any straightforward definition of recall. Is it hairsplitting to make a distinction for impeachment (removal for cause) and recall? >>Without this "hopeless" calculation, Tom ends up eliminating all >>remaining candidates on the basis of top-choice votes until he's >>the last candidate standing, and is eliminated himself for not >>crossing the threshold. >> >>This is clearly inconsistent with voter intent. If I rank an >>ultimately unelectable candidate T ahead of candidate B, it should >>not hurt candidate B's chances, assuming that candidate T is not >>elected. > >In other words, there are yet more nuances to STV available, which >means it is all the more important to explicitly specify a >particular universally defined algorithm, right? Yes, with the recognition that we might want to revisit the algorithm from time to time. STV methodology is an area of lively discussion. I suppose that algorithm choice and evolution ought to be a role for the standing election committee--charge them to stay abreast of research and recommend changes as appropriate. -- /Jonathan Lundell. From prindle@greens.org Thu Dec 29 18:35:22 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 31999 invoked from network); 29 Dec 2005 18:35:21 -0000 Received: from vms040pub.verizon.net (206.46.252.40) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 18:35:21 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS900AMUVMV4KRS@vms040.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Thu, 29 Dec 2005 12:35:20 -0600 (CST) Date: Thu, 29 Dec 2005 13:35:04 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] just the facts In-reply-to: X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051229133119.01edd860@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <6.1.0.6.0.20051227143927.04d51620@mail.nyu.edu> Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: >The more-or-less "standard" description of Meek's method (Algorithm 123) >runs to some six pages, plus a couple more of a proof that the algorithm >results in a unique solution. If we end up agreeing that Meek's method >(for example) is the one we want to use going forward, is there really a >percentage in having that much detail in the bylaws? Do we want to settle >for a less good method simply because it's easier to describe? After all, >approval voting is much easier to describe and count than STV, but it's >totally majority-take-all. I think it's a trade-off. The systems that are easier to describe are also easier to manipulate. I'm willing to put up with a pretty high degree of complexity in order to have a system that makes it very difficult to gain an unfair advantage through "strategic voting," but that willingness is not absolute. And given the experience of the Tulsa election, I cannot support using a system that is not described in exact detail in the bylaws. We don't need proofs; the bylaws don't need to justify themselves. But if the algorithm is not in the bylaws, we stand a good chance of running into the same problem again, and I doubt the proposal will even pass. (Remember, we are not here to spell out our ideal election system but rather one that we expect can muster 2/3 of the votes of the NC.) ------------------------- - Eric Prindle http://prindle.blogspot.com From prindle@greens.org Thu Dec 29 18:39:32 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 32302 invoked from network); 29 Dec 2005 18:39:32 -0000 Received: from vms042pub.verizon.net (206.46.252.42) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 18:39:32 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS90053YVTTHXQ4@vms042.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Thu, 29 Dec 2005 12:39:30 -0600 (CST) Date: Thu, 29 Dec 2005 13:39:14 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] just the facts In-reply-to: <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens .org> X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051229133520.01edb440@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: My last statement about the problem with "throwing the seat to the majority" was in error because I wasn't thinking about it from a Droop perspective. However, I think this raises Jonathan's previous point: the implicit "NOTA" of voters exhausting their ballots does not "mean" the same thing for each voter. In a highly factional election like the one in Tulsa, I doubt very much that members of the minority faction exhausted their ballots with the goal of throwing the final seat to the majority; members of the majority faction, on the other hand, may have wanted precisely that result. NOTA makes sense in single-seat IRV elections because if no candidate can muster a majority, the same voters come back and choose from among a new set of candidates. In a multi-seat STV election, it's a totally different situation because the group of voters filling the vacancy is not the same as the group of voters who created it in the first place. >I'm quoting Eric replying to me from two separate messages. I want to >make sure I'm understanding the arguments correctly. > >>>It's more violative of PR to allow a minority candidate with >>>insufficient support to cross a static threshold to be seated than to >>>declare a vacancy and move to an IRV election, in my opinion. Maybe >>>there is a way to split that divide. >> >>I think there is. I would argue that the threshold should be dynamic to a >>"floor" of half the initial threshold (plus a nominal offset). That way, >>NOTA only "wins" if it effectively gets _more_ votes than the last >>remaining unelected candidate. > >But this is precisely the case when using a Droop threshold, right? If >there are [S] seats available, when the last STV round is reached, >assuming there is one candidate left standing and [S-1] seats have been >filled, and also assuming a fractional Droop threshold [D] that must be >passed, there will be [D*2] votes left, split between the last standing >candidate and "exhausted". If the candidate has more than [D] votes, she >is elected. If not, then there were more exhausted votes than votes for >[D] at that point; therefore, (implicit) NOTA only "won" when NOTA had >more votes than the last remaining unelected candidate. In essence, isn't >using a Droop threshold as opposed to a Hare threshold already a "split of >the divide"? > >>Under a static threshold, a single voter exhausting his or her ballot (an >>implicit NOTA vote) could in some situations throw the seat to the NC >>majority. In that scenario, NOTA is not the "will of the voters" but >>rather one person's veto. It is unlikely to happen, but three or four >>voters (out of a total of more than 100) could definitely exercise such a >>veto in many elections. That's why I don't think it's consistent with the >>principles of proportional representation. > >Why is this considered a veto? Either the last standing candidate has >sufficient support or he does not. If the last standing candidate has >less overall support than (implicit) NOTA, in essence, the controlling >bloc at this point - the bloc of voters with exhausted ballots whose votes >are implicitly for NOTA - are not vetoing the other candidate, but are >affirmatively choosing a vacancy, and therefore an IRV vote, over that >other candidate. That might be little more than a veto, but it might also >be a legitimate sentiment for NOTA, in that they want someone who wasn't >running. > >Part of what I'm trying to understand is why throwing a seat back to a >majority-of-the-body vote is so violative of PR in a situation like >this. My understanding all along has been that one of the things that's >great about STV is that it ensures minority representation but also >protects the majority by avoiding a situation where candidates with >insufficient support get elected because somebody has to get elected. > >Now, I have a related question about this. Consider the original >incorrect results of the Tulsa election that ended in the vacancy. More >than three candidates received approval votes exceeding 50%... would it >have been violative of PR to have retabulated the results, removing the >three candidates already elected, so as to use the existing ballots >instead of having a re-vote? I'm not saying this is a good route, but I'm >trying to get more of a philosophical/theoretical understanding for what >we mean by PR and how we can best secure it. > >- Phil > >_______________________________________________ >SC-cochair-WG mailing list >SC-cochair-WG@gp-us.org >http://lists.gp-us.org/mailman/listinfo/sc-cochair-wg ------------------------- - Eric Prindle http://prindle.blogspot.com From prindle@greens.org Thu Dec 29 18:49:16 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 438 invoked from network); 29 Dec 2005 18:49:16 -0000 Received: from vms042pub.verizon.net (206.46.252.42) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 18:49:16 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS9003JYWA2TW73@vms042.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Thu, 29 Dec 2005 12:49:15 -0600 (CST) Date: Thu, 29 Dec 2005 13:48:59 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] just the facts In-reply-to: <5.1.0.14.2.20051228204125.02f60008@mail.mcleancountygreens .org> X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051229134546.01ed9930@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: <" <5.1.0.14.2.20051227195157.02f06008"@mail.mcleancountygreens.org> <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> <5.1.0.14.2.20051228204125.02f60008@mail.mcleancountygreens.org> Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: >I am also curious about a related issue. I have long maintained that an >electorate - be it the voting public or be it a body like the NC - should >retain the right to recall an elected official. Is there a way to make >recall consistent with STV without making the recall threshold incredibly >high (say, above 80%?) I imagine this is somewhat outside the purview of >this group, but I'm wondering if there's already a littany of arguments >behind it... One possible solution would be to have a two-track recall system. You could recall a single SC member with a vote of 100 percent minus the election quota the year she or he was elected, "plus one." Alternatively, you could recall the _all_ the SC co-chairs simultaneously with a simple majority vote (or two-thirds majority if you prefer). This would recognize the ambiguity of the STV situation, in which the entire body that's elected is in one sense a single "elected official," at the same time consisting of a number of officials who were effectively elected by segments of the voters. ------------------------- - Eric Prindle http://prindle.blogspot.com From prindle@greens.org Thu Dec 29 18:50:33 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 574 invoked from network); 29 Dec 2005 18:50:33 -0000 Received: from vms046pub.verizon.net (206.46.252.46) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 18:50:33 -0000 Received: from EricPrindle.verizon.net ([71.242.151.13]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IS900ASBWC7IB32@vms046.mailsrvcs.net> for sc-cochair-wg@gp-us.org; Thu, 29 Dec 2005 12:50:32 -0600 (CST) Date: Thu, 29 Dec 2005 13:44:52 -0500 From: "Eric J. Prindle" Subject: Re: [SC-cochair-WG] just the facts In-reply-to: X-Sender: ejp236@mail.nyu.edu To: sc-cochair-wg@gp-us.org Message-id: <6.1.0.6.0.20051229133941.01ed6db0@mail.nyu.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: >The question becomes, what constitutes "sufficient support"? I think the answer to this is pretty straightforward. In a single-seat election, where one person has to represent 100 percent of the voting population, 50 percent plus one is "sufficient support" for election. Agreed? Well then in an election for four seats, where each person theoretically represents 25 percent of the voting population, I would argue that 12.5 percent plus one is "sufficient support" in the final analysis. This brings me to another point I wanted to make: I think our initial choice of the Droop quota was the wrong one, and we should switch to the Hare quota. I'm taking this position for two related reasons. 1) Under the Droop quota, when four seats are to be filled, about one-fifth of the voting population goes essentially unrepresented. In Tulsa, we had two candidates who both theoretically represented about one-fifth of the voters, and the controversy was over which fifth would go unrepresented. After the fact, this seemed a little strange to me. Under the Hare quota, a problem like this would only arise if it was unclear which candidate was the best representative of the "last" fourth of the voters. 2) The Droop quota gives a slight advantage to majority factions. To the extent that the GPUS has factions, a majority faction already has an advantage in the elections for Secretary and Treasurer, so I don't think they should have this advantage as well. ------------------------- - Eric Prindle http://prindle.blogspot.com From jlundell@greens.org Thu Dec 29 19:34:53 2005 Return-Path: Delivered-To: usgp-mx-sc-cochair-wg@gp-us.org Received: (qmail 3002 invoked from network); 29 Dec 2005 19:34:52 -0000 Received: from relay00.pair.com (209.68.5.9) by cesarchavez.cagreens.org with SMTP; 29 Dec 2005 19:34:52 -0000 Received: (qmail 3892 invoked by uid 0); 29 Dec 2005 19:34:49 -0000 Received: from unknown (HELO ?192.168.0.3?) (unknown) by unknown with SMTP; 29 Dec 2005 19:34:49 -0000 X-pair-Authenticated: 207.213.214.33 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.1.0.6.0.20051229133941.01ed6db0@mail.nyu.edu> References: <5.1.0.14.2.20051227095901.02e2bd80@mail.mcleancountygreens.org> <2022.216.201.119.126.1135708839.squirrel@webmail.mcleancountygreens.org> <5.1.0.14.2.20051227195157.02f06008@mail.mcleancountygreens.org> <6.1.0.6.0.20051229133941.01ed6db0@mail.nyu.edu> Date: Thu, 29 Dec 2005 11:30:54 -0800 To: sc-cochair-wg@gp-us.org From: Jonathan Lundell Subject: Re: [SC-cochair-WG] just the facts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sc-cochair-wg-admin@gp-us.org Errors-To: sc-cochair-wg-admin@gp-us.org X-BeenThere: sc-cochair-wg@gp-us.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: sc-cochair-wg@gp-us.org List-Help: List-Post: List-Subscribe: , List-Id: Steering Cmte Cochair Working Group List-Unsubscribe: , List-Archive: At 1:44 PM -0500 12/29/05, Eric J. Prindle wrote: >>The question becomes, what constitutes "sufficient support"? > >I think the answer to this is pretty straightforward. In a >single-seat election, where one person has to represent 100 percent >of the voting population, 50 percent plus one is "sufficient >support" for electi