New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the voting process #60

Open
jeffjaffe opened this Issue Jul 27, 2017 · 83 comments

Comments

Projects
None yet
@jeffjaffe

jeffjaffe commented Jul 27, 2017

The last line in Section 7.3 (about votes) says

'In the case of Advisory Board and TAG elections, "one vote" means "one vote per available seat".'

I think this line is a holdover from previous voting procedures. We now use STV. A literal interpretation of this line is that (e.g.) in an AB election with 4 open seats, each AC rep would have 4 votes: i.e. 4 opportunities to use STV. This is absurd.

I recommend dropping this line.

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Jul 27, 2017

I very strongly disagree. I would argue instead that the current implementation of STV is incorrect because it violates this point in the Process Document. One might argue, I suppose, that the "single" in STV means that the AC's intent in approving STV voting implied that we were moving from "one vote per available seat to "one vote", but to my shame I didn't realize this until recently. But STV was sold to us as an alternative tabulation system using ranked rather than binary preferences, not an alternative voting system where we only got one vote no matter how many seats were open.

I don't know enough about STV mechanics to suggest an alternative ranked preference tabulation system that allows one vote per available seat, but we should investigate.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Jul 27, 2017

I agree with both Jeff and Mike. We undoubtedly have an inconsistency. Mike, I cannot think of any STV system in which one gets one vote per seat; equal-rank voting sort of comes close, but isn't really this, and anyway, we can't implement it.

We either delete this sentence, or we re-think STV. I fear the latter is too soon and too large.

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Jul 27, 2017

My inclination is to take this to the AC. Clearly there is a logical inconsistency in the Process. I thought we were approving a one vote per seat ranked preference system, but apparently there is no such thing. It would be informative to know what other people on the AC expected... Other than an end to the debate few understood or cared about!

I think the most responsible thing to do is tell the AC "we screwed up... help us figure out how to rectify our error." They'll hate us for making them think about voting systems yet again, I suppose, but the alternative of running elections that are in violation of the process is worse.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Jul 27, 2017

I think it's way too early to go back to the well...

@jeffjaffe

This comment has been minimized.

jeffjaffe commented Jul 27, 2017

It is clear that the intent of the pieces of the process document (the portion on STV and the last line of Section 7.3) are talking about different voting systems. There are four ways I can think of to deal with the situation.

  1. We simply delete the line in Section 7.3. That is what I proposed above, but Mike didn't like that idea.

  2. We can harmonize STV with the line in Section 7.3, by giving everyone 4 votes and then everyone will deliver 4 identical ballots so we just create 4x the number of votes with the same result. That is what I referred to as absurd, above - but we could do it.

  3. We can simply ignore the line in Section 7.3, which I believe was the intent of Process 2017. While we could do that, it is not the neatest thing to do.

  4. We can propose a broader fix to election issues. That seems to be what Mike is proposing. I'm not opposed to that idea, but I don't have any ideas at the moment - so I'll leave it to Mike or others to propose something.

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Jul 27, 2017

I guess I have a taste for the absurd: I thought we were doing something like #2 when we agreed to STV voting in W3C elections. I'd prefer #4 but don't have a concrete proposal. We have to live with #3 until the process can be updated.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Jul 27, 2017

I agree #2 is absurd; we just multiply all the numbers by 4. Equally absurd would be asking people for 4 rankings, potentially different, for the 4 seats. "For the first seat I prefer Mike over Chris, for the second, Chris over Mike..." huh?. In the next process revision, we either need to do #4, or (as seems likely in the time available) #1. Leaving #3 is poor form, but I suppose...

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Jul 28, 2017

I'm not sure #2 is so absurd if it is described as:

  • All AC members get one vote per seat, but are asked to do only one ranking.
  • The first open seat is filled according to the current STV algorithm
  • The winner is removed from the candidate pool
  • The next open seat is filled by according to the STV algorithm with the remaining set of candidates
  • Repeat until the n seats are filled.

