Clarify the voting process about w3process

[chaals]

Please. I made an editorial mistake a few years ago in failing to delete a line of the document when I thought I had done it. I am appalled that neither this group nor the Advisory Board has worked out how to solve that problem for such a long time.

If anyone wants to open an issue regarding the mechanism for voting, go ahead, but please can we stop holding simple editorial fixes hostage for years over far more complex issues?

(The underlying issue was resolved. The fact that people don't like the resolution is a reasonable basis for re-examining it at some point, e.g. after some experience - the same as it was only settled the first time after more people had gained some experience with the proposal. But as @michaelchampion suggests, that is a different issue).

[michaelchampion]

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?

[frivoal]

My assumption is that in case of equal preference without the ability to equal rank, a fair amount of people will be tempted to rank the incumbent first, "just in case", because it makes them feel that since they cannot express their preference, they should be voting strategically. This works against candidates that are perceived to have lower chances. I believe that having the ability to rank equally limits this effect. Regardless, my main point was to agree that the current process is self contradictory, that given that contradiction and how non obvious voting system are it is not self-evident what the AC thought it was agreeing to, and that resolving it is non editorial and needs to go back to the AC, with an explanation of the contradiction, and at least a choice between the old system and the one implemented, and possibly some variants that fall within the range of what people might have thought they were agreeing to. This is without prejudice for or against the systems. -- Sent from my phone. Please excuse my brevity.

[michaelchampion]

If it was blindingly obvious then why didn't the contradiction with "one vote per open seat" leap out at everyone who read the draft document for several years?

The easiest way forward would be to ask the AC how they want to run elections now that the misunderstanding has been cleared up.

[fantasai]

I wanted to drop a link here to @bkardell’s post from last December where he expresses some very serious reservations about the current system: https://bkardell.com/blog/W3CTAGElectionChange.html

Having talked to both @bkardell and @cwilso about that post, I know that Chris spent a lot of time trying to explain through a lot of confusion how the system actually works and what its implications are. To say that the AC didn't understand the implications of the changes seems much more likely than not.

The system @michaelchampion describes in #60 (comment) makes sense to me, and is probably the most consistent with the current wording in the Process document. If I had to interpret the Process as it stands now, this is what I would do. (And, fwiw, is also the interpretation I came up with before reading @michaelchampion’s comment.)

https://www.w3.org/2018/Process-20180201/#AB-TAG-elections

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, using a Single Transferable Vote system...

If, after the deadline for nominations, the number of nominees is ... Greater than the number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the number of available seats, the deadline for votes, details about the vote tabulation system selected by the Team for the election, and operational information.
...
When there is a vote, each Member (or group of related Members) may submit one ballot that ranks candidates in the Member's preferred order.

https://www.w3.org/2018/Process-20180201/#ACVotes

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

https://www.w3.org/2002/10/election-howto#votes

STV Meeks used as Tabulation system; OpenSTV 1.7 used to perform the computation.

The interesting situation is that, regardless of what the AB decides to do in the future, we are now operating under the 2018 Process document. I would argue that enacting @michaelchampion’s proposal is what we must do, per Process 2018, unless someone else has a different proposal which is also consistent with the Process as it stands now.

[michaelchampion]

@chaals said no

I believe it was the clear intention of Process 2017 to implement exactly the voting system which had been trialled by the AC on 3 live elections, and that this was a failure of the editor."

We all failed; you didn't catch what you clearly would have understood to be an inconsistency, I (and I suspect others on the AC) failed to understand the details of STV well enough to know that it wasn't just adding a ranked-voting option to the one-vote-per-open-seat system, and the team failed by implementing what they thought the Process was supposed to say rather than what it actually said.

As @bkardell notes, nobody really knows what this all means. Given there is an inconsistency in the "axioms" expressed in the process document, obviously there is no logical answer (or rather , all answers are equally logical ). Since there's no consensus among those of us who maintain the process document whether the inconsistency should be corrected by removing the STV language or the one vote per open seat language, I don't see any way forward other than to poll the AC on which way they want to run elections, now that we've had some experience with both systems.

[dwsinger]

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]

@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?

[michaelchampion]

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

[dwsinger]

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

[frivoal]

I agree with @michaelchampion that it is likely that a significant portion of the AC did not realize that the introduction of STV-as-we-did it was in contradiction with "one vote per available seat".
I think there are 3 possibilities:

