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

Cutting to the chase:
> I hope to get a chance to talk with you during / around the upcoming F2F
in Seattle about that.

Yes, let's do that.

On Thu, Jan 5, 2017 at 9:20 PM, Florian Rivoal <florian@rivoal.net> wrote:

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