As best I can recollect, that's how I THOUGHT the new voting system worked when we voted to add STV to the Process. I admit to not thinking through exactly how I thought STV would work in a system where each voter gets multiple votes, but I sortof assumed that since we weren't talking about removing the "one vote per available seat" rule, I thought someone smarter than me had figured out how the two constraints would work in harmony. I suspect I'm not the only AC rep who was under that delusion.

That's consistent with the current process document that specifies both an STV system and gives AC members one vote per open seat.

That mitigates the concerns about one's 2nd thru n rankings being more or less meaningless. Once your top-ranked candidate wins a seat, your 2nd-ranked candidate "gets your vote".

It may not meet the original goal of tilting the system toward diversity, I'm not sure.

It adds some complexity for the team I suppose

I think it would be more robust than the current STV system in the face of extremist candidates
strongly supported by slightly over 1/n of the electorate but low ranked by (n-1)/n of the electorate. We can argue whether that's a bug or a feature. I believe it's a feature in a consensus-based decision culture even if it's plausibly a bug in a voting-based decision culture.

Am I missing some absurdity here?

@jeffjaffe

This comment has been minimized.

jeffjaffe commented Jul 28, 2017

Mike, I'm not sure I understand your proposal.

As David said above, if we give each AC rep 4 opportunities to do an STV vote and then add up all of the results - presumably most AC reps fill out their 4 ballots identically. This has the effect that everyone gets 4x the number of votes, but does not change any of the outcomes compared to single vote STV. The fact that it does not change outcomes is the reason that David and I called it absurd.

Is that indeed what you are proposing we should do, or did you have something else in mind?

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Jul 28, 2017

OK, I think I get what Mike is proposing. Today, we tabulate the votes; imagine that the top vote-getter gets just the quota. The ballots that placed that candidate first are never considered again.

In contrast, Mike is suggesting that after the first seat is filled, we re-run the tabulation using all the ballots, but marking the elected candidate as having withdrawn, so all votes cascade past that candidate.

It's an interesting thought experiment, but I want someone who understands voting and tabulation to weigh in.

@chaals

This comment has been minimized.

Contributor

chaals commented Jul 28, 2017

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Aug 18, 2017

@jeffjaffe here's why I don't agree with your summary of my proposal on 7/27/2017

if we give each AC rep 4 opportunities to do an STV vote and then add up all of the results - presumably most AC reps fill out their 4 ballots identically. This has the effect that everyone gets 4x the number of votes, but does not change any of the outcomes compared to single vote STV.

Consider the example I've used before:

  • Granger and Weasley are mainstream candidates with broad but somewhat lukewarm support; few strongly prefer one over the other.
  • Malfoy is an extreme candidate, passionately supported by a substantial minority but fervently opposed by a majority.

In the old system, Granger and Weasley both get 65% of the votes, and Malfoy gets 35%, thus Granger and Weasley are elected.
In the current system, Granger gets ranked first by 33% and second by 32%; Weasley gets ranked first by 32% and second by 33%; and Malfoy gets ranked first by 35%. Thus Malfoy and Granger are elected – Malfoy in the first round since he got over the threshold, Granger in the second round after Weasley was eliminated and his voters’ second place votes went to her.

In my proposal, which as best I recall is how I thought this would work when I voted for the STV system, there are n STV elections for the n open seats. The threshold is 50% since each is a single-winner election.

In the example first round of the election for the first seat, nobody meets the threshold. Weasley is eliminated, and his first place votes are given to his voters' second choice, Granger. Thus Granger is elected in the second round.

In the STV election for the second seat, since Granger has already been elected, first place votes for her are allocated to her voters' second ranked candidate, Weasley in this contrived example. Weasley is over the threshold so gets elected in the first round.

