Re: Spec organizations and prioritization

On 3/20/2012 6:48 AM, Dominique Hazael-Massieux wrote:
> Hi,
>
> As a follow-up to my message yesterday:
> http://lists.w3.org/Archives/Public/public-w3process/2012Mar/0051.html
> (and based on a message I have just sent to one of my WG:
> http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0075.html )
>
> Summary of my reasoning below:
> * specs should be organized around bundle of features that get shipped
> roughly simultaneously
> * specs that describe features that will get shipped earlier should get
> priority handling in WG over other specs
>
>
> The W3C Patent Policy only protects specs once they have reached the
> final stage of the standardization process (Recommendation status).
>
> It implies that to protect as well as possible implementers and users of
> the technologies we develop, we need to bring our specs to
> Recommendation status as fast as possible (without compromising their
> quality obviously).
>
> Given that the overall duration of standardizing a spec is completely
> determined by the time required to get the least implemented/tested
> feature to be implemented and tested, we should organize our specs so
> that all the features they bundle have roughly the same schedule impact
> on implementation and testing.
>
> Now, an important piece is that most specs don't live in isolation, but
> have dependency to other specs. But the real important dependency is not
> the formal normative dependency that are created among specs, but rather
> the one that is driven by implementations. In other words, what matters
> is what will get shipped by most implementations simultaneously.
>
> In my mail to the WebRTC linked above, I take a concrete example with
> the API to access camera; taking another example; the right size of a
> CSS module shouldn't be a module that binds related features, but rather
> features that are going to be deployed (or have been deployed) in
> browsers simultaneously.
>
> Now, it's not always possible to know what implementations will do, but
> in many cases it is; some implementors will be reluctant to state they
> will implement this or that, but might be more amenable to identify
> features that they want to see developed in priority.

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.

I may be misinformed, but my impression is that what you are requesting 
is precisely what we are trying to achieve with CSS 3.

CSS 2.1 was a monolith and took years to complete.  For CSS 3, the team 
architected the work by describing 50 modules that could proceed to REC 
independently.  Isn't that the same as identifying a set of features 
that are being worked on simultaneously?  Doesn't that provide the lever 
required to move independently based on what is being implemented.

To be sure, we might not have selected the precise correct 
modularization nor implementing it perfectly.  But is seems to address 
this requirement.

I believe that WebApps also has much of this independence - although 
perhaps less rigorously.

It would be interesting to see whether in HTML 5.1 we could get HTML to 
a similar description.

>
> Some features require a long time to design/implement, others much less
> so.
>
> The specs that should get priority attention in Working Groups are the
> ones that will be implemented interoperably the fastest. This evaluation
> needs to take into account both the complexity of the spec, and the
> roadmap from implementors (often correlated aspects).
>
> This takes into account the dependency considerations above: logically,
> the features that will be deployed the most quickly are the ones for
> which all the dependencies (in the sense above) will be deployed the
> most quickly (if they haven't been yet).
>
> By the "attention of the Working Group", I mean that action items for
> the said spec(s) should get priority over the other; reviews of these
> specs should be sought for before the others; testing efforts should
> start earlier than for the others.
>
> Now in most groups, there are times where a spec doesn't need the whole
> group attention, and it's perfectly reasonably that in these low times,
> other specs get the focus; but as soon as a priority spec needs the
> group's attention again, it should take priority over the other work.
> This can be organized non-disruptively if the group is warned well in
> advance (which I think in most cases is easy).
>
> Dom
>
>
>

Received on Tuesday, 20 March 2012 15:42:06 UTC