Reconsider incubation

[jwrosewell]

As referenced in August advisory committee discussion the word incubation implies that the incubator desires the proposal to eventually “live”. It has been used interchangeably with experimentation which has an important and different meaning.

The process of incubation within the W3C context implies that further nurturing, consideration and refinement are required. Such incubation should be available for proposals that expressly aim to fulfil the goals of the W3C and are otherwise legitimate.

Continued discussion and revision of proposals risks conveying the implication that the proposals may, over time, be capable of refinement to become the basis for acceptable and legitimate standards.

The process of “incubation” thus risks conferring legitimacy on the proposer for illegitimate and unacceptable proposals if no action is taken and any proposal can be considered for incubation.

Where the proposal in “incubation” is not competitively neutral, or would favour one company or sector over another, there is a risk that the incubation groups fall foul of the competition law rules.

[TzviyaSiegman]

This is an AB priority this year. See notes on the discussion, More to come.

Some points I plan to add are:

• proposal for incubation template
• phases of incubation maturity
• incubation graduation
• what gets incubated

[frivoal]

If I understand correctly, you are asking for two things:

1. call incubation something else, to avoid suggesting that we necessarily want the proposal to live
2. put a non-zero set of requirement before incubation is allowed to begin, to avoid conferring legitimacy to things that may be problematic

First, it is a little difficult to ask for a change to the Process to stop calling it incubation, since the Process doesn't call it incubation (the word does not appear in the document), and that is merely the way people talk about that phase. Prescriptive linguistics is out of scope for this CG. A request to the AB / Team / AC to please use different words can be made, but this is not the place for it.

Furthermore, It seems to me that both requests stem from a misunderstanding.

The practice of incubation (there is no defined process of incubation) is merely the idea to take work to the point where formal standardization is likely to be viable and successful. Over the years, we have developed a culture of working in the open as much as possible, requesting feedback from others as much as possible, and evaluating both the technical merits and the community support of proposals before starting official standardization, and that is usually what is referred to when talking about incubation.

As @TzviyaSiegman, said we could, and intent to, better document what these best practices are.

But we as a community are not trying to incubate everybody's ideas, i.e. make sure they live. In fact, this is pretty much close to the opposite: we as a community ask proposers of new ideas that if they would like to get their ideas standardized, they, as the proposer of the idea, should incubate them to the point where it's clear to everyone else that the idea has a chance of being viable, both from a technological and from a community support standpoint. The reason we ask for that is precisely because we don't expect all ideas to be viable, and want to limit the cases where we accidentally start standardizing something that ultimately fails.

As you point out, "incubation" implies a desire that the proposal eventually lives, but that desire resides in the person making the proposal.

Beyond that, what the rest of the community provides is guidance based in shared accumulated experience of what is most likely to work, and various forums with various degree of formalism to let people give exposure to their ideas and recieve feedback on them, so that they can attempt to incubate their idea, i.e. get it to the point where it's clear enough that they have a good chance of success that we can start standardization.

Based on that, asking for incubation to start later is inherently a self-contradiction. This would be equivalent to something like "Please to not attempt to establish that your proposal is worth standardizing until it is sufficiently clear that it is worth standardizing", "Please stop trying to find supporters for your proposal until it has more supporters", or "Please stop refining your proposal until it is more refined". A proposal cannot mature until a certain stage unless someone works on it, and that's what incubation is.

Now, you may very well think that the way certain venues attempt to support people's incubation efforts are misguided. I gather you have issues with WICG and its https://discourse.wicg.io/ . You are perfectly welcome to take that feedback to WICG itself, or to take your technological proposals to a different venue, or to start a different venue if you think you have a better way to guide people. But WICG has no particular legitimacy in the eyes of the Process, and so requests to this CG that the Process be changed because you don't like the way WICG operates are out of scope.

