W3C home > Mailing lists > Public > public-w3process@w3.org > May 2014

RE: Call for Consensus - "Use 'Schulze STV' for voting"

From: Bassetti, Ann <ann.bassetti@boeing.com>
Date: Mon, 19 May 2014 16:30:41 +0000
To: Carl Cargill <cargill@adobe.com>, "Nottingham, Mark" <mnotting@akamai.com>
CC: "public-w3process@w3.org" <public-w3process@w3.org>
Message-ID: <96210A64A8AC40458F5180192EB9257431C1C708@XCH-PHX-101.sw.nos.boeing.com>
+1  Carl more powerfully and effectively expresses the points I have been trying to make.

I dispute Mark's characterizations:

*         "... group of people who don't think it's worth the time to talk about changing how we vote. "

*         "... why people are voting against this, beyond "I don't care / we don't need it."

I have always said I would be interested and pleased to study a proposal that explains - with data to back up the statements!:

A) what the current problem is;
B) what the proposed solution is;
C) why the proposal is expected to be better

So far this thread comes across as a very small group possessed by the demons of a hyper-specialized topic. There have been a zillion words written, but nothing succinct, nothing backed up with data.  Chaals' note re: Schulze STV and perhaps a long-ago note from David Baron(?) are the only ones I recall with any actual proposals.  Yet neither of those answer A / B / C above.

And, BTW, I vote NO on Schulze STV for the reasons Jeff Jaffe gave (particularly that silence should not be construed as consent in this instance).

  -- Ann

From: Carl Cargill [mailto:cargill@adobe.com]
Sent: Saturday, May 17, 2014 10:45 PM
To: Nottingham, Mark
Cc: public-w3process@w3.org; Carl Cargill
Subject: RE: Call for Consensus - "Use 'Schulze STV' for voting"

Mark -

My comments in-line and indented and highlighted.

To sum my responses - you haven't made a case for change by demonstrating a positive need or benefit to the consortium and the members that would result from the change.

Treating this as a business case, your arguments would read something like this:

-          We - a group of us - think there is a problem in our group (where "we" is defined as "my friends and I").

-          We know we need to change because we've been talking about it for a long time.

-          We've got a new technical solution that has demonstrated a limited success in solving a certain class of problems, and we think that the problem we have may be one of this class.

-          We think that the new technical solution we've read about (which, admittedly hasn't been used in this type of case too often, if at all)  may be applicable to the problem that we think that we have.

