Spec organizations and prioritization

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.

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 10:49:23 UTC