Re: Spec organizations and prioritization

On 3/22/2012 8:51 AM, Marcos Caceres wrote:
>
>
> On Thursday, 22 March 2012 at 12:23, Jeff Jaffe wrote:
>
>> [adding Daniel Glazman]
>>
>> On 3/22/2012 6:27 AM, Anne van Kesteren wrote:
>>> On Tue, 20 Mar 2012 16:41:50 +0100, Jeff Jaffe<jeff@w3.org (mailto:jeff@w3.org)>  wrote:
>>>> As a strawman, I would propose that to achieve your goal we need zero
>>>> changes to the W3C process. Rather we need changes to a practices
>>>> and culture, through a single characteristic - modularization.
>>>
>>>
>>>
>>> To me it sounds like you are trying to actually create more process
>>> with respect to how specifications are designed.
>>
>>
>>
>> I don't understand what more process you think I am creating. In
>> particular, my suggestion adds zero rules.
> I agree with Anne here. You are assuming that modularisation solves the problem in the way CSS is doing it. It is also possible to "modularise" sections of a spec for stability (as the WHATWG  HTML spec does), without making separate specs.

Much of what I would have said has have already appeared elsewhere on 
the thread: notably by Dom and others.  A few other comments.

It is true that I was describing advantages in the CSS approach.  It is 
not true that I was disagreeing with the approach of the WHATWG HTML spec.


>   Some specs, like HTML5, make sense as a monolithic spec: breaking it up into lots of "modules" would just be "make work".

There are tradeoffs between being broken up and being monolithic.  I was 
not advocating anything as a universal solution.  I do believe, however, 
that there could be more modularity for the HTML spec.  As pointed out 
elsewhere on the thread, that actually has already resulted in parts 
being separated.

>
> As a point of comparison: look at the interop in HTML5 feature sets and the size of the HTML5 spec relative to other "modules" and that might give you an indication of speed and progress… HTML5, for its size and scope, has move at a pretty amazing speed by anyone's measure (and retained extremely high quality).

I don't doubt that HTML5 has moved at a pretty amazing speed.  I'm 
gratified that we are targeting 2014 for REC (although I worry about 
what will happen with a second last call).

We have to be careful about generalizing the conclusion.  One thing that 
has helped with HTML5 is that we have a single prolific editor who has 
his head around the entire spec despite its size.  That would not 
necessarily be reproducible for all specs.

It is also the case that despite outstanding work on HTML 5, Hixie often 
reminds me that on some measures we are actually well behind where we 
should be.  The last version of HTML to reach REC got there years ago.  
I think we all agree that we need to get successive versions of HTML to 
REC faster.  For HTML 5 we are using time boxing to force ourselves to 
get there.  There are other proposals on the table - such as annual 
snapshots - each of which have their own pluses and minuses.

It was pointed out elsewhere on the thread that although the community 
has made amazing progress with HTML 5, we are still criticized on some 
interoperability issues - since features are advancing at different 
speeds within different products.

>>> Enforcing more rules on limited resources is a sure way to make them
>>> go away. (Unless you lead by example and demonstrate the effectiveness,
>>
>> I was suggesting that the CSS group was providing the example. Surely
>> you don't want me to create a new group just for the purpose of setting
>> an example.
> I don't know if they are or not. Work in CSS still progresses at generally normal pace (standardisation takes around 5 years on average, no?). W3C actually has all that data (how long from it takes from FPWD to Rec… would be good to get proper stats about how long on average the process takes and compare across groups).
>
>

Received on Thursday, 22 March 2012 18:52:42 UTC