Sections 3.4 and 6.2.6 have different statements about Voting rules in a Charter about w3process

[dwsinger]

editorial, to align? In Section 3.4, it says "A group charter should include formal voting procedures (e.g., quorum or threshold requirements) for making decisions about substantive issues.” but 6.2.6 says "A charter may include additional voting procedures, but those procedures must not conflict with the voting requirements of the Process Document.” These are (mildly) in conflict; I’d suggest changing the “may” in 6.2.6 to a “should."

[chaals]

I don't think this is editorial, and do think it should be discussed. I also don't think it is urgent.

If a group defines voting procedures, perhaps they should be in the charter, but I would rather not have charters full of stuff like that.

First because we seek to decide by consensus, and second because having a sensible default in the process can save a lot of text.

[chaals]

Note that if we put some default, it needs to describe what can and what cannot be changed by charter or later group agreement.

[dwsinger]

Section 3.4 already has a lot about voting. It says where charters may adjust, but has no defaults for this sentence "A group charter should include formal voting procedures (e.g., quorum or threshold requirements) for making decisions about substantive issues." I suggest we add "If not defined in the charter, there is no quorum, and the threshold is simple majority, i.e. that there are more Yes than No votes with abstains and failures to vote not counted." I see no value in the sentence in 6.2.6 and would rather define voting in exactly one place. Delete from 6.2.6 "A charter may include additional voting procedures, but those procedures must not conflict with the voting requirements of the Process Document.”

[chaals]

That mostly works for me, but I think we need to describe which conditions specified as defaults can be overridden, or whether any and all conditions can be overridden by a charter, or what...

I don't mind specifying that all voting rules can be overridden, on the basis that a charter must identify its additional voting procedures, and gets reviewed.

I do want defaults, so charters may add more instead of having to do so to make sense.

[michaelchampion]

I'm uncomfortable with changes to the process that weaken the idea that consensus means "lack of sustained opposition". I can live with all the criteria in the pull request except "* More votes in favour than against means a proposal is a decision." Simple majority without quorum is not "consensus" as W3C has defined it (except for appeals of the Director's decisions, which is specifically flagged as "exceptional").

My sense of appropriate defaults would be

• Issues generally decided by a Call for Consensus, if fewer than 5% of the active (as determined by the Chair) paticipants in the WG object, the proposal is a decision.
• If there is sufficient dissent, the Chair must call a vote
• Require 1 week notice, asynchronous voting over at least 48 hours for
  substantive issues.
• 1 person, one vote
• Quorum is 50% of the working group members
• 2/3 voting in favour than against means a proposal is a decision
• Non-substantive issues can be voted however the group chooses
• Require charters to list any additional voting requirements

I'm not wedded to any of these numbers -- maybe 10% objections in a CfC triggers a vote, or maybe the quorum is 25%, or maybe the threshold is 2/3 of the active participants but there is no quorum. But it should be HARD for a WG to take some controversial decision unless it reflects a strong consensus of those affected by it.

[dwsinger]

I think that any default voting has to be bland. This is the section on what the default voting process is in WGs, not on consensus in general, so let's stay on that. I think any other threshold than simple majority is going to be hard (but charters may set a higher threshold). We could say that consensus is vastly preferable to voting.

[chaals]

We already say that consensus is preferable to voting. This section begins "groups should not vote until they have exhausted avenues to find consensus".

[dwsinger]

I think we have a disconnect between what this issue was about, and what it did. The issue was simply to set defaults for the things that the process made explicitly variable by charter, as noted by the explanation of commit:
Add default conditions:

• No quorum for votes
• Require 1 week notice, asynchronous voting over at least 48 hours for
  substantive issues.
• 1 person, one vote
• More votes in favour than against means a proposal is a decision
• Non-substantive issues can be voted however the group chooses
• Require charters to list any additional voting requirements

What we ended up doing was changing the rules, which is beyond the intent. I think we should revert, and re-think. My strawman is to insert at the end of 3.4 the defaults which hold in the absence of explicit statements in a charter, and leave the rest of 3.4 entirely untouched.

The following default conditions hold but may be over-ridden in a charter:

1. Can invited experts vote? (yes)
2. What are the default quorum and threshold requirements? (none, and 50% of those voting)
3. What are the default notice requirements? Require at least 1 week notice, asynchronous voting over at least 48 hours for substantive issues.

[dwsinger]

In 3.4, after "A group charter may include further information on voting procedures (e.g., quorum or threshold requirements) for making decisions about substantive issues." add "The following default conditions hold but may be over-ridden in a charter:

