What kind of Group is for what kind of work?

[frivoal]

What kind of Group is for what kind of work? If you want to deliver REC track or Registry track documents, you need a Working Group.

Beyond, that, things are pretty fuzzy. There are a bunch of differences between WGs, IGs, CGs, and BGs, but it's not clear to me that they really tell us which kind of group is suitable for which purpose.

In response to a recent AC review for a charter, a member felt "This IG should instead be a CG" about a proposed group. It's not clear to me that the Process contains much to either to support or refute that claim.

Here are some questions I'm not sure we have an answer to:

• When a group's sole output is reviews of what others do, should it be a WG? an IG? a CG? (See also Tighten the Scope for definition of Working Groups #414)
• When a group's sole output is Notes, should it be a WG or an IG? Also the only real rule about Notes is that they need the consensus of the group that published them. Nothing stands in the way of CGs doing that too, even if they cannot technically call such documents Notes. But only WGs and IGs can elevate such documents to Statements.
• IGs can be chartered to have open public participation. When is it preferable to have one of these over a CG, or the other way around.

Here are some other assorted differences:

• WGs have strong patent coverage. CGs have some patent coverage. IGs have none.
• WGs and IGs are subject to the Process, and therefore to Formal Objections, the Council, and so on. CGs have their own separte (lightweight) process, which doesn't include those concepts.
• WGs and IGs need an AC-Approved charter, CGs do not (they can have a charter, but don't need to, and if they do have one, it doesn't need AC approval).
• You need to be a Member (or an Invited Expert) to be part of a WG (though that's not needed to submit feedback). The same is true for some IGs, though other IGs can be open to anyone. Anyone can join a CG.
• CG may—but do not need to—use consensus as the basis of decision making. WGs and IGs have to.
• I could not find a requirement to abide by the CEPC in the texts people need to agree to in order to join a CG. (This surprised me. Hopefully I just missed it)
• I could not find a description of disciplinary procedures for CGs. (This surprised me. Hopefully I just missed it)
• Both CGs and IGs/WGs have requirements about archival, but those requirement are not identical.

Oh, and we have Business Groups too. I suspect the goal for those is somewhat clearer, but then again maybe not, and there could be some interesting overlap with IGs in some cases.

I think we should spend some time thinking about:

• Do all these types of groups serve distinct purposes? Should we combine some?
• Are the differences between these types of groups serving those distinct purposes, or are some of them accidental/historical? Should we harmonize more?
• Would incorporating CGs and BGs into the process, as asked in Community and Business Groups #326 or Community Groups and Business Groups should be incorporated into the Process #409 help harmonize them with WGs and IGs, or would that make the unified Process needlessly complex?
• When some goals can be fulfilled by multiple types of groups, should people be free to pick whichever type they prefer? Should we require things like "Don't charter a WG if an IG could do it" / "Don't charter an IG if a CG could do it"?

[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.