-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coordination between the CG and WG #10
Comments
This looks good overall - my only suggestion is that it may not be needed to have shared repos between CG and WG which make it harder to track IPR contributions (at least in the current state of our tooling) and doesn't seem necessary in our case given that the WG charter would seem to leave enough room for it to work on e.g. new operations that wouldn't be a fit for the first release of WebNN. In that sense, it would probably be closer to how the Immersive Web CG/WG operates where a repo belongs to either the CG (for new specs in incubation) or the WG (for specs it has started pushing on the Rec track). |
IIUC, in this envisioned work mode we'd transition the ownership of the webnn repo to the WG and work on any new operations for that API in scope of the WG. I believe we could share the same GH organization between the CG and WG and let the repo be the boundary to make it easier to track IPR contributions. The proposed Tentative Deliverables #9 would start their journey in CG-owned repos, either in proposals or in dedicated repos such as model-loader and with good progress the repo ownership would be migrated to the WG. @dontcallmedom does that sounds right? (Linking to infra issue w3c/ash-nazg#181 so we don't forget.) |
that's exactly right @anssiko |
@dontcallmedom if you think we should tweak the charter language to accommodate this proposal, feel free to craft a PR for that. Otherwise, we feel free to close this issue. |
let's close it - there is ongoing discussion adopting pre-defined language in charters to describe this type of relationships; I'll provide a pull request if and when it gets settled before we move forward with the review. |
Nota bene: The aspects discussed in this issue are operational, and as such we do not need to codify these aspects in the proposed charter document itself. That said, I thought it'd be good to share this proposal here to capture any comments and in general to give a heads-up to the community on what we're planning.
Given PR #9 suggests a close coordination between the Community Group and Working Group is needed, I propose the WG adopts a work mode similar to the WebGPU CG and WG to minimize the friction for participants while crossing the group boundary.
In practice this proposal, if adopted, would mean the CG/WG boundaries can remain pretty transparent for regular participants and the existing already familiar day-to-day tooling used in the CG would be shared with the WG. For example, both the CG and WG would use the same:
We'd automate tasks such as IPR checks on pull requests targeted at Working Group deliverables to make sure the participants can focus on the technical work without the need to worry about (less exciting) process-related aspects.
@tidoust, you set up the WebGPU CG/WG in this fashion couple of months ago. Feel free to share your experiences on how that has worked and what we should learn from you.
FYI @dontcallmedom
The text was updated successfully, but these errors were encountered: