- 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