Clarify the voting process

[jeffjaffe]

The last line in Section 7.3 (about votes) says

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

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

I recommend dropping this line.

[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 notifications@github.com 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 https://github.com/w3c/w3process/issues/60#issuecomment-388153110, 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 notifications@github.com 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 notifications@github.com 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 https://github.com/w3c/w3process/issues/60#issuecomment-388153110, 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 https://github.com/w3c/w3process/issues/60#issuecomment-388153110 :

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 notifications@github.com 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.

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

[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 notifications@github.com 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 notifications@github.com 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 notifications@github.com wrote:

On May 14, 2018, at 9:34 , Chris Wilson notifications@github.com 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 https://github.com/w3c/w3process/issues/60#issuecomment-388727322, or mute the thread https://github.com/notifications/unsubscribe-auth/AAe8eaefqqjlwWOGBJ9ZPJldR-eJYN5aks5tyTcGgaJpZM4OlZjr .

[dwsinger]

On May 14, 2018, at 10:02 , Chris Wilson notifications@github.com 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 notifications@github.com wrote:

On May 14, 2018, at 10:02 , Chris Wilson notifications@github.com 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 https://github.com/w3c/w3process/issues/60#issuecomment-388758066, or mute the thread https://github.com/notifications/unsubscribe-auth/AAe8eUign3NugClVE4bhrP6wEtUnkocYks5tyVFWgaJpZM4OlZjr .

[dwsinger]

On May 14, 2018, at 11:43 , Chris Wilson notifications@github.com 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 notifications@github.com wrote:

On May 14, 2018, at 11:43 , Chris Wilson notifications@github.com 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 https://github.com/w3c/w3process/issues/60#issuecomment-388761991, 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.

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

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. https://github.com/w3c/w3process/issues/60#issuecomment-318534082 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.

[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

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

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

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

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

[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/w3c/w3process/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/w3c/w3process/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/w3c/w3process/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/

[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/)