Evaluating policies; pubrules

W3C is operating under a number of policies with various status and
changeability.

I haven't gone through all our policies, although in my previous
messages I've already identified policies that could use to be revised
(e.g. the normative dependency requirement, the determination of
substantive changes).

I think our point of reference for evaluating policies should be whether
they help or not to achieve our goal (getting features deployed
interoperably on a RF basis).

A lot of them would probably need a big refresh under that light; I
think we should try to identify which would allow the biggest gain in
time in our day to day operations, and focus on those first.

I think our publication process is a likely candidate (but that's a
hunch, not at all a given). Each publication request can easily induce a
week of delay (combining the transition requests, the two-days-per-week
window of publication, and the need to make a document pubrules
compliant). For a spec that goes through 10 updates, that's 10 weeks of
delay, so 2.5 month; not huge on the overall duration of our processes,
but not negligible either. Also, it creates a psychological barrier to
publication which likely has a bigger impact still.

For all intent and purposes, pubrules is about packaging our
specification. Packaging has a role in getting our specs implemented,
and thus the features they describe:
* W3C is (somewhat) trusted as a source of features
* a given status indicator brings a given faith in the stability of the
spec
* the PP boilerplate helps enforcing the patent policy

But it feels like the cost of enforcing all of pubrules uniformly is
disproportionate with that benefits; for instance, it's not clear that
having all internal anchors checked at FPWD is such a big win.

A more productive way to ensure the packaging quality of our spec would
be to provide tools of continuous improvement (e.g. check-on-commit,
alert on regression, etc). A number of requirements that are
"nice-to-have" but have low impact on implementations should move toward
parts of the process where the work can be done without impacting the
overall schedule of the work.

Dom

Received on Tuesday, 20 March 2012 14:44:27 UTC