1. AC Reps meant STV in the form that we implemented, and did not notice the lingering sentence about "one vote means one vote per available seat"
2. AC Reps understood the combination of the two to mean what @michaelchampion said (or some other thing that combined STV and "one vote per available seat", and just failed to notice that the STV variant we implemented was not what they had in mind.
3. AC reps did not notice that STV and "one vote per available seat" were contradictory.

Voting systems are complex and subtle, the raw numbers were not public, and between "one vote per available seat" and "using a Single Transferable Vote system" the first of the two sentences is the more obvious one. Based on that, I don't think we can easily assume that most AC-Reps who voted for this meant (1).

Resolving this is only editorial if all/most people meant (1), and I don't think we can know this for a fact. I think we have to go back to the AC.

Whether we should stick with meek-STV, go back to the old method, do @michaelchampion 's suggestion or something else altogether is a significantly more difficult question, given the big consequences that subtle differences in voting systems can have.

The feature with STV is that it gives a better chance than the old system to minority-favored candidates.

I think* the downside is that it:

• does not strongly distinguish between candidates that have the favor of a large minority but are strongly disliked by the rest, and candidates that have the favor of a large minority but are relatively unknown to the rest.
• if anything, it favors the strongly polarizing ones, as for the others, it is quite possible that those who have the support of large minority but are relatively unknown to the rest would be ranked high but not first by that minority, who still knows incumbents and may approves of (some of) them equally.

I think* @michaelchampion's suggestion does not have that downside, that it rejects loved-by-some-hated-by-most candidates, and that it does favor liked-by-many-but-not-always-as-number-1 candidates. It does have the downside that chaals mentions: the largest coherent bloc can win everything without an actual majority.

I would be interested in seeing the results of past elections with @michaelchampion 's method applied.

I think* that meek STV with equal ranking mitigates both the "large coherent block" downside and the "liked-by-many-but-not-always-as-number-1" downside.

---

 * IANAVSS (I Am Not A Voting System Scientist), so what I think is true about their various properties might not be.

[chaals]

@frivoal We ran three votes with both systems - the old one, and an experiment that would be analysed but not change the outcomes.

I would expect the AC to be surprised if we implemented anything other than what was put in front of them repeatedly as the experimental version, in which most who voted actually participated.

By comparison, that people noticed what the editor and others considered an obvious error wildly inconsistent with what had been presented in practice and what had been explained repeatedly, and assumed it meant either that we would use the old system, or that we would use a different system that as far as anyone know has not existed in practice, seems very unlikely to me.

[michaelchampion]

And I agree with @frivoal "What doesn't seem reasonable is to stick with a system that a non trivial part of the AC feels we picked it by accident or by misunderstanding." I am an AC member who had no idea that this change would eliminate the one-vote-per-open seat provision in the process. It not only was not removed from the draft voted on, it was NEVER MENTIONED in the years of discussion, as far as I can find.

The experiment did not generate enough data to illustrate the different outcomes that different voting systems could create, nor were enough data released for anyone not familiar with the arcana of voting systems to infer that the vote-counting process the team used didn't actually follow the letter of the process document.

It is LOGICALLY possible to have an STV ballot for each open seat. I now understand that is not what "STV" means to voting theorists, but it was not at all apparent to me when I voted for this process change, and I'm sure I'm not the only AC member in that position.

[bkardell]

As just a 'concerned individual', I remain very confident in my previous assertions that ACs do not understand the new voting system. Aside from a few people on the AB who I have discussed with at great length, I have yet to meet someone in the W3C (AC or just member) who seemed they could actually explain it or use it to accurately represent what they thought they were representing, or that what they thought they were representing wasn't actually even possible to represent. To be entirely honest, every time I go through and explain it again, I find something new perplexing about it.

If you combine the low participation numbers with the actual expressive ability of the votes and then the fact that people don't even understand it to begin with... Well, I'm not sure how to best verbalize what I am trying to say here, but... I'm not sure what the results even "mean" at that point. If that makes sense.

Sorry, I realize this is somewhat of an aside on the issue and ultimately not very helpful.

[fantasai]

@dwsinger,

You have a vote in every seat that’s open, today — a vote per seat. Your preference list is used for every seat until either every seat is filled, or your preference list is exhausted (which is roughly similar to voting for fewer people than the open seats, under the old system).

This is absolutely not true if you implement STV under Meek’s as one vote per election rather than one vote per seat (as @chaals is explaining was intended). It is true if we follow @michaelchampion’s suggestion of applying the given ballot per seat.

To give a simple proof-by-example that it is not true: if each AC provided a fully-ranked ballot, and 5 of the candidates each received exactly 20% of the first place votes (and 2 of the candidates received none, only 2nd place or later), then at no point in Meek’s algorithm do we look at any ranked position other than the first-place vote. The entire remainder of every ballot is perfectly discarded.

@chaals,

I'm highly skeptical about this, because I don't clearly understand the proposal itself.

Reread #60 (comment) , which I believe has been edited for clarity.

From a voter perspective, do voters provide 4 complete rankings?

No, they provide one ranking. There is a single ballot containing one ranking. This is very clearly specified in the Process document, and is not a condition we can violate. (Nor does it make any sense to provide 4 different rankings, obviously.)

[fantasai]

#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.

[dwsinger]

why? what good does it do to have an incorrect statement that was unintentionally left?

if you want a change to the voting process, this sentence will not help a jot. It just makes us all look like fools

[LJWatson]

@michaelchampion if you believe there is good reason to revisit the matter of which voting methodology W3C should use, then open a new issue, present your case, and let's take it from there. Using a remnant of text that remains only because of an editorial oversight as leverage to keep pressing your case is not getting us anywhere, and as @dwsinger notes, is more likely to result in intransigence than progress.

[tantek]

This is not an “editorial mistake” from the perspective of those that carefully reviewed the Process document with the voting changes and in particular interpreted the only logical way that the election could be implemented given the text of the document (literally STV per seat for the number of seats in an election), and only approved the process accordingly. Several AC reps would have filed formal objections to the process had this been dropped before the Process went to review, and before that, in the AB.

The Process also doesn’t say, implement whatever voting experiments were run, so the excuses that have been made to justify running the subsequent elections as they have been run (“but the experiments!”) also hold no justification in the Process document.

Both of those are deemed objectionable enough to not remove this text from the Process and yes that leaves us at an impasse that the AB must take-up to resolve, especially towards a future where we may/will be relying even more on elected bodies to resolve conflicts rather than a BDFL “Director”.

I do not expect to see this resolved for 2021.

(Originally published at: https://tantek.com/2020/281/t1/)

[michaelchampion]

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]

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]

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]

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

[jeffjaffe]

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]

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]

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...

[jeffjaffe]

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]

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]

A very rough answer is no. In more detail, I think it is a terrible idea that makes bad outcomes very likely. Mike asserted that second preference votes didn't count but all the information I have seen suggests that is simply false. The people elected were preferred over those not elected by the tabulated rankings. Mike's proposal seems to be a return to the old system that tended to a winner takes all outcome. An example from us history is to assert that Walter Mondale had less than 2% support since he only won a single state - and then translate that into a Senate with 2 democrats.While this might make agreements easier to reach it seems unlikely to help ensure they reflect a real consensus. More when I'm back working. Cheers17:50, 28 July 2017, David Singer <[email protected]>: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. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread. Private mail - Chaals is Charles McCathie Nevile - Standards Declaimer

[michaelchampion]

@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]

@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

[dwsinger]

On Aug 20, 2017, at 10:48 , Michael Champion ***@***.***> wrote: @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?

