What should the requirements be for specifications produced by more than one WG? about w3process

[dwsinger]

My limit of two was not the number of joint deliverables per WG, it was the number of WGs that join to make one deliverable.

[chaals]

The usual situation is that each Working Group has the entire specification as part of their chartered deliverables, and the working assumption is that they are each committing to the entire deliverable.

Agreed that it makes sense to ask PSIG to describe the best practices for making this so...

[LJWatson]

*The Process says little on the subject of joint deliverables. The closest thing I could find is in sesction 5.2.6 Working Group and Interest Group charters:

• Any dependencies by groups within or outside of W3C on the deliverables of this group. For any dependencies, the charter must specify the mechanisms
  for communication about the deliverables;
• Any dependencies of this group on other groups within or outside of W3C. Such dependencies include interactions with
  W3C Horizontal Groups;>

The first question seems to be whether there is a reasonable case to be made for having joint deliverables?

[chaals]

As far as I can tell the case for joint deliverables is roughly as follows:

1. There is a need for the overlapping expertise in two or more working groups
2. The overhead cost of having all the relevant stakeholders join one or other working group is higher than the net benefit
3. Similarly to 2 above, the overhead cost of starting a new Working Group to produce the deliverable is higher than the net benefit
4. There is a patent commitment by the union of membership in the two groups, which is stronger than if the deliverable were produced by a single group.

Points 2 and 4 above are somewhat in tension. Given that a commitment to work on a specification is already a sine qua non for making it a deliverable, the largest obstacle to having people join working grups is often the IPR commitment required. However, in the case where groups have multiple deliverables - which seems to be almost certainly the case where there is a proposal to undertake a joint deliverable since presumably both groups already had other deliverables, a specific issue can be the requirement to commit IPR or exclusions to other deliverables in the scope of a group.

Against this, the argument against joint deliverables seems to be:

1. Administrative overhead cost in e.g. determining consensus for such things as transition requests;
2. A lack of clarity about decision making in the event of conflict between the two groups.

The first of these is really a question of developing a sensible arrangement between any two or more groups proposing to work jointly on a deliverable. The second is somewhat related, but goes more to the point that the process - and the patent policy - fail to explain clearly the implications of joint deliverables.

A related question is the IPR commitment of reviewers from "horizonal groups", where those reviews lead to substantive changes, and thus new "essential claims".

While I am generally reluctant to support joint deliverables, it seems the rationale to allow them is sufficiently strong in practice that we should resolve this problem to the extent possible. For example, the TAG is not chartered to work on "normal" specs, but does originate them from time to time, often passing them as "joint deliverables" with a Working Group in whose scope they clearly fit.

I think there is a fairly simple outline to the solution:

1. State in the process that work can be chartered as a joint deliverable, by 2 working groups
2. State that where a WG decision is required, e.g. for transition, the decision is required of both groups
3. If the collective chairs are unable to negotiate a joint consensus of the groups on some issue, then we should pick an escalation path. Possibilities include referral to the Team, the Tag, the Director, or determining that the work cannot proceed and publishing it as abandoned work in a Note.

At the same time, we should distinguish between the case where there is a joint deliverable, and where a new group has been rechartered to take on a deliverable in an existing charter, so the group which was working on the deliverable is no longer responsible for it, and determine what are the responsibilities of the "interim" Working Group once the specification has passed from their responsibility - in particular with respect to IPR commitments for changes they introduced. I suspect that in the first instance we should refer that question to PSIG to see if there is a consensus.

[dwsinger]

I agree with chaals, except that the last paragraph he writes seems to be about handoff rather than joint deliverables, and he handled that in the supergroups work last year.

I would suggest we keep joint to at most 2, indeed. On escalation, what is the escalation if only one group cannot achieve consensus? I think I would tend to prefer that the two groups agree on a decision policy (which might, for example, be CfO handled by the chairs of both groups, or might be an escalation one).

[LJWatson]

Do we have any way to find out how many joint deliverables there are in production at present? Limiting joint deliverables to two per WG seems reasonable, but it would be good to know whether that is indeed the case.

Otherwise, the update to the process suggested by @chaals with the refinements suggested by @dwsinger LGTM.

[paulbrucecotton]

Limiting joint deliverables to two per WG seems reasonable

I don't know why you would create such an artificial limit. The long time joint work between the XSL WG and the XML Query WG covered many more deliverables than that as part of the following set of TR documents: XPath 2.0, XQuery 1.0, XQueryX 1.0, XSLT 2.0, Data Model (XDM), Functions and Operators, Formal Semantics, Serialization.

/paulc

[chaals]

I wouldn't make the restriction either way in the process. Paul points out that there is plenty of history of making joint deliverables. At the same time there is often significant pressure at chartering time against any particular joint deliverable, and some of that just seems to be a reflex action rather than considering the specific circumstances. If it turns out that we need, say, CSS, XML and RDF working groups to collaborate on a deliverable that the membership decides we need, then adding a further barrier to the natural reluctance to complicate life seems unnecessary. cheers

…

On 16/06/17 17:56, David Singer wrote: My limit of two was not the number of joint deliverables per WG, it was the number of WGs that join to make one deliverable. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEfw_DvCPAjQXflb7qkvL--oBTfN8RYcks5sEqWWgaJpZM4NEodm>.

[vfournier17]

My concern is making sure the patent licensing commitments to the "joint" deliverables are clear. Would this be spliced up by which WG contributed which part of the deliverable? Or would the participants of each WG have a full patent licensing commitment to the entirety of the "joint" deliverables. This seems like more of a psig PP interpretation question than a process one.

[paulbrucecotton]

My concern is making sure the patent licensing commitments to the "joint" deliverables are clear.

Using XPath as an example the SOTD of the Recommendation makes this very clear:

"This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures (W3C XML Query Working Group) and a public list of any patent disclosures (W3C XSLT Working Group) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy."

Note: I have NOT reproduced all the links in the above text.

/paulc

[dwsinger]

It does not seem that any process requirements are needed to enable this, as we do this now. At most we could clarify, but that's not urgent.

[dwsinger]

seeing no action needed, we close this