Policy Review Potential Updates For CAP Polling

[HeaLnDeaL]

approved by Birkal

CAP's use of ranked voting scripts has been a blessing in many ways, and it is a huge improvement over other voting methods that do not allow for users to vote for multiple candidates. However, Instant Runoff Voting/Preferential Bold Voting are not without their flaws. They do a great a great job at picking a winner where the margin is wide, but there is an uneasy side effect. Essentially, these voting methods work by eliminating the item with the least number of first ranked votes, re-tallying, and repeating until the appropriate number of winners remain. However, when the item with the least number of first ranked votes has barely lower first ranked totals than the item with the most first ranked votes, then there is the potential for "unfair" results.

Take the following scenario:

Option A gets 28 first ranked votes.
Option B gets 30 first ranked votes.
Option C gets 31 first ranked votes.

According to our current voting methods, Option A automatically loses and cannot win. However, it is possible (and has happened once before since I've been a mod) that Option A has much more second place votes than B or C, and thus the majority of people prefer Option A over Option B and Option C when tallied individually with head to head matches.

Take this additional scenario:

Option A gets 30 first ranked votes.
Option B gets 30 first ranked votes.
Option C gets 31 first ranked votes.

IRV/MBV counts both A and B as having the least number of first ranked votes, and eliminates both of them. Option C then automatically wins, and second ranked votes aren't used at all to determine the winner. Though rare, this above scenario shows a complete failure of our voting scripts.

For the purposes of the proposals below, head-to-head vote counting should be a bit more explicitly defined with a more observable. As mentioned above, the implementation of a head-to-head counting method would count every slated item against every other. Option A would be counted against Option B with C removed, then again against C with B removed, and then Option B would be counted against Option C with A removed. Below is what this would look like in small sample size of five votes (and here we're slightly expanding the slate size to four as well).

Person 1 votes for sparktrain, cbrevan, snake_rattler, jas61292
Person 2 votes for jas61292, cbrevan
Person 3 votes for sparktrain, jas61292
Person 4 votes for snake_rattler, sparktrain
Person 5 votes for snake_rattler, cbrevan, jas61292

With the above pool of head to head votes, head-to-head matches would come up with the following:

sparktrain:3 vs cbrevan:2 - more voters prefer sparktrain to cbrevan.
sparktrain:2 vs snake_rattler:2 - the same number of voters prefer sparktrain and snake_rattler.
sparktrain:3 vs jas61292:2 - more voters prefer sparktrain to jas61292.
cbrevan:2 vs snake_rattler:2 - the same number of voters prefer cbrevan and snake_rattler.
cbrevan:2 vs jas61292:2 - the same number of voters prefer cbrevan and jas61292.
snake_rattler:3 vs jas61292:2 - the voters prefer snake_rattler to jas61292.

In the above method, sparktrain is preferred twice and tied with preference once, cbrevan is tied twice and is not preferred once, snake_rattler is preferred once and tied twice, and jas is preferred in no head-to-head match up. The head to head match ups thus display that spark and cbrevan tied, snake_rattler came in third, and jas61292 came in last. To break the tie for first, IRV/PBV would be used.

Proposal A
Initiate a "Close Poll" Clause for final polls in which if the difference between the option with the least first ranked votes and the most first ranked votes is less than X% (I'd propose at minimum 10%, max 20%; a specific number could be up for discussion) then all entries will be compared to each other one on one. As in Option A will be run against Option B with C eliminated and then against Option C with B eliminated, and repeated for all options/combinations. If there's an option that beats the other two one on one, then that option will automatically win the poll, regardless of what IRV says. If there is not an option that beats both others, then the normal IRV/PBV determined winner will be the winner of the poll.

Proposal B
All final polls will tally in a head-to-head match (Option A will be run against Option B with C eliminated and then against Option C with B eliminated, and repeated for all options/combinations. If there's an option that beats the other two one on one, then that option will automatically win the poll, regardless of what IRV says. If there is not an option that beats both others, then the normal IRV/PBV determined winner will be the winner of the poll.) Proposal B aims to bypass trying to make a less-than objective cut off percentage to initiate the head-to-head tallies by requiring them outright in final polls. However, unless voting scripts are changed, this would result in more work for the mods to count the votes and a lot of cases where IRV/PBV obviously got it right will still have to be counted separately.

Proposal C
All CAP competitive polls, not just final polls, will tally head-to-head matches. The three entries that win the most head-to-head matches move onto the final poll. If there is a tie in the number of head-to-head victories that would make more than three entries win, then IRV/PBV would determine which of those tied for third place should move on. If both the number of head-to-head victories and IRV/PBV determine a tie for third place that would result in more than three entries moving onto the next poll, then those tied in third place will all move on. This proposal is perhaps the most extreme of the the three, and would fundamentally change how CAP polls are counted for the benefit of making sure IRV/PBV doesn't mess up in excessively close match ups at any stage. This proposal would undoubtedly require a new programmed voting script that counts head-to-head matches.

It should in general be noted that head-to-head matchups and IRV/PBV will usually, given a decent sample size of votes, both find the same results. However, head-to-head matches and IRV/PBV both have flaws. Head to head matches ignore how much more voters preferred one candidate to another. IRV/PBV ignore the number of raw times that a single candidate to preferred to another single candidate. But, when uses collectively, IRV/PBV and head-to-head matches seem to fix each other's flaws.

In addition to preferences in proposals, this thread will also serve as discussion for proposal amendments and submissions of new proposals that deal with the issue. People who do not like any proposal above and who wish to stick with pure IRV/PBV voting are welcome to reply and explain their reasoning as well.

 

[Tsaeb XIII]

I had every intent of posting a thread on our polling systems in CAP but, since this is up, I figure I'll tack onto this one. First things first, let's respond to the OP. For the purpose of the remainder of this post, I'm going to assume that it's possible to get scripts working for whatever method we end up deciding on, and thus discuss the ideal polling structure for CAP. It may be that we have to settle for something less than ideal in order to practically implement the process, but this post is about voting theory and the philosophy we want to aim for.

At the end of the day, any voting system is based on a certain philosophy of how to count a vote and how to submit a ballot. IRV is based on the simulation of runoff voting, using the usual standard that you eliminate whoever at each stage currently has the fewest votes. This incorporates a weighting level of preference value by making it more valuable to obtain higher preferences than lower preferences to avoid being eliminated before you can receive preferences. On the other hand, Head to Head (HTH for the purpose of this post) works on the philosophy that broad support at any reasonably high level of preference is worth more than receiving particularly high preferences. HTH is arguably better for selecting a consensus option, whereas IRV is more likely to produce the most broadly acceptable directly supported candidate. For a project like CAP, it seems as though broad consensus support is probably more valuable to us than looking for the most outright supported option. It matters far less that we pick the option that people absolutely love than that we pick an option that everybody can get on board with and that few people actively dislike, and HTH is much more likely to achieve this. Because of this, I advocate that we adopt Proposal B as provided in the OP.

Given my support for HTH over IRV and MBV with regards to CAP philosophy, it may come as a surprise that I'm not going all the way and supporting Proposal C. The reason why is because I believe there is a much deeper problem we currently have with our initial voting stages that HTH deepens rather than resolves. IRV and HTH ultimately work best when they're selecting a single winner. When there is only a single winner to be chosen, it is natural to expect that the winner should be selected primarily on the basis of outright majority support. If only one option can be chosen, choosing the most representative outcome is equivalent to choosing the option that has majority support. However, the moment multiple candidates are being considered, outright majority support and a representative outcome diverge. As a result, we have to make a decision when designing our voting philosophy as to whether we want our final poll slates to represent the options most favoured by the majority, or the options that best represent our CAP community.

What do I mean by this? Imagine, for the moment, a first level poll that has two clearly defined voting blocs that split 51-49 percent. If there are six options on the poll, three from each bloc, and preferences rigidly flow internally within a bloc before moving across blocs, MBV will result in the in final slate consisting entirely of the options representing the 51% bloc. If you're wondering whether this actually happens, my movepool for Plasmanta was a major beneficiary of it. There was a particular move that divided the voting community; its exclusion ended up having the majority, and thus every movepool that left it out ranked higher under MBV than those that included it. My movepool came fourth, the lowest of movepools that omitted the move; in general, I was ranked last or not ranked at all on the votes that wanted the move and I was typically fourth on those that wanted its omission. Had the third place option never been submitted, I would have been on the final slate simply on the basis that I left out a particular move and the bloc supporting its omission had dominance over the poll. As such, the final slate did not represent the community as a whole, merely a single voting bloc that obtained over 50% in the first stage poll. This is not the only poll where I've seen this happen; the name poll for Plasmanta included a highly controversial option that had enough community support that it probably should have been on the final poll, but was locked out because of MBV.

Now, if we assume that our polls were being voted on by exactly the same group of people, voting in exactly the same order of preference, this wouldn't necessarily be a major problem. However, a large part of the reason that we have multiple polls is that we recognise that polls with fewer options attract more votes. As such, the composition of the group voting in the final poll may be different from the composition of group voting in the initial poll. It cannot be assumed that the majority of that group would agree with the majority from the first stage. Because of this, I believe that it is ideal that the final poll reflect the variety of options that gained substantial community support.

There is another facet of this to be considered. There are fundamentally two tasks that CAP voting needs to achieve - separating between similar options that reflect a shared aim and separating between divergent options that reflect different aims. What is happening at the moment is that the second task, separating between different aims, is happening at the first stage of voting. The aim that receives majority support in the first stage, supported by MBV polling, selects three options that all share their aim. This produces three relatively similar options that make the slate for the final poll, at which point the first task is achieved using the final stage IRV poll. There are two big problems with this. Firstly, it's running completely backwards with respect to the demographics that are well understood to vote in each of the polls. In general, the first poll attracts people who will go over similar options with a fine tooth comb to work out the differences between them, and rank their votes such that they distinguish between them. The final vote, on the other hand, attracts people who will look at the big differences and make their decisions based on the things that stand out. To align our voting decisions with our demographics, it seems like it would make sense to reverse the order that we attempt to achieve these tasks, trying to use the first poll to distinguish between similar options and the second poll to distinguish between divergent aims. Let the voters who pay attention to detail determine the best option for each aim, and then let as many people as possible have a say in which aim the project ultimately adopts. The second big problem is that, by deciding the major details after the first poll, we reduce engagement in the final poll. In a stat spread example, if you wanted a fast build and all the final poll options are slow, you might not have any strong feelings at all about which slow gets adopted; you still think it should have been fast. By eliminating all the fast options, the only people left with major interest in the final poll are those who care about the small differences.

As such, I believe that we need to adopt a voting system that reverses the order that we achieve the two major goals of voting and ensure that the major segments of the community are represented on the final polls even if an option fails to achieve majority support after the first poll. This involves a change in our philosophy regarding the first polling stage of CAP: instead of using the first stage to determine winners (i.e. looking for a ranked list of most popular to least), the first stage needs to be thought of as determining representatives (i.e. choosing the best option from the broad schools of thought present in the discussion thread). This means we need to take a step away from voting methods designed to select one candidate who ranks more highly than others, and move to voting methods designed to select a group of candidates who, between them, are proportionally representative of the community of voters. In pursuit of this aim, I propose that we adopt a multimember Single Transferable Vote (STV) system for our initial polling stages used to select a slate for final polls.

For those unfamiliar with the system, STV is the big brother of IRV; strictly speaking, IRV is the single member form of STV. STV grants each voter a single unit worth of voting power, but allows that voting power to transfer between candidates as the election proceeds. In IRV, that unit of voting power remains unified because there is only one quota (i.e. winning candidate) that can be obtained. However, in the broader sense, STV actually allows that unit of voting power to be split between candidates. It is based on the principle that a candidate should only obtain just as much support as they need to obtain a quota, and that any leftover support can be redistributed partially to other candidates. This overcomes the issue with IRV that caused us to shift to MBV in the first place, the issue that a single very popular top candidate causes a small number of votes to determine the rest of the ranking beneath it. There are a few different algorithms for counting STV, so I'm advocating one of many here. To start with, work out the threshold for a quota. To do this, you divide the number of available votes by the number of candidates plus one, and then round up. If we consider the OP votes as an example, let's say we wanted to use STV to choose two candidates. The quota would be ceiling(5/3)=2 (it may seem slightly counter intuitive to use candidates plus one rather than simply candidates, but think about its implication for a single candidate election; in a single candidate election, once someone has more than half the votes, they don't need to get to all of the votes to know that they've already won - the same principle applies in that if, for three candidates, three people already have more than a quarter of the vote, there aren't enough votes left for anyone else to overtake them). The algorithm then proceeds in a loop until enough candidates are elected as follows:
[
If one or more candidates already have more than a quota
then
(
Each candidate who exceeds the quota is elected
For each candidate who exceeds the quota, calculate the fraction of their votes that are surplus. Redistribute that fraction of each of their votes to a subsequent preference
)
else
Eliminate the lowest ranking candidate and redistribute all of their votes to a subsequent preference.
]

Basically, instead of thinking of a vote as a single discrete unit, STV thinks of it as an array in which the values sum to a total of 1. If there are 3 candidates on offer, an array would be of the syntax [Candidate 1, Candidate 2, Candidate 3, Exhausted]. When the vote is first cast, if the first preference was for Candidate 3, the array would be [0,0,1,0]. If candidate 3 was elected with a redistribution of 10% of their vote, and the voter's second preference was candidate 2, their array would change to [0,0.1,0.9,0]. If candidate 2 was eliminated and their vote was exhausted, the array would then become [0,0,0.9,0.1]. The values within the array move around because of preference flows, but the total value never increases or decreases.

In practice, what is achieved by STV is that no vote gets to count twice; if you've helped a candidate get selected, the proportion of your vote that helped achieve that can no longer influence the election of an additional similar candidate. Instead of 50% of the community getting to decide all of the options that win, it becomes possible for a bloc of about a third of the community to be represented on the final slate. The final slate would represent the diversity of the community, allowing us to engage as many voters as possible in making the major decisions that determine the direction of our projects.

In summary, I put forward an additional proposal to complement those listed in the OP, that is easily compatible with Proposals A and B from the OP.

Proposal D
All polls that are used to determine a slate for a subsequent polling stage will replace MBV with multimember STV. If a single option obtains in excess of 50% of the primary vote in this first stage, it will still automatically win as is currently the case. Otherwise, the goal of the first stage of polling is to use STV to select a set of options that represents the broad CAP community, with a final stage using IRV or HTH to determine that actual winner.

Needless to say, I support the pairing of Proposals B and D to implement an overall polling structure that best achieves our goals of being a community project. While I have no experience scripting for forums, I hope that it is possible for these proposals to be implemented in script. If it is not, if a script can be prepared that can scrape the votes from the thread and format them in something Excel compatible, I'd be more than happy to create a spreadsheet that does the vote counting and outputs it in a forum friendly format.

 

[NumberCruncher]

I agree with Tsaeb. STV seems to solve the issue presented. I would put my support behind Proposal D.

 

[HeaLnDeaL]

If there are six options on the poll, three from each bloc, and preferences rigidly flow internally within a bloc before moving across blocs, MBV will result in the in final slate consisting entirely of the options representing the 51% bloc. If you're wondering whether this actually happens, my movepool for Plasmanta was a major beneficiary of it. There was a particular move that divided the voting community; its exclusion ended up having the majority, and thus every movepool that left it out ranked higher under MBV than those that included it. My movepool came fourth, the lowest of movepools that omitted the move; in general, I was ranked last or not ranked at all on the votes that wanted the move and I was typically fourth on those that wanted its omission. Had the third place option never been submitted, I would have been on the final slate simply on the basis that I left out a particular move and the bloc supporting its omission had dominance over the poll. As such, the final slate did not represent the community as a whole, merely a single voting bloc that obtained over 50% in the first stage poll. This is not the only poll where I've seen this happen; the name poll for Plasmanta included a highly controversial option that had enough community support that it probably should have been on the final poll, but was locked out because of MBV.

First off, I'll just say that I had access to Tsaeb's complaint before I made the OP for this thread; Tsaeb PMed jas, jas shared the PM with the mods. And I think we just need to step back and analyze through what lens Tsaeb is viewing this under. I believe he is making two false claims within his proposal that discolor the rest of his post.

1) The claim that voting blocs create an all-or-nothing idea. Just to give some background on general terms, a voting bloc usually refers to the voters, not the slate; the bloc is a group of like-minded voters who rank similar options highly. A bloc is really just inevitable, but the idea that if 51% of people bloc together to vote for 3 similar options will allow those 3 similar options to automatically advance is not entirely true. Quite to the contrary, I've been in multiple mod conversations about vote splitting among slate groups. As said above, a voting bloc refers to the voters, but slate groups are what we can call the similar slate options that might be targeted by a voting bloc. Slate groups have the potential to suffer from voting splitting. Say that there's a large voting block that all like 3 options, but there's two, smaller voting blocks that only like one option each. Chances are that the smaller, more focused voting blocs will get their preferred options to move onto poll 2 because the larger bloc that favors similar slate items might split votes. Overall, we must examine at a much deeper level that voting blocs and slate groups produce results in which one slate group moves on and all other items fail. Furthermore, as voting blocs are the voters (something we shouldn't control too much), the problem (if one exists) is less so in the blocs and more so in the slate groups. The TL/ TLT are aware of slate groups and the mods communicate with them about potential slate groups as they appear. This last CAP during typing, it was clear that the Fairy-typings were all one such slate group. The mods discussed this, I personally talked to spark and the TLT about it, and ultimately the TL and TLT were able to come up with a slate that a) represented the ICC (Intelligent Community Consensus), b) didn't blatantly favor a single typing, and c) didn't have an enormous potential for vote splitting.

Related to this is the idea that voting blocs and slate groups do not follow a one to one ratio. Voting blocs are general trends, but sometimes two different voting blocs will have an item on the slate that they both like. For example, in CAP22's typing we could hypothetically say that there was a Fairy voting bloc that voted for fairy slate groups and there was a Fighting voting bloc that voted for fighting slate groups. These two voting blocks preferred different slate groups, but one option on the slate was part of different slate groups and the overlap resulted in two voting blocs both liking the same slate option. At the core of this, we find that slate groups are not exclusive; something in the slate can be part of multiple slate groups, and thus favored by multiple voting blocs.

So, I don't overall see the evidence in Tsaeb's claim here. Voting blocs exist, we can't change that. But they, alongside slate groups, are much much less static that what Tsaeb tries to boil them down to. Tracking how they go down is not that easy, and really almost every winning item wins because it attracts multiple voting blocs, not because it has the support of one voting bloc that constitutes 51% of the voters.

2) Tsaeb's anecdote heavily relies on the community being split on a single move. Voters are perfectly allowed to vote on what criteria they choose, and if it comes down to a single move, then so be it. We are not here to tell voters to vote for something because of X or Y reason. The slate itself represents the ICC. The slate represents all relevant voting blocs (or rather discussion blocs). The slate already does this in poll 1, so I see no reason why we should force multiple voting blocs to be represented in poll 2. If a single slate group makes it to poll 2, you have to realize this is because the vast majority of voters favored that slate group. I'm just not liking the idea of ignoring the majority of people when majorities choose slate groups. Of course, I still think that thinking in terms of black and white slate groups and voting blocs ignores some intricacies in play (these are general trends based on general results, not based on exact motivations). Tsaeb's anecdote tries to create a problem by dividing things into simple black and white terms; into two voting blocks, each preferring a different slate group (movepools with move X, movepools without move X). And yes, it does seem somewhat troubling when you look at it that way. Essentially, it's presented under the guise that we have Republicans and Democrats (-HeaL shoots himself for making political analogies), and then if 51% of people prefer Republicans that only 3 Republicans make it to the final poll. However, that's simply not how things really go down. What *really* happens is that the TL/TLT treat the discussion thread like political primaries. The TL/TLT works very hard and deliberately to judge the different philosophical ideas and to make a slate that showcases the ICC. Some of the more major party ideas might end up with more than one slate item, thus forming slate groups. Some of the smaller party ideas might only get one slate item, but nonetheless similarities emerge and you could imagine that slate item caucusing with another party... Essentially the TL/TLT makes sure the parties are represented. Of course, we have a TL/TLT decide the slates rather than having a vote-for-anything-discussed system because the TL/TLT provides checks against anti-concept material. But essentially the slate itself is about party representation, which seems to have been a major concern of Tsaeb.