So this isn't just the current STV system multiplied by n; having n elections for the n open seats is different because the threshold is different with n elections for a single seat as opposed to 1 election for multiple seats. It is consistent with the current process document because it gives AC reps 1 vote per open seat and runs an STV election for each seat.

It this a more desirable election system than the one we have used in practice (in violation of the literal wording of the process doc)? I'm pretty sure there will be much disagreement. I biased my contrived example by giving the 35% candidate the name of an evil character, what if it were "Lovegood" [1], i.e. someone with an outsiders perspective but with the best interests of all at heart? So, the real question is whether we -- as an organization that operates by consensus rather than voting -- should we fear the consequences of a non-mainstream "bad" candidate more or less than we hope for the benefits of a non-mainstream "good" candidate? Living in a kakistocracy created by the quirks in my country's election system :-) I'm feeling more paranoid than hopeful about voting systems at the moment myself.

I do submit that if there is no agreement to change the process document to eliminate the sentence about 1 vote per open seat, the Team is obligated to implement the process as it stands, and my proposal provides one mechanism to do so.

[1] http://harrypotter.wikia.com/wiki/Luna_Lovegood

@jeffjaffe

This comment has been minimized.

jeffjaffe commented Aug 20, 2017

@michaelchampion Thanks for providing a detailed example. Now I at least understand what you are proposing.

Indeed, what you are proposing is an approach that one could use for elections and indeed it would give a different result that how we have implemented STV. I see your point how this can be viewed as both STV (since it has n instances of STV voting with one winner) and also has n votes per 7.3 in the Process Document.

I don't personally agree with your conclusion, however, that this is the correct interpretation of the process document.

  1. Section 2.5.2 talks about using an STV system (singular). It does not talk about multiple STV systems.
  2. STV as commonly defined is a single vote system for multiple seats; not multiple instances of votes for each for a single seat [1].
  3. (Most importantly): when we ran several trial elections and spent numerous hours discussing it - the method that we used in the trials was the method that we used in the actual election last spring. Not once did someone suggest the novel interpretation you have provided. Hence I believe the membership voted on that one when they made the change in Process 2017.

[1] https://en.wikipedia.org/wiki/Single_transferable_vote

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Aug 20, 2017

@jeffjaffe writes

(Most importantly): when we ran several trial elections and spent numerous hours discussing it - the method that we used in the trials was the method that we used in the actual election last spring. Not once did someone suggest the novel interpretation you have provided. Hence I believe the membership voted on that one when they made the change in Process 2017.

I doubt very many of the AC members voting understood that they would henceforth have only one vote no matter how many seats are open in AC and AB elections, and that the contradictory words to in the process were an obvious bug. I certainly didn't. And there was no example in the test runs that illustrated the anomalies found by analyzing the first really competitive election.

My point is that having multiple votes is not logically incompatible with ranked preference voting, even if this is a "novel interpretation" or one believes that the term STV suggests a single vote. (I assumed it meant a single vote for each seat that could be transferred across candidates, not a single vote for all seats).

It seems like the time has come to take this question to the AC: Given the incompatibility between the formal process and the actual procedure, do they want to make the process align with the procedure by eliminating the "one vote per open seat" language, or do they want the team to implement a ranked preference procedure that gives them one vote per open seat?

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Aug 21, 2017

@chaals

This comment has been minimized.

Contributor

chaals commented Aug 23, 2017

