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 Tuesday, 29 November 2011 15:12:43 UTC