I asked David Baron, and he doesn’t feel enough of an expert. As I understand it, we want to compare two ways of using STV; and I would need analysis on the second before going to the AC. Does it work? Has it been used? What consequences does it have? 1. Classic STV. One preference list, and so on, with votes cascading on a n-seat quota until all seats filled. What we did. 2. STV seat-by-seat. The first seat is filled as if it were a one-seat election (50% threshold?). Then that candidate is marked ‘withdrawn’ and the same set of ballots used to fill the second seat. And so on until all seats are filled. I don’t see #2 as being any more or less “one vote per seat”. It might be different, but I do not wish to experiment on live elections, and I am unwilling to ask the AC until we have done or read some analysis. David Singer Manager, Software Standards, Apple Inc.

[chaals]

+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]

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.

[jeffjaffe]

@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.

[dwsinger]

We agree that this sentence should be removed to reflect reality that we have STV. A separate issue will be filed on whether we should revert from STV to the previous voting system, or something else.

[chaals]

If a candidate has sufficient support they will be elected in either system. STV slightly favours the candidates who are not polarising over those who are.

Candidates who are disliked by many, under STV, can be voted against by the many, by ranking them last, rather than the limit provide by the old system of one unranked preference for every available seat.

The fact that STV encourages, instead of discourages, a broader pool of candidates reinforces this effect.

Under the old system, it made more sense to only vote for a single candidate - and we know that this occurred often - in the order of 25%-35% of votes. This strategy strongly favours polarising candidates. It also strongly favours coordination in advance of the election to minimise the pool of candidates (again, something that we saw occur regularly under the old system).

Under STV, where a voter can rank all candidates without prejudice to the value of their vote, there is an incentive to do so. In comparison to the old system, this favours "compromise", and "somewhat unknown" candidates, because they will get preferred above "polarising" candidates by those who don't consider them top choices.

[chaals]

Equal ranking merely saves time for voters who don't want to choose between two candidates.

Equal ranking has no real impact on the "large minority block wins everything" issue. That is a feature of the old system and something Meek actively works against.

It has a minimal impact* on polarising vs unknown candidates - Meek (and other STV systems) already address this issue as noted above.

It seems intuitively strange, but it is mathematically true, that tossing a coin is a thoughtful rational way to rank candidates where you don't actually have a real preference. Equal ranking stops people having to think about why that is so, and thus removes apparent complexity.

Equal ranking does not make it more likely that if you cannot decide then both your candidates will be elected. Nor does it penalise indecision: your candidates do get the full value of your vote.

*minimal impact: In principle it would have none, but since a "polarising" candidate is almost never going to be absolutely first or last choice for all voters, some will likely rank them equally when that is available who would have otherwise explicitly put them last. In practice, this reality of behaviour can slightly attenuate the system's built-in favouring of compromise/unknown over polarising candidates. In practice, it is unlikely to make a lot of difference to real outcomes.

[jeffjaffe]

@frivoal While the Team prefers to stay neutral on how the AC decides to do voting, I feel obligated to bring you up to speed on the previous discussions about this issue - since I infer that you are not happy with the current method.

Unless and until we change the process again, the Team (which has been the one interpreting the process document in practice for elections) has felt that the proper voting mechanism to use is the one that we used during the couple years of experimentation. That is what we have been using until now.

Looking forward, the Team will implement whatever changes are agreed to.

[frivoal]

@jeffjaffe I understand that, and have no expectation that the team will change anything for the ongoing election. I am mostly commenting on this now to inform the AC voters of what my position regarding this open issue would be if elected, as requested in the AC forum.

I don't think I am in strong opposition against the current voting method. It seems to me that meek-STV with equal ranking would be better (even though @chaals seems to think that my intuitions on this are wrong), but I can live with either.

What doesn't seem reasonable is to stick with a system that a non trivial part of the AC feels we picked it by accident or by misunderstanding. We should either make sure that we are picking it intentionally, or revert. Living with the ambiguity is not appeasing.

[jeffjaffe]

@frivoal I think the entire AB agrees that it is desirable to add equal ranking. The operational problem is that we have not found software that tabulates this, and it is too expensive to implement ourselves.

[dwsinger]

equal-ranking: Since I have wanted to use equal-ranking, I have not opposed it. But I am concerned that people understand it. @chaals "Equal ranking merely saves time for voters who don't want to choose between two candidates." -- I don't think it's merely that. If I equal-rank 4 candidates first, and you rank order them, they get 1/4 of a vote from me in the first round, and one of them gets a full vote from you in the first round (with the rest getting no vote from you). That's a difference of impact. If we introduce equal-ranking, I want to be sure we understand it.

separate-stv-per-seat: I remain deeply concerned about adopting such a system without any live examples around the world, and without any analysis by voting system scientists.

[chaals]

Equal ranking: Why it is not trivial to implement (it was described by Meek decades ago) is that it effectively needs to expand the apparent number of votes. So in your example, your equal ranking effectively turns into one vote for each possible ranking of the 4 candidates, and mine turns into an equivalent number of votes, all of which rank the candidates in the same order.

Clearly, if these were the only two votes, my vote would be decisive.

That makes sense - you don't mind which of the four are chosen, I have expressed a preference, we both got what we asked for.

Let's expand the example, assuming there are in fact only 4 candidates, and there there are two other votes. Both rank my last choice and my third choice equal-first, my second choice third, and my first choice last.

At that point, the number of seats matters. It's close to two against one, and the first elected is going to be one of those top-ranked by the two. In practice, My preference for 3 over 4 will be what combines with the votes from those 2 to elect my third choice first.

Update In this precise case, I think you might get a tiebreak situation. In a real case where there are 20 votes not 4, a very slight variation amongst them will resolve it. Although I still haven't done the precise maths.

The point is that when you equal-rank two or more candidates, no candidate is penalised in terms of overall votes. It is only in the choice between those candidates where your vote no longer has an impact. Because you expicitly asked for that.

[dwsinger]

Yes, with single seats I might agree. I think the confusing effects might come up in a multi-seat election, where those who rank in strict order (no equal preference) repeatedly get more weight behind a candidate in each round, over the population who gave equal ranking. example: even in one seat, if A,B,C,D each equal rank X,Y and D,E,F rank Z first and W second, the the second group wins the seat because Z has 3 votes while X=Y=2 votes (4 half votes); but the population supporting X,Y is 4 voters while only 3 support Z,W. Or something like...