I see the quota limits more of changing people's votes, and that bothers me. Take the situation where people only rank one option. Assume option A reached its quota, and then more votes are to be counted that only ranked Option A... Those votes would suddenly be meaningless? That's not right in my book, and I think it creates more problems than it solves.

TL;DR: I believe that voting blocs and slate groups are more complicated than what Tsaeb explained since individual voters and slate items might navigate between multiple blocs and groups. I believe that the idea of "group representation" is already perfectly met with the choosing of the slate itself and trying to force multiple groups into the final poll could involve changing the voters' intention too far.

At this stage I'm not going to just shut down discussion altogether on proposal D, but I feel that the basis for D's introduction relies too heavily on assumptions that aren't yet proved or provable at all, and that these assumptions talk about changing voting in a way that could potentially be off topic. My intention with this thread was to address the instances where IRV just flat out gets things wrong and to fix it with an additional checking measure. If 51% of people genuinely want 3 similar options, then that's not really an instance where IRV is miscalculating their votes.

 

[Tsaeb XIII]

At this stage I'm not going to just shut down discussion altogether on proposal D, but I feel that the basis for D's introduction relies too heavily on assumptions that aren't yet proved or provable at all, and that these assumptions talk about changing voting in a way that could potentially be off topic. My intention with this thread was to address the instances where IRV just flat out gets things wrong and to fix it with an additional checking measure. If 51% of people genuinely want 3 similar options, then that's not really an instance where IRV is miscalculating their votes.

Apologies if it seems like my proposal is diverting attention from yours; in my opinion, it fell within the scope of dealing with edge cases that our current system has the potential to produce. As mentioned in my post, I'm fully on board with your original proposal. It seemed, however, that if we're already discussing polling methods, this was the place to bring up the concern I have.

I'll attempt to address the concerns you've raised. Firstly, I recognise that the issue I've described will not occur in every single poll. Sometimes, particularly when addressing things like abilities, there won't be blocs corresponding to slate groups. Nevertheless, as with the problem you raise in the OP, it exists as an edge case that the system has the potential to produce. I'm advocating for a system that does not produce these edge cases. I haven't gone through and analysed a large sample of CAP polls (if I get time over the coming week, I may do so), but in my time around the CAP project, I know there are more polls that have followed the pattern I described than just the ones I've mentioned. MBV creates the possibility for a small majority in the first poll to ensure that the final poll is made entirely of options from a particular slate group, even if it does not always do so. Another thing I wasn't clear enough about in my first post is the role of the TL/TLT in shaping the original slate from ICC. I recognise the excellent work our TL/TLT does in a) making sure that completely counterproductive options don't make the slate and b) making sure that the variety of groups present in the discussion thread receive some representation on the slate for the first poll. It is not unusual, however, for a the first slate to include multiple options that are similar; this should be expected if the ICC from the thread included substantial support for those variants. The system isn't broken if the first slate contains relatively similar options.

Addressing your concern number 1, while vote splitting can be a factor, it should be far less of a factor in any preferential system. If it is enough of an issue that polls change based on it, perhaps we need to consider a rule for the first voting thread that requires a minimum number of preferences to be expressed. Under MBV, a smaller focused group is fighting an uphill battle to be represented on the slate for the final poll, because it is entirely dependent on votes exhausting due to vote splitting and incomplete preference flows; if everyone completed even half their preference flows, MBV would guarantee that a small majority favouring a slate group would guarantee only that slate group was represented on the final slate. Consensus options, like your mention of Fairy/Fighting receiving support from both Fairy supporters and Fighting supporters, will still receive support under STV, especially if either the Fairy supporting bloc or the Fighting supporting bloc received less than a full quota or substantially more than a full quota.

Something you didn't mention in your response, but that I want to emphasise here, is that statistics demonstrate that we attract different demographics to our different voting stages. I would not have a major issue with using MBV if the final voting stage consisted entirely of voters who also voted in the first stage. In practice, however, our polling stages consist of one group of voters deciding on a narrower group of options for a different group to vote on. There is overlap between these two groups, but they are not the same groups. This means that a slate group that gets a majority in the first poll does not necessarily mean that the same result will occur in the second poll. There are several voting philosophy issues here. Firstly, MBV allows votes to count multiple times, once when determining each level of ranking. This is fine if all you want to do is indicate a ranking based on raw popularity within that group, but not if you want the voice of everyone who voted to be expressed. Do we want the first poll to be based on raw popularity, or do we want it to act as a filter on the slate presented by the TL/TLT to select the best representatives from the original slate to present to the broader community in the final vote? This is why I emphasise that I believe that our two voting stages should be based on selecting representatives in the first stage and selecting a winner in the second stage, not selecting winners in both stages.

You mention that voting blocs and slate groups aren't as static as I suggest. I agree that they are not always as static as my post suggests they are; that is my mistake for focusing on the problematic edge case without mentioning the broader context. Voting blocs and slate groups aren't always static, but they have the potential to be. Again, if I get time, I'll try to come up with a metric to determine how often it happens and go trawl through old voting threads to find out how often this edge case comes up. I suspect stat spreads and the old movepool stage will be where it'll show its head most often, especially around Speed stats.

Addressing your second concern, it would not be entirely inaccurate to flip your argument around and say that the MBV vote already produces a majority supported winner, so why force a second vote at all? The first voting stage is always going to be some sort of hybrid of the TL/TLT slating stage and the final stage voting for a winner. At the moment, we predominantly have that overlap between the first voting stage and the final voting stage. I see no reason, however, why the overlap couldn't shift. The ICC of the thread results in a large slate, in which all major perspectives are represented. This is the best slate we will have at any point during the voting process. If we could guarantee that every voter produced a complete preference flow from this slate and indeed voted on this slate, we would only need a single IRV or HTH voting stage to determine the winner. The problem is that we have many people who don't vote on this slate. Any option, then, that gets cut out by the first voting stage is an option that many voters never get to vote on. Philosophically, maybe we're okay with that. Maybe we adopt the position that, if you want a say on an option, make sure you vote in the first poll. Nevertheless, if we know that there are voters who simply stay away from polls with large slates, then perhaps the onus should be put back on the system to make sure that they get the chance to have as much say as people who vote in the first poll. That means shifting our first poll mentality away from being a preliminary stage for the final poll and towards being a refinement stage for the slate selection done by the TL/TLT. To return to the political analogy, the TL/TLT vet the candidates presented in the thread to ensure that the best of what's on offer is presented in the first stage slate. At the moment, we then conduct a popularity vote that could, even if it doesn't always, present entirely candidates from a single party that has slightly greater than majority support among that group of voters. A larger group of voters than picks from that group. I advocate moving to a system that's designed to filter the vetted group down to a smaller group that showcases the major views that received substantial support, and allow the largest group of voters possible to choose between those since the majority in the second poll may differ from the majority in the first poll. That is, a majority in the first poll shouldn't be capable of blocking a view from being represented in the final poll unless that majority is so large that the addition of extra voters is extremely unlikely to shift the majority. STV does this by ensuring that, for a 3 option final slate, you need just over 25% of the community to be represented on the final slate. A single slate group that collects over 75% of the vote can ensure that all other options are locked out, but that sort of majority almost guarantees one of those options wins anyway. I believe this is exactly what we want from our polling process; a small majority can't lock an option out from the final poll, but a supermajority can. My concern is not entirely about party representation because, as you said, the TL/TLT already does that when they make their slate. My concern is that we recognise that we have a voting demographic who only votes in the second poll, but the system allows for the second poll to not represent parties that there is a reasonable chance they may wish to vote for.

I'm unsure what your major concern with quotas and changing votes is. If someone only votes for a single candidate under MBV, their vote is exhausted once that candidate is elected (that is, every vote above 50% is meaningless, just like every vote with no additional preference above a quota in STV is meaningless). If someone only votes for a single candidate under STV, their vote is exhausted once that candidate is eliminated or elected. Some variants of STV will try to reallocate votes that don't exhaust before votes that do if a candidate receives a surplus (e.g. On a quota of 25%, a candidate receives 30% of the vote. For 50% of the people who voted for them, that candidate is their last preference before exhausting. That is, 15% out of that 30% would exhaust and 15% wouldn't. So, you leave the 15% that would exhaust entirely with the candidate, and you then identify that you need to reallocate 5% out of the remaining 15% that will remain live. To do so, you reallocate 1/3 of each of the votes that had an additional preference and leave 2/3 of it with the candidate. This ensures that as few votes as possible are exhausted. If a candidate has fewer votes with an additional preference than they have surplus, you reallocate all of their votes that have an additional preference and then only exhaust as much as you have to. This is a more complex implementation, but it's one that can be used if you're worried about too many votes exhausting).

In summary, my proposal is underpinned by a philosophical stance that we should use the first voting stage to choose representatives rather than winners. This is not about modifying the intentions of voters; we just have to communicate that what the first poll is designed to achieve has changed. No longer are they voting about who will win, they're voting about who will represent them on the final slate. It's changing what we intend for the first voting stage of the process to achieve. I believe it's the superior option because it prevents the edge case of a small majority locking out another option from the final poll that may otherwise have won on the final poll because of the larger voting demographic not necessarily sharing the preference of the first demographic. If the stance we, as a Policy Review Committee, decide to take is that we want the first stage to remain about choosing winners, then we should reject Proposal D. However, if we decide that the philosophical arguments justify changing it to a stage of slate refinement by selection of representatives, that's where Proposal D comes in.

All that being said, I hope this thread doesn't become entirely about Proposal D, because Proposals A and B definitely address a concerning edge case and, particularly in three candidate elections, are pretty much outright superior to what we're using at the moment. I hope the rest of the PRC get behind them, even if Proposal D is eventually rejected.

 

[HeaLnDeaL]

In summary, my proposal is underpinned by a philosophical stance that we should use the first voting stage to choose representatives rather than winners.

And to this I've already said that the TLT/TL chooses representatives already. To me, it makes no sense trying to get two stages of representatives if the people choose, based on their votes, not to see a representative of a certain category/slate group.

Essentially, your proposal is about policing content in relation to polling and doing so by making sure different content groups are represented. This is fundamentally different than the aims of Proposals A, B, and C which aim to decide the polling content based on the voters wishes. A, B, C recognize that IRV/MBV do not always produce a result that is in keeping with the voters' wishes as a whole. D on the other hand has a different philosophical bent of a problem that 1) has not been proven to exist and 2) if it exists it hasn't even proven to be a problem. In the anecdote provided, it is not a foregone conclusion that anything was inherently wrong with you coming in 4th place out of a slate group of 4 and that the other 3 people in your slate group advanced to poll. What happens if 70% of people prefer a slate group? Should we really try to actively make sure that 3 things from the same slate group don't make it to the final poll? I believe that there are many times when it is perfectly reasonable that 3 things from the same slate group make it to the final poll. I think we need to make sure that our polls showcase the wishes of our voters. If the voters express through their votes that they like a single slate group, why should we deny them their wishes?

 

[QxC4eva]

I think Heal's counter argument is invalid. He quoted just the example in proposal D and based his whole argument off that. Which means all he did was criticize the example and not the proposal itself. Anyway that example is just one scenario out of many, but Heal took that as the basis for all scenarios. Hence the misunderstanding!

I've already said that the TLT/TL chooses representatives already. To me, it makes no sense trying to get two stages of representatives if the people choose, based on their votes, not to see a representative of a certain category/slate group.

I believe that the idea of "group representation" is already perfectly met with the choosing of the slate itself

The TL/TLT works very hard and deliberately to judge the different philosophical ideas and to make a slate that showcases the ICC. ... Essentially the TL/TLT makes sure the parties are represented.

TL/TLT choosing representatives is very different to STV representation. CAP's polling system has 3 demographics:

• A) people who took part in the discussion
• B) people who voted in poll 1
• C) people who voted in poll 2

