Re: Working group voting procedures in Process 2018

I think that WG voting as a mechanism to resolve an issue where a consensus cannot be reached shouldn't be treated the same way as e.g. collecting individual preferences on F2F location. It would probably be useful to differentiate them by using different terms - vote vs. straw poll. Vote would then default to one per member organization, straw poll is one per WG participant.

Thank you,
Vlad



> On Oct 24, 2017, at 4:37 PM, David Singer <singer@apple.com> wrote:
> 
> Overall, I think it should perhaps be default to organization, but the note still holds - this is no way to make a decision that is contentious, and in some cases (e.g. “where should we hold the next face to face?”) a vote per person (who intends to attend) is more useful.
> 
> Perhaps the process should allow the chair to choose which?  As Chaals said, if it’s that contentious, find a better way to consensus than a simple majority vote (of either people or organizations).
> 
>> On Oct 24, 2017, at 6:20 , Tantek Çelik <tantek@cs.stanford.edu> wrote:
>> 
>> On Mon, Oct 23, 2017 at 1:55 PM, Michael Champion
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__Michael.Champion-40microsoft.com&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=_uOKY0wXObRvkphqm8YQKX-lRmwW9HRc6_b_cCDDMHM&e=> wrote:
>>> 
>>> I also  have reservations about the changes to 3.4.  I'm embarrassed to see that I seem to have proposed the "one person one vote" language in https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_w3process_issues_24&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=xphNA0xG7hqanbpAdTZigZ8RT8QG-PQA38ZFPtWGmuA&e= because I have no recollection of what I was thinking, and David Baron is right about the risk of having organizations appoint members to a WG solely to weight the vote tallies.  Chaals has a point that it seems likely that any obvious abuse of this voting rule would trigger a formal objection, but I disagree with
>>>> 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*.
>>> There's a lot of recent research/policy indicating that defaults are taken very seriously and it's important to set them appropriately, e.g. https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Nudge-5Ftheory&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=ULt57gOPO8maFu0CBWvaM6OrYFh17Qq3YJ9g6EX1EqU&e=, https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Default-5Feffect-5F-28psychology-29&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=CzHuVTmJronQp5lxv5KAFVUKz2M7m5j3Ain5DO82T-M&e=  .  If we are going to change the defaults for voting, it's critical that there is broad consensus on what the default policies should be.
>>> 
>>> I stand by my comment on that issue that I'd prefer not to do anything that undermines the definition of consensus as "lack of sustained opposition", but if necessary I could live with supermajority voting rules to resolve deadlocks.   The Process CG seems to have concluded that discussing supermajority or quorum thresholds would  take too long to fit it into Process.  That being as it may, I prefer the Process 2017 language to the current draft language about default voting rules.
>> 
>> Agreed, and given two strong opinions for the Process 2017 language
>> (mchampion above and dbaron below "This seems undesirable to me."),
>> one weak abstention (chaals "I'm not terribly concerned at what the
>> default looks like"), I've filed
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_w3process_issues_121&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=GMiQwoDzRhhsFQ8NyzjPIDePkqjuccHDT6kbX0K1ARs&e= accordingly for further
>> discussion / consensus.
>> 
>> Pull requests welcome.
>> 
>> Thanks,
>> 
>> Tantek
>> 
>> 
>>> -----Original Message-----
>>> From: Chaals McCathie Nevile [mailto:chaals@yandex.ru]
>>> Sent: Monday, October 23, 2017 12:53 PM
>>> To: Jeff Jaffe <jeff@w3.org>; L. David Baron <dbaron@dbaron.org>
>>> Cc: W3C AC-Forum <w3c-ac-forum@w3.org>; chairs@w3.org; ab@w3.org; public-w3process@w3.org
>>> Subject: Re: Working group voting procedures in Process 2018
>>> 
>>> On Mon, 23 Oct 2017 18:49:14 +0200, L. David Baron <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.
>>> 
>>> 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]https://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_w3process_&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=LsLN9f17qyxHud3wJ87K4cLn5I5YQo2dBJEnqcKJdhU&e=
>>>>> 
>>>>> 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]https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_wiki_Process2018&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=YwdeYYtSvKtdSKMgIgTkHkt9ESp4jKruhkFA9umJfw8&e=
>>>>> 
>>>>> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_w3process_issues&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=laKTabz6ZsNu2AK-KLDo3x4ZWYNhJDXR8Qkby912l3I&e=>.
>>>>> 
>>>>> More general discussion and comments should be sent
>>>>> topublic-w3process@w3.org  (Mailing list archive, publicly available)
>>>>> or toprocess-issues@w3.org  (Member-only archive).  You may discuss
>>>>> your comments on any other list, such 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__yandex.com&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=C2Kj038ka9apxelu-QXgkqyOiz3H0qoKQwNTuXcBJZQ&s=EDWH1N9ArFxfdXKpfVjhsUrZYsWoIRTjCCe1MNOhjvU&e=
> 
> David Singer
> 
> singer@mac.com
> 
> 
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 
>