1. Invited experts may vote.
2. There is no quorum.
3. The threshold is that more vote one way than the other (i.e. simple majority), with abstentions and failures to vote uncounted.
4. The minimum voting period is 7 calendar days.
5. The minimum notice period is 7 calendar days before the end of voting (note that voting may thus start, e.g. at a face to face, before the formal notice is sent, and note that is good practice to provide notice as soon as possible once a vote is established).

[chaals]

Should I presume that we are returning to the "one vote per member or group of related members"? And do invited experts get one vote each?

I'm happy either way on both these questions, and think the other changes we have made are reasonable. I agree with @dwsinger that these should be bland. Otherwise we risk legitimising the idea of settling for a vote because consensus is hard.

As @michaelchampion notes, we should be clear that voting is generally a poor substitute for consensus. But I disagree that we should assume the vote settles the issue for all time, so do not think it needs to be buttressed by something like "most of the WG voted for this, so it must be right". The allows recorded dissent to be presented when the Director, with review by the full AC, examines the question of whether something should become a Recommendation. Voting enables the group to move forward to that point instead of being blocked.

[michaelchampion]

Should I presume that we are returning to the "one vote per member or group of related members"?

I believe the answer is Yes

And do invited experts get one vote each?
Unless there are multiple invited experts from a particular organization, in which case they would only get one vote collectively.

I strongly agree with this from @chaals

The allows recorded dissent to be presented when the Director, with review by the full AC, examines the question of whether something should become a Recommendation. Voting enables the group to move forward to that point instead of being blocked.

Words to that effect might be added right after the first sentence in 3.4

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock.

Maybe "Voting enables the group to move forward after recording the distribution of opinion on an issue, and recording dissent to be presented when the Director or AC reviews a WG's actions."

I won't object if there is consensus to add the defaults Dave proposes and defer further discussion to the next iteration. But voting is a gnarly issue and I'd prefer to balance any text that makes it clearer/easier to hold votes with text reinforcing the idea that voting has in practice been a poor way to settle issues at W3C.

[dwsinger]

leaving to next year, we reverted 3.4 in Process 2018

[dwsinger]

From Andreas in AC review, for the record:

Change

• Section 5.2.6
• URL: https://www.w3.org/2017/11/Process-20171102#WGCharter
• Description: Charters must include documentation of any voting procedures additional to those defined in Section 3.4 Voting.

Comment

It is unclear if additional formal voting procedures that are neither documented in the charter nor in section 3.4 can be adopted by the group. This should be clarified in section 3.4.

[frivoal]

Assuming it is meant as a replacement of the 3.4 sentence, the change proposed in #24 (comment) does seem like a strict improvement, so I think it should be approved, even if we later do better.

@chaals

We already say that consensus is preferable to voting.

I don't think this is quite enough. Of course people prefer when everybody agrees over when only some people agree. But putting it this way seems to encourage doing something over nothing, even when we cannot reach agreement as to what needs to be done. It is unfortunate that sometimes people cannot agree, but when that is the case, perhaps doing nothing is preferable.

@michaelchampion suggested further changes, requiring some kind of super majority for the vote to pass. The flip side is that if there is no objection after the vote, then opposition was mostly a bluff (it may have represented a preference, but not something people could not live with), and if there is, this will be examined again anyway at some later point. So in practice, the super majority rule does not achieve much. Actually I don't think votes can achieve anything that that decisions by fiat by the chair cannot: if the outcome is acceptable to everyone, we have somehow found consensus after all, and if it is not, there will be formal objections, which needs to be resolved higher up. This makes me wonder if votes in Working Groups are needed at all. How often are votes in WGs used in practice (actual formal votes, not straw-polls)? Maybe my memory fails me, I cannot recall seeing one.

I think looking at examples of actual formal votes that achieved something useful, if such a thing exists, would be a good idea.

[dwsinger]

I think Votes in WGs can work in the same way as any other decision process; if people accept that that is the defined way to make a decision and move on, losing a vote is not always followed by a FO (and indeed, a FO that appeals the result of a properly-conducted vote on a subject where a decision was clearly needed, would be weakened). The contentious DNT group had both 'least strong objection' decisions and also (IIRC) votes, and we did not always have follow-up FOs.

[dwsinger]

Trying again. In order to simplify charters, we adjust 3.4 to help provide defaults:

Remove "Unless the charter states otherwise, Invited Experts may vote."

Then add after "A group charter should include formal voting procedures…":

The following default conditions hold for voting, that may be over-ridden in a charter:

