RE: [CSSWG] Minutes and Resolutions Telecon 201-08-17

So where do we sit on this topic?  Do we focus on moving the module forward to CR or find some way to move individual features to CR instead?

-Brian

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Sylvain Galineau
Sent: Friday, August 19, 2011 3:59 PM
To: fantasai; www-style@w3.org
Subject: RE: [CSSWG] Minutes and Resolutions Telecon 201-08-17


[fantasai:]
> 
> On 08/19/2011 12:24 PM, Sylvain Galineau wrote:
> >>
> >> CR is not the final stage in the process, REC is. The intention of CR
> >> is to allow time for implementations and to reflect the feedback of
> >> that experience into the spec.
> >
> > Since reflecting the feedback from implementation into the spec takes
> > the spec back to WD it seems a singularly contradictory goal for a
> > step that also aims to exit towards REC. I would maximize the odds of
> > exiting CR successfully and on time by entering it *once* based on
> > actual implementation experience already factored into the spec. As
> > opposed to a mix of very real and entirely theoretical features.
> > (Crazy talk, I guess)
> 
> The fact that integrating implementation feedback into a CR is impossible
> without going to WD is imho a serious brokenness in the W3C Process. :( We
> have a PER phase for REC, but not a PECR for CR. This is the why we keep
> bouncing mostly-stable specs to LC for minor fixups. :/

It wouldn't be broken and a lot clearer imo to bounce between a Call To Implementation
phase and draft; or better, stay in Call To Implementation until such time as enough
is covered by implementation experience to move it to CR. CR would just be the test 
suite stage and really be a 'candidate REC' formality as opposed to bunch of conflicted 
things.

> 
> But I would rather work around that brokenness (and lobby W3C to fix their
> process) than distort the meaning of the WD and CR phases, which I think
> are fairly well thought out.

Sure, they are well thought out, hence our arguing on the brokenness around them :)
At the very least, this is one of those things that is just unclear and confusing.
(Like everyone attaching a meaning to CSS3 that has nothing to do with what it is).

> 
> >> The intention of the at-risk list is to allow the CR to drop features
> >> that do not garner implementations so that the rest of the spec can
> >> make progress.
> >
> > But I thought CR was a call to implementation ?
> 
> Right. But sometimes the call is not answered. :)
> 
> > Do the words 'at risk' typically motivate implementors to commit their
> > resources to a feature ?
> 
> Depends on how valuable the implementors think the feature is. If it's
> very valuable, they might consider making sure it gets implemented. 

If it's very valuable, why does it end up at risk in CR? At the least, it
wouldn't seem to be a common scenario.

>If it's not, then the presence of the feature on the at-risk list would
> indicate that it's not worth bothering with for completeness, since
> there's a good chance it'll be dropped.

Precisely.

> 
> If all the relevant implementers were active participants in the CSSWG,
> then there wouldn't be a need to put things in CR before we could find out
> whether they would get implementations: we could just ask our members.
> But it so happens that there are implementers who are not in the CSSWG.

And these implementers are less likely to be deterred by the feature being
'at risk' than others? If this qualifier signals that the feature is 'not
worth bothering with for completeness' I'd think that would turn off any 
implementer.

> So we need to be open to their participation in the call for
> implementations.
> The process provides for that participation via publishing a CR. And it
> allows us to reduce the risk of having things hold us back by giving the
> CR an at-risk list, which allows us to drop features if they don't get
> implemented or if we find out, from the implementation experience, that
> they really need to go back to a WD and get rehashed. So nobody's losing
> anything here, afaict.

It's not clear anything is 'won' either. As far as image() bidi addressing i18n
WG feedback, I'm unclear on the following:
- Either they don't mind their feedback to be addressed through at-risk features.
That would point out to a clear lack of urgency and suggest the resolution of the
feedback can wait for the next level.
- But if the i18n WG would object to bidi being dropped then the feature can't be
at-risk. 

Either way, I'm afraid I won't make much sense of the request and its resolution.


> 
> ~fantasai
>

Received on Monday, 22 August 2011 19:13:31 UTC