What kind of Group is for what kind of work? about w3process

[michaelchampion]

I agree it's time for the Process to explicitly discuss CGs / BGs, and clarify their relationship to IGs and WGs. Some thoughts off the top of my head:

• Let's preserve the fundamental difference between CG and WG patent policies: CGs require RF patent commitments on one's own contributions, WGs require RF patent commitments on the consensus outcome of the group.
• I'm unconvinced that BGs have any reason to exist at this point. Use cases for a "CG with Team support" could be covered by an IG open to non-member participation AFAICT.
• I'd like to see CGs explicitly mentioned in the Process: CG's start with a Problem; WG's start with a rough outline of a solution to that problem. Likewise the Process should point to CGs as the appropriate mechanism to "incubate" specs: Build a community of people with a shared challenge who develop a technology to address it and a spec for it's interoperability features (API, protocol, format ...) to the "proof of concept" stage where there is a critical mass of users and implementers who agree it's ready to standardize.
• CGs MUST abide by the CoC/CEPC and work by some sort of defined consensus-seeking process (although not necessarily all the constraints and details defined in the Process Document). For example, CGs have no ability to appeal to the Team or a FO Council if they can't get consensus. CGs can be test beds for process innovations (WHATWG-style strong editors, chairs empowered to make decisions even in the face of dissent, various voting mechanisms, whatever) ... but within the broad constraint of having a defined consensus-seeking process.
• IGs can continue more or less as presently defined to focus on understanding a problem, doing "gap analysis" to document current standards' lack of ability to address a problem, and to build a community. IGs should not incubate solutions (their patent policy doesn't support that). But successful IGs shouldn't immediately charter a WG to find a solution, they should spin off one or more CGs to incubate solutions, and propose WG only when they have reached a level of maturity.
• The model of parallel CGs for incubation and WGs for standardization can work well, and the Process should mention that (and perhaps offer best practice guidance derived from experience with groups such as Web Assembly that succeed with it).
• It should be HARD to charter a WG, that is a feature not a bug. If competing CGs, or different factions in a CG, have very different visions for how to address a problem or disagree on fundamental aspects of a solution, W3C should not create a WG to sort it all out. The competing communities need to find common ground -- or the marketplace pick a winner -- before W3C creates a WG. The WG process is too heavyweight and burdensome on the AC and FO Councils to use to pick fundamental technical directions.