Privacy Community Group charter should focus on incubation

[tantek]

The Privacy Community Group charter in the Mission, Scope, and other sections, should explicitly mention incubation, and drop & avoid language which implies working-group-like standards development.

Instead, the Coordination should explicitly list where incubations are intended to graduate to, separately from groups expected to coordinate with as relevant.

Also the Process section should also describe exit conditions for an incubation, for how / whether a proposal should be abandoned/dropped from the group, or how a proposal should complete incubation and considerations for how to choose which Working Group it should graduate to.

Some specifics: in the Mission section up front it says “to develop privacy-focused web standards and APIs”. That should for example be changed to say incubate, e.g. “to incubate privacy-focused web standards and APIs”.

In issue #2, there is mention of “2. The deliverable phase, AKA specification.” This should be dropped from the CG charter, as when the incubation phase has completed for a proposal, the next step should be to transition it to a working group.

Label: charter.

(Originally published at: https://tantek.com/2020/030/b1/privacy-community-group-charter-focus)

[hober]

Thanks for all this feedback! I'm going to try to get a PR up today to address most or all of it.

[hober]

The Privacy Community Group charter in the Mission, Scope, and other sections, should explicitly mention incubation, and drop & avoid language which implies working-group-like standards development.

I'll be working on this in PR #5.

Instead, the Coordination should explicitly list where incubations are intended to graduate to, separately from groups expected to coordinate with as relevant.

We had intended to document this per-deliverable, in the list of deliverables. This wasn't obvious before, because we hadn't yet adopted any. As of 872aff4 we have one, so you can now see the table of deliverables which includes where we expect them to end up.

Also the Process section should also describe exit conditions for an incubation, for how / whether a proposal should be abandoned/dropped from the group, or how a proposal should complete incubation and considerations for how to choose which Working Group it should graduate to.

I'll be working on this all of this in PR #5.

Some specifics: in the Mission section up front it says “to develop privacy-focused web standards and APIs”. That should for example be changed to say incubate, e.g. “to incubate privacy-focused web standards and APIs”.

You addressed this in #4. Thanks! PR #5 will attempt to catch the other cases.

In issue #2, there is mention of “2. The deliverable phase, AKA specification.” This should be dropped from the CG charter, as when the incubation phase has completed for a proposal, the next step should be to transition it to a working group.

I think this is a simple miscommunication, and I will try to address it in #5. You're using "incubation" to mean "everything prior to migrating the work to a WG", and I was using it in a narrower sense. The PR will adopt your use of the term.

[othermaciej]

At the risk of inventing more terms, we could say "pre-incubation" for proposals that don't yet have enough support to be adopted? This status sort of exists in WICG too, where proposals often exist as outside explainers or even spec drafts, prior to being approved for import via WICG's Discourse.

[cwilso]

Actually, that's just part of the process of incubation. You can call it the "proposal stage" or something - before it's an "official WICG incubation", but that latter designation in WICG just means 1) patent commitments have been made, as it's been "contributed", and 2) more than just one organization has stated this is an interesting proposal to incubate (a requirement to transition anything into WICG).

[cwilso]

And to be clear - the attempt to define a term "Deliverable" for a CG is problematic. No matter what weight you may have given them, or what version of consensus you are using, all bets are off when work migrates to a WG - the WG has to call for a consensus to adopt that work. (E.g., we had an explicit call for consensus to adopt the WebXR work from the previous WebVR CG into the Immersive Web WG.). At that point, anything could get redefined, so it doesn't pay to enforce too much process up front; if you do, you'll just need to re-acquire consensus in the WG.

[othermaciej]

Worth noting, the exit path for some products of this CG could be a WHATWG Workstream rather than a W3C WG (in fact that is the plan of record for the one deliverable added to the charter so far).

[cwilso]

Yep, noted. This operational agreement is explicitly compatible with the WHATWG SG agreement definition for DOM/HTML features - although I'd point out that this explicitly means for those features you need two of Google, Mozilla or Apple to agree to this feature; features in core DOM/HTML couldn't be "supported" by anyone else.

[hober]

Actually, that's just part of the process of incubation. You can call it the "proposal stage" or something

In my WIP charter patch to address this feedback (#5), I've gone with "Proposal" for things that haven't yet been adopted by the CG (thanks for that suggestion), and "Work Item" for things that have been adopted.

(I had originally thought that "deliverable" would be a sufficiently de-fanged alternative for the word "specification", but apparently that isn't so, so "work item" it is. Is "work item" too awkward? Would people prefer a different term? Bikeshedding welcome in #5.)

[hober]

@tantek wrote:

Also the Process section should also describe exit conditions for an incubation, for how / whether a proposal should be abandoned/dropped from the group, or how a proposal should complete incubation

I've tried to spell out the lifecyles of proposals and work items (née deliverables) in 0d58d27, 43b6aeb, and 5d4b6fe. Please take a look at PR #5.

and considerations for how to choose which Working Group it should graduate to.

I added some text in 4f088a8 (also in PR #5) to indicate that the Editors and Chairs will work together to figure out the best destination to migrate the work to. I think it may be premature to spell out specific considerations; let's wait until we actually migrate a few things and capture what we learn from the experience.

[hober]

@tantek, I believe this has all been addressed in 32bd9e8. If you agree, please close this issue.

[cwilso]

This resolves my concerns about over-selling incubation.

[tantek]

Thanks @hober. I reviewed the changes in #5 and it all looks good. Consider this issue resolved by those changes.

Closing issue.

(Originally published at: https://tantek.com/2020/042/t2/)