[chaals]

@dwsinger wrote

those who ranked repeatedly get more weight behind a candidate in each round.

I don't understand what you mean.

[dwsinger]

(updated)

[chaals]

First, this assumes nobody ranked all four candidates, and second, I don't think so, running it in my head.

In your scenario, Z doesn't have a quota for a single seat, so W gets eliminated, with nothing to distribute. One of X or Y are then distrbuted by tiebreak, whose votes transfer to the other at full value, so the other of X or Y gets elected.

In the two-seat scenario, Z has about a quota so either: Z gets elected, a bit gets distributed to W, but W is then eliminated, and one of X or Y is elected on a tiebreak. Or: W gets eliminated with nothing to transfer, then X or Y get eliminated with votes are transferred to the other at full value who is elected followed by Z. (This latter is an example of votes being extinguished. Because the X/Y voters didn't rank all the way down the line, the leftover bit gets lost. Not that it makes much difference in this tiny example, but with more votes and more seats it might).

In 3 seats, its Z, X and Y.

[chaals]

@frivoal wrote:

My assumption is that in case of equal preference without the ability to equal rank, a fair amount of people will be tempted to rank the incumbent first, "just in case", because it makes them feel that since they cannot express their preference, they should be voting strategically.

They make that assumption. But it would be based on a fundamental misunderstanding. The reason for changing the voting system was precisely to make sure that such an assumption went from being pretty much guaranteed correct to wrong and irrelevant.

The whole point of STV is that if you ranked someone first who turned out to be eliminated, your vote transfers to your second-ranked candidate. Instead of not counting for anything - which is what happened under the old system.

In addition, if you happened to vote for someone who would have won without your vote, then your vote still gets transferred - but as a fraction. For example, if a candidate got 20 votes, but only needed 10, then each paper which ranked them first only uses half their vote. So for each paper, the second-ranked candidate gets an additional half a vote to add to whatever they already had.

[dwsinger]

I agree with @chaals; we used what had been explained and trialed, and simply didn't notice this sentence.

[dwsinger]

@michaelchampion "it was NEVER MENTIONED in the years of discussion". Every single experiment and every single explanation clearly explained we were using STV voting, and how it would work. We studied STV modes in detail. It was blindingly obvious that STV voting works with a Single Transferable Vote. That's what STV means.

[dwsinger]

We missed that sentence when adjusting the process document.

[chaals]

Separate STV per seat:

I'm highly skeptical about this, because I don't clearly understand the proposal itself. From a voter perspective, do voters provide 4 complete rankings? If so, how does that work - do we have 4 sequential elections? And if not, how does it match the "one vote per seat" motivation of the proposal, rather than just being a novel proposal for an alternative method of counting STV votes?

[chaals]

@michaelchampion asked:

If it was blindingly obvious then why didn't the contradiction with "one vote per open seat" leap out at everyone who read the draft document for several years?

As far as I recall - and I was the editor at the time so this is clearly my fault - I simply failed to notice, or forgot to remove the sentence when making the particular edit. (It may be one of the cases where I was given a particular text change by this CG, and didn't carefully enough check whether it was complete).

I believe it was the clear intention of Process 2017 to implement exactly the voting system which had been trialled by the AC on 3 live elections, and that this was a failure of the editor. I have no doubt that had I looked carefully I would have reached the conclusion is the first comment in this issue.

As I recall, when it was brought to my attention that was my reaction to my mistake.

@michaelchampion objected to fixing the error, but agreed that we should be following the intention of Process 2017. I believe the rationale was so the anomaly would continue until it raised enough heat to reopen the whole voting systems discussion.

...10 months later...
It is unclear to me as a participant in this group whether that has now occurred, and is the focus of the discussion, or whether the issue is that STV and Meek's counting algorithm are somewhat complex and people would like to understand them better.

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.
part 1: please mind the copyright statement) and part 2 (which justifies equal ranking - same copyright).

[frivoal]

On May 9, 2018, at 7:57, fantasai ***@***.***> wrote: I would argue that enacting @michaelchampion <https://github.com/michaelchampion>’s proposal is what we must do, per Process 2018,

Technically I agree. At the same time, while the current method is not widely understood (as @bkardell <https://github.com/bkardell> and @fantasai detailed), it was indeed trialed for a while, and explanations were given (even if the consequences were not fully understood by many). So, violating the letter of the process (what we do now) is not good, but doing something else than what was explained and trialed does not seem great either. Hence, we should go back to the AC, explain again, and vote again (and this time make sure that the text of the Process matches the intent). Also, since I don't expect that people want to have voting system discussions all the time, if there are proposals for different voting systems we should include that in the discussion as well rather than just resolve the ambiguity/contradiction now and have a separate discussion later. As for the current election, short of throwing out the votes that have already been cast and possibly redoing the nomination phase as well, I don't see how we can switch voting systems half way through. This kind of scramble does not sound desirable, especially given that we have used the present system already in the past.

[dwsinger]

On May 8, 2018, at 20:37 , Michael Champion ***@***.***> wrote: As @bkardell notes, nobody really knows what this all means.

I am quite sure that that is not true (for example, there are people in the AC who study voting systems, as we well know). I am also aghast at the suggestion that some of the brightest people I know can’t understand STV, as applied to multi-seat elections. I would expect erudite discussion of the quota, or the details of the algorithms. Not basic “I don’t know what this all means”. David Singer Manager, Software Standards, Apple Inc.

[dwsinger]

On May 9, 2018, at 2:40 , Florian Rivoal ***@***.***> wrote: > On May 9, 2018, at 7:57, fantasai ***@***.***> wrote: > > I would argue that enacting @michaelchampion <https://github.com/michaelchampion>’s proposal is what we must do, per Process 2018, Technically I agree.

I do not. You *have* a vote in every seat that’s open, today — a vote per seat. Your preference list is used for *every* seat until either every seat is filled, or your preference list is exhausted (which is roughly similar to voting for fewer people than the open seats, under the old system). I could make at least as plausible a case that we are not in violation of the process as Michael’s case that we are. I do think that the sentence adds nothing and could cause confusion, but it’s an editorial drop. Honestly, the complaint is not over this sentence: it’s that we no longer support block voting. And that was the *intention*: STV makes it more likely we’ll elect a diverse group, that a heavy block vote won’t sweep the day and exclude all the diverse candidates. That is what we wanted — and, I think, still want. If anyone wants to go back to the system which reduced diversity, please say so (and why). It’s mildly concerning that we can’t express equal preference, and the AB has wanted to allow it as soon as we find tabulation software that supports the documented and analyzed ways to do it. But the absence of it is hardly a show-stopper. If you really don’t mind whether Amalasuentha or Gaiseric are elected, then it doesn’t matter which order you rank them; flip a coin. David Singer Manager, Software Standards, Apple Inc.

[dwsinger]

#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". As @chaals and I have both requested: we need to see this algorithm described in detail and analyzed in consequence. The sequential nature of it appears to mean that the downplaying of those voting for winners is eliminated, and my consequent guess of what is described here is that it would reduce or even eliminate the proportionality of the result, and result in lower diversity. It is also probably more open to strategic voting. In the lack of detailed description and analysis, I don't know, though.

The stray sentence is not important. What's important is what we want. The AB, when adopting and proposing this, wanted better diversity. The response seems to be "but I want to vote for a slate and get it elected" which is almost precisely the opposite effect. Don't tell me whether you want this sentence; tell me what voting effect you want.

Maybe the voting system is not what controls diversity – certainly we have discussed disincentives to stand, for example – but it almost certainly affects it.

What I am not happy to do is revert either (a) because the editor left a confusing sentence in the process or (b) because a group of highly trained computer scientists want, but don't seem to be able, to understand how multi-seat STV works. I don't think you need to understand how multi-seat STV works; the literature gives a good introduction to the ideas that it reduces the incentive for strategic voting, and gives better representation to minority communities (and hence better diversity). Is this bad?

[michaelchampion]

The stray sentence is not important.

It's important to me.

What's important is what we want. The AB, when adopting and proposing this, wanted better diversity. The response seems to be "but I want to vote for a slate and get it elected" which is almost precisely the opposite effect. Don't tell me whether you want this sentence; tell me what voting effect you want.

The effect I want is consensus on who to elect to the TAG and AB: the set of people with the most support should win. That's why the stray sentence is important to me. The current election system, by contrast, assumes and promotes competition and tribalism, not consensus. As an AC rep, I am somehow supposed to rank people that I want to all win. If I advocate for any one person I am essentially advocating against all the others. That is antithetical to a culture of consensus in my view.

I don't see one-vote-per-open-seat as antithetical to diversity. I want a diverse AB -- I'd like to elect people from multiple regions, with a relatively even distribution of genders, and with expertise in both platform implementation and website development. Under the old system, I could cast my votes for people from different continents, of different genders, and with different skill sets. In the new system I cannot express my preference for diversity with my single vote. I have to decide which person (and implicitly which "tribe") is most important to me.

gives better representation to minority communities (and hence better diversity).

The "diversity" created by a multiple-winner STV system is indeed the ability for minorities to band together to give their #1 vote to the same person and ensure their election. That makes lots of sense in a traditional competitive political system -- people generally have long-term affiliations with a particular political party, profession, ethnic group, union, whatever. They want a representative of their affiliation group to have a seat at the table when costs and benefits are being distributed. The representatives have real voting power and can make deals: you support the tax cut that benefits my affiliation group and I'll support the program that benefits yours. If we were talking about electing a legislature here, I'd probably agree with a proposal to adopt STV.

But that's not how W3C works. We would have lots of "diversity" if we elect an AB rep who speaks for the (hypothetically) 20% of the members who want to recind the EME Recommendation, another who speaks for the 20% who want to charter an EME next generation WG, another representing the 20% who wants W3C to double down on HTML and DOM, another representing the 20% who want to just stop work on W3C versions of HTML and DOM, and another representing the 20% who want to downplay the HTML web and go all in on the Semantic Web.

Is this bad?

In this scenario, the various factions could make deals and build majorities on a particular issue, but they are not likely to find much consensus. I think that is "bad" in an organization that treats consensus as a key value and gets paralyzed when there are sustained objections that the Director cannot mediate a solution to.

[jeffjaffe]

I see two threads in this discussion.

One thread (which I started when I raised this issue) is how to align the process document with the way that we ran the STV experiment and the way we have been running the STV elections. Although that was the original issue raised, arguably it is not the most important issue.

@michaelchampion writes a compelling post which basically asks whether the STV that we switched to, first experimentally - then in practice - is the type of voting that we want. Imho, the discussion about "what is the best way for us to vote" is more important than the issue of "was the process document written precisely or not".

[dwsinger]

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]

@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]