-          We want to bet the consortium (or at least an element of consortium management) on using  this different and largely untested solution (in this class of problem, if we've defined the problem correctly) to fix a problem that we assert that exists, even if everybody else doesn't acknowledge the problem, but because we've been talking about the problem are sure that it exists - probably.

-          If people don't object to being experimented upon, that means they agree.

Did I miss one of you your arguments?

I've had business cases like that presented to me when I taught - the assertion that a problem exists (without rigorous proof of the problem) and that the proposed solution would fix the problem. Absent the problem statement based on fact - which I don't find in any of the arguments made so far -  the solution proposed is one of many possible solutions - since the problem isn't agreed.

Give me a real problem statement with substantiated proof like:

-          Consortium membership is declining because the AB voting scheme is flawed; this is how it would be improved by the change:

-          The Community group success rate is bad because AB voting is flawed; this new voting scheme would fix that by ...:

-          The advice given to the W3C Management team by the Advisory Board is bad because the voting is non-representational; by using our scheme, better advice and success would happen.

Any change requires a substantial proof case. In my view, you haven't made one.


Carl Cargill
Principal Scientist, Standards
Adobe Systems
Office: +1 541 488 0040
Mobile: +1 650 759 9803

-----Original Message-----
From: Nottingham, Mark [mailto:mnotting@akamai.com]
Sent: Saturday, May 17, 2014 8:38 PM
To: Carl Cargill
Cc: David Singer; Charles McCathie Nevile; public-w3process@w3.org<mailto:public-w3process@w3.org>
Subject: Re: Call for Consensus - "Use 'Schulze STV' for voting"

Hi Carl,

On 17 May 2014, at 12:24 am, Carl Cargill <cargill@adobe.com<mailto:cargill@adobe.com>> wrote:

> I find myself in an interesting position on this issue. While I have been trying to follow the thread diligently, I find that I cannot identify any specific rationale for changing the current voting methodology.  And this frustrates me.


> I see glimpses of some form of frustration - Chaals and others seem to be requesting change - and yet, the rationale for the change is unclear.  Is there a belief that installing a new voting systems will magically change the mission, the status, or the impact of the AB? Or will a new host of potential candidates be identified that will suddenly appear to become involved because of the changed method of selection?  Will this selection methodology help solve (or even have an impact on) the larger issues of membership, funding, relevance, or any other of the pressing problems. If so, how?

For me, the motivation is that first-past-the-post voting is obviously flawed and introduces significant biases.

              DATA PLEASE. I find no "obvious flaw", nor do I detect bias.  You need to be a bit more explicit, unless you're representing your viewpoint only.

As Chaals mentioned, this was seen pretty clearly in a recent TAG election.

I'm also for even the smallest move away from big-company politics; the consortium has a significant image problem in this regard, and forcing our members to vote strategically doesn't help.

              DATA PLEASE. What big company politics? I used to be on the AB; I saw no "big company politics". What is a "big company"? Is Akamai? Is Adobe? Where and how do you draw a line?

              What image problem? Could you be more explicit? What causes the image problem? AB voting?  The presence of "big companies?"

There are obviously many alternatives, each with its own ups and downs. However, *any* kind of STV is preferable to the current regime, because it doesn't have the gross problems associated with first-past-the-post.

              Again, Data. I completely disagree that "any kind of STV is preferable". That's presented as your view, and  I'll accept that. But present it as Mark's view, not fact.

So, if we're going to subject our choice to rigorous selection criteria, I'd ask that the current system be subjected to the same scrutiny.

My suggestion would be that the current system has been subjected to an immense amount of scrutiny - and that the alternatives have "gross problems associated with" STVs (to paraphrase your above statement.)

> I think that the selection process of the AB is the least of the problems that we have in the W3C.  We're focusing on a solution set that is intellectually interesting (the proper voting method) while ignoring the larger set of issues that are hard and challenging - like how to keep the W3C and Web relevant in the next decade or so, how to increase participation, how to attract more technical challenges, or how to impact the policy issues that are roiling the industry.


> If we'd spent the intellectual capital on one of these pressing (possibly even survival) issues, we'd have had a discussion that might move the industry.


> To make this explicit, I agree with Mike, David, Jeff, and others who find this discussion either premature, irrelevant, or, in my case, both.

Given how much time and coin the Consortium has spent on useful things like Web Services, I think we can spare a bit of time to contemplate how we make decisions.

Indeed, if it's truly irrelevant, the most expedient way for you to move on to more critical issues would be to wave through an acceptable change. The fact that some are vocally opposing it tells me that there's more going on.

That's sophistry; the easiest way to move on to critical issues would be to move on to critical issues. Neither you nor Chaals have made a case that this is a critical issue except to you and a small "group of people" who want to change a voting method.  The fact that there are people like me opposing should tell you that I find the debate to be trivial but bothersome.

> Let's either make this a "factful" discussion with a set of discrete issues we're trying to solve and why these issues take precedence over the more pressing technical and policy issues faced by the consortium,  or let's drop it and get back to the business of dealing with significant issues that impact W3C and the industry.

We currently have a group of people who want to change the voting regime, and a group of people who don't think it's worth the time to talk about changing how we vote. It has been this way for some time, and over the years I think the motivations and benefits have been discussed at length. Chaals has made a concrete proposal along those lines.

As such, I'd very much like to hear why people are voting against this, beyond "I don't care / we don't need it."

How about because they think you're wrong and that the current system works?  How about "You haven't proven that there is a problem to the larger consortium members that is significant enough to get people to act"?

If you really want to go down the use cases route, I'll take stab. W3C should have a voting regime that:

  * Does not require voters to vote "strategically" (e.g., not voting for their preferred candidate because it will be perceived as "throwing your vote away")

              Again - Data points to show that this is a significant problem amongst the W3C membership.

  * Minimises the number of unrepresented or disenfranchised voters


  * Attempt to represent the membership's voting accurately




Mark Nottingham    mnot@akamai.com<mailto:mnot@akamai.com>   http://www.mnot.net/
Received on Monday, 19 May 2014 16:31:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:10 UTC