Re: Can we get consensus on what incubation means (was: Re: WICG Incubation vs CSSWG Process)

> On Jan 4, 2017, at 06:14, Chris Wilson <cwilso@google.com> wrote:


>  • However, there's a key feature that is missing there, that I went into at some length at TPAC - incubation has to enable graceful failure.  By that, I mean that ideas that are being incubation don't have a timeframe for completion, nor is there any penalty if an idea goes back on the shelf (or dies completely) - and in particular, it's clear when that happens.  For example, the CSS WG charter has a large number (29, I think) of features that are "Exploring".  The CSS WG *has* been incubating ideas for about 20 years (although for the first couple of years, to be frank, we were just slamming most of the ideas straight into the specs, since there was a lot of blank ground) - but the scale has gotten a bit out of hand, and yes, the explicit "incubation" is partly about getting more externals involved.

I think it would help to have a more explicit way of distinguishing within the "exploring" part things that:
1 - are under active development with broad participation
2 - look like reasonably good ideas to everyone, but lack momentum and are unlikely to progress without more active participation
3 - things that are now recognized by most as failed experiments

Core participants in a WG are probably able to tell which is which, but making it explicit would improve legibility to the rest of the world.

In particular, identifying things as being in the 3rd category the issue raised by Mike Champion:

> Once a spec is published by a WG as an official working draft, it takes on a life of its own – the team will expect it to progress, chairs/editors will feel responsible for advancing it and resolving issues, so it is hard to admit failure.

Identifying things as being in the second category may help guard against prevent tragedies of commons,

>  • As for the commentary on scroll-anchoring, et al - yeah, there are always rough edges, and vendors will not always follow your best practices on future proofing, when there are critical user functions to address.  However, I will call your attention to Rick Byers' explicit comment in that issue: "The actual API surface area is tiny and rarely needed, so I'm optimistic we can continue to incubate, including making breaking changes if it becomes necessary to get interop in the future."  (Underline is mine.)  If we ship features before REC, we are responsible for maintaining.

I think this is a good example of something that is a historical artifact of how the CSSWG works, rather than an essential feature, and one we could (and therefore should) probably easily fix.

The current CSSWG policy of "allowing" things to go in productions only once the spec reaches CR is in my view merely a blunt attempt at doing what the "Interoperability and Compatibility Risk" part of Blink's intent to ship aims to do.

Changing that WG policy to either the spec being in CR *or* sending the WG an intent to ship (preceded by an intent to implement?) with an assessment of Interoperability and Compatibility Risk would seem like a good idea to me.


>  • I'm not sure where the assertion that this [early/"premature"/"sans REC"/"unstable" feature shipping] doesn't happen was made; I certainly wouldn't have said it.  It will happen.  It has always happened.  This needs to be managed, and minimized as possible, but I don't believe it can be avoided - and so I want to make sure we clearly define it, and make sure implementers understand their responsibilities.

I agree. Here as well, I think the current CSSWG policy is an blunt and improvable attempt at that. I think we will stand a better chance of clarifying what the guideline that we expect to be followed is, as well as what we expect from implementers when they chose to go against it if we document it in one place an mostly stick to it, rather than by multiplying venues.


> In short, two points:
>  • Incubation doesn't have to mean the WICG.  I feel like I've said this in every conversation about WICG since it was created, but maybe I missed one or two.

I have indeed heard this statement multiple times. At the same time, as far as I understand, Google has taken the stance that it would conduct all its incubation in the WICG, been in favor for adding mandatory out-of-the-WG incubation to the webplatform WG, and rencently (which is in part what triggered this whole thread and our tense discussion at last TPAC) attempted to impose to others that they did their incubation out of the CSSWG and in WICG.

> If you want to take this spirit into the CSS WG and do everything under that umbrella, then I'd ask you consider what we're really trying to solve for with incubation (graceful failure, clear stability indicators, open participation with clear IP commitments), and figure out how to achieve the same aims in whatever forum you want.

Thanks, that's very helpful. I think this kind of actionable feedback from you (or people with a similar position with regards to incubation) about what needs work in a particular WG before you consider it an appropriate venue for incubation will help progress.

I think that in the particular case of the CSSWG, the gap between the current practice and what I now understand to be your expectations isn't actually that hard to bridge. I hope to get a chance to talk with you during / around the upcoming F2F in Seattle about that.

—Florian

Received on Friday, 6 January 2017 05:21:28 UTC