When TL/TLT chooses representatives, it is a ICC-based representation of demographic A. With STV, it is a proportion-based representation of demographic B. So both are different things there's no overlap here. Both filter the slate in different ways so they complement each other fairly well. just coz the word "representation" comes up twice doesn't mean they're the same thing! >.<

Essentially, your proposal is about policing content in relation to polling and doing so by making sure different content groups are represented.

STV doesn't force different content groups to win. All it does is proportionally represent people's votes, so a 'minority' ballot is worth as much as a 'majority' ballet. In IRV, minority ballots are worth less than majority ballots.

Say we have a race between Slowbro (30 Spe) and Rapidash (105 Spe). IRV is like giving Rapidash a choice scarf (i.e. majority dominating) and Slowbro an iron ball (i.e. minority suppressed), while STV does not give items to either mon (i.e. 30 and 105 Spe retain their proportions). Yah either way Rapidash is gonna win, but things could differ once we try to rank similar mons.

Hopefully those who get this analogy can see how STV may be the better choice for poll 1 (by setting an even ground for all candidates) and IRV better for poll 2 (where we need to pick a winner)

I think we need to make sure that our polls showcase the wishes of our voters. If the voters express through their votes that they like a single slate group, why should we deny them their wishes?

"Keeping voter wishes" isn't a simple black and white term. There's many ways to do it, each with different pros and cons with none being a perfect solution. IRV keeps voters wishes and so does STV, but like already said they do it in different context so which one to use comes down to philosophy. Using one over the other doesn't "deny wishes"

My intention with this thread was to address the instances where IRV just flat out gets things wrong and to fix it with an additional checking measure.

It's not exactly IRV getting things wrong, but when its used where it's not meant to be used - like the case described in the OP and another by Tsaeb. Proposals A&B will fix the former, C fixes the former but creates another problem, while D fixes both.

 

[Bughouse]

This is the internet where we get to design our own rules and we have small voting populations and the ability to change our scripts to whatever would count votes the "best."

There's a very simple way to tell if a voting system is using "best" practices. They're called the Condorcet criteria.

STV is not Condorcet. PBV is not Condorcet. This is because no form of IRV is Condorcet.

Ranked Pairs is. Period.

If we truly care about getting the "right" winner every time, not ease of the scripts or ease of explaining how the vote is calculated to voters, then proposal C is 100% the right one.

 

[QxC4eva]

I was hoping Tsaeb will reply but he's gone again :\

Bughouse - no voting system meets every criteria. Condorcet is one, but not the only criteria there is.

Quoting the OP: "Head to head matches ignore how much more voters preferred one candidate to another."

So the more candidates there is, the less reliably HTH can find the 'true' winner, as it doesn't care about winning margins.
That makes HTH less ideal for poll 1 (whose slate size bigger than poll 2), Proposal C is therefore questionable.


I think we all agree on HTH for poll 2 though!

 

[Bughouse]

No you're really missing out on the main benefit of ranked pairs... it's for its use in large polls. The smaller the poll is, the less likely that there are more than 2 frontrunners. And if there are only 2 (or even just 1) frontrunners, then ranked pairs offers literally zero benefit over IRV.

Now I get that you prefer STV for this preliminary task anyway, but just don't say something silly about ranked pairs as though it's a flaw. It's meant for that type of situation.

Anyway, without even needing to go back and run historical votes under new and old system, I can confidently say that
1) STV and Ranked Pairs would produce the same results from the first poll to the second at least 80% of the time, almost certainly at least 90% of the time.
2) There is nothing so fundamentally different between the polling methods that the winner or runner up in one is absent in the other. The occasional differences between the two would almost always be on only one option moving forward to poll 2, and it would be the least popular option that makes it through. (People do not have uniform voting bloc preferences down the line like would be needed to reach large differences in the outcomes. People who vote option A first do not uniformly prefer options B and C next before options D-H. They just don't. Everyone has different reasons that inform their preferences and therefore ultimately their votes.)
3) Assuming no large differences in the voter pool or preferences between the first vote and second vote, this least popular option would not have won anyway (this would be easy to check... has the last option through to the final poll won often or even at all?)
4) This is in fact even more true than it appears on its face because the last option to sneak through in STV but would not have been present in Ranked Pairs ... well that means it did worse in ranked pairs than in STV. It has an even worse chance at an upset in the next poll than ordinary last-through-the-screen options because in the next vote we would be using a method unfavorable to the polling option.
5) CAP's polls always ultimately select a single winner, not a proportional representative body, so achieving greater proportionality in the intermediate polling stage, while admirable, is unnecessary (pending assumption in parenthesis in 3)
6) STV would be far more complicated to explain to a voter who was confused or mistrusted the method
7) Using two different voting methods requires two sets of scripts to newly write and maintain and the attention to detail on whether to run voting script 1 or voting script 2 and not make that mistake

So for minimal benefit, none other than maybe making a few more people feel good about their submissions through one round of voting, we get more work and more confusion.

If you can find an actual vote where my claim in 2 is untrue, where ranked pairs and STV would have produced a different outcome going from poll 1->2 by more than just the last option that made the cut, then I may reconsider. But absent that particular evidence it seems unnecessary and therefore bad due to the added difficulties and confusion.

 

[QxC4eva]

Fyi, HTH is not ranked pairs - it's a dumbed down version of it. HTH more closely resembles Copeland's method, cuz there's no sorting and locking
So there can be cases like A having 6 borderline wins (50.1% majority) claiming victory over B who has 5 landslide wins (>70% majority). The more candidates, the more ambiguous this gets.

I think in #1 to #4 your main point is STV only makes a tiny difference and I agree, but same goes for every other proposal :P
#5 - since runoffs declare the final winner, having two runoffs means we actually end up declaring two winners....which isn't logical. STV fixes that by removing the first runoff.
Your #6 and #7 are very good points against STV and I totally agree!


...but nice switchover :3

If we truly care about getting the "right" winner every time, not ease of the scripts or ease of explaining how the vote is calculated to voters, then proposal C is 100% the right one.

6) STV would be far more complicated to explain to a voter who was confused or mistrusted the method
7) Using two different voting methods requires two sets of scripts to newly write and maintain and the attention to detail on whether to run voting script 1 or voting script 2 and not make that mistake

 

[HeaLnDeaL]

So I just want to bump this thread with a real example from a past CAP poll that illustrates why I think IRV fails in close poll scenarios. Take a look at the Plasmanta Movepool Poll 2 results:

----------------------------------------------
Array ( [capefeather] => 15 [korski] => 15 [healndeal] => 16 )
----------------------------------------------
Array ( [capefeather] => 22 [korski] => 24 )

Congratulations to healndeal for winning the movepool polls!

As you can see, I had only had one more first place vote than Korski or capefeather. However, since both Korski and cape were tied in last place, IRV automotically eliminated both of them, which made me win by default without having my votes compared head to head with either candidate. Now, in this particular situation I don't think IRV actually got it wrong, because if you count the votes in the thread again, I still win in head to head vote pairings. But one could easily imagine how a result for a poll like this could have gone wrong. IRV overly weights first ranked votes, which creates a scenario for someone with barely the most first ranked votes to win even if he/she actually would lose in head to head matches (as discussed in the example in the OP).

To me, this isn't in any way about changing the way slate options are represented in the polls. The TLT and TL already work very hard to make sure options are fairly represented. I'm not looking for mechanisms that claim to make a more diversely spread final poll. I'm looking for mechanisms to stop IRV sucking terribly when polls are close like in the above example. HTH or Ranked Pairs stop this. I don't think it has been proven that STV does stop this. In terms of the mechanics of IRV, I think it has been clearly demonstrated that very close polls have the potential to distort the results. Does this happen often? No, not at all. But should we sit back and let our voting mechanism decide a winner that is actually contrary to what the voters voted to win? No, I don't think so either.

In short, if someone can convince me that it's impossible for STV to not mess up the same way IRV does when polls are exceptionally close, then I might consider it more (this is my opinion as a user, not as a moderator; as a moderator I don't think there's enough consensus to actually make a decision yet). So far, most/all of the discussion I've read regarding STV has been under the aim of changing the candidates that make it to the final poll rather than fixing problems where the final winner itself is decided unfairly. Unless that changes, I really have to go to bat for HTH in some form or another, as it directly fixes the problems of IRV during close polls.
Now, I also want to take some time to address another point that has been brought up more of as a sidenote until now. I do think that there is some potential discussion regarding issues that arise with having a separate poll 1 and poll 2. Theoretically IRV can choose the winner out of 1 poll, but the fact is we have 2 polls. And there have been multiple instances where the winner in poll 1 is NOT the winner in poll 2; just take a look at Kerf Prevo's stats polls to see that I won in poll 1 but came in a very distant second in poll 2 (I'm pretty sure there have also been poll 1s where I came in second but then managed to win in poll 2). In terms of keeping track of the vote, having two polls for each competitive stage does create some wonky conflicting results. But this is due to our lack of a shared voter base between the polls rather than an inherent flaw in the ballot counting from our scripts.

