Re: Spec organizations and prioritization

On Thu, 22 Mar 2012 13:51:37 +0100, Marcos Caceres <w3c@marcosc.com> 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. Some specs, like HTML5, make sense as a  
> monolithic spec: breaking it up into lots of "modules" would just be  
> "make work".
>

+1 for "modularized" sections inside big specifications.
If we put the RF discussion aside for a second and look at the issue of  
other organizations referencing W3C specs,
the problem so far has not been that specs were not in CR but that wasn't  
clear what (inside the spec) was stable and ready for implementation and  
what it was still under discussion and very unstable.

I guess that to achieve this we don't need any change to the process  
though, just some editorial guidelines similar to what the already cited  
WHATWG HTML specs does.

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

As mentioned the speed of a spec is probably also proportional to the  
interest/hurry people have to implement it. There is no point in pushing  
out a spec quickly if nobody is going to implement it and , even worst, if  
when implementing it it will need heavy changes that basically make that  
spec obsolete.

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

+1



-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Thursday, 22 March 2012 13:17:52 UTC