1. Invited experts may vote (subject to the requirement above on representation by organization).
2. There is no quorum.
3. The decision threshold is that more vote one way than the other (i.e. simple majority), with abstentions and failures to vote uncounted.
4. The minimum voting period is 7 calendar days.
5. The minimum notice period is 7 calendar days before the end of voting (note that voting may thus start, e.g. at a face to face, before the formal notice is sent, and note that is good practice to provide notice as soon as possible once a vote is established).

Other voting conditions that are not present in, and not in conflict with, the W3C Process and the group's Charter may be adopted by the group, by a pre-existing decision method, for a specific decision, or generally.

[michaelchampion]

I don't see any pressing problem that this would fix. As @frivoal notes above, "How often are votes in WGs used in practice (actual formal votes, not straw-polls)? Maybe my memory fails me, I cannot recall seeing one".

I feel that charters should be tailored to the needs of the community in a particular working group and am leery of setting defaults. IMHO the Process should specify hard constraints that charters MUST respect. The thread above doesn't suggest there is a lot of consensus on this, e.g. on whether supermajority votes can determine "consensus".

[dwsinger]

It's a minor cleanup and minor optimization, so not pressing. The cleanup is to be consistent; the optimization avoids charters having to write this (and clarifying what the situation is when they don't). It can wait, I am not aware of major issues...

[michaelchampion]

I'd be OK with an editorial (?) change to make both 3.4 and 6.2.6 consistently use "may" or "should". I'd prefer "may" over "should", but whatever.

[dwsinger]

We should discuss this cleanup for Process 2020. See #24 (comment)

[dwsinger]

agreed on May2019 call to make consistent but not insert defaults; charters or chairs will have to be explicit.

[dwsinger]

Check that Dec 5 comment from Andreas is addressed

[css-meeting-bot]

The Revising W3C Process CG just discussed Issue #24, and agreed to the following:

• RESOLVED: Accept Mike Champion's proposal, but don't insert defaults

The full IRC log of that discussion

<jeff> Topic: Issue #24
<jeff> David: Process document is confused
<jeff> ... different rules
<florian> github: https://github.com//issues/24
<jeff> ... no defaults
<jeff> ... tried to fix
<jeff> ... should we make it consistent?
<jeff> Florian: No strong preference
<jeff> ... inconsistencies are bad
<jeff> ... Mike said unify may and should
<cwilso> I'd prefer "may" also,.
<dsinger> https://github.com//issues/24#issuecomment-421505889
<jeff> ... baking in default rule undermines consensus
<jeff> David: No, this is default rules
<jeff> ... look at my post
<jeff> ... default rules if you don't change them
<jeff> ... shall we insert
<jeff> Florian: Alternatives is all charters must say something
<jeff> ... or are underdefined
<jeff> David: Yes
<jeff> Florian: I'm ok with that. makes voting annoying
<jeff> ... a feature!
<jeff> DS: Others?
<mchampion> +1 to making voting possible, but "annoying" to enable
<jeff> Nigel: If you want to discourage voting
<jeff> ... and it is never used
<jeff> ... make it a pain
<jeff> q+
<fantasai> s/and it is never used/which is rarely used anyway/
<jeff> Florian: So let's make it annoying.
<jeff> ... chairs can decide
<jeff> DS: No groundswell for defaults
<jeff> ... so we will make it consistent but not insert defaults
<jeff> Fantasai: Makes sense
<jeff> ... don't want threshold
<jeff> ... different kinds of decisions
<jeff> q-
<jeff> ... rules won't reflect how we work
<jeff> DS: So concluded. I'm inserting a comment.
<fantasai> s/decisions/decisions have different thresholds, e.g. we bias to no change when there's no consensus/
<jeff> Nigel: Andreas' comment
<jeff> ... proposal is they can be adopted, but don't have to be in charter
<nigel> -> https://github.com//issues/24#issuecomment-349412331
<jeff> ... dec 5 2017
<jeff> q+
<jeff> David: You are right.
<jeff> ... chair will need to be explicit
<jeff> ... that is a consequence
<dsinger> q?
<dsinger> ack jeff
<cwilso> +1 to Jeff's comment. I can't even tell what the consensus is on this issue from the notes.
<jeff> Jeff: Can we finish this one.
<jeff> Florian: We need to resolve this and post to gh
<dsinger> resolved: accept Champion proposal, but not insert defaults
<jeff> ... such as resolve and accept Mike's comment
<florian> this comment: https://github.com//issues/24#issuecomment-422474665
<jeff> Fantasai: Link to the comment
<fantasai> RESOLVED: Accept Mike Champion's proposal, but don't insert defaults
<jeff> David: Skipping #79 (done last meeting)
<jeff> issue - 235
<dsinger> https://github.com//issues/235#issuecomment-471777210