- From: T.V Raman <raman@google.com>
- Date: Fri, 27 Oct 2017 10:00:17 -0700
- To: hta@google.com
- Cc: david.wood@ephox.com, chaals@yandex.ru, jeff@w3.org, dbaron@dbaron.org, w3c-ac-forum@w3.org, chairs@w3.org, ab@w3.org, public-w3process@w3.org
1+:-) Thanks for the clear analysis --- Harald Alvestrand writes: > In a consensus process, voting is what you have when you have to > decide, but consensus can't be found. > So I think we all agree that it's an emergency measure, and will > practically be done only in stressed situations. > Making up rules while stressed is bad. So clear, reasonable "default > rules" are needed. > Sociology: People who percieve a situation as a "win/lose" situation > will position themselves to win as best they can. > So if voting is going to happen, people *will* try to skew the voting > rolls - whether by changing "who votes", by trying to exclude certain > groups/people from voting ("you can't vote, you have a conflict of > interest"), or by making the vote particularly onerous to participate > in ("you have to be on this telechat at 3AM to cast your vote"). > It's obvious for both "one person one vote" and "one company one vote" > how to stack the vote - in one case, bring 100 of your closest friends > to the meeting; in the other case, tell every company and organization > you work with to join up and send a representative. Both have happened > in standards organizations we've worked with. > The difference is that stacking the vote by adding companies: > a) takes longer > b) costs more - with some of that being money that ends up in the W3C's > coffers > c) is harder to hide (because it takes longer). > If we have to have voting on issues that are important (and I think we > have to), I'd prefer the option that makes vote-stacking take longer > and be more expensive for the stacker. > > On Wed, Oct 25, 2017 at 3:51 AM, David Wood <[1]david.wood@ephox.com> > wrote: > > Hi all, > On 24 October 2017 at 05:52, Chaals McCathie Nevile > <[2]chaals@yandex.ru> wrote: > > On Mon, 23 Oct 2017 18:49:14 +0200, L. David Baron > <[3]dbaron@dbaron.org> wrote: > > I'm curious about the rationale behind one of the changes within > #24, which covers voting *in working groups* (which is described in > both the new and old process as a rare procedure that should only be > used when consensus cannot be reached). > In the current process, votes in a working group MUST be taken > per-organization (or group of related members). In the revised > process, the default voting process (which can be overridden by > charters) is that votes in a working group default to one vote per > participant. > This change seems to introduce the risk that, if a working group is > facing issues contentious enough to lead to a vote, it allows > organizations to add new members to the group in order to change the > results. This seems undesirable to me. > > >From my perspective it is true that some organisation might try to > fill the group to win a vote. In the unlikely event that an > important issue really got determined this way and left people > unhappy at the outcome, I would expect a formal objection. I expect > part of the director's analysis of such an objection to include > looking at any such attempt at "distorting the outcome" with about > as much contempt as the particular case merits. > > Chaals calls this scenario "unlikely". Is it really? > It might be worth noting that I recently (in the last two years) > attended a meeting where the CSS working group had a majority of voting > members attending from a single organisation. A quick check of the > membership of that group [1] yields: > Google: 19 participants > Microsoft: 11 participants > Apple: 11 participants > Mozilla: 8 participants > Without making any attempt whatsoever to infer whether those numbers > are a good idea (they might be for such a core WG), it is certainly an > existence proof that WGs can end up with a small number of > organisations dominating the active participation. > Regards, > Dave > [1] [4]https://www.w3.org/Style/CSS/members > > Voting is a suboptimal approach for most important decisions anyway. > It is potentially useful to stop a bikeshed discussion (not because > it gets a good answer, but because there isn't one apparent and it > stops the time being sucked into different ways to make a bad > decision...). > An alternative perspective is the old HTML Working Group, which had > far more invited experts - each given one vote - than organisational > members who were thus a small minority in any official vote. While I > hope that was an historic anomaly, in a group where one large > organisation has 4 times as many people as anyone else doing 75% of > the work, while I suspect there will be other problems it seems > reasonable to let them have more than 1 vote, in the broken case > that this is the only way forward on an issue. > So yes, there is a power shift in the "default" model. Between > Arrow's theorem, a sense that very many questions are badly put to > vote in my experience, and the sense that this is already a case > that should have been avoided, I'm not terribly concerned at what > the default looks like because I think it represents an attempt to > save discussion on an issue rather than a soundly justifiable basis > for claiming the answer is *right*. > cheers > Chaals > > (I'm coming to this from the perspective of a member of the CSS > working group, which officially has 19 participants from Google, 11 > from Apple, 11 from Microsoft, 8 from Mozilla, 6 from Vivliostyle, 5 > from Adobe, 5 from BPS, etc., but has also never held a vote. But > I'm under the impression that there have been a small number of > working groups where voting was used a good bit.) > -David > On Wednesday 2017-09-27 20:36 -0400, Jeff Jaffe wrote: > > Dear AC representative, WG Chair, or member of the public, > The W3C Advisory Board is forwarding a proposed Process 2018 draft > [1] to the Advisory Committee for consideration and comment. The > plan is that, based on the received comments, a revised draft will > be sent to the Advisory Committee for formal Review prior to the > November TPAC meeting and that there will be time for questions and > comments on the proposed Review document at the TPAC meeting. > [1][5]https://w3c.github.io/w3process/ > The major changes in this document and their rationale, with links > to the current process and a diff from it, are provided in a > backgrounder [2]. > [2][6]https://www.w3.org/wiki/Process2018 > We call special attention to issue #5 - designed to increase agility > for errata management moving us closer to a living standard model > and issue #52 which updates participation and election rules for the > TAG. > Please send comments as soon as possible (to facilitate response > preparation) and prior to October 26th (a 4 week comment period). > Specific comments on the text are best filed as Github issues or > even pull requests at the Process CG github > site<[7]https://github.com/w3c/w3process/issues>. > More general discussion and comments should be sent > [8]topublic-w3process@w3.org (Mailing list archive, publicly > available) or [9]toprocess-issues@w3.org (Member-only archive). > You may discuss your comments on any other list, such > [10]asw3c-ac-forum@w3.org, as long as you send the comments to one > of the W3process lists above and copy that list in the discussion. > Jeff Jaffe, Chair, W3C Advisory Board > Charles McCathie Nevile, Editor, W3C Process Document > David Singer, Chair, W3C Process Document Task Force > > -- > Chaals is Charles McCathie Nevile > find more at [11]http://yandex.com > > References > > 1. mailto:david.wood@ephox.com > 2. mailto:chaals@yandex.ru > 3. mailto:dbaron@dbaron.org > 4. https://www.w3.org/Style/CSS/members > 5. https://w3c.github.io/w3process/ > 6. https://www.w3.org/wiki/Process2018 > 7. https://github.com/w3c/w3process/issues > 8. mailto:topublic-w3process@w3.org > 9. mailto:toprocess-issues@w3.org > 10. mailto:asw3c-ac-forum@w3.org > 11. http://yandex.com/ -- --
Received on Friday, 27 October 2017 17:00:44 UTC