How do you believe "and seeks to find a consensus way forward" is addressed by our current system? Even highlighted, let alone encouraged? I find lots of rhetoric around this space, and of course it is challenging to be entirely objective. I will say that I entirely agree with Mike - I think STV does, in fact, encourage tribalism. I disagree that the first-past-the-post system was encouraging strategic voting; slate voting, yes, but I think it's questionable whether that's good or bad. I would hope the AC meeting session on STV will actually cover the difference between STV's encouragement of diversity and majority voting's consensus-building. I'd agree with David's last question being important.

…

On Thu, May 10, 2018 at 12:03 PM, David Singer ***@***.***> wrote: 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 reduce 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 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? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAe8ecib381kwZpjV6KogCT7xmxL8-iKks5txI8PgaJpZM4OlZjr> .

[dwsinger]

I totally agree that there is a lot of rhetoric, and seems to be emotionally charged. I actually don’t think the voting system is our biggest problem, and I fear we are bikeshedding. I wasn’t particularly unhappy with the old system, nor with the new. That said...

On May 12, 2018, at 9:57 , Chris Wilson ***@***.***> wrote: How do you believe "and seeks to find a consensus way forward" is addressed by our current system? Even highlighted, let alone encouraged?

That’s part of the AB’s job once elected, isn’t it? I don’t think that the voting system has any impact on whether/how the AB seeks to find consortium consensus, as it works. (Though, see below, ways we vote can make it harder or easier for the AB so to do).

