[EM] Yes/?/No

robert bristow-johnson rbj at audioimagination.com
Mon Nov 2 07:32:36 PST 2020



> On 11/02/2020 5:00 AM Kristofer Munsterhjelm <km_elmet at t-online.de> wrote:
> 
>  
> On 01/11/2020 02.34, robert bristow-johnson wrote:
> > 
> > 
> >> On 10/31/2020 9:03 PM Forest Simmons <fsimmons at pcc.edu> wrote:
> >>
> >>
> >> Approval is one of the easiest election methods to explain and to
> >> understand; the ballots are identical to traditional FPP ballots except
> >> the instructions now say to mark the names of all of the candidates that
> >> you like instead of only one of them. As before the winner is the
> >> candidate with the greatest number of likes.
> >>
> >> But what about the candidates that you just like a little bit? Do
> >> you include them or not? Where do you draw the line between like and not like?
> >>
> > 
> > i've been trying for a couple years to get the Election Science
> > people to answer that simple question.  should a voter approve of their second
> > choice or not?  there is no simple answer and the voter is burdened with
> > the task of tactical voting.
> 
> The simple answer is that any ranked method has to decide the answer to
> some pretty tough elections. (Burlington being one of them.) Approval
> abdicates the responsibility to get them right, and places it on the
> voters instead.

that's not an answer (simple or not) to my question.  the question is simply this: in Fargo North Dakota (which, BTW, is 30 km from where i grew up in the '50s, '60s, and '70s) where they have adopted Approval Voting (as best as i can tell, it's the only U.S. jurisdiction to do so), in an election with 3 or more candidates, should the voter Approve their second-preferred candidate?

that is a specific question.  and it has no non-tactical answer.

(but with the ranked ballot, there is a simple non-tactical answer to the question of what the voter should do with their second choice.  unfortunately, with Hare-STV that simple answer might hurt the voter's political interest.)

> That's how it can, on paper, satisfy so many desirable
> properties (like IIA); but in a sense, it's a trick.
> 
> Approval is very simple to understand (procedurally) and count, 

but it's not easy to vote.  it forces every voter to vote tactically.

> and it
> probably *is* the best incremental change to FPTP if you're only allowed
> to make a slight change. But if you can aim higher, there are plenty of
> ranked methods better than it. IMHO.
> 

since we're already making the leap to RCV (and this year it looks like RCV is picking up steam), we should make a slight change to RCV to fix this obvious problem that was manifest in Burlington Vermont in 2009.  as best as i can tell, BTR-STV is the simplest, slightest change that does that.

BTW, in case anyone is interested, I wrote a "white paper" directed toward Burlingtonians (and other Vermonters) about this that has slightly more accurate numbers than either Warren Smith or Brian Olson's analysis.

https://www.dropbox.com/s/umfyn6roysithpg/The%20Impetus%2C%20Necessity%2C%20and%20Purpose%20of%20Ranked-Choice%20Voting.pdf?dl=0

and i have been able to find a nice and free copy of the Scientific American article from 2004, co-written by Nobel laureate Eric Maskin about RCV and Condorcet.  but i don't like his terminology in two cases.

https://www.dropbox.com/s/jl8cwhwhdsy10gh/The%20Fairest%20Vote%20of%20All.pdf?dl=0

also, I didn't report that, despite a mayoral veto, i was not successful in getting a Condorcet-compliant RCV on to the ballot for March Town Meeting.  but the Progs have fucked up their RCV ballot question so bad that i think it will fail in March.  i **did** persuade a couple of state legislators (one on the Gov. Ops. committee) as to what the problem is and what a solution could be (and i am plugging BTR-STV, simply because it is the simplest adjustment to the existing Hare STV to make it Condorcet compliant, sorry Markus).

-- 

r b-j                  rbj at audioimagination.com 

"Imagination is more important than knowledge."


More information about the Election-Methods mailing list