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

> On Jan 8, 2017, at 13:02, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> On 01/06/2017 12:20 AM, Florian Rivoal 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.
>> 
>> 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
> 
> This is everything that hasn't been updated lately and isn't #3. :)

I don't think there's too much of a problem for a WG's code members to identify which is which, but for newbies or occasional participants, it might be trickier.

It gets fuzzier if you consider the technology as a whole, rather than the spec alone.

Judging by the spec alone, for a while until you and Tab started working on it, it looked like snap-points was at least in category 2, maybe on its way to 3. Then it started shipping.

Or to take another example, where would you say nav-up/nav-down/nav-left/nav-right are? It's in CR, so 1? no recent update so 2? Shipping in TVs so 1? Blink recently passed on shipping it due to concerns that this was designed the wrong way, so 3?

Also, although it sort of looks the same, I think there's a difference between a spec being somewhere down the todo list of an overbooked editor, and being on nobody's todo list.

I suspect that trying to flag things (and revise the flag periodically) would be informative to outsiders, better synchronize with implementers, and help distinguish editorial resources bottleneck from lack of interest.

>> 3 - things that are now recognized by most as failed experiments
> 
> As I've mentioned already, the CSSWG's drafts were all audited last year and are marked as such (or should be if the action items to publish were followed through--I think they were, though I didn't personally check).

Yes, we did. I just suggest to make this a bit more systematic, so that we make sure to do it periodically, and also take this opportunity to flag (separately) stalled good ideas.

>>> 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.
> 
> I haven't seen this problem in the CSSWG. If it's considered a failure, we aren't afraid to admit it. See above.

Agreed. My suggestion is not about a big change from this: just make sure we do it periodically, and that we use a W3C-wide recognizable way of retiring things from TR. Maybe what we do is already it.

>> 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.
> 
> We already have a policy that allows for exceptions to CR *if* it has the broad consensus of the CSSWG that it's appropriate to do so. I think this is much better than a policy that merely requires a vendor to make some kind of unilateral announcement based on whatever they feel like, without any attempt to get either feedback or consensus.

I am not suggesting that browsers merely notify us unilateraly that they are about to ship something, which is sort of what happens now when they let us know *at the end* of their "intent to ship" process. Rather, I'd like them to notify us that they are *considering* shipping something. The blink intent to ship process includes a mandatory step about evaluating whether shipping the feature would lead to compat / interop / standardization / future evolution difficulties. The CSSWG should be in the loop when that happens. This would be a way to trigger the discussion (which our documented practices allow for but rarely happens) in the WG about whether it is appropriate.

If the WG decides against shipping, hopefully we'll have reasons, and a reasonable vendor may follow our recommendation and invest in plugging the gaps in the spec first. If the vendor disagrees with the reasons, they are of course able to just ignore the WG and ship anyway, but that's the case under any possible process, since the W3C does not have authority over vendors.

Making it a systematic practice for vendors to get in touch with the WG when they are considering implementing or shipping something would help with prioritization, status flagging (see above), and avoiding accidental shipping of stuff that's not ready.

—Florian

Received on Tuesday, 10 January 2017 04:39:39 UTC