I find lots of rhetoric around this space, and of course it is challenging to be entirely objective. I will say that I entirely agree with Mike - I think STV does, in fact, encourage tribalism. I disagree that the first-past-the-post system was encouraging strategic voting; slate voting, yes, but I think it's questionable whether that's good or bad.

I believe when we started this exercise, we asked questions about patterns of voting. One of the simplest strategic votes in first-past-the-post is to vote for fewer candidates than there are seats — up to voting only one that you want to see elected. This reduces the possibility that you’re giving weight to candidates you care less about. And indeed, in FTP voting, you cannot express a preference: I really want this one or two, these two are OK. There was substantial evidence of such strategic voting. Also, if you *don’t* want someone elected, you can vote for the person most likely to dislodge them, even if you would not ordinarily support that person.

I would hope the AC meeting session on STV will actually cover the difference between STV's encouragement of diversity and majority voting's consensus-building. I'd agree with David's last question being important.

I don’t see how FTP builds a consensus around who gets elected. Could you explain? The most likely outcome that I see is that the dominant voting block carries the day and gets their slate elected, and everyone else gets to watch. 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.

On Thu, May 10, 2018 at 12:03 PM, David Singer ***@***.***> wrote: > 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 reduce 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 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? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#60 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAe8ecib381kwZpjV6KogCT7xmxL8-iKks5txI8PgaJpZM4OlZjr> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

David Singer Manager, Software Standards, Apple Inc.

[dbaron]

@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]

Ah, thanks. I had heard of Condorcet (and seen his statue in Paris) so I didn’t read as carefully as I should, and instead learned about Borda Counts (mod or not).

…

Sent from my iPhone

On May 12, 2018, at 12:10 PM, L. David Baron ***@***.***> wrote: @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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bkardell]

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.

[jeffjaffe]

@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]

@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]

On Sat, May 12, 2018 at 10:49 AM, David Singer ***@***.***> wrote: I totally agree that there is a lot of rhetoric, and seems to be emotionally charged. I actually don’t think the voting system is our biggest problem, and I fear we are bikeshedding. I wasn’t particularly unhappy with the old system, nor with the new.

I actually AM unhappy with the new voting system, because I think it promotes tribalism under the name of diversity. It also gives any individual Member *less* ability to express who they think are good representatives for them on the AB (since they really do only get a SINGLE vote, regardless of how many seats are open.)

> How do you believe "and seeks to find a consensus way forward" is addressed > by our current system? Even highlighted, let alone encouraged? That’s part of the AB’s job once elected, isn’t it? I don’t think that the voting system has any impact on whether/how the AB seeks to find consortium consensus, as it works.

That was precisely my point, as your previous statement implied that the choices were between electing a consensus slate of members, or electing diverse members and then finding consensus after the fact. Despite the fact that you, I, Mike and Tantek all work for major browser vendors, I'd say we frequently have different perspectives and disagree.

I believe when we started this exercise, we asked questions about patterns of voting. One of the simplest strategic votes in first-past-the-post is to vote for fewer candidates than there are seats — up to voting only one that you want to see elected. This reduces the possibility that you’re giving weight to candidates you care less about. And indeed, in FTP voting, you cannot express a preference: I really want this one or two, these two are OK. There was substantial evidence of such strategic voting. Also, if you *don’t* want someone elected, you can vote for the person most likely to dislodge them, even if you would not ordinarily support that person.

I'm sorry, but the STV system still lets you express "no other candidate" - so I'm not sure how that's less strategic? It would seem to be MORE supportive of strategic voting.

I don’t see how FTP builds a consensus around who gets elected. Could you explain?

I mean building consensus inside the AB, not around who gets elected.

The most likely outcome that I see is that the dominant voting block carries the day and gets their slate elected, and everyone else gets to watch. 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.

Personal experience leads me to believe that you shouldn't claim the AB finds it easy to agree. As stated before, I don't see the current AB members as interchangeable; if we want more diversity, I would strongly express that we simply need to expand the AB. Given the growth in membership (and the W3C's scope) since the AB was instantiated, I would think that would be an obvious need.

[dwsinger]

On May 14, 2018, at 9:34 , Chris Wilson ***@***.***> wrote: I'm sorry, but the STV system still lets you express "no other candidate" - so I'm not sure how that's less strategic? It would seem to be MORE supportive of strategic voting.

a) that option has no effect and b) that’s not strategic voting. Strategic voting is when you express something that is not your actual desire, in order to influence the election. So, for example, you actually like 3 candidates, but you vote for your top preference only, because that has a strategic effect. David Singer Manager, Software Standards, Apple Inc.

[cwilso]

a) that is an error in our PRocess, yes. b) So, it's only called strategic voting if it's not labelled as your clear intent? On Mon, May 14, 2018 at 12:49 AM, David Singer <[email protected]> wrote:

…

> On May 14, 2018, at 9:34 , Chris Wilson ***@***.***> wrote: > > I'm sorry, but the STV system still lets you express "no other candidate" - > so I'm not sure how that's less strategic? It would seem to be MORE > supportive of strategic voting. a) that option has no effect and b) that’s not strategic voting. Strategic voting is when you express something that is not your actual desire, in order to influence the election. So, for example, you actually like 3 candidates, but you vote for your top preference only, because that has a strategic effect. David Singer Manager, Software Standards, Apple Inc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAe8eaefqqjlwWOGBJ9ZPJldR-eJYN5aks5tyTcGgaJpZM4OlZjr> .

[dwsinger]

On May 14, 2018, at 10:02 , Chris Wilson ***@***.***> wrote: a) that is an error in our PRocess, yes.

Well, we have never achieved consensus at the AB that it should have an effect. It was in the experiments because we may have learned something, and for some reason the team thinks that it should therefore be in the actual votes. I’ve always thought that a non-sequitur.

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

