Re: CfC to make Screen Wake Lock, DeviceOrientation Event, and Geolocation joint deliverables

That’s a good question Reilly. Let me try to unpack it a little. Again with my chair hat on:

First, this is nothing specific to the DAS WG. Based on my understanding of the W3C Process (IANAL) royalty-free patent commitments are included or excluded at CR (Snapshot specifically) transition time. Such an opportunity is not offered at PR transition time. I have a reason to believe W3C members prefer not to delay securing these important commitments and as such prefer deliverables to enter CR when the W3C Process-aligned standard Success Criteria is met. This is done to assure specifications produced under this policy can be implemented on a RF basis.

This model is codified in the W3C Process and Patent Policy, two foundational documents that enjoy broad W3C membership support. As the chair, I need a good reason in order to diverge from this standard policy for the joint deliverables. I don’t see any good reason right now.

This brings me to the following question: why WebApps WG wants to diverge from the W3C Process-aligned standard Success Criteria that is used by 39 out of 42 WGs currently? What makes WebApps WG different from all the other 39 WGs?

If the unstated concern is that publishing updates after entering CR is tedious, I’m happy to share that is no longer the case:

With the streamlined CR publication flow we can automate CR Draft publications that usually follow CR Snapshot(s) in a manner the publication process is functionally indistinguishable from publishing a WD. I’ve deployed this model to my other WGs and it works well. This improvement was added to the W3C Process in 2020 but not all groups are aware of it. I’d propose we adopt the same model for our joint deliverables.

Thanks,

-Anssi

On 3. Apr 2024, at 19.58, Reilly Grant <reillyg@google.com> wrote:

Given the goal we were pursuing in the DAS WG was to get all these specs to Rec we'd have to satisfy the same requirements at the PR stage that WebApps requires for CR so I don't see the functional difference. Yes, it means CR might take longer but that's time we'd spend getting to PR anyways so why does it matter?

On Wed, Apr 3, 2024 at 7:29 AM Kostiainen, Anssi <anssi.kostiainen@intel.com<mailto:anssi.kostiainen@intel.com>> wrote:
Thanks for your insights Reilly. I think I see Marcos’ perspective more clearly now.

To help inform this discussion, I will provide the most recent resolutions and group decisions regarding relevant transitions:

Screen Wake Lock WD -> CR [1]
DeviceOrientation Event WD -> CR [2]
Geolocation CR -> PR/REC [3]

In the light of this information, and considering the state of implementations, I have a reason to believe we will soon test the joint Success Criteria for multiple joint deliverables at CR transitions. With my chair-hat-on perspective, a non-conflicting Success Criteria between the groups is important regardless of whether we publish a Working Draft before a CR or not; CR transitions are either imminent or coming up soon.

(My working assumption is the joint group wants to advance joint deliverables to CR when the standard Success Criteria is satisfied.)

An unclear or conflicting Success Criteria will become a blocker for a timely advancement and risks joint deliverables being stuck at a Working Draft status. I observed confusion regarding Success Criteria in response to [2] with CR and PR expectations mixed up and prefer us to not repeat that discussion for other joint deliverables.

The chairs and team contacts will convene tomorrow to build consensus around these important topics, including transitions. We will update the joint group on our progress.

Thanks,

-Anssi

[1] https://www.w3.org/2021/10/28-dap-minutes.html#r01

[2] https://lists.w3.org/Archives/Public/public-device-apis/2024Mar/0000.html

[3] https://lists.w3.org/Archives/Public/public-device-apis/2022Mar/0008.html


On 3. Apr 2024, at 1.09, Reilly Grant <reillyg@google.com<mailto:reillyg@google.com>> wrote:

I agree with Marcos that the Success Criteria question does not apply to publishing updated Working Drafts that reflect the joint deliverable status and that is all that's needed at this time.

While fixing the error in the WebApps WG charter is important it doesn't change the goal. The whole reason we adopted these specifications as joint deliverables was that they have the necessary implementation commitments to advance on the standards track.

Reilly Grant | Software Engineer | reillyg@google.com<mailto:reillyg@google.com> | Google Chrome<https://www.google.com/chrome>