Now, do I think 2 polls without a shared voter base is the best thing we could do? No, not necessarily. It does have the benefit of letting the top candidates have more time to collect votes which in turn helps create hype and makes the process more exciting. Perhaps there's better ways to do this, however? I'm not sure. One idea would be to have all of the votes from the first poll carry over to the second poll, but reduce the votes down to only the top 3 and then allow 24 hours for new voters to vote for the top 3 (this makes sure that everyone who voted in poll 1 has their votes counted in poll 2, which doesn't always happen). However, the fatal flaw in this idea is that some people actually change their votes between poll 1 and poll 2, and a changed vote halfway through this system could change who makes it to the final three and makes it more confusing. Essentially in the current system, poll 1 lets people vote for who they want in the final poll, not who they want to win. Maybe this is just redundant with the slate vetting and ICC though? It's hard to say.

But there has always been one pretty big benefit that the two poll system has, and this is probably a huge reason why we still use it. It is inherently easier for people to judge a slate of 3 than a slate of 8. Take things like movepool for instance; each submission has a TON of information and it is almost impossible to get the average Pokemon player to read through a group of similar 8 movepools and be entirely focused and know all of the differences by heart. But a 3 submission final poll? It's a lot easier to digest that information. Furthermore, the criteria that people look for in Poll 1 and Poll 2 might change, and I think that's perfectly okay. I think this might even relate back to Tsaeb's acknowledgement of people not voting for submissions that contained a move they didn't like. In poll 1, people's criteria when voting could very well be on there most importantly perceived traits. Voters might really hate the move Charge Beam and really love the move Volt Switch and vote accordingly based on that. But by the time poll 2 comes around and the slate is smaller, reading the finer details maters a lot more, and the order of ranked votes can change. I think this is just a natural and fair result for movepools based on the amount of information given.

However, the argument of "the amount of information" making it hard to make a completely informed vote in a poll is almost entirely restricted to movepools and concepts. Typing, Stats, and Abilities all contain a LOT less information and thus the average voter can digest the entire slate in minutes (or almost even instantly) rather than hours. As such, if people here truly truly dislike having 2 polls, as a user I might agree that there isn't much of a reason to have two polls for Typing, Stats, and Abilities (though I would strongly believe that we should keep two polls for concepts and movepools). I think there are some good, arguable points on why stats, typing, and abilities could shift to operate under a single 48 hour polling system. I don't think it necessarily has to be this way, and there is some potential risk of confusion in having some polls operate with 1 poll and others with multiple. But I think it is perhaps time to let this "side note" about the number of polls come into a more focused discussion.

However, the other side effect of having one, longer poll is that HTH gets a lot more confusing to juggle with. HTH works absolutely perfectly in situations where the slate size is of 3 candidates. If it gets larger, then it has the potential to get more complicated. This in turn brings up another point that I would like to see have more discussion on. In what ways can HTH get messy and exactly how big are the risks of running it in a slate size of 8? At what number of candidates does HTH get unreliable?

I still personally think that fixing IRV when it screws up in more important than changing our 2 poll system, but I guess discussion on both should be allowed since both do directly impact CAP polling. Choosing HTH or IRV or STV might be reliant on our slate sizes and our number of polls, and I think discussing these factors collectively might help our discussion. I'm trying to keep my mind open on a lot of things for the time being and I'm not ready to dismiss anything yet. Maybe I'll regret this later and think that opening the flood gates to additional polling issues was a bad idea... But in this moment I'm hoping that allowing us to consider the multiple pieces going on will let us move the discussion forward rather than just keep up this stalemated battle between the HTH/Ranked Pairs camp and the STV camp.

 

[QxC4eva]

Well now that Heal opened up his mind we can finally have a meaningful discussion :P
I agree much of this goes beyond the OP's problem, but proposals A-C do make some big changes that drag in other issues. Like C is almost an entire system overhaul so there's lots to say about that! Anyway, I still see some proposal D confusion so I'll try explaining it in simpler terms.....

---

Starting from basics, CAP's polling system goes like this:

runoff -- "an additional election that resolves an inconclusive one."

Runoffs are meant to be final. They give us the winner and that's it - finished. Right now CAP does a runoff in poll 1, and then for some reason, proceeds to do another runoff in poll 2! Not only is it redundant, but if both rounds have different winners (due to different voters / people changing their mind) then it's unfair to the winner of poll 1. Because both winners are equally legitimate.

Here's a more ideal system:

You can think runoff as "finding the winner" and filter "eliminating the losers". Poll 1 no longer attempts to find the winner, instead it attempts to eliminate the losers. (a subtle but different thing!) The runoff is left to the very end.

So what's wrong with CAP's system? Why can't poll 1 do a runoff and qualify the top 3? Well, we risk some people getting 2 or more of their favorites winning, and others with nothing they like. That's undemocratic. The proper way is to elect the best combination of 3 that every voter will find at least one they like (or at least can put up with). STV does that. STV is not a runoff.

Runoff once, not twice.

Hope that explains the D!

---

If you're wondering what the ballot instructions for STV is, it's the same as IRV:

This is a ranked vote: order does matter! You can upvote your favourites and downvote your least favourites. You may choose to rank as many or as few options as you like, but we encourage you to rank as many options as possible to ensure your preferences are taken into account.

The difference is how the votes get counted which is no concern to most voters anyway. For the CAP leaders, all they need to know is it's a system designed to elect multiple winners. IRV and HTH are single winner systems.

I ran some scripts to test out STV and HTH...

Main points:

• STV will advance different entries for the secondary ability poll, art poll 2, TLT, prevo stats, and prevo art poll
• STV is less prone to having ties than HTH and PBV
• HTH is very prone to ties when there's >3 entries (see TLT poll for problem)
• HTH ignores winning margins, and may advance the top 3 even when #1 is a supermajority in PBV and STV (see typing poll) That's unless we adjust it to check supermajorities in the tallying phase
• The above two points make HTH undesirable for initial stages, and puts proposal C into further question.
• Where HTH actually shines is when there's exactly 3 entries, like the prevo typing poll, where the only way to tie is by the simplest Condorcet paradox (e.g. grass>water>fire>grass) which IRV can easily resolve.
• Since proportional rep will qualify different entries in some polls, shows that CAP's initial rounds don't reflect the whole community consensus, but a smaller subset of people within it. From that it's fair to say the system is not entirely democratic.

Some logs for reference~

TLT poll - STV

CAP 22 Topic Leadership Team Poll -- STV output

Quota: 6.8

Round 1: cbrevan=15  snake_rattler=6  snobalt=5  numbercruncher=3  ununhexium=2  deckknight=1  ignus=1  elitelordsigma=1  --> cbrevan qualifies
Round 2: snake_rattler=8.733  snobalt=6.64  deckknight=4.28  numbercruncher=3  ununhexium=2  elitelordsigma=1.547  ignus=1  --> snake_rattler qualifies
Round 3: snobalt=6.861  deckknight=5.086  numbercruncher=3  ununhexium=2.121  elitelordsigma=1.668  ignus=1.664  --> snobalt qualifies
Round 4: deckknight=5.102  numbercruncher=3.014  ununhexium=2.135  elitelordsigma=1.677  ignus=1.673  --> ignus eliminated
Round 5: deckknight=6.553  numbercruncher=3.014  ununhexium=2.135  elitelordsigma=1.898  --> elitelordsigma eliminated
Round 6: deckknight=8.451  numbercruncher=3.014  ununhexium=2.135  --> deckknight qualifies
Round 7: numbercruncher=3.578  ununhexium=3.222  --> ununhexium eliminated
Round 8: numbercruncher=6.572  --> numbercruncher eliminated

[Ballot#01] ununhexium=0.778, deckknight=0, snobalt=0, elitelordsigma=0, numbercruncher=0.111, ignus=0, snake_rattler=0, cbrevan=0, EXHAUSTED=0.111
[Ballot#02] cbrevan=0.514, deckknight=0.448, snake_rattler=0, elitelordsigma=0, snobalt=0, ununhexium=0.013, EXHAUSTED=0.025
[Ballot#03] ununhexium=0.778, elitelordsigma=0, ignus=0, cbrevan=0, numbercruncher=0.111, EXHAUSTED=0.111
[Ballot#04] cbrevan=0.514, deckknight=0.448, snake_rattler=0, elitelordsigma=0, snobalt=0, ununhexium=0.013, EXHAUSTED=0.025
[Ballot#05] cbrevan=0.514, elitelordsigma=0.243, deckknight=0.205, ununhexium=0.013, numbercruncher=0.013, snobalt=0, EXHAUSTED=0.013
[Ballot#06] snobalt=0.994, deckknight=0.005, cbrevan=0, ununhexium=0, snake_rattler=0, numbercruncher=0, elitelordsigma=0, ignus=0, EXHAUSTED=0
[Ballot#07] snake_rattler=0.828, cbrevan=0, deckknight=0.157, elitelordsigma=0, numbercruncher=0.01, snobalt=0, ignus=0, ununhexium=0, EXHAUSTED=0.005
[Ballot#08] cbrevan=0.514, deckknight=0.486, elitelordsigma=0, snake_rattler=0, ignus=0, EXHAUSTED=0
[Ballot#09] cbrevan=0.514, deckknight=0.448, snake_rattler=0, elitelordsigma=0, snobalt=0, ignus=0, numbercruncher=0.025, ununhexium=0, EXHAUSTED=0.013
[Ballot#10] snobalt=0.994, ignus=0.001, deckknight=0.004, snake_rattler=0, elitelordsigma=0, cbrevan=0, numbercruncher=0, EXHAUSTED=0
[Ballot#11] cbrevan=0.514, deckknight=0.448, ignus=0, elitelordsigma=0, snake_rattler=0, snobalt=0, ununhexium=0.013, numbercruncher=0.013, EXHAUSTED=0.013
[Ballot#12] snake_rattler=0.828, ignus=0.049, cbrevan=0, deckknight=0.108, numbercruncher=0.01, elitelordsigma=0, snobalt=0, ununhexium=0, EXHAUSTED=0.005
[Ballot#13] snake_rattler=0.828, cbrevan=0, snobalt=0.171, deckknight=0.001, elitelordsigma=0, numbercruncher=0, ignus=0, ununhexium=0, EXHAUSTED=0
[Ballot#14] snake_rattler=0.828, ignus=0.049, cbrevan=0, deckknight=0.108, snobalt=0, numbercruncher=0.01, elitelordsigma=0, ununhexium=0, EXHAUSTED=0.005
[Ballot#15] numbercruncher=0.889, deckknight=0, ignus=0, cbrevan=0, snobalt=0, elitelordsigma=0, snake_rattler=0, ununhexium=0, EXHAUSTED=0.111
[Ballot#16] ignus=0.444, snobalt=0, deckknight=0.486, cbrevan=0, elitelordsigma=0, ununhexium=0.023, snake_rattler=0, numbercruncher=0.023, EXHAUSTED=0.023
[Ballot#17] snobalt=0.994, ununhexium=0.004, numbercruncher=0.001, deckknight=0, elitelordsigma=0, ignus=0, snake_rattler=0, cbrevan=0, EXHAUSTED=0.001
[Ballot#18] cbrevan=0.514, snobalt=0.483, deckknight=0.003, numbercruncher=0, elitelordsigma=0, snake_rattler=0, ununhexium=0, ignus=0, EXHAUSTED=0
[Ballot#19] cbrevan=0.514, deckknight=0.448, numbercruncher=0.025, snobalt=0, ununhexium=0, snake_rattler=0, elitelordsigma=0, ignus=0, EXHAUSTED=0.013
[Ballot#20] snake_rattler=0.828, ignus=0.049, cbrevan=0, elitelordsigma=0.025, deckknight=0.083, numbercruncher=0.01, snobalt=0, ununhexium=0, EXHAUSTED=0.005
[Ballot#21] snobalt=0.994, cbrevan=0, elitelordsigma=0.002, deckknight=0.003, snake_rattler=0, ignus=0, ununhexium=0, numbercruncher=0, EXHAUSTED=0
[Ballot#22] cbrevan=0.514, snobalt=0.483, snake_rattler=0, numbercruncher=0.003, deckknight=0, ununhexium=0, elitelordsigma=0, ignus=0, EXHAUSTED=0.001
[Ballot#23] snake_rattler=0.828, cbrevan=0, deckknight=0.157, elitelordsigma=0, numbercruncher=0.01, ignus=0, ununhexium=0, snobalt=0, EXHAUSTED=0.005
[Ballot#24] numbercruncher=0.889, cbrevan=0, snake_rattler=0, deckknight=0, elitelordsigma=0, EXHAUSTED=0.111
[Ballot#25] snobalt=0.994, cbrevan=0, numbercruncher=0.005, deckknight=0, ununhexium=0, snake_rattler=0, elitelordsigma=0, ignus=0, EXHAUSTED=0.001
[Ballot#26] elitelordsigma=0.556, snobalt=0, cbrevan=0, snake_rattler=0, deckknight=0.375, ununhexium=0.023, numbercruncher=0.023, ignus=0, EXHAUSTED=0.023
[Ballot#27] numbercruncher=0.889, deckknight=0, snake_rattler=0, cbrevan=0, snobalt=0, ignus=0, EXHAUSTED=0.111
[Ballot#28] cbrevan=0.514, snake_rattler=0.392, ununhexium=0.067, deckknight=0, elitelordsigma=0, ignus=0, numbercruncher=0.013, snobalt=0, EXHAUSTED=0.013
[Ballot#29] deckknight=0.93, cbrevan=0, ununhexium=0.023, elitelordsigma=0, snake_rattler=0, ignus=0, numbercruncher=0.023, snobalt=0, EXHAUSTED=0.023
[Ballot#30] cbrevan=0.514, snake_rattler=0.392, elitelordsigma=0.04, deckknight=0.045, numbercruncher=0.006, ununhexium=0, snobalt=0, ignus=0, EXHAUSTED=0.003
[Ballot#31] cbrevan=0.514, snake_rattler=0.392, deckknight=0.086, ignus=0, snobalt=0, elitelordsigma=0, numbercruncher=0.006, ununhexium=0, EXHAUSTED=0.003
[Ballot#32] cbrevan=0.514, snobalt=0.483, ununhexium=0.002, deckknight=0, snake_rattler=0, ignus=0, elitelordsigma=0, numbercruncher=0.001, EXHAUSTED=0.001
[Ballot#33] cbrevan=0.514, snake_rattler=0.392, deckknight=0.086, snobalt=0, numbercruncher=0.006, ununhexium=0, elitelordsigma=0, ignus=0, EXHAUSTED=0.003
[Ballot#34] cbrevan=0.514, snake_rattler=0.392, deckknight=0.086, elitelordsigma=0, numbercruncher=0.006, snobalt=0, ununhexium=0, ignus=0, EXHAUSTED=0.003

RUNDOWN:
1. cbrevan (7.711)
2. snake_rattler (6.926)
3. snobalt (6.589)
4. deckknight (5.652)
5. numbercruncher (3.132)
6. ununhexium (1.75)
7. elitelordsigma (0.865)
8. ignus (0.593)

typing poll - HTH

CAP 22 Typing Poll 1 -- HTH output

electric/fairy (44:37) electric/fighting
electric/fairy (50:33) electric/grass
electric/fairy (27:56) fairy/fighting
electric/fairy (52:25) fairy/steel
electric/fairy (57:20) fire/steel
electric/fairy (61:18) ground/ice
electric/fighting (51:31) electric/grass
electric/fighting (25:60) fairy/fighting
electric/fighting (53:30) fairy/steel
electric/fighting (57:20) fire/steel
electric/fighting (59:21) ground/ice
electric/grass (18:64) fairy/fighting
electric/grass (45:36) fairy/steel
electric/grass (53:27) fire/steel
electric/grass (54:24) ground/ice
fairy/fighting (65:17) fairy/steel
fairy/fighting (69:15) fire/steel
fairy/fighting (67:10) ground/ice
fairy/steel (41:34) fire/steel
fairy/steel (46:29) ground/ice
fire/steel (40:33) ground/ice

RUNDOWN:
1. fairy/fighting (6)
2. electric/fairy (5)
3. electric/fighting (4)
4. electric/grass (3)
5. fairy/steel (2)
6. fire/steel (1)
7. ground/ice (0)

art poll 2 - STV

CAP 22 Art Poll 2 -- STV output

Quota: 34.25

Round 1: magistrum=31  sunfished=22  fellfromthesky=19  axl=16  qxc4eva=14  yilx=14  thebangzats=12  golurkyourself=9  --> golurkyourself eliminated
Round 2: magistrum=34  sunfished=25  fellfromthesky=20  axl=17  qxc4eva=15  yilx=14  thebangzats=12  --> thebangzats eliminated
Round 3: magistrum=35  sunfished=27  axl=21  fellfromthesky=20  yilx=18  qxc4eva=15  --> magistrum qualifies
Round 4: sunfished=27.169  axl=21.145  fellfromthesky=20.218  yilx=18.073  qxc4eva=15.145  --> qxc4eva eliminated
Round 5: sunfished=34.169  fellfromthesky=22.266  axl=22.194  yilx=21.097  --> yilx eliminated
Round 6: sunfished=39.194  axl=29.218  fellfromthesky=27.315  --> sunfished qualifies
Round 7: axl=32.176  fellfromthesky=29.3  --> fellfromthesky eliminated
Round 8: axl=46.564  --> axl qualifies

[Ballot#001] magistrum=0.984, qxc4eva=0.003, axl=0.013, EXHAUSTED=0.001
[Ballot#002] magistrum=0.984, golurkyourself=0, sunfished=0.016, EXHAUSTED=0
[Ballot#003] fellfromthesky=0.778, golurkyourself=0, sunfished=0, EXHAUSTED=0.222
[Ballot#004] sunfished=0.934, thebangzats=0, yilx=0, golurkyourself=0, axl=0.06, qxc4eva=0, fellfromthesky=0, magistrum=0, EXHAUSTED=0.006
[Ballot#005] fellfromthesky=0.778, axl=0.193, qxc4eva=0, yilx=0, thebangzats=0, golurkyourself=0, sunfished=0, magistrum=0, EXHAUSTED=0.029
[Ballot#006] yilx=0.556, qxc4eva=0, golurkyourself=0, axl=0.415, EXHAUSTED=0.029
[Ballot#007] sunfished=0.934, golurkyourself=0, thebangzats=0, fellfromthesky=0.022, yilx=0, qxc4eva=0, axl=0.038, magistrum=0, EXHAUSTED=0.006
[Ballot#008] magistrum=0.984, fellfromthesky=0.011, axl=0.005, qxc4eva=0, golurkyourself=0, yilx=0, thebangzats=0, sunfished=0, EXHAUSTED=0.001
[Ballot#009] sunfished=0.934, axl=0.06, golurkyourself=0, qxc4eva=0, EXHAUSTED=0.006
[Ballot#010] magistrum=0.984, fellfromthesky=0.011, sunfished=0, qxc4eva=0, thebangzats=0, yilx=0, EXHAUSTED=0.005
[Ballot#011] axl=0.971, qxc4eva=0, EXHAUSTED=0.029
[Ballot#012] magistrum=0.984, axl=0.015, yilx=0, golurkyourself=0, EXHAUSTED=0.001
[Ballot#013] golurkyourself=0.111, sunfished=0.823, axl=0.06, thebangzats=0, fellfromthesky=0, magistrum=0, yilx=0, qxc4eva=0, EXHAUSTED=0.006
[Ballot#014] sunfished=0.934, fellfromthesky=0.022, magistrum=0, yilx=0, EXHAUSTED=0.044
[Ballot#015] magistrum=0.984, axl=0.015, yilx=0, EXHAUSTED=0.001
[Ballot#016] fellfromthesky=0.778, magistrum=0, sunfished=0, qxc4eva=0, axl=0.193, EXHAUSTED=0.029
[Ballot#017] magistrum=0.984, golurkyourself=0, axl=0.015, EXHAUSTED=0.001
[Ballot#018] sunfished=0.934, magistrum=0, fellfromthesky=0.022, yilx=0, golurkyourself=0, axl=0.038, qxc4eva=0, thebangzats=0, EXHAUSTED=0.006
[Ballot#019] yilx=0.556, magistrum=0, thebangzats=0, EXHAUSTED=0.444
[Ballot#020] qxc4eva=0.444, yilx=0.111, fellfromthesky=0.222, EXHAUSTED=0.222
[Ballot#021] axl=0.971, yilx=0, sunfished=0, qxc4eva=0, magistrum=0, golurkyourself=0, fellfromthesky=0, thebangzats=0, EXHAUSTED=0.029
[Ballot#022] qxc4eva=0.444, sunfished=0.556, EXHAUSTED=0
[Ballot#023] sunfished=1, yilx=0, magistrum=0, EXHAUSTED=0
[Ballot#024] magistrum=0.984, fellfromthesky=0.011, axl=0.005, sunfished=0, EXHAUSTED=0.001
[Ballot#025] yilx=0.556, axl=0.415, thebangzats=0, EXHAUSTED=0.029
[Ballot#026] yilx=0.556, qxc4eva=0, fellfromthesky=0.222, axl=0.193, thebangzats=0, magistrum=0, golurkyourself=0, sunfished=0, EXHAUSTED=0.029
[Ballot#027] golurkyourself=0.111, magistrum=0.873, fellfromthesky=0.011, thebangzats=0, EXHAUSTED=0.005
[Ballot#028] fellfromthesky=0.778, magistrum=0, sunfished=0, qxc4eva=0, EXHAUSTED=0.222
[Ballot#029] golurkyourself=0.111, sunfished=0.823, magistrum=0, thebangzats=0, fellfromthesky=0.022, EXHAUSTED=0.044
[Ballot#030] magistrum=0.984, fellfromthesky=0.011, sunfished=0, golurkyourself=0, qxc4eva=0, thebangzats=0, yilx=0, axl=0.005, EXHAUSTED=0.001
[Ballot#031] axl=0.971, sunfished=0, magistrum=0, fellfromthesky=0, yilx=0, golurkyourself=0, thebangzats=0, qxc4eva=0, EXHAUSTED=0.029
[Ballot#032] magistrum=0.984, sunfished=0.015, thebangzats=0, golurkyourself=0, fellfromthesky=0.001, axl=0.001, qxc4eva=0, yilx=0, EXHAUSTED=0
[Ballot#033] magistrum=0.984, fellfromthesky=0.011, qxc4eva=0, sunfished=0, yilx=0, EXHAUSTED=0.005
[Ballot#034] qxc4eva=0.444, sunfished=0.556, EXHAUSTED=0
[Ballot#035] magistrum=0.984, axl=0.015, fellfromthesky=0, sunfished=0, EXHAUSTED=0.001
[Ballot#036] fellfromthesky=0.778, magistrum=0, yilx=0, qxc4eva=0, golurkyourself=0, EXHAUSTED=0.222
[Ballot#037] magistrum=0.984, fellfromthesky=0.011, sunfished=0, axl=0.005, EXHAUSTED=0.001
[Ballot#038] axl=0.971, magistrum=0, sunfished=0, golurkyourself=0, yilx=0, fellfromthesky=0, thebangzats=0, qxc4eva=0, EXHAUSTED=0.029
[Ballot#039] fellfromthesky=0.778, magistrum=0, axl=0.193, qxc4eva=0, EXHAUSTED=0.029
[Ballot#040] magistrum=0.984, sunfished=0.015, golurkyourself=0, axl=0.001, yilx=0, thebangzats=0, EXHAUSTED=0
[Ballot#041] qxc4eva=0.444, sunfished=0.49, axl=0.06, fellfromthesky=0, golurkyourself=0, EXHAUSTED=0.006
[Ballot#042] qxc4eva=0.444, golurkyourself=0, thebangzats=0, EXHAUSTED=0.556
[Ballot#043] sunfished=1, magistrum=0, EXHAUSTED=0
[Ballot#044] axl=0.971, fellfromthesky=0, sunfished=0, thebangzats=0, golurkyourself=0, qxc4eva=0, EXHAUSTED=0.029
[Ballot#045] magistrum=0.984, sunfished=0.015, thebangzats=0, yilx=0, golurkyourself=0, fellfromthesky=0.001, EXHAUSTED=0.001
[Ballot#046] axl=0.971, sunfished=0, magistrum=0, EXHAUSTED=0.029
[Ballot#047] fellfromthesky=0.778, magistrum=0, golurkyourself=0, EXHAUSTED=0.222
[Ballot#048] magistrum=0.984, axl=0.015, qxc4eva=0, EXHAUSTED=0.001
[Ballot#049] sunfished=1, thebangzats=0, EXHAUSTED=0
[Ballot#050] axl=0.971, qxc4eva=0, yilx=0, magistrum=0, sunfished=0, fellfromthesky=0, golurkyourself=0, thebangzats=0, EXHAUSTED=0.029
[Ballot#051] fellfromthesky=0.778, sunfished=0, axl=0.193, EXHAUSTED=0.029
[Ballot#052] magistrum=0.984, golurkyourself=0, yilx=0.005, axl=0.01, fellfromthesky=0, sunfished=0, thebangzats=0, qxc4eva=0, EXHAUSTED=0.001
[Ballot#053] thebangzats=0.222, golurkyourself=0, axl=0.748, fellfromthesky=0, qxc4eva=0, EXHAUSTED=0.029
[Ballot#054] qxc4eva=0.444, yilx=0.111, golurkyourself=0, axl=0.415, fellfromthesky=0, EXHAUSTED=0.029
[Ballot#055] yilx=0.556, qxc4eva=0, sunfished=0.444, EXHAUSTED=0
[Ballot#056] fellfromthesky=0.778, magistrum=0, axl=0.193, EXHAUSTED=0.029
[Ballot#057] yilx=0.556, sunfished=0.379, fellfromthesky=0.022, axl=0.038, EXHAUSTED=0.006
[Ballot#058] sunfished=0.934, axl=0.06, thebangzats=0, golurkyourself=0, EXHAUSTED=0.006
[Ballot#059] thebangzats=0.222, yilx=0.333, magistrum=0, fellfromthesky=0.222, qxc4eva=0, golurkyourself=0, axl=0.193, sunfished=0, EXHAUSTED=0.029
[Ballot#060] sunfished=0.934, thebangzats=0, axl=0.06, magistrum=0, yilx=0, fellfromthesky=0, golurkyourself=0, qxc4eva=0, EXHAUSTED=0.006
[Ballot#061] magistrum=1, EXHAUSTED=0
[Ballot#062] golurkyourself=0.111, qxc4eva=0.333, magistrum=0, thebangzats=0, axl=0.526, yilx=0, fellfromthesky=0, sunfished=0, EXHAUSTED=0.029
[Ballot#063] fellfromthesky=0.778, EXHAUSTED=0.222
[Ballot#064] magistrum=0.984, golurkyourself=0, qxc4eva=0.003, yilx=0.003, fellfromthesky=0.005, axl=0.005, sunfished=0, EXHAUSTED=0.001
[Ballot#065] golurkyourself=0.111, magistrum=0.873, qxc4eva=0.003, fellfromthesky=0.008, yilx=0, thebangzats=0, axl=0.005, sunfished=0, EXHAUSTED=0.001
[Ballot#066] axl=0.971, yilx=0, golurkyourself=0, sunfished=0, magistrum=0, EXHAUSTED=0.029
[Ballot#067] sunfished=1, magistrum=0, thebangzats=0, EXHAUSTED=0
[Ballot#068] golurkyourself=0.111, magistrum=0.873, sunfished=0.015, yilx=0, fellfromthesky=0.001, qxc4eva=0, thebangzats=0, axl=0.001, EXHAUSTED=0
[Ballot#069] axl=0.971, fellfromthesky=0, qxc4eva=0, golurkyourself=0, thebangzats=0, magistrum=0, sunfished=0, yilx=0, EXHAUSTED=0.029
[Ballot#070] sunfished=0.934, golurkyourself=0, axl=0.06, thebangzats=0, yilx=0, EXHAUSTED=0.006
[Ballot#071] fellfromthesky=0.778, sunfished=0, qxc4eva=0, golurkyourself=0, EXHAUSTED=0.222
[Ballot#072] sunfished=0.934, yilx=0, fellfromthesky=0.022, EXHAUSTED=0.044
[Ballot#073] thebangzats=0.222, sunfished=0.712, fellfromthesky=0.022, yilx=0, magistrum=0, qxc4eva=0, axl=0.038, EXHAUSTED=0.006
[Ballot#074] magistrum=0.984, fellfromthesky=0.011, EXHAUSTED=0.005
[Ballot#075] sunfished=1, magistrum=0, qxc4eva=0, EXHAUSTED=0
[Ballot#076] magistrum=0.984, thebangzats=0, golurkyourself=0, yilx=0.005, fellfromthesky=0.005, sunfished=0, qxc4eva=0, axl=0.005, EXHAUSTED=0.001
[Ballot#077] qxc4eva=0.444, sunfished=0.556, magistrum=0, yilx=0, EXHAUSTED=0
[Ballot#078] sunfished=0.934, axl=0.06, magistrum=0, fellfromthesky=0, golurkyourself=0, yilx=0, qxc4eva=0, thebangzats=0, EXHAUSTED=0.006
[Ballot#079] fellfromthesky=0.778, axl=0.193, qxc4eva=0, EXHAUSTED=0.029
[Ballot#080] axl=0.971, magistrum=0, fellfromthesky=0, sunfished=0, EXHAUSTED=0.029
[Ballot#081] thebangzats=0.222, yilx=0.333, magistrum=0, fellfromthesky=0.222, axl=0.193, sunfished=0, EXHAUSTED=0.029
[Ballot#082] fellfromthesky=0.778, EXHAUSTED=0.222
[Ballot#083] magistrum=1, EXHAUSTED=0
[Ballot#084] golurkyourself=0.111, axl=0.86, sunfished=0, EXHAUSTED=0.029
[Ballot#085] qxc4eva=0.444, thebangzats=0, sunfished=0.556, EXHAUSTED=0
[Ballot#086] thebangzats=0.222, axl=0.748, fellfromthesky=0, EXHAUSTED=0.029
[Ballot#087] axl=0.971, magistrum=0, yilx=0, sunfished=0, EXHAUSTED=0.029
[Ballot#088] yilx=0.556, sunfished=0.379, axl=0.06, thebangzats=0, EXHAUSTED=0.006
[Ballot#089] fellfromthesky=0.778, sunfished=0, golurkyourself=0, magistrum=0, EXHAUSTED=0.222
[Ballot#090] fellfromthesky=0.778, thebangzats=0, yilx=0, qxc4eva=0, golurkyourself=0, axl=0.193, sunfished=0, magistrum=0, EXHAUSTED=0.029
[Ballot#091] yilx=0.556, magistrum=0, fellfromthesky=0.222, sunfished=0, EXHAUSTED=0.222
[Ballot#092] thebangzats=0.222, yilx=0.333, magistrum=0, sunfished=0.379, axl=0.06, golurkyourself=0, qxc4eva=0, fellfromthesky=0, EXHAUSTED=0.006
[Ballot#093] yilx=0.556, thebangzats=0, EXHAUSTED=0.444
[Ballot#094] sunfished=0.934, golurkyourself=0, qxc4eva=0, yilx=0, thebangzats=0, fellfromthesky=0.022, magistrum=0, axl=0.038, EXHAUSTED=0.006
[Ballot#095] magistrum=0.984, fellfromthesky=0.011, sunfished=0, yilx=0, thebangzats=0, EXHAUSTED=0.005
[Ballot#096] yilx=0.556, axl=0.415, EXHAUSTED=0.029
[Ballot#097] thebangzats=0.222, magistrum=0.762, qxc4eva=0.003, fellfromthesky=0.008, axl=0.005, EXHAUSTED=0.001
[Ballot#098] qxc4eva=0.444, EXHAUSTED=0.556
[Ballot#099] sunfished=1, thebangzats=0, golurkyourself=0, EXHAUSTED=0
[Ballot#100] sunfished=0.934, axl=0.06, magistrum=0, thebangzats=0, EXHAUSTED=0.006
[Ballot#101] fellfromthesky=0.778, EXHAUSTED=0.222
[Ballot#102] golurkyourself=0.111, sunfished=0.823, fellfromthesky=0.022, yilx=0, thebangzats=0, EXHAUSTED=0.044
[Ballot#103] magistrum=0.984, qxc4eva=0.003, axl=0.013, EXHAUSTED=0.001
[Ballot#104] fellfromthesky=0.778, thebangzats=0, sunfished=0, EXHAUSTED=0.222
[Ballot#105] sunfished=0.934, golurkyourself=0, axl=0.06, thebangzats=0, magistrum=0, fellfromthesky=0, qxc4eva=0, EXHAUSTED=0.006
[Ballot#106] axl=0.971, qxc4eva=0, yilx=0, EXHAUSTED=0.029
[Ballot#107] magistrum=0.984, sunfished=0.015, qxc4eva=0, thebangzats=0, yilx=0, fellfromthesky=0.001, golurkyourself=0, axl=0.001, EXHAUSTED=0
[Ballot#108] thebangzats=0.222, yilx=0.333, axl=0.415, golurkyourself=0, EXHAUSTED=0.029
[Ballot#109] thebangzats=0.222, sunfished=0.712, magistrum=0, qxc4eva=0, axl=0.06, golurkyourself=0, yilx=0, fellfromthesky=0, EXHAUSTED=0.006
[Ballot#110] qxc4eva=0.444, sunfished=0.49, golurkyourself=0, yilx=0, thebangzats=0, magistrum=0, axl=0.06, fellfromthesky=0, EXHAUSTED=0.006
[Ballot#111] thebangzats=0.222, EXHAUSTED=0.778
[Ballot#112] qxc4eva=0.444, golurkyourself=0, sunfished=0.556, magistrum=0, EXHAUSTED=0
[Ballot#113] fellfromthesky=0.778, qxc4eva=0, axl=0.193, sunfished=0, thebangzats=0, EXHAUSTED=0.029
[Ballot#114] axl=0.971, magistrum=0, yilx=0, fellfromthesky=0, qxc4eva=0, sunfished=0, golurkyourself=0, thebangzats=0, EXHAUSTED=0.029
[Ballot#115] thebangzats=0.222, axl=0.748, EXHAUSTED=0.029
[Ballot#116] qxc4eva=0.444, fellfromthesky=0.333, sunfished=0, magistrum=0, EXHAUSTED=0.222
[Ballot#117] magistrum=1, golurkyourself=0, EXHAUSTED=0
[Ballot#118] magistrum=0.984, golurkyourself=0, axl=0.015, fellfromthesky=0, EXHAUSTED=0.001
[Ballot#119] yilx=0.556, magistrum=0, axl=0.415, EXHAUSTED=0.029
[Ballot#120] magistrum=0.984, sunfished=0.016, qxc4eva=0, EXHAUSTED=0
[Ballot#121] magistrum=0.984, yilx=0.005, thebangzats=0, sunfished=0.009, golurkyourself=0, axl=0.001, qxc4eva=0, fellfromthesky=0, EXHAUSTED=0
[Ballot#122] fellfromthesky=0.778, golurkyourself=0, thebangzats=0, magistrum=0, axl=0.193, yilx=0, EXHAUSTED=0.029
[Ballot#123] yilx=0.556, thebangzats=0, golurkyourself=0, magistrum=0, axl=0.415, fellfromthesky=0, sunfished=0, qxc4eva=0, EXHAUSTED=0.029
[Ballot#124] golurkyourself=0.111, fellfromthesky=0.667, qxc4eva=0, EXHAUSTED=0.222
[Ballot#125] qxc4eva=0.444, golurkyourself=0, fellfromthesky=0.333, magistrum=0, yilx=0, axl=0.193, sunfished=0, thebangzats=0, EXHAUSTED=0.029
[Ballot#126] sunfished=0.934, axl=0.06, thebangzats=0, EXHAUSTED=0.006
[Ballot#127] thebangzats=0.222, axl=0.748, golurkyourself=0, yilx=0, EXHAUSTED=0.029
[Ballot#128] magistrum=0.984, qxc4eva=0.003, EXHAUSTED=0.013
[Ballot#129] sunfished=0.934, magistrum=0, fellfromthesky=0.022, golurkyourself=0, qxc4eva=0, thebangzats=0, yilx=0, axl=0.038, EXHAUSTED=0.006
[Ballot#130] axl=0.971, golurkyourself=0, fellfromthesky=0, EXHAUSTED=0.029
[Ballot#131] axl=0.971, golurkyourself=0, fellfromthesky=0, EXHAUSTED=0.029
[Ballot#132] yilx=0.556, EXHAUSTED=0.444
[Ballot#133] qxc4eva=0.444, magistrum=0, yilx=0.111, golurkyourself=0, EXHAUSTED=0.444
[Ballot#134] yilx=0.556, thebangzats=0, magistrum=0, sunfished=0.444, EXHAUSTED=0
[Ballot#135] axl=0.971, sunfished=0, EXHAUSTED=0.029
[Ballot#136] sunfished=1, golurkyourself=0, EXHAUSTED=0
[Ballot#137] magistrum=1, EXHAUSTED=0

RUNDOWN:
1. magistrum (33.944)
2. sunfished (30.809)
3. axl (26.616)
4. fellfromthesky (17.566)
5. yilx (9.463)
6. qxc4eva (6.572)
7. thebangzats (2.667)
8. golurkyourself (1)

art poll 2 - HTH

CAP 22 Art Poll 2 -- HTH output

axl (55:54) fellfromthesky
axl (54:48) golurkyourself
axl (46:69) magistrum
axl (60:45) qxc4eva
axl (54:62) sunfished
axl (57:44) thebangzats
axl (55:48) yilx
fellfromthesky (52:48) golurkyourself
fellfromthesky (41:69) magistrum
fellfromthesky (63:38) qxc4eva
fellfromthesky (54:56) sunfished
fellfromthesky (59:42) thebangzats
fellfromthesky (55:49) yilx
golurkyourself (40:69) magistrum
golurkyourself (50:46) qxc4eva
golurkyourself (40:68) sunfished
golurkyourself (51:40) thebangzats
golurkyourself (48:47) yilx
magistrum (73:35) qxc4eva
magistrum (60:53) sunfished
magistrum (69:40) thebangzats
magistrum (69:36) yilx
qxc4eva (41:67) sunfished
qxc4eva (52:46) thebangzats
qxc4eva (49:49) yilx
sunfished (72:31) thebangzats
sunfished (65:42) yilx
thebangzats (42:48) yilx

RUNDOWN:
1. magistrum (7)
2. sunfished (6)
3. axl (5)
4. fellfromthesky (4)
5. golurkyourself (3)
6. qxc4eva, yilx (1)
-
8. thebangzats (0)

art poll 2 - ranked pairs ....just to show HTH =/= RP!!

CAP 22 Art Poll 2 -- Ranked Pairs output

[Pair#01] sunfished (72:31) thebangzats
[Pair#02] magistrum (73:35) qxc4eva
[Pair#03] magistrum (69:36) yilx
[Pair#04] magistrum (69:40) golurkyourself
[Pair#05] magistrum (69:40) thebangzats
[Pair#06] sunfished (68:40) golurkyourself
[Pair#07] magistrum (69:41) fellfromthesky
[Pair#08] fellfromthesky (63:38) qxc4eva
[Pair#09] sunfished (67:41) qxc4eva
[Pair#10] sunfished (65:42) yilx
[Pair#11] magistrum (69:46) axl
[Pair#12] fellfromthesky (59:42) thebangzats
[Pair#13] axl (60:45) qxc4eva
[Pair#14] axl (57:44) thebangzats
[Pair#15] golurkyourself (51:40) thebangzats
[Pair#16] sunfished (62:54) axl
[Pair#17] axl (55:48) yilx
[Pair#18] yilx (48:42) thebangzats
[Pair#19] magistrum (60:53) sunfished
[Pair#20] qxc4eva (52:46) thebangzats
[Pair#21] axl (54:48) golurkyourself
[Pair#22] fellfromthesky (55:49) yilx
[Pair#23] golurkyourself (50:46) qxc4eva
[Pair#24] fellfromthesky (52:48) golurkyourself
[Pair#25] sunfished (56:54) fellfromthesky
[Pair#26] golurkyourself (48:47) yilx
[Pair#27] axl (55:54) fellfromthesky
[Pair#28] qxc4eva (49:49) yilx  --> CANCELLED (tie)

MAGISTRUM > [sunfished][axl][fellfromthesky][thebangzats][golurkyourself][yilx][qxc4eva]
[magistrum] > SUNFISHED > [fellfromthesky][axl][yilx][qxc4eva][golurkyourself][thebangzats]
[magistrum][sunfished] > AXL > [fellfromthesky][golurkyourself][yilx][thebangzats][qxc4eva]
[magistrum][sunfished][axl] > FELLFROMTHESKY > [golurkyourself][yilx][thebangzats][qxc4eva]
[magistrum][sunfished][axl][fellfromthesky] > GOLURKYOURSELF > [yilx][qxc4eva][thebangzats]
[magistrum][sunfished][axl][fellfromthesky][golurkyourself] > YILX > [thebangzats]
[magistrum][fellfromthesky][sunfished][axl][golurkyourself] > QXC4EVA > [thebangzats]
[sunfished][magistrum][fellfromthesky][axl][golurkyourself][yilx][qxc4eva] > THEBANGZATS

RUNDOWN:
1. magistrum (1|3|0.5)
2. sunfished (0.67|2|0.33)
3. axl (0.33|1|0.03)
4. fellfromthesky (0|0|0.06)
5. golurkyourself (-0.33|-1|-0.15)
6. yilx (-0.67|-2|-0.19)
7. qxc4eva (-0.67|-2|-0.29)
8. thebangzats (-1|-3|-0.36)

Back to proposals, my order of preference is D > B > A > current process > C. I support D because the others elect a second winner to replace the first one, which doesn't make sense! Proposal A and B are my next favorites since they fix the OP's issue.. I just like B more cuz it's simpler :P The reason I think C is worst than right now is that HTH can get ambiguous in large polls. IRV on the other hand, is never ambiguous. Even if it doesn't elect the Condorcet winner it still elects the most popular one, so it's arguble whether it messed up or not >.>
If proposal C uses Ranked Pairs over HTH, my preference will change to D>C>B>A>current. Ranked pairs is not ambiguous unlike HTH.

You probably think by now proposal D is my religion but it's definitely not! :D If you ask me, I'd go with CPOSTV for poll 1 and Ranked Pairs for poll 2. Both are "upgrades" of STV and HTH are less prone to stuff like tactical voting. But I notice CAP seems to like taking things one step at a time, so maybe it's best to move on from here with proposal B first, then eventually to D if we agree.



Q&A

I'm looking for mechanisms to stop IRV sucking terribly when polls are close like in the above example. HTH or Ranked Pairs stop this. I don't think it has been proven that STV does stop this.

Every system will "mess up" in some way or the other, so the question is where to draw the line. I can flip your statement around and say HTH would suck terribly by electing candidate A who has fewer high place votes than B. Switching back to IRV will fix that! At the end of the day, it really depends how you want to define the winner. Me and Tsaeb agree with you that the final poll should elect the Condorcet winner (instead of the most popular one) which is why proposal D supports HTH in poll 2. But for poll 1, I argue that it's more important to accurately eliminate stuff than to accurately declare who came first. Under this context, IRV and HTH will "mess up", STV does not.

I'm not looking for mechanisms that claim to make a more diversely spread final poll.

Of course you're not. ;p Diversity just happens to be a common difference with STV and IRV results. It's not the actual reason why STV was proposed in the first place. If you found Tsaeb's explanation confusing feel free to read the wikipedia article.

Now, do I think 2 polls without a shared voter base is the best thing we could do? No, not necessarily. It does have the benefit of letting the top candidates have more time to collect votes which in turn helps create hype and makes the process more exciting. Perhaps there's better ways to do this, however?

Yup - proposal D. Refer to the top of my post, the very reason for D was to address the voter bases problem and still have 2 polls.

In terms of keeping track of the vote, having two polls for each competitive stage does create some wonky conflicting results. But this is due to our lack of a shared voter base between the polls rather than an inherent flaw in the ballot counting from our scripts.

I agree it's not a flaw in the counting script ... but it's a flaw in the CAP process. Both polls have different demographics so why does CAP have two polls AND both of them be runoffs? :\ All we need to do is fix one of this. We either have one 48-hour runoff poll, or have two polls where only the final one is a runoff. Either way is fine. The later is what D is about!

In poll 1, people's criteria when voting could very well be on there most importantly perceived traits. Voters might really hate the move Charge Beam and really love the move Volt Switch and vote accordingly based on that. But by the time poll 2 comes around and the slate is smaller, reading the finer details maters a lot more, and the order of ranked votes can change.

+1
That's actually a good reason why poll 1 should NOT be a runoff!

if people here truly truly dislike having 2 polls, as a user I might agree that there isn't much of a reason to have two polls for Typing, Stats, and Abilities

I still think two polls is better! But I guess having a single one for the "easy" polls isn't a bad idea, though, it may kill off some excitement.. xP

In what ways can HTH get messy and exactly how big are the risks of running it in a slate size of 8?

Not exactly big (see the chart above) The golden rule of vote counting is more votes = more likely to win, so the results won't be that noticeably different even if you happen to use the "wrong" counting script. But still, HTH *theoretically* does a bad job at ranking the entries in order. Something with 6 borderline wins will place higher than something else with 5 landslide wins....which isn't completely wrong, but is completely ambiguous. These cases happen more often than the OP's one so if that was a problem, this is also a problem. Anyway if we're gonna use Condorcet for big polls, Ranked Pairs is worth looking into!

At what number of candidates does HTH get unreliable?

4 and above.

3 is ideally the only slate size HTH should do. If the slate is bigger than that, Smith-IRV or Ranked Pairs is more ideal. (but more complex to script)

I still personally think that fixing IRV when it screws up in more important than changing our 2 poll system, but I guess discussion on both should be allowed since both do directly impact CAP polling.

Again, IRV doesn't "screw up" - it elects the most popular entry and does a very good job at it. Unfortunately, the "most popular entry" doesn't mean "the entry who beats all the other entries one on one". So if you want the winner to be the latter, use HTH. If you want the winner to be the former, use IRV. If you want more than one winner, use STV. This has nothing to do with a flaw in the counting script, but a flaw in CAP's ability to decide which counting script to use. The 2 poll system issue is another case where the wrong counting script was used, so it's very related to this discussion...

this stalemated battle between the HTH/Ranked Pairs camp and the STV camp

:P I don't think it's HTH vs STV. More like proposal C vs proposal D! (HTH+HTH vs STV+HTH)
I do support HTH for poll 2 and I'm against STV for poll 2, so go figure! Same for everyone else here I think.

I think Bughouse just confused HTH with ranked pairs.... if HTH was indeed ranked pairs then what he said about it would be correct. The slate size won't be a problem and proposal C would be viable. But D still gets my vote as it also fixes what currently makes no sense in the CAP polls.


Summary:

• IRV elects the most popular entry
• HTH elects the Condorcet winner (but sucks at ranking)
• Ranked Pairs elects the Condorcet winner (good at ranking)
• STV elects multiple winners.

Once you got this you can decide which is best for which poll!

 

[HeaLnDeaL]

Every system will "mess up" in some way or the other, so the question is where to draw the line. I can flip your statement around and say HTH would suck terribly by electing candidate A who has fewer high place votes than B. Switching back to IRV will fix that! At the end of the day, it really depends how you want to define the winner. Me and Tsaeb agree with you that the final poll should elect the Condorcet winner (instead of the most popular one) which is why proposal D supports HTH in poll 2. But for poll 1, I argue that it's more important to accurately eliminate stuff than to accurately declare who came first. Under this context, IRV and HTH will "mess up", STV does not.

IRV elects the most popular entry.

That irv inherently elects the most popular choice is an assertion that bothers me the most out of the above response. For starters, no attempt at defining what makes a vote "the most popular" was ever made and I think that the example in my above post with A and B getting 15 first ranked votes and automatically being eliminated compared to choice C with 16 is a prime example of where things get confusing. IRV doesn't always give the item with the most single place votes the win, as a 15, 16, 17 would eliminate the 15, allowing the chance for the 16 to beat the 17. I just don't see how a system that eliminates the two 15s compared to the one 16 inherently chooses the "most popular" option; if anything, that's an example of the "most fervently supported." Anyway, despite me disagreeing with this minor language usage, I think we do agree with the core idea of the Condorcet winner being the "best" kind of winner.

For now before I have time to sleep on everything fully, I just wanted to say that I really do like Ranked Pairs. They seem to solve the main problem with HTH. And if we're being honest, HTH was just something I came up with over the past year or two viewing CAP polls. Ranked Pairs is a lot older and created by someone with a lot more experience and thus is kind of just a better system. Overall, RP does everything I wanted while fixing the things I didn't know how to fix myself :/

 

[QxC4eva]

Oh my apologies :\ I assumed you already know what IRV does, but okay.

IRV elects the entry with the most direct support. Condorcet methods (e.g. HTH, Ranked Pairs...) elects the one with the most indirect support.

Indirect support is a weaker reason to declare someone a winner for, but has the benefit of reducing the number of votes going to waste. Presidential elections put emphasis on direct support, but for CAP, indirect may have better value as it gives a more widely accepted result, if we still want people to stick around the later stages :P

In your 15s and 16 example, the 16 has the most direct support, and maybe one of the 15s has the most non-direct support. Whoever ends up winning depends on which definition CAP wants to use for their winner.


If you still don't like my explanation, maybe refer to Tsaeb's first post,

IRV is based on the simulation of runoff voting, using the usual standard that you eliminate whoever at each stage currently has the fewest votes. This incorporates a weighting level of preference value by making it more valuable to obtain higher preferences than lower preferences to avoid being eliminated before you can receive preferences. On the other hand, Head to Head (HTH for the purpose of this post) works on the philosophy that broad support at any reasonably high level of preference is worth more than receiving particularly high preferences. HTH is arguably better for selecting a consensus option, whereas IRV is more likely to produce the most broadly acceptable directly supported candidate.

and why he prefers Condorcet winner over the instant runoff winner:

For a project like CAP, it seems as though broad consensus support is probably more valuable to us than looking for the most outright supported option. It matters far less that we pick the option that people absolutely love than that we pick an option that everybody can get on board with and that few people actively dislike, and HTH is much more likely to achieve this.

IRV ignores relative preference, while Condorcet methods ignore absolute preference. Neither one is right or wrong. They just do different things.. :|

 

[HeaLnDeaL]

Yes I completely know what IRV is and what is does, I just didn't think the word "popular" as a good choice for the type of winner it always gets. It was a minor wording issue, which was why I kept that note short.

 

[QxC4eva]

I think you know exactly how IRV counts votes, but it doesn't seem like you're fully aware of the philosophy that goes with it. Hope it's all clear now. Anyway, I realize I forgot that CAP uses PBV not IRV!! :P Which kinda throws off my reasoning a bit cause unlike IRV, PBV is a (pseudo) multi-winner system. You wouldv'e got credit for catching me out on that :3

So more about PBV.... It's an old system rarely used nowadays for a good reason. The way it chooses winners is non democratic. For multi seat elections it's been mostly replaced by STV - which you can think as a more democratic version of it. A problem with PBV is when there's no options that particularly stand out from the rest, the biggest minority (i.e. not the majority) will end up electing most of the winners...shutting out the rest of the community. Which isn't always a bad thing btw, as the winners will probably be more like-minded and work together better so it's great for the TLT poll. But for other polls, it goes against the spirit that CAP polls should be democratic. Democracy is when the elected winners represent the consensus of the whole community, not just the consensus of the biggest minority. And given the fact many poll 1s have too much info to fully digest in one go, makes sense for the qualifying entries to be decided by everyone, not just the biggest like-minded group who may very well end up changing their mind later.

So I guess here's the new summary :P

• IRV elects the entry with the most direct support
• Ranked Pairs elects the entry with the most relative support
• PBV elects multiple entries (undemocratically)
• STV elects multiple entries (democratically)

 

[DougJustDoug]

I have been following this thread from its inception, but I have waffled on when and how to weigh in. I am always interested in ways to improve our project, and polling is a huge aspect of our processes. But when I think about our big problems with polling, I'm not very worried about how slates are formed or how ballots are counted. I think our polling results have much bigger problems related to poll manipulation, uninformed voting, etc. That is not the topic of this PR thread, so I'm not going to get much deeper into that. But, I'm just saying when I consider issues in CAP with the "best option" not always winning, I don't tend to look at our slating and poll styles as a major factor.

BTW, I put "best option" in quotes, because trying to define what SHOULD win a CAP poll is a tar-baby I don't want to latch onto now or ever, really.

With all that said, if we can improve our polling without a lot of downside, then I'm all for it. Here are a few things that came to mind as I have been reading this thread:

Posters in this thread really need to be careful with their use of acronyms.
I see a whole lot of mention of "IRV" and "MBV" in this thread, despite the fact that those two polling styles are very rarely (if ever, in the case of IRV) used in the CAP project. Our most-used polling style by a huge margin is Preferential Block Voting -- acronym PBV. I suspect most posts in this thread that refer to IRV or MBV are really referring to PBV. Maybe I'm wrong, in which case, I'm confused as hell.

MBV, used properly, refers to Multiple Bold Vote, which is only used for the Art slating (aka Art Poll 1) and Name slating (aka Name Poll 1), and aren't even "winner polls", because we CAN'T get a winner from those polls no matter how many votes any option receives. The purpose of those polls is to cut down a mammoth number of options to a slate of options considered to be good by the community.

A sidenote about MBV -- I personally think we should be clearer in our voting instructions of MBV polls, that people should identify options that they think are "good", and not just the options that they want to "win". It doesn't really impact the ultimate winner, but it does impact how many submitters get positive feedback that they made a good submission -- which I think matters in those two contests, the art contest in particular. But almost nobody reads the voting instructions and those two flavor polls are cattle-calls for drive-by voting anyway -- so I guess I'm tilting at windmills on this one...

IRV, used properly, refers to Instant Runoff Voting, which is basically NEVER used in CAP any longer. Mods have been asked to use PBV in every case we used to use IRV. It doesn't affect the single winner, which is the same whether you count the ballots with IRV or PBV. But PBV has the advantage of giving better information about the placement of non-winners. Which, again, I think matters for feedback to the contestents.

So, if posters really are using MBV, IRV, and PBV interchangeably or mistakenly -- please stop. If I'm wrong, and people really are contesting our use of MBV or IRV for choosing winners -- then I'm not sure how to respond, because we don't use MBV for winner determination, and we don't use IRV at all really.


The cases that HealNDeal mention in this thread are not hypothetical and really have happened in CAP, and it is worth preventing them in the future, if we can.
However, as has been mentioned many times in this thread, there are flaws in every voting system being considered. So even if we fix the problems HealNDeal mentioned, I suspect we'll be creating some new future problems to take their place. On top of all that, CAP polling has all sorts of variability and chaotic factors influencing results that will never be ironed out fully. Splitting hairs on how to most fairly break a tie between the 5th and 6th place option in a close poll that was probably rife with cheating and idiot drive-by voting in the first place -- meh, it's hard for me to get too excited about that. But if there's a somewhat objectively better method, I won't oppose it.


I am actually interested in using STV for narrowing slates BECAUSE it is convoluted and hard to understand.
One issue we have with CAP polls, is people trying to game their ballot rankings to affect the results. With publicly posted ballots, this will always be a problem to a certain extent. PBV polls have curbed that to a certain extent, because most people don't understand how PBV polls are counted, and even if they do, it's very hard to calc by hand. STV appears to be even more obscure and complicated, so perhaps more people won't bother to try and game the results, and they'll focus on just casting their own ballot according to their preferences. I'm NOT saying we are going to hide anything or prevent anyone from keeping their own running tally. I'm just saying that a complex counting system can be a good thing, in a way, as long as STV ballots are simple and easy to compose (and they are, afaik).

 

[HeaLnDeaL]

I see a whole lot of mention of "IRV" and "MBV" in this thread, despite the fact that those two polling styles are very rarely (if ever, in the case of IRV) used in the CAP project. Our most-used polling style by a huge margin is Preferential Block Voting -- acronym PBV. I suspect most posts in this thread that refer to IRV or MBV are really referring to PBV. Maybe I'm wrong, in which case, I'm confused as hell.

This will be a Preferential Block Vote (PBV) (a form of Instant Runoff Voting which re-runs the counting, each time removing the previously top-ranked candidate in order to determine the 2nd most preferred, 3rd most preferred, etc.), the details of which are outlined here and here. This is a ranked vote: order does matter! You can upvote your favourites and downvote your least favourites. You may choose to rank as many or as few options as you like, but we encourage you to rank as many options as possible to ensure your preferences are taken into account.

The way CAP has explained PBV, as evidenced by our own poll OPs above, is that PBV is a type of IRV. By CAP's own definition of it, PBV is basically just IRV that is re-run to get second, third, etc places. However, since the entire point of this thread (at least at the start) was meant to deal with the winner and NOT with ranking differences between second, third, etc, IRV and PBV are rather interchangeable in the discussion. PBV and IRV both select the same exact final winner (PBV just also gives more than the final winner) and the way they both do so is what has been deemed a problem. So really, for the problem that I started to address in the OP, PBV and IRV are rather interchangeable because they both eliminate the ballot item with the least number of first ranked votes first and this is exactly what the problem is. If the item with the least first ranked votes only narrowly has less than the other options but has a drastic number of second ranked votes, then it could beat the other candidates one on one (head to head) and it thus could be the Condorcet winner. So, really, the problem with PBV is the problem with IRV. I see no reason why those terms should not continue to be used interchangeably under the context of this particular conversation since it is their shared method of elimination that is the problem.

The cases that HealNDeal mention in this thread are not hypothetical and really have happened in CAP, and it is worth preventing them in the future, if we can.
However, as has been mentioned many times in this thread, there are flaws in every voting system being considered. So even if we fix the problems HealNDeal mentioned, I suspect we'll be creating some new future problems to take their place. On top of all that, CAP polling has all sorts of variability and chaotic factors influencing results that will never be ironed out fully. Splitting hairs on how to most fairly break a tie between the 5th and 6th place option in a close poll that was probably rife with cheating and idiot drive-by voting in the first place -- meh, it's hard for me to get too excited about that. But if there's a somewhat objectively better method, I won't oppose it.

The simple fact however is that the real and true case examples that are prompting this thread are instances where there were NOT any other chaotic variables identified, such as cheating. There's really no way to measure "idiot drive-by voting" and every single vote counting method would deal with this equally, so it's completely moot to bring that up unless there's some sort of proposal to require certain qualifications for voters, which is a whole different can of worms and one that I think would be far harder to change. Have we known of campaigning and cheating to distort results? Yes. It has it's own PRC thread. This is a different matter entirely with completely different polls that have prompted the discussion.

Regarding STV vs PBV stuff (now I'm talking about ranks beyond first place, so in THIS instance it is important to call it PBV and not IRV), where the ranks below first place actually matter, I think I'm now convinced of at least one poll where we absolutely should use STV, and that is the TLT poll. The TLT poll is the only poll we have the has multiple winners. STV chooses a proportional set of winners whereas PBV chooses non-proportional winners meaning that similar ballot items ARE more likely to be chosen from a group of similar slate options. Now, with every poll in CAP except the TLT poll, the way that ranks under first are chosen doesn't directly impact the real winner, or the real result. The TLT poll is obviously different, and I think it's unfair for a single voting group to decide all of the winners in the TLT poll. STV lets different "parties" in CAP have the chance to be properly represented in a TLT poll. In the earlier post by QxC with the list of different outcomes for the different counting methods, the TLT poll is one with fairly significant result changes between the counting methods. Particularly, there was a significant minority group that very strongly favored Snobalt, but because that particular poll bent to the wishes of the large, majority group of CAP-metagame-player voters, Snobalt was excluded and we ended up with a TLT made exclusively metagame players (Deck might not be the most involved metagame player, but he still is one). I think now that our voter base has changed significantly in favor of metagame players, it would be a disservice to the older veterans to always be shut out of CAP TLT participation because of the way PBV counts. STV is a more inclusive voting method for the TLT poll and allows non-majority CAPpers to have an opportunity to lead. I do not want CAP to be controlled by a single voting group, and having a PBV TLT poll allows this to be a real possibility. I also believe that the TLT poll is the one to have the most clearly defined voting groups, because in other polls we are voting on competitive slates rather than on people themselves.

For non-TLT polls, I don't particularly think we need to use STV, and I view a PBV --> HTH (or Ranked Pairs, but HTH and Ranked Pairs pretty much yield the same results in a 3 slate poll) as a method that lets us figure out what traits we all want in the winner the most and then decide from similar options on which is better overall. However, if we're interested in representing the vote shares between different vote groups more accurately, then I do think that STV has some merit... Really, these are just two different philosophies that ultimately produce the same final winner... do we want to reward non-winners that are similar to the winner or different from the winner? It's a weird judgement call and I don't really think there's been enough evidence to show me which side is better. I personally lean away from STV from non-TLT polls because I don't see any "net" benefit. For the TLT polls, actual winners DO very and thus I do think there definitely is a net benefit.

 

[jas61292]

While I may not be the biggest expert in polling methods, I have spent plenty of time looking into it over the years, and I was very involved in the last couple polling changes. So with that said, I want to start by reiterating something Doug said in his post: there are flaws in every voting system. I know its easy to see advantages of something, new or old, and latch onto them, but the fact is, if there were an ideal system, it would be known and everyone would use it. I think it was said best by capefeather last time this topic was brought up:

Every voting system is vulnerable to some kind of manipulation, and/or fails to elect a candidate who fits certain criteria of who "ought" to be the winner. So pointing out that a voting system we're using is flawed doesn't really do anything. If we used that reasoning to change the polling system we have, we'd be changing it every time this topic is brought up.

With that in mind, honestly, I do not really care that much what specific method we use for most polls. Any system we use will have issues, and I'm in agreement with Doug that, in general, whatever issues they are, their impact will likely pale in significance compared to the impact of poll manipulation, uninformed voting and the like. However, there are a few things I would like to see out of our polling system. Most importantly, if we can avoid it, I don't want to use a polling method that gives greater benefits to opinions that are never going to have majority support, but are the single favorite of a minority, as this tends to let controversial minority opinions last longer than is deserved, and, in my opinion, this directly leads to more cases of attempted manipulation.

What exactly do I mean by this? Well, this was exactly the case back before we switched our polling over to PBV. At the time, we used an IRV vote, and would move on the top 3. As you know, IRV is not designed to pick multiple winners. However, since our first poll did not pick a winner, I'm guessing the logic was that it was good enough to just narrow things down. However, knowing how IRV works, this meant that we did not move on the three most popular options, but instead (if we accept the premise that IRV is picking the most popular option) it would move on the most popular option, along with two options whose popularity never got properly compared to anything. The second place option was pretty much just the favorite of those who didn't like the first place option. Not actually the second most popular. This means that an option that was loved by a significant minority group of voters (say 35% for example), but hated by everyone else, would frequently move on, despite the fact that far more than 3 other options would be able to beat it head to head, and that, baring strange shifts in the voter base (such a manipulation), shouldn't have any chance to win.

This was something I brought up when we decided to change from IRV to PBV, and while it was never really the focus of conversation, I believe that if we want to actually have the most accurate results (with regard to community opinion), we should try and use a method that moves on the communities top favorites, not those most likely to result in the closest final poll. To be completely honest, I think PBV already does a pretty good job of this, and I'm not completely convinced we need to change anything. But, as I said, I honestly don't care too much in general.

HOWEVER, there is one specific thing brought up in this thread that I am very much against. That would be from HeaLnDeaL's most recent post, regarding the selection of the TLT. Specifically:

The TLT poll is obviously different, and I think it's unfair for a single voting group to decide all of the winners in the TLT poll. STV lets different "parties" in CAP have the chance to be properly represented in a TLT poll. In the earlier post by QxC with the list of different outcomes for the different counting methods, the TLT poll is one with fairly significant result changes between the counting methods. Particularly, there was a significant minority group that very strongly favored Snobalt, but because that particular poll bent to the wishes of the large, majority group of CAP-metagame-player voters, Snobalt was excluded and we ended up with a TLT made exclusively metagame players (Deck might not be the most involved metagame player, but he still is one). I think now that our voter base has changed significantly in favor of metagame players, it would be a disservice to the older veterans to always be shut out of CAP TLT participation because of the way PBV counts. STV is a more inclusive voting method for the TLT poll and allows non-majority CAPpers to have an opportunity to lead. I do not want CAP to be controlled by a single voting group, and having a PBV TLT poll allows this to be a real possibility. I also believe that the TLT poll is the one to have the most clearly defined voting groups, because in other polls we are voting on competitive slates rather than on people themselves.

The very first sentence here I fundamentally disagree with. This is not politics. TLT members are not representatives. They are leaders. And, in fact, are 4 separate leaders for 4 separate positions. We absolutely should be looking to find the 4 people that the highest number of people in the community believe are qualified. Frankly, doing them all in one poll is just a convenience thing. Ultimately, our goal should be to have the community's most preferred typing leader, the community's most preferred stats leader, the community's most preferred ability leader, and the community's most preferred movepool leader. If only a minority group of people (no matter how significant) think someone should be on the TLT over the other options, well, then... they should not be on the TLT. We should not be looking to find a way to get that group representation, because TLT members are not representatives. Now, am I saying that the way we do it now is perfect? Not necessarily. But if it is not perfect, that is only because IRV itself is not perfect (which of course it is not, as no polling method is). The fact is though, that if we accept the idea that IRV is an acceptable method to use, I believe PBV is a significantly better method to use than STV for the TLT poll, because it essentially represents running 4 separate IRV polls to find the 4 most qualified people.

Now, if the issue is that qualified people are not making it onto the TLT because people would rather vote for the people they know from their subsection of the community (clique) rather than the overall most qualified individuals, then that is a problem. However, in such a case we should be looking at how to bridge the gaps between sections of our community, such that qualified people get the recognition they deserve. We should not be looking to change our polling method.

 

[HeaLnDeaL]

Now, if the issue is that qualified people are not making it onto the TLT because people would rather vote for the people they know from their subsection of the community (clique) rather than the overall most qualified individuals, then that is a problem.

Quite frankly I think this is the potential problem, and STV does alleviate it (and if you're trying to get a TLT purely based on qualifications, then I don't think a community vote is the best way to achieve that result at all, but the mods already cutting unqualified candidates from the slate already alleviates the majority of "qualification" problems). It's not like STV makes a person with full support from a 20% minority group move on. But what happens if a person gets 45% support but is doomed to fail because they aren't part of the current clique that is in power? That doesn't sit right with me, and a similar situation with Snobalt likely happened last time. I've been part of the metagame playerbase clique since my start here in CAP and I've witnessed at the beginning how much it sucked for none of us to have any chance to do anything. Now that the clique I belong to is in power, I don't want us abusing people of different CAP cliques because I know what it feels like not to be in the majority.

In regards to "representation"/"representative" vs "leader" I don't think it's an issue that is so black and white. I would guess that a significant number of voters in TLT polls to at least some level consider someone's past record to help decide what kind of leading style they would want to help "represent" them. It's certainly not a blanket catch-all representation, but I also think that the concept of representation is completely devoid of TLT polls. If there's a group of people who believe that leadership should be done a certain way, they are in some way voting for leaders that represent that leadership style. It's certainly not representative in the sense that people are choosing people to vote in their stead, but people are still choosing leaders that represent their leadership ideals... or their cliques.

I will say that I think the majority of TLT winners usually attract support from multiple factions on CAP. Deck Knight, for example, is well respected across metagame players and process veterans alike. This last CAP, however, seemed to offer one of the most polarizing results that favored metagame players to the exclusive of all others who didn't fit inside that clique. I don't want to name out names, but it's pretty obvious some people on the last TLT only won because of their metagame resume (even despite a lack of a process resume)... and we were building a metagame Pokemon, so the fit seemed to fit for a lot of voters. But if this is a sign for a future trend, then it definitely worries me... However, as a trend doesn't quite exist yet, I suppose that there's no reason to act quite so hasty... So, I suppose I'll temporarily drop my support for STV for TLT polls, but if it does become a clique war trend you can definitely bet I'll bring it up again. I want all of CAP to get along, and if the formerly bullied metagame camp begins to turn into a tyrant majority then I definitely won't be happy :c

 

[QxC4eva]

About the acronyms, I think the only real messup is the OP saying "IRV/MBV" instead of "IRV/PBV". Tsaeb was being consistent with the OP so when he says MBV he really meant PBV. In my big post, I forgot that CAP uses PBV so my reasoning was a bit off (correction is in my previous post). As for HTH, I'm pretty sure that me, Heal and Tsaeb all refer to the A.H. Copeland method - the head to head formula described in the OP. Bughouse thought it was Ranked Pairs, a different method that's better but more complex than HTH. For STV, we refer to the multi-member STV. (not single-member)

As Doug and Heal said already, IRV and PBV give the same first place winner. So references to IRV refer to the "first place winner component of PBV" - which is more specific than just saying "PBV". That's why the term IRV is still used even though CAP no longer uses it in pure form. Now I realize that can be confusing so I'll PBV from now on. c:

A sidenote about MBV -- I personally think we should be clearer in our voting instructions of MBV polls, that people should identify options that they think are "good", and not just the options that they want to "win".

Maybe call it by the proper name "approval voting"? The entries you put are what you "approve"....which I guess is more specific than the ballot instructions saying vote for what you "like" (idk if it'll make any difference though) I'm sure if we called it by the proper name there won't be the acronym confusion in this thread! PBV ballots happen to fit the "multiple bold vote" description too so what did you guys expect? >.<

However, as has been mentioned many times in this thread, there are flaws in every voting system being considered. So even if we fix the problems HealNDeal mentioned, I suspect we'll be creating some new future problems to take their place.

(and I guess also capefeather's quote in jas' post)

This is exactly the thing I was worried Heal may not have fully understood. Nothing is perfect - which makes our choice of voting system a debate on philosophy, not the actual numbers involved. The numbers in the OP only prove that both systems can sometimes give different results (well duh, cuz they're different systems!!) but there's still no mention why in a close poll, the one with the most pairwise victories has to be the winner, and not the last one remaining if we held a runoff. Me and Tsaeb mentioned a possible reason why the pairwise winner may be better for CAP, but there's been no confirmation if we're in agreement or not.
And yup, replacing PBV with Ranked Pairs will create new problems! If you're curious, one of the drawbacks of Condorcet methods is they violate the "Later No Harm" criteria, which means you may cause your first preference to lose by filling out more preferences after it. So if we're to be honest, the ballot instructions should warn people to NOT fill in any preferences other than their first if they only want that to win. While this may help voters fully express their intentions, less preferences means the final poll result will be less accurate (and we might as well use PBV if people are just gonna "bullet vote"....)

With that said, I want to point out that every voting system has an intended role -- this is different from each one having "pros and cons". The fact that IRV was not designed to pick multiple winners is not a flaw, it's its role. PBV was designed to (kindof) pick multiple winners, so CAP's decision of moving to PBV is perfectly reasonable - something you can't oppose with the "pros and cons" argument. So what exactly are pros and cons? It's when you look at the voting criteria. For example, PBV fails the Favorite Betrayal criteria - that's a flaw because you can sometimes betray your favorite, to keep it simple :P While I can't speak for the OP's issue, Tsaeb's issue is definitely about finding a system more closely fit to do what we want to achieve - which again cannot be refuted by the pros and cons argument.

I view a PBV --> HTH as a method that lets us figure out what traits we all want in the winner the most and then decide from similar options on which is better overall.

If the PBV vs STV argument were that simple then yeah, it really doesn't matter which one we use. But there's a bunch of other factors too, like the different demographics and how much info each poll has, as well as the manipulation issue brought up recently. It's hard to claim that PBV will pick out traits and STV will pick out details. But we do know that people may change their mind later etc, so whatever's been decided in poll 1 may be somewhat obsolete by the time we reach poll 2. Proportional rep will give us more insurance and a safer way to ensure poll 1's results stay relevant in poll 2, even when the voter base / criterias have changed. It's also more democratic. I agree the end result is usually the same anyway, but democracy is about the process not the end result. If CAP leadership chose jas for TL by default, that's undemocratic. But if the community voted jas for TL, that's democratic. The fact that Jas would be TL anyway doesn't make the former method comparable to the later.

About manipulation- it's less likely for a controversial minority to skew the results if we go for the whole community representation. With PBV, a group only needs to exceed a certain threshold to take control of the entire poll. This threshold can be very low if there aren't any frontrunners in the poll. With STV, a group needs to be a supermajority (make up >50% of the voter pool) to take entire control, which is a lot harder to do.

 

[HeaLnDeaL]

I have since the beginning fully understood that no polling method is perfect. Yes, every polling system has benefits and negatives. But I'm personally irked people just say that as if it's a valid excuse not to analyze our options. Of course nothing's perfect. That doesn't mean we need to settle for something with quite awful flaws when better alternatives exist.

I believe promoting a Condorcet winner (when possible) in the final poll is a superior guiding principle than what we currently have. It is unfair to have the majority of the community prefer one candidate compared to both others in separate head to head matches but still have that candidate lose. IRV/PBV unfairly value the number of first ranked votes despite their being no correspondence to CAP voters saying that "I value my first ranked choice considerably more than my second." A Condorcet winner keeps the "distance" between ranks more equal within one's ballot. If people wanted to value their first ranked vote considerably more than their second in the final poll, they have the option to show this by ranking ONLY their first ranked; thus we would assume someone ranking first and second means that the distance is not the significant, but IRV/PBV doesn't count this way in certain cases. IRV/PBV has the illusion of making vote ranks more equal in their distance but then doesn't count them equally. It fools voters in cases where the vote tally is exceedingly close, already explained in depth in the OP and other posts. Now, in first polls with more than 3 options, this obviously opens up more problems. HTH or other Condorcet methods in a 3 candidate poll does not fool the voters. The voters are free to rank as many as they want in 3 way HTH without fear of their vote getting miscounted.

I'm also assuming that the majority of us in the thread prefer HTH or other Condorcet methods in the final poll (since QxC, Bug, and myself all agree on this particular point), and I'm assuming it has in some part to do with because we see the problems identified in the OP as real concerns and we want to fix them. Saying "polling options all have flaws" does not fix it. If we realize the limitations to our fixing method and address it in a specific way rather than a general way then we can solve problems rather than caving in. We know HTH works great with 3 candidates and not so great with more. The solution? If we're going to use it, use it in a way that works with 3 candidates, or tweak it to Ranked Pairs to work with more than 3.

No, we cannot have a perfect method. But we can have a better one.

 

[QxC4eva]

I'm not sure if that's a proper reason to use Condorcet method @_@ Yes I do prefer it over PBV but for a totally different reason to yours. I think yours is more to do with uninformed voting than a flaw in the counting system. Also....do CAP voters really think that way? I had no idea there's a equal gap between their preferences! In voting philosophy, it's normal to bias the first choice more than the rest because first is the "favorite". If I put 8 preferences down, what I have for my 1st and 2nd rank is more worthy of attention than my 5th and 6th. In government elections, first place votes = confidence. Having lots of first preferences gives you an 'official order' to govern, no matter how many mid or last preferences you get. If all you get is second place votes, it means people really like you but aren't confident with you as their leader. That's kinda the assumption being made, cuz preferential ballots (aka CAP ballots) don't have enough info to tell us exactly how much people like their first over their second. The only way to know is upgrading our ballots to range ballots which will complicate things for our voters. So because we're stuck with preferential ballots, our counting script needs to make assumptions. There's many ways to do it that's why there's so many counting scripts out there!

If you want a script for linear preferences, Borda Count is the one to use. Lets say there's 4 entries here's how it works - first choice gets 3 points, second gets 2, third gets 1, and last gets 0. Total is 6 points. If you put only 1 choice, it'll get 3 points (like usual) and the rest will get 1 each so the total is still 6. At the end, rank the entries by their total score.

Unlike most other voting systems, in the Borda count it is possible for a candidate who is the first preference of an absolute majority of voters to fail to be elected; this is because the Borda count affords greater importance to a voter's lower preferences than most other systems, including other preferential methods such as instant-runoff voting and Condorcet's method. The Borda count tends to favor candidates supported by a broad consensus among voters, rather than the candidate who is necessarily the favorite of a majority; for this reason, some of its supporters see the Borda count as a method that promotes consensus and avoids the 'tyranny of the majority'. Advocates argue, for example, that where the majority candidate is strongly opposed by a large minority of the electorate, the Borda winner may have higher overall utility than the majority winner.

There, I think this describes what you're looking for better than anything else! I don't think Condorcet will solve your problem since the actual gaps between the ranks also vary, it still 'unfairly' puts some bias on the ballot's first choice.

Hide

Okay time out!!

Borda count actually sucks. I wrote that just to show you're misunderstanding :P Maybe lets assume we're just undecided between PBV and HTH?

Proposal E - if PBV fails to elect the Condorcet winner, start a poll 3 with the PBV winner vs Condorcet winner. Single bold vote.

Since we're incapable of discussing which winner is better, poll 3 will let the community decide that instead. >_> Having an extra poll is more trouble but this rarely happens anyway so it's not like it'll change much of anything. Has anyone found a case of it in CAP before? Nope. But when it does happen, the extra poll might be worth making things 'fair' again.

 

[HeaLnDeaL]

I'm not sure if that's a proper reason to use Condorcet method @_@ Yes I do prefer it over PBV but for a totally different reason to yours. I think yours is more to do with uninformed voting than a flaw in the counting system. Also....do CAP voters really think that way? I had no idea there's a equal gap between their preferences! In voting philosophy, it's normal to bias the first choice more than the rest because first is the "favorite".

First you question the uniformity that I asserted but then you assert that the gap between first and second is the largest gap but you offer no evidence to support this at all. What I used to evidence my position was that in a 3 option head to head people can and do vote for only their favorite. In such cases we know definitely they value their favorite far more than the other two options. Thus the assumption (yes it's an assumption but it's based on something at least) is that people who rank both first and second actually somewhat like their second option. Why is this an assumption? Because if they hated their second option then they could just vote for their favorite and not rank any further. Compared to IRV, HTH takes people who ranked second options more seriously when polls get close (as evidenced by the many examples of IRV/PBV doing weird things that aren't correlated to voter intentions under close polling situations). I for one thing that having voter intentions valued is something WE should value when counting votes. HTH demonstrates voter intentions better than IRV in close poll calls.

That said, your proposal E is also something that I think works wonderfully and I fully support it because it gets rid of needing to assume intentions. I think HTH assumes intentions far better than IRV as I argued above, but yeah, it is still an assumption (just a better assumption). Your proposal E gets rid of the assumption and therefore I fully support it. The downside is obviously that it extends polling time, but it is likely to be a rare event and it's definitely worth it when polls get that close. I've gone and slightly changed the wording of your proposal to make sure it's clear that we're talking about Poll 2 scenarios rather than Poll 1.

Proposal E - If PBV fails to elect the Condorcet winner [in a poll of 3 candidates], then a new final poll with the PBV winner vs the Condorcet winner will occur. This new poll will then operate under Single Bold Vote.

EDIT: actually I'm not sure anymore as I think Bughouse's redundancy point has some merit. If the condorcet winner already beat the other two head to head then why have a third poll? And really, the condorcet winner always beating the PBV winner head to head is really one of the fundamental things that started this thread.

The fact the the condorcet winner statistically always beats the PBV winner in a single bold vote just adds credit to the argument that the condorcet method has the best results anyway.