Inconsistency in managing dissent

[dontcallmedom]

https://www.w3.org/2021/Process-20211102/#managing-dissent states:

The Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection)

This seems like a catch-22 - there can only be a formal objection (thus dissent) to a decision; prior to a decision, there can't be a formal objection, so there can't be dissent.

Based on the following sentence:

Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision.

it may be that the intent was to say that the chair can record a decision that some participants said they could not live with (in which case they may raise a formal objection following the decision)?

cc @jan-ivar @caribouW3

[nigelmegitt]

This does not match my understanding:

1. A Proposal is raised.
2. An opportunity to assess consensus for the Proposal occurs.
3. Formal objections to the Proposal can be raised.
4. The Chair can:
   1. assert that there is no consensus and therefore no Decision
   2. make a Decision with recorded dissent, i.e. formal objections

Of course another option is to amend the proposal and go round the loop again.

[dontcallmedom]

https://www.w3.org/2021/Process-20211102/#WGArchiveMinorityViews is explicit that a Formal Objection can only be raised to a decision (and thus not on a proposal).

[nigelmegitt]

I can't find it now, but I think I made a comment that I thought that wording was wrong, at some point...

[dwsinger]

Perhaps it's that a person can indicate that they object, and would likely FO if the decision were made?

[chaals]

It seems like @nigelmegitt is right abut what happens in practice and @dontcallmedom is right about the fact that the letter of the process document creates an impossible situation, and should be amended to match reality better.

[TallTed]

In my experience of what happens in practice, "3. Formal objections to the Proposal can be raised" should be rewritten as "3. Objections of various degree to the Proposal can be raised, including 'I will find conformance with this painful but doable', 'if this persists to PR, I will raise a Formal Objection at that time', etc."

[jeffjaffe]

if this persists to PR, I will raise a Formal Objection at that time', etc."

Formal Objections can be raised to any decision, not just PR.

Perhaps, "if this proposal persists to a decision, I will raise a FO at that time".

[dwsinger]

yes

"I object strongly, and if this proposal were adopted as a Decision, I would likely raise a Formal Objection." is the sense we are looking for.

[TallTed]

Yes, that.

Typically, this has resulted in revision(s) to the proposal, which result in a decision which all can abide, even if it's not fully to anyone's taste.

[jan-ivar]

... a Formal Objection can only be raised to a decision (and thus not on a proposal).

Well, in practice a "decision" seems a process itself hidden in each WG's decision policy, typically: "To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions".

IOW, (provisional) decisions trigger CfCs to flush out FOs, which is how chairs are able to operate and use them as input to manage dissent, which requires evaluating the "weakest" FOs.

This explains how "the Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection)".

IOW, it's the decision that triggered the CfC and FOs that is being "recorded" (with its FOs).

"I object strongly, and if this proposal were adopted as a Decision, I would likely raise a Formal Objection."

To manage dissent requires evaluating the "weakest" FOs, which seems hard to do with mere threats of FO.

[nigelmegitt]

a "decision" seems a process itself hidden in each WG's decision policy

I take the WG's decision policy to be additional practice on top of whatever the Process says.

it's the decision that triggered the CfC

I don't think this can be right. The decision policy wording you quoted @jan-ivar reads to me as: we might make what seems to be a decision during a meeting, but really it's a strong proposal and not actually a decision until the CfC period has ended and the Chair has declared consensus.

That's certainly been my practice: whenever a "resolution" (another term that's not quite a decision?!) is made during a meeting, I pull it out in the meeting minutes summary email and state the review period end date as per the Decision Policy, and explain that objections can be raised. After the review period, if there's no objection, only then do I consider it to be a Decision.

[jan-ivar]