I will note that some (but certainly not all) working groups have indicated in their charters that they prefer WICG as the place to incubate new ideas. If you think that preference is misguided, the right place to raise that concern is during the development and review of charters that do state that preference.

[TzviyaSiegman]

I don't think that best practices belong in the Process document. I would prefer to document the items I listed above in /Guide as best practices. Part of what has worked well with incubation, when it has worked well, is its flexibility.

[frivoal]

As @TzviyaSiegman, said we could, and intent to, better document what these best practices are.

I don't think that best practices belong in the Process document. I would prefer to document the items I listed above in /Guide as best practices

Sorry, I wasn't clear. Yes, that's what I meant. "we" as a community, can and should work on guidelines. "we" as a community group, have nothing to do about this, ecause the process is not the place for guidelines.

[dwsinger]

I am also unclear as to what you want. Before we adopted practices around incubation, it happened either:

• as explorations in working groups, which can be distracting from the deliverables
• or in work fully outside the W3C (e.g. by individual members exploring ideas, or at other venues)

We offer CGs as a third alternative, to make new ideas and incubation more visible to the community overall. Perhaps there is a better word, but I think that at least the people who 'lay the egg' are hoping that it will eventually hatch into some sort of standard, and so (for me) it has a reasonable set of overtones. But if you have better ideas, please propose away.

Whether bringing things to incubation brings legitimacy or status seems a question more about being clear about status, as I commented on #480 .

What exactly would you like changed in the process document?

[cwilso]

To be more explicit, prior to the concept of incubation in CGs, incubation either happened

• in Working Groups, where typically there was VERY STRONG impetus for the incubation to "not fail"
• outside the W3C, typically in "smoke-filled back rooms". (well, not really, but it was not an open offer of collaboration; it tended to be invitation-only discussions.)

The concept of incubation in CGs was designed to address both these problems - but more than anything (if you go look at notes from TPAC conversations on incubations, I repeatedly stressed this point), the point was that incubations in CG CAN fail, and indeed we wanted the price of that failure to be lower, while still encouraging broad participation in those early explorations.

I do not agree that incubation implies survival, and the references pointed to by OP only re-reference his personal interpretation that incubation predestines success. Of course the point of incubation is to test if there is something there that COULD survive, but in fact the whole point of this process was to 1) make the cost of it failing much, much less (compared to a WG issuing a Recommendation of something that turns out to be a mistake), while 2) ensuring that such explorations enable and encourage input and involvement from others.

Any attempt to deny the concept of incubating proposals will IMO, regress our process by either putting early ideas into WGs' purview (thus leading to much higher cost for failures) or hiding the exploration process behind closed doors (making the development of the web less open to all).

[mnot]

FWIW I agree with @dwsinger that #480 should largely address this. People draft specifications all of the time, the issue comes about when they're prematurely assumed to have consensus by people who don't understand the process. And @cwilso is absolutely on point - it's better that proposals get sunshine early rather than after they're fully developed (this is an explicit goal of competition law's approach to standards in many jurisdictions, FWIW).

[LJWatson]

@cwilso wrote:

To be more explicit, prior to the concept of incubation in CGs, incubation either happened:

• in Working Groups, where typically there was VERY STRONG impetus for the incubation to "not fail"
• outside the W3C, typically in "smoke-filled back rooms". (well, not really, but it was not an open offer of collaboration; it tended to be invitation-only discussions.)

An indirect effect of this last point is that it was almost impossible to know what was being incubated, and that made it much harder for people to be able to review and comment on the ideas being put forward - especially for smaller organisations that had an active interest but few people with the time to spend hunting the web for the places where ideas were being discussed.

It is now much easier to follow ideas and discussions because they're happening in one place - and the fact that place is a CG further democratises the process because anyone can offer a perspective whether they are a W3C member or not.

[jwrosewell]

Thank you for the comments and information. This can be closed at this time as I agree 474, 475, 476, 477, 478 & 480 cover the core issue.