search

w3c / process

W3C Process Document
https://www.w3.org/policies/process/drafts/
196 stars 130 forks source link

Define "joint deliverables" #754

Closed frivoal closed 1 year ago

frivoal commented 1 year ago

In his AC review of Process 2023, @ericsiow made the following comment (not blocking adoption of P2023):

[We] would like to see the joint deliverable concept formally defined in a future version of the W3C Process Document.

(Reproduced with permission)

plehegar commented 1 year ago

The context here are the joint deliverables between the Web Applications Working Group and the Devices and Sensors Working Group. While I don't mind formally defining the concept, I'm not aware of any actual problem created by having joint deliverables between the 2 groups.

See https://github.com/w3c/webappswg/issues/90 https://github.com/w3c/das-charter/issues/123

cc @marcoscaceres @LJWatson @anssiko @reillyeon

cc

marcoscaceres commented 1 year ago

Right, can't do any harm to define the concept. but shouldn't block us from doing joint deliverables.

Joint deliverables have been a feature of the W3C has since at least 1998 (e.g., XML Linking Language (XLink) Design Principles was a joint deliverable between the XML Core Working Group and the XML Linking Working Group). And there are a ton of examples at https://www.w3.org/TR/

Additionally, WebApps has a joint deliverable already with DAS (Contact Picker) and the collaboration works great.

Here's a shot at defining joint deliverable as a starting point:

A "joint deliverable" is a technical specification or document collaboratively produced by two or more working groups within the W3C. These groups work together to address a specific technical challenge or achieve a shared goal, abiding by the W3C Patent Policy to protect contributions and enable royalty-free implementation. Joint deliverables arise from the combined expertise and resources of involved working groups, reflecting their shared interests in resolving overlapping issues.

frivoal commented 1 year ago

If it's purely descriptive, I think it might belong in /Guide rather than in the Process (which people are complaining it is already too long). An addition to the Process is most justified if we do want to add some rules about what someone must do to charter such work, or what happens when each working group working on a joint deliverable has internal consensus but that there isn't consensus between the two groups, or anything that RFC2119 language of some kind.

marcoscaceres commented 1 year ago

I guess it’s up to @ericsiow as OP to clarify what “concept formally defined” means to them exactly. I’ve never encountered any issues doing a joint deliverable, so unsure what the ask is aside from the definition I gave above.

anssiko commented 1 year ago

Thanks @frivoal. It has been brought to my attention this issue has been discussed in #2 earlier. That historical context suggests this is not a purely descriptive issue as you alluded. There are many facets to this issue.

Drawing from my experiences as the chair of multiple WGs with diverse participation, two WGs that aspire to take on a joint deliverable are likely to have been chartered with different:

And may have been chartered with different:

What follows is that it is undefined what happens if the two WGs, for example:

It seems like a partial solution here would be to say that in case of disagreement, the W3C Process Document (or other authoritative document referenced by it) prevails. For example, the Rec Track transition requirements are well-defined in the W3C Process Document. Some other aspects may require additional RFC2119 language.

Based on #2 it also looks like some PP interactions in this context are undefined (IANAL).

(Btw. Thanks to the entire Process CG for your heroic effort that was the latest update!)

dwsinger commented 1 year ago

I think we felt that the PP applies to every deliverable of a working group, joint or not. Is there something unclear?

dwsinger commented 1 year ago

I suspect that we should say that the joint deliverable must remain in scope for both working groups, and that to advance both groups must decide and it must meet the success criteria of both groups.

nigelmegitt commented 1 year ago

I think we felt that the PP applies to every deliverable of a working group, joint or not. Is there something unclear?

Presumably every member of the union of the set of members of each of the joint WGs is covered by the IPR requirements. In a hypothetical pair of WGs, let's say a subset of members of each group want to contribute to a Rec track report. There may be other members of either group who are brought in to the IPR requirements if it is made jointly by both groups. That could be a reason in favour or against doing that, but it would be good to make sure that everyone is aware.

dwsinger commented 1 year ago

@nigelmegitt I think that's why it has to be in the charter (and scope), listed as a deliverable, of both WGs

plehegar commented 1 year ago

There is an intent to refine joint deliverables in the upcoming DAS charter.

anssiko commented 1 year ago

To: AB and Process CG experts watching:

We've been made aware of https://github.com/w3c/w3process/issues/2 and ISSUE-93 -- any other discussions either in public or Member-only space we should be informed of? Thanks for letting us peek into your institutional memory.

I'm tagging @chaals who was part of the discussions in 2014 and has sticked around long enough to have accumulated knowledge in this space that is second to none.

chaals commented 1 year ago

I can't think of other discussion that's generically public, but it is worth looking for the groups who have produced or worked on joint deliverables.

In practice I think you've identified the potential pain points already.

plehegar commented 1 year ago

As a general principle, each Working Group must follow its charter, including in the case of joint deliverables.

  1. If one of the Working Groups decides to drop a joint deliverable from its charter, only the charters of the remaining Working Groups involved in that joint deliverable are applicable.
  2. A Working Group cannot publish features on the W3C standard track that are outside of its scope. The scope of the narrower Working Group prevails in joint deliverables. So any feature which is out of scope for one of the Working Groups involved cannot appear in the joint deliverable.
  3. Each Working Group is obligated to follow its Success criteria requirements. So the success criteria of the joint deliverable is the combination of the success criteria of all of the Working Groups involved. Any conflict between the success criteria section ought to be resolved before the charters are approved.
  4. Each Working Group must follow its decision policy. If conflicting decisions are recorded, the Working Groups need to resolved their differences. So, for example, all of the Working Groups must agree to publish any revision in order for the publication to happen.
plehegar commented 1 year ago

The current thinking is that this is purely an update of the Guide. There is no need to update the Process for this.

plehegar commented 1 year ago

See PR https://github.com/w3c/Guide/pull/182

I also added the handling of:

@frivoal also mentions that we'll need to handle additional cases of group coordination:

Finally, we should consider moving this issue to the Guide repo.

frivoal commented 1 year ago

@frivoal also mentions that we'll need to handle additional cases of group coordination:

  • what happens if one of the Groups is the TAG?
  • what happens if one of the Groups is a CG?

I think that the answer is if/when we do such things, we're bound by the charter of the WG, since that's the only Group that's actually allowed to publish things on the REC track. Participants beyond the WG (TAG members, CG members, what have you) will need to abide by https://www.w3.org/2023/Process-20230612/#contributor-license to make contributions