Making sure the charter is flexible enough

[jbingham]

Could we make the charter broad enough or extensible enough so that it can accommodate other APIs in the future? In the community group, we've discussed a graph API, a model loader API, and operation-specific APIs. It would be nice if we didn't have to update the charter if we want to add other APIs in the future.

@anssiko has some ideas

[anssiko]

Thanks for opening this issue @jbingham. I'll loop in @dontcallmedom for the W3C perspective.

There are W3C Working Groups that include provisions in their charters that allow them to incrementally adopt improvements from a Community Group over the lifetime of the Working Group. This is exactly to avoid the costly (time, effort) process of rechartering to add new deliverables or add new features to existing deliverables. Couple of concrete examples below.

WebAssembly Working Group (proposed Charter):

Revisions to the WebAssembly Recommendation will be proposed periodically, capturing changes that have been incrementally adopted by the Working Group.

Immersive Web Working Group (Charter):

The Working Group also may choose to deliver normative specifications for the following features, if there is consensus in the Working Group that they are ready to move to the Recommendation track after sufficient incubation in the Immersive Web Community Group.

GPU for the Web Working Group (Charter):

The GPU for the Web Community Group developed the specifications adopted by this Working Group. It is expected that the Community Group will continue to drive the technical work on the specifications and incubate new features. This Working Group will work with the GPU for the Web Community Group on shaping the specifications for the Recommendation track.

I think a similar approach could be a good fit for the proposed Web Machine Learning Working Group.

I can craft a PR for review along these lines once we've received some initial feedback on the proposal. I'll put this topic on our upcoming CG call as well.

[dontcallmedom]

yes, having an open ended charter is definitely an option - the cost of doing so is that it may create barriers for participation depending on how open-ended it is - some organizations may be reluctant to sign up if the scope of their IPR commitments is too broad.

If the list of adoptable-items is reasonably well-defined, another approach is to list the specific items that the WG might adopt from the CG, as done e.g. in the WebApps WG charter:

Depending on the WICG progress, the Group may also produce W3C Recommendations for the following documents: …

[ericprud]

SPARQL 1.1 did something similar with "time permitting" deliverables.

(I don't know how deliverables are in a position to permit time; doesn't it just grind inexorably on?)

[anssiko]

Thanks for your suggestions @dontcallmedom and @ericprud.

@jbingham I drafted a PR #9 adapting the approach successfully used by other W3C WGs (noted above) that have had similar requirements. Does this look like an approach we could refine further in this context? Any questions, please let us know!

[anssiko]

This issue is addressed by PR #9.