That’s what I have understood the meaning of ‘strategic voting’ is — that you don’t vote simply what you want, you vote in a way to maximize some effect. The example we’ve had cited runs roughly like this. Consider the following example under the old system. Imagine a 3 seat election; and indeed there are 3 candidates I would like to see elected. Nonetheless, there is one I really want to see elected, and I am aware that this person is not the strongest candidate. If I vote for all 3, I may be assisting a result in which the other 2 get elected but not my preferred candidate; I am better off voting for just that one candidate so as to avoid giving a lift to those other two. This is a ‘strategic vote’, in that I am not expressing my preference (the 3 I like). David Singer Manager, Software Standards, Apple Inc.

[cwilso]

I feel it's disingenuous to say "strategic voting is enabled by FPTP but not STV" when the same preference is being expressed in both systems. On Mon, May 14, 2018 at 2:41 AM, David Singer <[email protected]> wrote:

…

> On May 14, 2018, at 10:02 , Chris Wilson ***@***.***> wrote: > > a) that is an error in our PRocess, yes. Well, we have never achieved consensus at the AB that it should have an effect. It was in the experiments because we may have learned something, and for some reason the team thinks that it should therefore be in the actual votes. I’ve always thought that a non-sequitur. > b) So, it's only called strategic voting if it's not labelled as your clear > intent? That’s what I have understood the meaning of ‘strategic voting’ is — that you don’t vote simply what you want, you vote in a way to maximize some effect. The example we’ve had cited runs roughly like this. Consider the following example under the old system. Imagine a 3 seat election; and indeed there are 3 candidates I would like to see elected. Nonetheless, there is one I really want to see elected, and I am aware that this person is not the strongest candidate. If I vote for all 3, I may be assisting a result in which the other 2 get elected but not my preferred candidate; I am better off voting for just that one candidate so as to avoid giving a lift to those other two. This is a ‘strategic vote’, in that I am not expressing my preference (the 3 I like). David Singer Manager, Software Standards, Apple Inc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAe8eUign3NugClVE4bhrP6wEtUnkocYks5tyVFWgaJpZM4OlZjr> .

[dwsinger]

On May 14, 2018, at 11:43 , Chris Wilson ***@***.***> wrote: I feel it's disingenuous to say "strategic voting is enabled by FPTP but not STV" when the same preference is being expressed in both systems.

There is a difference between: a) FPTP — “please vote for the candidates you’d like to see elected” and I *don’t* do that, and vote for only one, for strategic effect and b) STV — “please rank the candidates in preference order” and I do exactly that. There is (surprise) a wikipedia article. <https://en.wikipedia.org/wiki/Tactical_voting> David Singer Manager, Software Standards, Apple Inc.

[cwilso]

In name, yes, I agree there is a difference, but in pragmatism, you are expressing the same non-preference for someone by ranking up others as you are by ranking "no other candidate" over a given candidate. On Mon, May 14, 2018 at 2:55 AM, David Singer <[email protected]> wrote:

…

> On May 14, 2018, at 11:43 , Chris Wilson ***@***.***> wrote: > > I feel it's disingenuous to say "strategic voting is enabled by FPTP but > not STV" when the same preference is being expressed in both systems. > There is a difference between: a) FPTP — “please vote for the candidates you’d like to see elected” and I *don’t* do that, and vote for only one, for strategic effect and b) STV — “please rank the candidates in preference order” and I do exactly that. There is (surprise) a wikipedia article. <https://en.wikipedia.org/ wiki/Tactical_voting> David Singer Manager, Software Standards, Apple Inc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAe8eS5fkAXrtUu9eTkz_Pss1p-GQwnSks5tyVR7gaJpZM4OlZjr> .

[chaals]

@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]

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]

@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.

[michaelchampion]

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]

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

[cwilso]

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]

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]

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]

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]

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]

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]

@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.

[jeffjaffe]

I would not recommend a long discussion of #60, but we should see if we can reach a quick consensus to implement the proposal of #60.

[cwilso]

Not a unanimous consensus, no.

[jeffjaffe]

I would be more sympathetic to those who are opposed to dropping the confusing line in Section 7.3, if I saw them proposing an alternative and attempting to gain consensus on an alternative. But I see no such initiative, hence my preference to correct the bug in 2021.

[michaelchampion]

Ignoring the wise advice in https://pics.me.me/i-will-not-take-bait-bait-is-the-mind-killer-bait-29383036.png at my peril...

All involved, most especially me, SHOULD be embarrassed about this situation. Simply closing the issue by ratifying the status quo created by W3M's implementation of Meek STV in contradiction to the verbatim text of the Process Document will take away all incentive to fix the problem.

@fantasai clearly explains the problem in http://fantasai.inkedblade.net/weblog/2020/w3c-advisory-board-election/ : "The election method (STV using Meek’s method) isn't optimized for electing a team, however: it's optimized for electing representatives of different factions. " During my time on the AB, I saw the TAG and AB reform campaigns put forward teams of candidates who were elected and revitalized both bodies. Then I saw Meek STV optimize for factionalism, and the AB lost cohesion and effectiveness. (Fortunately recent TAG nominees have been so broadly qualified the election system hasn't hurt that body's effectiveness).

Several solutions have been proposed and debated over the years, none got consensus. For example:

• Revert to the previous election system that proved effective at electing effective teams.
• Adopt some sort of approval voting system that selects the most broadly supported group of candidates rather than those with the strongest support of some faction.

Either could be enhanced with a formal or informal nomination committee that encourages diverse slates of qualified people to run.

Or there's my personal pet proposal -- don't change the Process, but implement a system that combines STV and one-vote-per-open-seat. :-) . It hasn't gotten much support, but after 3 years, I haven't been dissuaded that it combines the team-promoting feature of one-vote-per-open-seat and the diversity-promoting feature of ranked choice / transferrable vote elections in a more optimal way.

[dwsinger]

Simply closing the issue by ratifying the status quo created by W3M's implementation of Meek STV in contradiction to the verbatim text of the Process Document will take away all incentive to fix the problem.

