Chair powers and process

[cwilso]

There is a lot of bespoke process defined in this charter.

Regardless, it's unclear to me why there's so much process defined here for a CG. Anything in this charter is editable by the chairs at will - there is no process around it, on purpose. If you want to define this kind of process, we should really be editing the Process docs in the Process CG, so that it is consistent across CGs. If you're just concerned about having a fair, consensus-based process in the Privacy area, we should be ramping up a WG (which would have a consistent Process). There are some oddities exposed here, otherwise - for example, Chairs in this privacy CG can decide to remove deliverables unilaterally, something that Chairs in a WG typically cannot do.

[othermaciej]

CGs are allowed to have any process they want, as defined by the chairs. There's no requirement for CGs to have consistent process. They are not governed by the W3C Process. And a number of CGs that have worked on or are working on specifications expected to be standards-track all have different charters.

Having a Privacy WG at some stage is wholly reasonable. Many CGs have led to a WG eventually, including WebAssembly, WebXR, and likely soon WebGPU. (In some cases the CG even continues in parallel). However, a WG charter generally requires listing specific deliverables, and we don't yet know what those are. Hopefully after the CG has done enough work to know that, we can propose a corresponding WG.

[cwilso]

It is true there is no requirement for CGs to have consistent process (or be consensus-driven, which is why you can have multiple CGs that cover the same scope). They can have any decision-making process they want, but are required to be fair (https://www.w3.org/community/about/agreements/: "They must be fair and must not unreasonably favor or discriminate against any group participant or their employer."). CGs, in fact, don't even need a charter; just a short scope statement. (They are governed by a process - that latter link - just not by the W3C Process Document that covers everything but CGs and BGs.)

My point was that in declaring so much process, including a decision-making policy that is not really compatible with consensus as defined by the W3C Process for WGs, you will make the transition to standards track more fraught. (Because it is a transition to a different definition of consensus.)

[hober]

It's unclear to me why there's so much process defined here for a CG.

The Community and Business Group Process is minimal, and provides maximum flexibility to CGs to define their own process. As a result, there are a number of CGs which operate quite differently from each other. This is a good thing! CGs are an environment in which we can experiment, as a community, with possible process tweaks.

In this case, the Privacy CG's process is extremely closely modeled on that of the WHATWG. We received feedback while developing the charter that modeling the process on the WHATWG was desirable.

If you want to define this kind of process, we should really be editing the Process docs in the Process CG, so that it is consistent across CGs.

I think that would be premature. Let's find out if a WHATWG-style process can work well for a CG, by trying it here. If it works, we can take some of our learnings to the Process CG.

There are some oddities exposed here, otherwise - for example, Chairs in this privacy CG can decide to remove deliverables unilaterally, something that Chairs in a WG typically cannot do.

In #5 I've attempted to clarify this in 5d4b6fe.

[cwilso]

I would contest "the Privacy CG's process is extremely closely modeled on that of the WHATWG." The CG points to the SG definition of "qualifying entity", expands quite a bit from there, since the WHATWG policy doesn't clearly define "implementer", just "qualifying entity [for steering group membership", doesn't strictly follow its own definition today, and doesn't have all the subtlety of the expansion in non-core-engine features (which is where most of my disagreement lies, more on that soon).

Also, on "We received feedback while developing the charter that modeling the process on the WHATWG was desirable" - was this feedback at all in public? Because we kept asking to see a draft charter (e.g. in https://github.com/w3c/ping/blob/master/summaries/PING-minutes-20191205.md), but never got a response, or got to give feedback.

[othermaciej]

Since WHATWG Policy has been referenced...

In the WHATWG, "implementer" is an undefined term used in Working Mode as part of the rules for changes and feature additions. It's historically been interpreted as referring to independently developed mainstream browser engines. The definition of "qualifying entity" in the SG Agreement was reverse-engineered from this de facto usage and a desire to formalize it.

If the lack of crisp definition for "implementer" in WHATWG is a problem in practice, we can consider formalizing it. Just file an issue at https://github.com/whatwg/sg.

[cwilso]

As this has morphed into process/"implementer", I split the other half of this into a separate issue: #8.

[cwilso]

Also, for the record - I'm not particularly worried about the WHATWG's lack of crisp definition of "implementer", nor in the use of it as a requirement for final standardization. I do think as the number of qualifying entities goes down, it will become more problematic, and I think it's problematic to require that in order to propose an incubation.

[othermaciej]

There's already places to work on items that only have the support of only zero or one implementors, ranging from personal repos to WICG. Not clear why this has to be another.

Privacy CG seems more useful as a focused place for things that have support from multiple implementers and which have or are likely to have multiple implementations. Something like that is required at some stage of the standards process for every SDO relevant to web standards. That way, this CG can become more of a fast track to the standards process, like Web Assembly CG for example.

[cwilso]

First, I'm not arguing this should be a place to work on items that have no support. However, I'd point out that clearly the goal here is to bring together a focused community of privacy advocates from browsers, engines, user advocates, and more. That's a great thing. (And quite different from WICG, which is not particularly a focused discussion group at all - we do not hold teleconferences or the like.)

Throwing up a barrier to entry of "we will not consider incubating anything that doesn't show up with two engine implementers" is radically different than "can we focus the group's attention on proposals and incubations that have multi-vendor support".

I'd also strongly disagree that with a consensus model explicitly defined as different from the W3C WG model this will be a "fast track to the standards process". Web Assembly CG shares a Chair with the Web Assembly WG, and explicitly defines its decision model to be consensus - similar to the WG process, though of course may have a different set of constituents. (This is how we operate the Immersive Web CG/WG pairing, as well - tightly connected chairing, same consensus model and similar sets of constituents.)

[hober]

I think it's problematic to require [multi-implementer support] in order to propose an incubation.

Multi-implementer support isn't required to propose an incubation, though that's not explicitly spelled out in the current charter. The risk of this kind of confusion is precisely why I filed #2 a few days ago. See 0d58d27 (part of PR #5) for a proposal to clearly state this in the charter. (Your review of and comments on that PR would be greatly appreciated.)

[hober]

@cwilso, I believe this has been addressed in 32bd9e8. If we missed something, please let us know.

[cwilso]

I think this is resolved.