Re: Process issues

Le mardi 29 novembre 2011 à 14:05 +0100, Scheppe, Kai-Dietrich a écrit :
> Scope of a spec
> Are specs too large because they try to be all encompassing, thereby creating unwanted size?

My understanding of why "specs are too large" has been raised as an
issue is that:
1. large specs are harder to review than modularized spec where the work
of splitting orthogonal requirements make it easier to focus on one
aspect, and get it reviewed by the right people

2. large specs are harder to get through the TR process — proving that
1000 features are implemented twice independently at the same time is
much more difficult than getting 100 batches of 10 features

I've heard that large specs make it easier for editors to deal with
dependencies, definitions, etc; and there is very little doubt that
modularizing a technology is no trivial amount of work, and can
introduce subtle bugs that are harder to spot.

I don't think addressing that issue should be done by proposing how big
a spec should be. Moving away from large specs is mostly achieved by
someone putting in the work to split large specs in consistent modules;
this has happened a number of times already (canvas, web rtc, web
workers, web sockets, etc).

We could look at a process that would solve (or reduce) problem #2
above: there could be a way for sections of a document to progress at
different paces in the Rec track — in effect, moving the modularization
from the document to the process. But it's not clear to me that this
would be better than actually getting the right editorship resources to
help with producing more modular specs.


Received on Tuesday, 29 November 2011 14:42:10 UTC