"resolution" (another term that's not quite a decision?!)

It looks to me like "decision" and "resolution" are literal synonyms in the process: "group decision (also known as group “resolutions”)."

Since most groups define e.g."A call for consensus (CfC) will be issued for all resolutions", this is synonymous with "A call for consensus (CfC) will be issued for all decisions", i.e. we verify the consensus of a decision. It is "provisional" because we are doing so. Once it's verified (if it is verified), it is recorded. This introduction of a CfC is the extra step/hack added by most WGs.

It might be interesting to look at any WG without this provision to see how they operate, because it would seem the process already allows for FOs after a meeting decision, i.e. a very similar process.

What hangs in the balance here appears to be the formality status of objections to a CfC.

This makes me ask: were CfCs added to:

1. Defer the formality of meeting decision objections? Or,
2. Merely formalize the FO review process with a mechanism and a deadline?

In my mind, 1 doesn't work (creates a cycle), whereas 2 lets chairs manage dissent by looking at FOs, allowing for my view of the model and that of @nigelmegitt's view in that it effectively means "Formal objections to the Proposal can be raised.", assuming the proposal was presented in a meeting and went to CfC.

[chaals]

The answer to your question doesn't, IMHO, shed light on how to solve the problem this issue raises.

@jan-ivar asked:

This makes me ask: were CfCs added to:

1. Defer the formality of meeting decision objections? Or,
2. Merely formalize the FO review process with a mechanism and a deadline?

I think the Webapps group when I chaired it about 15 years ago was the first to routinely use this approach. (Others may have independently started doing the same thing though). It was actually to cater for the fact that not everyone could be present at any meeting we held, and we wanted to reassure people that their input would still be taken seriously.

So essentially the idea was that there was tie for asynchronous discussion, even after a meeting had apparently reached a conclusion. If there were dissent, then the group would try to work through that to consensus rather than dealing with a formal objection. Even the most contenntious issue of the first few years (what to call the things now known as querySelector() and querySelectorAll() because the single hardest informatic problem is naming things and off-by-one errors) was eventually resolved by a vote that was not afterward the subject of any formal objections.

(To digress further: In my own work I have moved to a process where we divide issues into

• ones that we believe have consensus, and any objection in a given time means they are returned for discussion
• ones that are close, where a meeting may resolve something close to a substantive proposal that was available when the agenda is developed
• ones that will not be resolved even if a meeting apparently reaches a conclusion, since we cannot predict what that might look like. Those are usually scheduled for decision at the next meeting as the category with apparent consensus. This approach relies on transparent agenda planning - we have a process where the next few meetings' agenda are visible and it's easy to shuffle items between them or request that - and reasonably disciplined use of agenda. So far it seems to balance the ability to move forward at a reasonable pace with ensuring that objections are properly considered. Something else we do is explicitly allow re-opening issues just because people have changed their mind. WfM, YMMV)

[jan-ivar]

If there were dissent, then the group would try to work through that to consensus rather than dealing with a formal objection. ... Even the most contenntious issue of the first few years ... was eventually resolved by a vote that was not afterward the subject of any formal objections.

So to resolve lack of consensus you went directly to a vote? Then my understanding is you skipped an option available to you: the part we're discussing here, managing dissent, which was billed to me as a (for some issues superior) alternative to voting. If you skipped it because it seemed to require FOs, whereas voting didn't, then that seems concerning to me, and worth fixing in the process document, because I see no reason why voting would be inherently more resistant to subsequent FOs than chairs making a group decision "on the basis of having assessed the consensus of the group". The Media WG did the latter last year and hasn't been subject to any FOs so far.

If managing dissent is not an alternative to voting (as implied by "assessed the consensus", where consensus has dissent and consensus juxtaposed), and not a license for chairs to resolve consensus with an override decision ahead of actual Director-bound FOs, then I'd like to know, as this may be grounds to overturn the Media WG decision last year.

[chaals]

I think we're coming back to the topic from a different angle...

So to resolve lack of consensus you went directly to a vote?

No. We discussed it for months. All the technical stuff had been sorted, and we got to the point where we had no rational way of agreeing a name (it really is a hard problem), and we agreed we'd just vote our way through because the particular choice wasn't going to matter much, and we were literally holding back implementation until we could agree on a name - nothing else needed to be done.

There were many many discussions before the vote, but I think it has been a long long time since I heard someone suggest that anything terrible has happened because it's called querySelectorAll and not matchAllSelectors, or something else.

The outcome of a decision made by voting is subject to Formal Objection as I understand the Process because nothing in the Process suggests that an FO depends on how the decision was reached. But also, requires that you have a good argument why the outcome was wrong - something I can imagine in many cases, and potentially in some naming discussions, but not in all of them.

[chaals]

(@annevk among others may have a different memory or perspective on how this all happened, and I haven't read the minutes. We're talking about something like a decade and a half ago...)

[jan-ivar]

No worries, I'm glad you didn't run into the problem, but I'm also not seeing what a WFM argument from over a decade ago that never relied on chairs overruling dissent/objections adds. Is the argument don't use it? If so, then we should perhaps capture that in the process doc? I'm in a situation right now where chairs are trying to resolve a difficult discussion where voting doesn't seem like the only path forward, and having a process doc that made sense regarding what options we have to proceed would be helpful.

[annevk]

👋🏻 (I recall the querySelector() situation similarly.)

And I do think it captures the spirit of what groups (and their chairs) ought to be doing. Avoid FOs where possible. And in my experience FOs are raised against a decision and may ultimately result in a phone call from the Director who will try to ameliorate the situation. For that reason alone they ought to be rare. (Not sure what this will mean in Director-free land, but I liked the spirit of the old Process in that regard.)

[jan-ivar]

in my experience FOs are raised against a decision

Maybe you're right (even though the recent example I cited seems a data point against that assessment), but this issue wasn't raised to determine that.

I find it a rather strange argument: Option B is demonstrably circular; you ought not use option B, so everything is fine.

It seems to me the process document should explain what option B is in words that work. Then chairs can assess whether they want to use it or not for their specific situation.

If FOs are to be avoided like lawyers avoid trials, maybe our process document defining "dissent" so narrowly is a mistake?

[jan-ivar]

the recent example I cited seems a data point against that assessment)

It was pointed out to me that that was a vote (even though the word vote isn't mentioned anywhere), so I stand corrected.

From scanning the various [WG and IG decision policies](), it looks like WebRTC is the only WG to allow chairs to forego voting (Patents and Standards IG and the Privacy IG have similar language): "When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on."

This may explain why this hasn't come up in other WGs before. It is this reference to "dissent" that is causing confusion in our particular case, since the process defines "dissent" as "At least one individual in the set registers a Formal Objection." and no-one has so far filed a formal objection by the (unwritten?) rule that they explicitly write something like "this is a formal objection".

Are these charters wrong to reference "dissent" ahead of a vote like this? How and when do other WG's (who don't mention dissent in their decision policy) use or rely on managing dissent and its language around "weakest objections" in their process, if at all?

[dwsinger]

A CfC happens after a preliminary determination of consensus but the population sampled is not all the group (e.g. in a call, at a F2F meeting, or the chair's perception that there is likely consensus). It's the way to determine that there really is consensus.

[frivoal]

I believe this issue would be addressed by merging https://github.com/w3c/w3process/pull/635

[fantasai]

https://github.com/w3c/w3process/pull/635 was merged, so I think we're good to close! Please let us know if something remains unaddressed in the draft: https://www.w3.org/Consortium/Process/Drafts/

[dontcallmedom]

thanks, this LGTM