On Thu, Mar 28, 2024 at 3:34 AM Kostiainen, Anssi <anssi.kostiainen@intel.com<mailto:anssi.kostiainen@intel.com>> wrote:
Hi Marcos,

With my chair hat on I respectfully disagree. This is an important issue and it needs careful deliberation.

Let me illustrate this situation with a real-world analogue that is easier for the wider group to relate to:

In this game two teams work toward a common goal. The players want to know the rules of the game before the kick off.

The players hear the new rules of the game contain substantive errors before the game has started. Specifically, the players hear it is unclear what is considered a goal in this game.

If you are a referee in this game, do you kick off the game regardless?

In my mind, a reasonable referee would say the errors must be corrected prior to the kick off.

(Replace “game” with “joint group”, ”players” with “participants", “referee” with “chair", ”rules” with “Charter", and ”goal” with "Success Criteria".)

Thanks,

-Anssi

> On 28. Mar 2024, at 6.32, Marcos Caceres <marcosc@apple.com<mailto:marcosc@apple.com>> wrote:
>
> Hi Anssi,
>
> The charter of both working groups already state that these are joint deliverables, so no CFC is (or was!) needed to publish.
>
> The Echidna stuff is just a formality - both groups already operate on “auto-publish” basis, and have for years. Even Contact Picker (which was already a joint deliverable) is auto-published using DAS’s Decision URL [1], without a CFC from WebApps (at least that I remember).
>
> We would only do a CFC if we wanted to advance a joint deliverable to another Status. If we want to do that, then that’s what we need to discuss and get agreement on across the two groups.
>
> I don’t see any blockers to continuing to publish Screen Wake Lock and Orientation Event as regular Working Drafts. We can, and should, just do that ASAP to allow us to continue keeping those specs fresh on /TR/.
>
> It seems we just need a plan to revert Geolocation back to Working Draft so we can update it (the "Updatable Rec" process is no fun, we should ditch that). Let’s take that up separately.
>
> [1] https://lists.w3.org/Archives/Public/public-device-apis/2021May/0008.html

>
>
>> On 27 Mar 2024, at 1:45 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com<mailto:anssi.kostiainen@intel.com>> wrote:
>>
>> Hi DAS+WebApps WGs,
>> +Atsushi,
>>
>> This Call for Consensus fails.
>>
>> Reason: It has been brought to our attention [1] (in response to [2]) that the current Success Criteria of the WebApps WG Charter contains significant errors and substantive changes are expected requiring Advisory Committee review. These proposed changes impact how the envisioned joint group can advance its joint deliverables on the Recommendation Track.
>>
>> We are seeking further clarification and will issue a new CfC as soon as possible and provide you with any new information that may emerge to assist you in informed decision-making on this topic.
>>
>> Thank you for your understanding.
>>
>> Thanks,
>>
>> -Anssi
>>
>> [1] https://lists.w3.org/Archives/Public/public-device-apis/2024Mar/0018.html

>> [2] https://lists.w3.org/Archives/Public/public-device-apis/2024Mar/0017.html

>>
>>
>>> On 18. Mar 2024, at 16.16, Kostiainen, Anssi <anssi.kostiainen@intel.com<mailto:anssi.kostiainen@intel.com>> wrote:
>>>
>>> Hi DAS+WebApps WGs,
>>>
>>> This is a Call for Consensus to make Screen Wake Lock [1], DeviceOrientation Event [2], and Geolocation [3] specifications joint deliverables between the Devices and Sensors Working Group and Web Applications Working Group and to continue use the automated publication system (“Echidna”) for these specifications after they have been adopted as joint deliverables.
>>>
>>> This CfC is the record of the group decision for both the groups.
>>>
>>> Please let us know by 26 March 2024 if you have any comments or questions.
>>>
>>> Thanks,
>>>
>>> -Anssi
>>>
>>> [1] https://www.w3.org/TR/screen-wake-lock/

>>> [2] https://www.w3.org/TR/orientation-event/

>>> [3] https://www.w3.org/TR/geolocation/
>>>
>>
>