+1 to Jeff's original proposal. -lots to Mike's suggestion, which would combine the complexity of STV ("You have to rank the candidates in your order of preference") with the unrepresentative outcomes of the old system ("the largest bloc can win everything, regardless of whether their support is 90%, or 19% with 75% preferring "anyone else or nobody at all").

I'm also not keen to replace the live elections with an apparently untried system. I can't find evidence of anyone using this approach anywhere, and it makes Schulze_STV seem tried and true by comparison.

It also appears that the rationale for suggesting it is false. The election results are not an anomaly caused by strangeness in Meek vote tabulation, they are a result of people winning more votes at higher rankings than the other candidates.

However surprising the outcome may be (and I have to confess I didn't find it very shocking, and even less so on reflection), it shows why we have secret ballots - because people may not be prepared to state their perceived interest publicly.

I also find Jeff's third argument reasonably compelling: what we are using is what we trialled and the AC worked with.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Aug 23, 2017

I find myself between Mike and Chaals.

Yes, STV will have the effect of (pick your euphemism here) [electing more diverse candidates | electing more fringe candidates]. Yes, STV also means that first preferences have more impact than second, they more than third, and so on (to the extent that I don't think any 4th preferences factored into the last election which was 4-seat), whereas in the past if we voted for N candidates, those N votes had equal impact. No, STV doesn't eliminate strategic voting, it just changes what that means (e.g. to try to get someone NOT elected, you vote strategically to raise the levels of those who might otherwise have trouble beating them). Yes, this is all a change, and yes, I am not sure we understood all this.

But equally, treating an N-seat STV election as N one-seat elections is something I can (in a limited search) find no analysis, literature or usage information on. I am, with Chaals, completely unwilling to run a live experiment without at least some intellectual understanding of it in theory.

I suppose the AB could request we run that tabulation on an election (possibly even the last one), but that doesn't substitute for analysis by voting-systems experts, IMHO. We could even re-tabulate, for AB and team eyes only, the last election. But I think I would only make that request if we understood an analysis.

So at the moment, I support only removing the mis-leading "one vote per seat" sentence.

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Aug 23, 2017

I'm going to oppose removing the "one vote per seat" sentence until we have a frank AC discussion along the lines "We messed up and need your guidance on how to fix it." I have no idea whether others on the AC supported the new system in the belief there was no contradiction between ranked preference voting and having one vote per open seat.

Given that -- for practical purposes -- there is a contradiction, we should re-ask the AC whether they prefer the old one vote per open seat un-ranked selection system to the one vote per election STV system. Some reasons for preferring the old system include:

  • It allows one to vote for a slate of candidates, not force one to impose artificial rankings on equal choices.
  • It makes it hard to elect fringe candidates who are opposed by a majority of the electors

Of course, each has a flip side:

  • The old system doesn't allow one to express a preference order
  • It makes it hard to elect fringe candidates whose virtues are not know to a majority of voters
@jeffjaffe

This comment has been minimized.

jeffjaffe commented Aug 24, 2017

@michaelchampion @dwsinger I think the best way to stimulate an AC discussion is to propose removing it and let the discussion take place.

If we don't remove it, the AC won't notice anything and there will be no discussion.

chaals pushed a commit that referenced this issue Aug 28, 2017

@chaals chaals closed this in #69 Aug 28, 2017

chaals added a commit that referenced this issue Aug 30, 2017

There is one vote for elections
Remove sentence that was apparently inconsistent and incoherent. See also #69, #70, and the actual issue #60.

@dwsinger dwsinger added the AC-review label Oct 6, 2017

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Nov 2, 2017

we re-open this issue and re-insert this contradiction to give us an actionable issue as a hook for further debate

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented May 10, 2018

I am glad to have turned the argument towards what we need/want, and away from the stray sentence.

Mike asks for 'consensus' outcomes. (I disagree that STV supports tribalism, at least, it does so less than the majority system we had, and indeed I disagree with much of the rest of the imputed characteristics of STV he gives).

But let's focus on finding consensus. I don't think the old "majority" system or the new STV are optimized for consensus. The old majority system was at risk of majority-tyranny and strategic voting. STV was chosen, as I said, to try to address those and improve diversity (we'll make better decisions if we hear from a wide range of viewpoints). Consensus is different: it looks for outcomes we can all live with: maybe nobody gets exactly what they actually wanted, but also nobody is desperately unhappy.

My first thought was that we could run STV 'in reverse', basically treating the lists as answering "who would you least like elected?" and discarding candidates until only the number of open seats remain. It doesn't take long to realize that this will tend to prefer candidates no-one knows about (and hence have no strong reason to object to).

I then turned to research, and indeed there is a long wikipedia article on the subject (surprise), which I urge you to read https://en.wikipedia.org/wiki/Consensus_decision-making. My read is that in this case we would need either Condorcet or Modified Borda Count.

Finally, I'd like to ask: do we want consensus on who is on the AB, or do we want a diverse AB that reflects the diversity of the consortium, and seeks to find a consensus way forward?

@swickr

This comment has been minimized.

Contributor

swickr commented May 11, 2018

@chaals commented

I note Meek's algorithm was explicitly designed in the late 1960s to prioritise using careful mathematics, to ensure quality data, and rely on computers for the processing, in order to get a result that reflected what voters were asking for, over being easy to run through in your head. Probably for that reason, when I try to run through a scenario like the examples above in my head, I sometimes discover I was not careful enough and got it wrong. Luckily, computers are more widely available than when Meek was a working computer scientist and mathematician in the 1960s and 70s.

If you read this far down, you may be interested in the actual proposal. I found it in French, and it's 15 pages without complicated mathematics, but if anyone has a link in english, or to something more accessible than a scanned PDF, I would be grateful.

I have been using the English versions reprinted in 1994 Paper I: Equality of Treatment of voters and a feedback mechanism for vote counting and Paper II: The problem of non-transferable votes from Voting matters - for the technical issues of STV, Issue 1 and found them to be very instructive.

@cwilso

This comment has been minimized.

Contributor

cwilso commented May 12, 2018

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented May 12, 2018

@dbaron

This comment has been minimized.

Member

dbaron commented May 12, 2018

@dwsinger wrote in #60 (comment) :

I then turned to research, and indeed there is a long wikipedia article on the subject (surprise), which I urge you to read https://en.wikipedia.org/wiki/Consensus_decision-making. My read is that in this case we would need either Condorcet or Modified Borda Count.

A few comments on this: Condorcet isn't a single voting method; it's a class of voting methods: those that produce the Condorcet winner when one exists (which isn't always the case). That said, it's not clear to me how one defines a Condorcet winner in a multi-winner election. Research I'm aware of to try to apply ideas from Condorcet methods to multi-winner elections led to CPO-STV, which is closely related to Schultze STV which was used in the voting experiments. In general, I think it's important to distinguish ideas that apply only to (or only work well in) single-winner elections from those that work well in multi-winner elections.


I'd also make one other comment: I wouldn't be particularly opposed to going back to the old system. It has the advantage of being easy to understand, and when consensus candidates exist, they may be more likely to be elected. That said, if we went back, I'd prefer to drop the requirement that you can't cast more votes than there are available seats; instead I'd prefer to just be able to vote or not vote for each candidate without being constrained by the maximum number of votes. This is known as approval voting. It still implies that the most any voter can do to the difference between candidates A and B in the vote counts is change that difference by 1. I think removing that constraint ("one vote per available seat") both makes things easier for voters and is better from a theoretical perspective.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented May 12, 2018

@bkardell

This comment has been minimized.

bkardell commented May 13, 2018

Yes, the resulting AB is likely to find it easier to agree because it’s less diverse but I don’t see how FTP voting gets an AB that represents the consensus of the corporation.

It's difficult to phrase this reply without saying "me" or "I", but this is the perspective that I know so please forgive that. As a person who advocated for slates of candidates I feel like this is somewhat misleading - not because I am offended by it or something, but because I think it potentially obscures important issues.

If someone were to compile a list of people actually elected before I began advocating for slates vs since, I believe that you will find that data supports that by numerous measures, diversity has increased. I have argued on more than one occasion that optimizing a diverse but productive mix, not a conflict free one or hive mind is a key goal. I have even supported or not supported the exact same candidate in different elections because of this.

I also pro-actively sought out and encouraged potential nominees that I felt helped this criteria, tho I would add this is tremendously challenging for many reasons, largely related to funding. I also arrived at my arguments and 'picks' through conversation with other W3C members and by attempting to build consensus on the optimized whole, given who we could draft for nomination, who the given candidates we had were, which particular seats/backgrounds that were up for election and what topics were in front of the AB. I think these slates tended to win, in part, precisely because we built up agreement and presented arguments together before casting votes, rather than simply asking people to please think about it on your own, show up and pull a lever - which is effectively what it was before. The process doesn't really offer more than relatively short statements written in a vacuum and sent to a mailing list in helping people think about the problem.

There are problems with First Past the Post, it's not tremendously expressive. It does, however, allow voters to express an opinion on the whole makeup. STV makes this pretty much all moot because there's no effective way to argue anything like this. It's not designed towards being expressive in that manner.

But all of this specifically gears the conversation toward how we count votes and judge the outcome. I realize that is the topic of this thread, but I think there's a different issue that is harder to articulate.. A meta-issue. Effectively, how do we balance lots of complex things that are sometimes at odds with one other. Are there some criteria that we could even agree would be 'success' in defining all the things about W3C's elected bodies?

For example, it seems to me that non-participation is a far bigger problem than first-past the post was if the stated factor for success is really 'consensus and representation of all the voices'. As @dwsinger pointed out at TPAC last year - we can't represent you or even know if we're doing a good job at reaching consensus if you don't express some opinion... Even if that opinion is simply to actively state "I don't have the time to consider this carefully, and I trust others". A vote is basically that - expressing an opinion. As in most voting systems, there isn't even a test to ensure that you've given it an ounce of thought - all opinions are counted as equally valid. A one-person org who joined only for networking reasons and has never shown up or done work has the exact same vote as MegaCorp who spends millions on active participation and gives this a ton of consideration.

Given this, and turnout, I am wildly confident that most of the people who could win STV elections actually could win elections if nominated in the old system too. While I would prefer a system that allowed me to express my actual intents and then have them counted as I intended - I'm not really sure how much more things need to be "feathered out" here practically speaking in terms of voting. In the first past the post system, even with 'slates', I feel like one could reasonably argue that a good way to do that would be to actively try to make a different argument, build some consensus among a group of people, and just get those people to show up.

One final thought: I do believe that funding participation is probably the biggest central/root problem/barrier to what I think are 'generally stated aims', it's very deeply intertwined in a whole lot of things here - but that's going to have to be another post, on another issue.

@fantasai

This comment has been minimized.

fantasai commented May 14, 2018

#60 is a vague description. For example, "The first open seat is filled according to the current STV algorithm" – I take this as meaning "Run STV as if only one seat were being contested, with a consequent high quota".

@dwsinger Yes. If the STV tabulation method used is Meek’s (as the Team has chosen), then for a single-seat election it essentially degenerates to Instant Runoff Voting (IRV). IRV is a well-documented and commonly used single-seat election method.

I see two threads in this discussion.

@jeffjaffe There's a third one: regardless of how we modify the Process in the future, how do we align the elections held this year with the currently-active Process? The method used to tabulate results in the TAG election in January afaict is non-conformant, and I don't think it's acceptable to repeat that mistake for the AB. It's clear from this thread that removing “one vote per available seat” is not an editorial change, and therefore ignoring it is a violation of the Process. Either W3C Staff needs to tabulate the results in conformance with the Process (and the consequent expectations of the various AB and AC members who expect it to be followed as written and ratified) or it needs the AC to explicitly approve not doing so.

@jeffjaffe

This comment has been minimized.

jeffjaffe commented May 14, 2018

@fantasai In the call for votes, we indicated that we were using STV and gave a link to the wikipedia article about STV. The precise counting method - Meek using OpenSTV - is the one that we used in the last several elections. It was also one of the ones that was used in the several election experiments which led to the modification of the election process in our process.

@fantasai

This comment has been minimized.

fantasai commented May 14, 2018

@jeffjaffe Yes, but while STV per seat and STV per election are both considered Single Transferrable Vote, only the former conforms with the Process. (Meek’s method can be applied per seat, it just ends up being less complicated with only one seat, so there is no conflict with the announcements that W3C made about counting methods.)

@cwilso

This comment has been minimized.

Contributor

cwilso commented May 14, 2018

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented May 14, 2018

@cwilso

This comment has been minimized.

Contributor

cwilso commented May 14, 2018

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented May 14, 2018

@cwilso

This comment has been minimized.

Contributor

cwilso commented May 14, 2018

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented May 14, 2018

@cwilso

This comment has been minimized.

Contributor

cwilso commented May 14, 2018

@chaals

This comment has been minimized.

Contributor

chaals commented May 20, 2018

@cwilso asked

So, it's only called strategic voting if it's not labelled as your clear
intent?

Yes. And that is one of the things that Brian Meek specifically tried to address with his method for counting ranked votes - ensuring that the most successful strategy for voting was to state what you actually wanted as your vote.

It is not true that with Meek voting there are no incentives for stating something other than your actual preference, in order to get an advantage over those who do behave that way. It is true that the real cases where it is applicable are vastly fewer than with "FPTP". It is also reported by those who can see the actual votes cast that large numbers of people appeared to be doing this in our "FPTP" elections, but not in our STV elections.

Expressing a vote for "no other candidate" is, in general, a real expression of what you want. If we had a mechanism that allowed this to produce a different result, I do not see evidence that votes would significantly differ (perhaps in the current "effect-free" model some voters are exaggerating their preference for rhetorical effect. That would make the difference non-zero).

@bkardell

This comment has been minimized.

bkardell commented May 22, 2018

Can someone recap any observations/outcomes from the recent AC meeting on @fantasai's point above on how to resolve that running the election similar to the last few is actually in conflict with The Process?

@jeffjaffe

This comment has been minimized.

jeffjaffe commented May 22, 2018

@bkardell This was discussed both at the AC meeting and in more detail at the AB meeting.

After we experimented with STV 2-3 years ago, the W3C Process Community Group and the Advisory Board re-wrote Section 2.5.2 to reflect that we should move to STV as our voting mechanism. The editor of the Process Document concedes that he did not see the line in Section 7.3 which appears to conflict with Section 2.5.2. Since there were no change bars associated with that Section, apparently no one else saw it either.

We actually ran not only three experimental elections, but a few actual elections using STV - Meek.

It was only after half a dozen or so elections, that I noticed the discrepancy between Section 7.3 and Section 2.5.2 when I opened this issue.

Although some have tried to find an interpretation which satisfies both Section 7.3 and Section 2.5.2, many opinions that I have heard is that they are in conflict. Given that there is an apparent conflict, the most reasonable approach appears to be using the counting mechanism that was used in the experiment, despite the fact that there was a bug in how that was translated to the process doc. After all, the whole point of the experiment requested by the membership was to see how STV works - and then if people liked it - switch to it.

IAC, the purpose of Issue #60 is to try to get consensus of what to do going forward. During the AB discussion, there was a notion that the real "problem" is that we have too many excellent candidates. As a result, Chris raised issue #190 to grow the size of the AB and TAG - and this was quickly endorsed by the AB. I believe there is a sense that if we continue to use STV, but grow the size of the AB, it may be easier to resolve issue #60.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Sep 12, 2018

Considering:

  • we have agreed (at the AB and CG) to increase the size of the AB,
  • that we know that we could re-insert this sentence if we change the voting system
  • that we are unlikely to get consensus to revert

could we agree now at least to make the document consistent and delete this sentence? please?

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Sep 12, 2018

No, sorry. Actually the discussion today nudged me further toward thinking the best voting system for W3C would be approval voting with a variable number of seats. I see increasing the size of the AB as a mitigation of the damage caused by our inability to get consensus to change the voting system. That damage includes driving away qualified people who aren't the top ranked representative of some faction, and forcing people who care about the outcomes to engage strategic coalition building during the nomination process, which I see as more distasteful than "strategic voting."

Increasing the size of the AB may have the desirable effect of getting more people with broad support in the #2 or #3 rank elected, but in the context of the voting system it may encourage further tribalism and further undermine W3C's consensus culture We shall see.

.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Sep 12, 2018

Great. Mike is on record as preferring inconsistent documents. Thanks so much, I really admire the commitment to quality.

@cwilso

This comment has been minimized.

Contributor

cwilso commented Sep 12, 2018

It's unclear to me who you want agreement from, but since I was an original commenter on this issue, I'll chime in. No, I don't think it's a fair thing to do to simply drop this sentence. (But no, I don't think either Mike or myself "prefer inconsistent documents", and it's unfair to mask the real issue here by putting it that way.)

Whether it was oversight or disingenuity, this line gave the impression that voters were still getting to vote on each seat. That is actually the exact opposite effect of STV, and I think many AC members were "sold" on the STV concept without really understanding what the side effects were, based on the results from a couple of uncontentious elections. I've consistently shocked people one on one when I've explained that they only get ONE SINGLE VOTE (yeah, I know, you'd think they'd realize it from the name). I agree with Mike that this issue shouldn't be resolved with a simple edit, but through exploration with the AC.

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Sep 12, 2018

I'd say I'm on record as preferring one vote per open seat, and would have strongly opposed the current system if proponents had been transparent that their intent was to undermine that principle. As I have argued in this thread, e.g.
#60 (comment) there is no logical inconsistency in the process document per se, only between the literal wording and its current implementation.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Sep 12, 2018

We can clearly make whatever adjustments we get consensus on to the process document. We do not need inconsistency in the document to enable that, or remind us.

This line was overlooked by everyone (editor included) when we formally agreed to adopt STV as it had been explained, and trialed. That's what we adopted, at the AB, the AC, and the CG. You can say now you regret your vote, or you weren't paying attention, or (as I do) that there were subtleties of effect that I had not foreseen. But insisting that the document remain inconsistent with the recorded resolutions and agreements of those bodies is not an effective argument for anything other than embarrassment.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Sep 12, 2018

If #60 (comment) was even vaguely what we had trialed, explored, read about, explained, or adopted in formal decisions, there might be an argument for it. It was never raised prior to the adoption of STV.

@michaelchampion

This comment has been minimized.

Collaborator

michaelchampion commented Sep 12, 2018

My concern is that W3M is inferring what they assume AC must have intended by approving a document that didn't match the extremely complicated process and confidential data used in the experiment some years ago. As Chris notes, the most sensible way forward is to re-poll the AC to see what they prefer now that we understand better the subtleties, foreseen or unforeseen 2 years ago.

@dwsinger

This comment has been minimized.

Contributor

dwsinger commented Sep 12, 2018

Just as a reminder, this issue is precisely removing this sentence (look at the filing). You may now feel that the adoption of STV is a mistake, and want to re-open the whole voting can of worms, but at the recent AC meeting there was no consensus to do that, and it would be a different issue.

We did re-poll the AC at the meeting. It was wildly inconclusive. And anyway "do you want to re-open the voting process discussion" is a different issue from maintaining a consistent document.

@jeffjaffe

This comment has been minimized.

jeffjaffe commented Sep 12, 2018

@michaelchampion The only thing that W3M inferred was that when we revised the Process Document to choose STV, that the AC approved the interpretation of STV that we had trialed, rather than a different interpretation of STV that does not appear anywhere in the STV literature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment