Joint deliverables with WebApps WG

Question

Joint deliverables with WebApps WG

Closed this issue a year ago · 15 comments

There is a proposal to broaden the scope of joint deliverables between the DAS WG and WebApps WG. For the list of proposed joint deliverables, see: w3c/webappswg#90

Rationale: This would allow members who are not participants of the DAS WG but are participants of the WebApps WG to contribute substantively to the DAS WG specifications identified as joint deliverables. For the current DAS WG participants this proposed change would be largely transparent. Some extra cross-group coordination would be needed for meetings and certain publications, but the day-to-day work would proceed as usual.

Concrete actions required:

Reach agreement on the joint deliverables between the WGs. This can be a relatively quick exercise if both the WGs work together in good faith as expected. The chairs and staff would facilitate this process.
Update both the DAS WG and WebApps WG charters to identify the joint deliverables. These changes require an AC review that is a costly step. This would similarly be handled by the chairs with assistance from the staff.

If we reach agreement, to ensure timely progress, we may want to consider an off-cycle refresh to both the charters. The proposed DAS WG charter with Contact Picker API as the joint deliverable is expected to be operational "soon" awaiting W3C Council recommendation and there's a WIP PR #122 on top of it to provide a branch where to incorporate changes for possible additional joint deliverables in the next off-cycle charter update. The WebApps WG charter is due for its scheduled update in Q2 2024, which seems too long time to wait. This further emphasizes the need for an off-cycle refresh.

Answer 1 · 2022-11-30T22:49:24.000Z

I have no objection to this as it enables progress.

Separately I would like to work on a solution which would enable any of the existing WebApps WG members interested in contributing to specifications under the DAS WG charter to join, as I feel that the WebApps WG has the same problem as the DAS WG with a rather broad charter and joint deliverables only make that worse.

Answer 2 · 2022-12-02T14:09:34.000Z

Closed a bit too early. Re-opening.

Answer 3 · 2022-12-02T14:41:48.000Z

Here's the PR for developing the joint deliverables proposal: #126

Sorry about the noise. I first deployed the baseline draft to keep us focused on joint deliverables related changes only.

Answer 4 · 2022-12-09T09:05:35.000Z

We observe intensifying interest from the WebApps WG toward the Screen Wake Lock API developed in the DAS WG. To that end, I updated PR #126 with a proposal to add the Screen Wake Lock API as a joint deliverable.

In order to proceed in a timely manner with this effort, we would ask everyone to share their feedback as soon as possible, latest EOY. We have received only support signals to date. Thank you for your support!

See also: HTML diff between the current DAS WG charter and PR #126.

Edit: update HTML diff link.

Answer 5 · 2022-12-09T10:14:39.000Z

I have no objection to this as it enables progress.

Also +1 here, especially from a Screen Wake Lock API perspective.

Answer 6 · 2023-06-21T10:31:33.000Z

After extensive discussions with various parties, I'm pleased to share we're making progress with our joint deliverables proposal. The latest proposal is available for your review at:

https://w3c.github.io/das-charter/das-wg-charter.html (diff to current)

Thanks to all the reviewers who have carefully scrutinized this proposal from various perspectives. This has been a long journey. Once operational, this will further accelerate the adoption of the WG's device-centric deliverables.

There's one more thing, however. We expect our joint work mode to be clarified in this charter before we bring this forward because the Process Document does not currently define or recognise the joint deliverable concept at all and we depend on it. To not block on the Process Document missing this important definition, we plan to address this by incorporating the missing definition and its interactions with the applicable parts of the Process Document in the affected charter documents directly. And later, contribute these changes to the Process Document to ensure other WGs who may wish to adopt a similar joint work mode can refer to the canonical definition in their charter documents.

Thank you for your patience as we work out the important remaining details with the experts.

Answer 7 · 2023-06-26T12:09:51.000Z

Thank you for the update. cc @marcoscaceres

Answer 8 · 2023-07-24T14:09:16.000Z

@anssiko any update on this front?

Answer 9 · 2023-07-24T21:34:43.000Z

@anssiko any update on this front?

I believe he is still on vacation which means he didn't have time to get to this before he left.

Answer 10 · 2023-09-07T15:55:46.000Z

@anssiko any update on this front?

Answer 11 · 2023-09-08T07:53:02.000Z

@plehegar this is slated for discussion in w3c/devicesensors-wg#66

Answer 12 · 2023-09-14T12:41:13.000Z

(note) had discussed during TPAC DAS meeting, agreed as
w3c/process#754 (comment)

Answer 13 · 2023-09-25T20:40:11.000Z

Can this issue be closed at this point?

Answer 14 · 2023-09-25T22:11:08.000Z

Assuming we don't want to wait until the new charters are adopted I think this and w3c/webappswg#90 can be closed.

Answer 15 · 2023-11-08T14:04:40.000Z

Addressed by a proposed recharter now under AC review (Member-only) until 9 December 2023.

Thank you for your contributions @plehegar @himorin. We wouldn't have gotten here without your dedication and hard work. I want to extend my thank you to various stakeholders of the W3C community who have provided support and guidance on this long journey.