RE: Process issues

Another reason very large specs are a problem is it is difficult to ever "finish" them.   Get it big enough and there is always something that needs to be modified.  That is an issue for patent policy.  It also plays into the misperception that nothing is stable.

An alternative is breaking very large specs up into modules and that way at least modules can firm up and become final (final until the next time they need to change).

Having smaller, modular specs does not preclude also having massive specs that are conglomerations of the modules if people want something to just be one single spec in a single document.  This seems like something where both sides can have it their way.

I don't think this is a process document issue.  Very large specs shouldn't be forbidden.  It's more how we decide to do our work.

>-----Original Message-----
>From: Charles McCathieNevile [mailto:chaals@opera.com]
>Sent: Tuesday, November 29, 2011 7:12 AM
>To: public-w3process@w3.org; Scheppe, Kai-Dietrich
>Subject: Re: Process issues
>
>On Tue, 29 Nov 2011 14:05:24 +0100, Scheppe, Kai-Dietrich
><k.scheppe@telekom.de> wrote:
>
>> "specs are too large"
>
>I don't think there are any implications for the process document here.
>There is the question of what happens to patent commitments based on FPWD if
>a specification is split in two (as there is when two specifications are merged -
>and both of these are complicated if the work goes into or comes from different
>groups).
>
>> There are many potential views on what is meant by that.
>
>Indeed :) Below are my personal ones...
>
>> Scope of a spec
>> Are specs too large because they try to be all encompassing, thereby
>> creating unwanted size?
>
>I think this is the most common reason.
>
>> Would it be beneficial to
>> - split a given spec up into reasonable components?
>>   (with reasonable being something depending on the topic)
>
>Yes. In general that is probably easier to do post hoc - and it means keeping an
>understanding of interdependencies - the web platform is built of many related
>pieces.
>
>> - give some guidance as to how big a given sub-section of a spec
>> should be (for example 1-20 pages as a suggestion)
>
>No.
>
>> - plan ahead and declare specific exclusions, to be saved for later
>> versions, basically like a roadmap.
>
>Sometimes.
>
>> Editing a spec
>> Is editing a spec with more than one person per document a problem?
>
>No, editing depends on the editors - and on the group to deal with any problems
>the editors cause.
>
>> Would it be beneficial to
>> - split larger specs up into sub-sections that are edited by different
>> people?
>
>Sometimes - it's up to the relevant working group and the "editor(s)".
>
>> - work on them within task forces inside the working group?
>
>Possibly - again, this depends on the working group.
>
>> Dependencies
>> Are specs to large because there are too many dependencies to consider?
>
>I don't think so. The web platform is complex because there are many
>dependencies to consider. I think specs are too large because people who edit
>them find it easier to keep everything in the one place.
>
>> - See the above which would allow parceling out work on dependencies.
>
>Parcelling them out doesn't necessarily make them go away - coordinating them
>actively can instead become a large overhead on further development.
>
>On the other hand, things broken up into smaller chunks that can more easily be
>mentally digested can more rapidly be absorbed as "background knowledge". If
>the information is clear, they can also be more easily referenced, which simplifies
>the task of somebody trying to work out what impact the state of the existing
>web has on some proposed new technology, and also provides more models for a
>new specification which is in itself helpful.
>
>> Why else might specs be considered too large?
>
>Starting (at the end of this mail ;) ) from use cases, I would say that specs being
>very large is a problem because it leads to people not actually *reading* them,
>but instead reading someone's handy summary. This applies to both people who
>use the spec in their content, and to those who implement it in software, and it
>leads to poor quality and interoperability issues.
>
>In addition, large specs are very difficult to review. This means either that a
>specification gets very little review (which is likely to result in problems that could
>have been found not being discovered until it has been shipped), or that
>developing it is a very slow process.
>
>Which suggests that we should provide guidance to groups suggesting they keep
>specs "manageable" and explain that this will help maintain the quality of their
>spec and subsequent implementation. As mentioned at the start I don't see this
>implying any recommendations to change the formal processes of W3C based on
>this question.
>
>cheers
>
>
>--
>Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>     je parle français -- hablo español -- jeg kan litt norsk
>http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Friday, 2 December 2011 23:12:34 UTC