Re: "Removed statement there is one vote per available seat" - was Re: W3C Process 2018

The more I think of this, the more I remain convinced that we should
go back to old, simple, and transparent voting system.

Michael Champion writes:
 > > * Run the STV tabulation on the preference lists as if there were only one available seat; elect that candidate; mark that candidate as ‘withdrawn’ 
 > > * Repeat for the remaining seats: Re-run the STV tabulation on the preference lists as if there were only one available seat; elect that candidate, mark that candidate as ‘withdrawn’ 
 > > I am not sure whether anyone anywhere uses STV like this, and I am not aware of any analysis or papers, and absent some sort of analysis, I would be pretty hesitant to adopt it. If you mean something else, please say (notably something in use and analyzed).If you mean something else, please say (notably something in use and analyzed).
 > 
 > That’s what I meant.  It’s how I assumed STV would work in the W3C context.  It’s more or less how the old system worked:
 > 
 > - Run the (trivial) tabulation of who got the most votes for the first available seat; elect that candidate;
 > - Repeat for the remaining seats: Run the (trivial) tabulation of who got the next most votes, elect that candidate
 > 
 > except that we would have a complicated STV tablulation based on preference  order rather than simple count of votes. 
 > 
 > I’m not necessarily advocating this procedure, I’m leaning toward just going back to the simple system we used to have. I’m just pointing out to the AC what I only recently understood: we no longer get to vote for the set of people we think are most qualified for various reasons, we are forced to rank them on some arbitrary scale, and only one vote ends up actually counting.  This is a fundamental change in the election philosophy that never got discussed as far as I can find in the archives. As Florian points out, it’s hard to reason about the implications of changing the voting system, but I don’t want to gloss this over as a simple bug in Process 2017 that can be fixed by removing the “one vote per available seat” language. 
 > 
 > 
 > 
 > > On Sep 29, 2017, at 12:39 PM, David Singer <singer@apple.com> wrote:
 > > 
 > > (I have reduced the number of mailing lists; surely we don’t need the AB and chairs explicitly in addition to the AC and the Process CG?)
 > > 
 > >> On Sep 28, 2017, at 15:34 , Michael Champion <michaelc.champion@gmail.com> wrote:
 > >> 
 > >> I’d like to bring to the AC’s attention one proposed change that I’m uncomfortable with,  to see what others think.  Process 2017 made official the voting system that we had experimented with for a couple of years, in which AC reps rank candidates for TAG and AB elections and then a Single Transferrable Vote algorithm computes a winner for each available seat. But Process 2017 left in this language in Section  7.3: 'In the case of Advisory Board and TAG elections, "one vote" means "one vote per available seat”.' I for one thought it was a feature, since it clarified that there was still one vote per available seat, and the ranking system encouraged people to vote for their preferred candidate knowing that each vote would still count even if their first choice didn’t get much support.   Others consider that a bug that needs to be fixed in Process 2018 by removing that sentence, since STV implies that each AC member has a single vote that gets transferred.  The team actually implemented the “one vote per election” rather than “one vote per available seat” method, since this is apparently how STV is used in practice around the world in cases where there are multiple open seats.  
 > >> 
 > >> To the best of my recollection this was never discussed while we were deliberating moving to the STV system. There is no mechanical reason the procedure as written in Process 2017 couldn’t be used:  The team would run the STV algorithm for each available seat, removing the winners of previous open seats (and reallocating their votes).  This how I thought the STV elections worked — AC members still had one vote per available seat, but ranked candidates rather than making binary choice for each.  
 > >> 
 > >> Since only the Team has access to the raw vote data, this discrepancy wasn’t noticed until recently.  Does it matter?  Definitely, the results can be different.   There is a GitHub discussion of this issue in which I go through a hypothetical example  https://github.com/w3c/w3process/issues/60#issuecomment-323474691 to illustrate how the different approaches work.  The  currently implemented STV system would make it easier to elect TAG and AB members ranked #1 by a substantial minority of the AC, the one-vote-per-available-seat STV system would tend to elect people broadly ranked in the top few spots.
 > >> 
 > >> To me, the question for the AC is: “When you voted to adopt the STV system, did you think we were making a fundamental change and giving you only one vote that actually counts in AB and TAG elections, or did you think we were keeping the one vote per available seat system but allowing you to rank candidates rather saying Yes or No to each? " 
 > >> 
 > >> I can live with whatever a majority of the AC thinks on this, but I didn’t want to support the proposed change until hearing what others on the AC thought. 
 > > 
 > > Lots of random thoughts here.
 > > 
 > > I am not sure what the application of STV using “one vote per available seat” would mean. I suspect it’s something like:
 > > * Run the STV tabulation on the preference lists as if there were only one available seat; elect that candidate; mark that candidate as ‘withdrawn’ 
 > > * Repeat for the remaining seats: Re-run the STV tabulation on the preference lists as if there were only one available seat; elect that candidate, mark that candidate as ‘withdrawn’ 
 > > I am not sure whether anyone anywhere uses STV like this, and I am not aware of any analysis or papers, and absent some sort of analysis, I would be pretty hesitant to adopt it. If you mean something else, please say (notably something in use and analyzed).
 > > 
 > > That this would have different effects is probably true; under the current tabulation, a winning quota <https://en.wikipedia.org/wiki/Counting_single_transferable_votes#Droop_quota> depends on the number of available seats. So, for example, 
 > > if we had had 80 ballots cast for 4 seats in the last election, the quota is (80/5)+1 = 17, whereas in what I wrote above it would be 80/2+1 = 41 on each round (‘pretend only one seat is open’). That lower quota is precisely what gives us a possibility of greater diversity; if there is a candidate who a quota’th proportion of the AC really wants, they can get elected, even if no other AC rep wants them at all (no votes transfer to them). As the quota rises, the importance of transferred (second, third, preference) votes rises. So yes, I expect to see more ‘minority’ (is that synonymous with ‘diversity’?) candidates elected under STV.
 > > 
 > > Yes, I am slightly disturbed that in the recent election, I don’t think 4th preference votes had any effect on the outcome (even though there were 4 seats), whereas previously, my N votes for M seats all piled into the pool.
 > > 
 > > It has been said that STV makes it harder to do ‘strategic voting’ — you just express your preference, and the tabulation process will apply it, and that’s the best way to influence the result towards what you want. Wikipedia (surprise) has discussion of tactical voting <https://en.wikipedia.org/wiki/Issues_affecting_the_single_transferable_vote#Tactical_voting> and this is particularly relevant if your top desire is to try to make sure someone is NOT elected. Yes, tactical voting is harder than the previous first-past-the-post. (Tactical voting there, as has been pointed out, can mean only voting for the candidates you really want to see elected, and not casting all N votes that you are allowed to.)
 > > 
 > > 
 > > 
 > > Dave Singer
 > > 
 > > singer@mac.com
 > > 
 > > 
 > > 
 > > David Singer
 > > Manager, Software Standards, Apple Inc.
 > > 
 > > 
 > 

--

Received on Friday, 29 September 2017 22:51:43 UTC