[EM] Tweaks to Asset Voting for multiwinner elections

[Abd ul-Rahman Lomax]

I'll be brief. Asset is often not understood.

On 4/12/2019 10:10 PM, Michael Rouse wrote:
>
> Kicking around a few ideas here, but assuming you have a number of 
> candidates running for a fixed but limited number of seats in a 
> legislature, how about:
>
>
> 1. Require each candidate to publicly rank all other candidates in the 
> race before the election.
>
In an Asset election "candidates" are actually candidates to be 
electors. Most of them will not even intend to become "seats." Asset is 
not a "race." There is no actual competition, only cooperation and 
collaboration to create seats.

In a large public Asset election, as many as 1% of the electorate may be 
willing to serve as electors, i.e., as public voters. So if the 
electorate is a million people, the "candidates" would be required to 
rank all 10,000 candidates? I don't think so.

Asset is terminally simple. It is actually negotiation and deliberation, 
not aggregation, and to elect a seat simply requires the agreement of 
electors who "transfer" a quota of votes. So all seats have the 
*unanimous* approval, directly or indirectly, of a quota of voters.

*Unanimous?* Let that word sink in.

"Race" is language from politics that would become obsolete with Asset. 
If I wanted to choose a proxy for some business purpose, what would I 
think about someone "competing" for my choice?

Let me suggest that I would think that this person has some ulterior 
motive and I would be unlikely to trust them. Yet we expect those who 
represent us in public affairs to "run" for the office. And then we get 
crazy results. Why are we surprised?

I'm leaving the rest, but this is all utterly unnecessary and would 
break Asset if implemented.

> 2. Allow voters to rank *one or more *candidates in order of 
> preference on their ballot (if you bother ranking someone it's assumed 
> you are okay with electing them -- if you don't want someone elected, 
> you don't rank them, kind of like in Approval).
>
> 3. Pick the group of candidates (equal to the number of open 
> positions) appearing on the largest number of *unique* ballots. This 
> is the most interesting step to me, since it seems like it would be 
> the most computationally-intensive step. In the (probably) unusual 
> case that more than one group has the same number of unique ballots, 
> there are several easy tie-breakers, so I'll ignore it as a 
> distraction for now.
>
> 4. Looking at each ballot, if one or more candidates ranked on it are 
> in the winning group in step 3, the highest ranked winning candidate 
> gets the asset.
>
> 5. If a ballot does not contain a candidate that is part of the 
> winning group, look at the rank order of the top candidate on the 
> ballot, and transfer the asset (votes) to the highest ranked person 
> who is in the winning group.
>
>
> As a brief explanation of each step,
>
> 1. Allows a complete ranking so no ballot is completely wasted. Plus, 
> this information is useful in itself -- if a candidate ranks highly 
> someone I detest, I can either not vote for them, or rank enough 
> candidates so it's unlikely my vote will be transferred.
>
> 2. Allows voters to pick however many candidates without splitting 
> their vote (some edge cases are possible, where a lower rank on a 
> ballot could knock out a preferred candidate, which is why you don't 
> rank someone unless you approve of them).
>
> 3. Maximizes the number of people whose vote goes to good candidate 
> (good in the sense that the voter is content with the result).
>
> 4. Minimizes votes "wasted" by padding someone's victory -- a person 
> with twice as many votes has twice the assets to wield.
>
> 5. Gives votes that would otherwise be wasted to the least offensive 
> candidate in the winning group.
>
>
> One nice aspect is the lower bound -- where the number of winning 
> candidates equals just one -- is just the Approval winner.
>
>
> Like I mentioned, just musing about things, though I would be 
> interested in other's thoughts.
>
> Mike
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20190423/c04292eb/attachment.html>