Re: CfC: Should WebCodecs be exposed in Window environments?

------ Original message ------
From: "Chris Cunningham" <chcunningham@google.com>
To: public-media-wg@w3.org
Date: 15/07/2021 18:08:30

>Hi Group,
>
>On yesterday's call I mentioned part of the W3C [process on managing 
>dissent](https://www.w3.org/2020/Process-20200915/#managing-dissent):
>
> > In some cases, even after careful consideration of all points of 
>view, a group might find itself unable to reach consensus. The Chair 
>may record a decision where there is dissent (i.e., there is at least 
>one Formal Objection) so that the group can make progress (for example, 
>to produce a deliverable in a timely manner). Dissenters cannot stop a 
>group’s work simply by saying that they cannot live with a decision. 
>When the Chair believes that the Group has duly considered the 
>legitimate concerns of dissenters as far as is possible and reasonable, 
>the group should move on.
>
>I want to encourage this path. After thorough consideration of the 
>option to defer, a clear majority of WG participants and an 
>overwhelming majority of developers have shown support for immediate 
>window exposure. I believe this is exactly the circumstance the above 
>guideline is meant for.
>
>I recognize the potential for formal objections and further escalation. 
>This possibility is always present in following the quoted guideline. 
>Recording a decision at least attempts to make progress. Also, FO 
>escalation is not a given. To those who might file FOs, it is of course 
>your right, but please consider the extensive discussions and the 
>standing majority of support for immediate window exposure.
For the sake of completion, I note that the process section quoted above 
also has "Groups should favor proposals that create the weakest 
objections. This is preferred over proposals that are supported by a 
large majority but that cause strong objections from a few people".

The process allows for a Chair decision. I wouldn't say that it 
encourages one. The process encourages consensus. In the absence of 
consensus, the process encourages groups to... devote serious energy to 
finding consensus ("a group should strive to make consensus decisions"). 
It may be interesting to look at how other W3C groups solved similar 
situations. For better or worse, I suspect that they all have in common 
that reaching a final decision took time. For instance, I don't recall 
details, but it probably took a couple of years for the Audio Working 
Group to get down to one and only one audio API from the proposals that 
had initially been brought to the group.

I'm not suggesting that spending time for the sake of spending time is a 
good strategy. It just seems weird to me that the group feels that it 
has already exhausted all possibilities on the question at hand and that 
it should escalate the decision to the next level. Good arguments have 
been raised on both sides of the equation. There seem to be areas that 
could still be explored or discussed, e.g. to:

- assess whether the control queue can alleviate jank concerns:
https://github.com/w3c/webcodecs/issues/211#issuecomment-879503390

- better understand constrained devices:
https://github.com/w3c/webcodecs/issues/211#issuecomment-880870815

- clarify criteria that could make people change their mind:
https://github.com/w3c/webcodecs/issues/211#issuecomment-861067041

- or perhaps constrain the API somehow so that problematic usage that 
would likely jank the main thread would actually be forbidden on the 
main thread, while other usages on the main thread would remain 
possible?

Francois.

Received on Friday, 16 July 2021 09:34:05 UTC