I assure you that the existing of this text provides zero incentive. In fact, focusing on this text instead of coming in with, and getting consensus on, an alternative is more annoying than helpful, and annoyed people tend to dig their heels in. I would strongly advise what Jeff advises: propose something, and get consensus. But stop forcing us to publish stupidities. It does no-one any good, and I assure you, detracts from your support, not adds to it.

[jeffjaffe]

Noting that I proposed this as a Proposed Candidate for P2021 only if there were a quick consensus, and seeing the lack of a quick consensus - I am comfortable deferring to P2022.

[cwilso]

@dwsinger I can understand that my response may feel like useless obstructionism. The main reason I have insisted on keeping this in the process is that it highlights the lack of understanding of how STV would work in practice that existed when it was implemented. I believe the vast majority of Members believed that they would continue to be able to vote for each seat (yes, despite SINGLE VOTE being in the name); I don't think it was ever explained to them that, in effect, they were more likely to approve of one of the representatives elected, but less likely to approve of all of them.

That said - yes, I am in fact planning on proposing an alternative in the near future.

[dwsinger]

@cwilso I can also understand the unhappiness. Despite all the trials, all the reading of literature, and all the briefings, I don't think I quite got how STV achieved the diversity goals: it does it by diminishing the effect of voters once they have elected someone — yes, you effectively have 1 vote (plus a bit depending on how overflow works). So, be aware that as far as I can see now (which may be as bad as my vision in the past), 'fixing' this might easily impair the diversity goal.

And, for what it's worth, we got into this using a system that was well researched and documented. I am not feeling enthusiastic about anything that hasn't been described in the literature and analyzed by experts in the field; an un-analyzed solution has a serious risk of worse unforeseen effects.

But I repeat: from a strict technical point of view, removing this sentence, and changing the voting system, are entirely orthogonal. The first depends on simply making consistent documents. The second depends on proposals and consensus, and the existence of this sentence does nothing to help make a proposal and nothing to help gain consensus. From a people point of view, keeping this sentence annoys people and is likely to reduce the likelihood of consensus, not increase it.

[TzviyaSiegman]

I saw comments on this issue, so I thought I'd have a look. This is a lot to read through and predates my time on the AB. There is far too much in this issue for it to be helpful. I recommend opening a new issue or PR to discuss the language of the Process and addressing the use of STV elsewhere. The 2 should not be discussed in the same issue.

[michaelchampion]

I suppose it would make sense to open a new issue and close this one as unresolvable IF it is framed as "How can W3C select leadership bodies that can effectively work by consensus as a team, while ensuring that their members appropriately reflect the diversity of W3C's engaged members"? If that new issue MUST be solved before a mechanism to select the Board of Directors of W3C, Inc. is put in place, that would generate the pressure needed to find an AB/Process CG/ AC consensus on the voting question.

[dwsinger]

This issue is not unsolvable; it is precisely about deleting a line in the process left as an oversight. As long as the line remains, this issue should be here to remind us to make consistent documents.

[dwsinger]

we intend to fix this in 2021 in the absence of a reason not to (and wanting a different voting process is a separate issue)

[css-meeting-bot]

The Revising W3C Process CG just discussed Clarify the Voting Process.

The full IRC log of that discussion

<fantasai> Topic: Clarify the Voting Process
<fantasai> github: https://github.com//issues/60
<plh> jeff: we're missing the folks who were objecting to discuss this
<tantek> issue 60 has better chance of being resolved in the AB than in ProcessCG
<plh> ... this issue is getting hidden greater issues.
<jrosewell> q+
<plh> ... we have layers of confusion. would be good to find out if the AC supports the council
<plh> ... and then comes back to this issue
<plh> ack j
<chaals> q+
<dsinger_> ack jrose
<plh> james: council is meant to replace the Director?
<plh> david: for the formal objection only
<plh> florian: only one role of the Director
<chaals> q-
<plh> plh: and the AB is conducting an experiment with the council
<plh> david: I'll propose to close this issue at the next meeting
<dsinger_> q?
<dsinger_> https://github.com/w3c/w3process/milestone/6
<dsinger_> q?
<jrosewell> q+
<plh> david: we have over 35 issues on P2021....
<plh> florian: not all of them are priorities. if we don't get to the others, we'll push them along to the next version
<plh> david: looking for specific proposals
<plh> david: for wide reviews, we need to progress
<plh> plh: I'll take #130
<dsinger_> q?
<dsinger_> ack jrose
<plh> james: for my part, I expect to make proposals/issues at the beginning of November
<plh> s/beginning/middle/
<chaals> [Thank you James for planning that effort]
<dsinger_> q?
<plh> david: ok, so post-TPAC we should look back the progress
<plh> https://github.com//issues/167
<plh> florian: it overlaps with the Director free process
<jeff> q+
<plh> ... not sure if it will solve it however
<dsinger_> ack jeff
<plh> jeff: good chance that things will get worst giving the number of engines
<plh> ... but, in the absence of a proposal, I'm not sure how to solve it
<plh> .... something vague to give the Director flexibility to use their judgement
<plh> ... maybe we close the issue and re-open if things change or we get a proposal
<plh> ... it pushes us to make more definition where it doesn't seem necessary
<dsinger_> q?
<plh> florian: maybe a guideline?
<jeff> q+
<dsinger_> q?
<dsinger_> ack jeff
<plh> jeff: maybe we should push the work on guidelines to somewhere else
<plh> ... as a way to avoid cluttering our agenda
<chaals> [I think there would be a need to think about how you are going to run such a group. There is already an open github repo that can be used for the work, but it isn't clear how changes get taken in…]
<plh> florian: it will clear the agenda but won't reduce the work
<jeff> [Good point Chaals. I was thinking of proposing PLH to chair the guidelines group and have them meet at the frequency that he thought would make sense.]
<plh> https://github.com//issues/236
<plh> fantasai: "Draft Notes" ?
<plh> https://www.w3.org/TR/?status=ret
<plh> florian: concerned about the mixing of documents on the REC track and those that are not
<plh> david: we can go some clean-ups
<florian> s/are not/are not, due to patent policy implications/
<plh> s/go/do/