Re: [SpecGL Draft] E. Principle: Do Quality Control during the specification development

At 09:12 AM 7/2/2004 -0400, Lynne Rosenthal wrote:

>This was a generalization of the old Test Assertion GL/CP as well as other 
>things.
>We discussed this (are TAs a technique or GP) at the F2F.  I argued that 
>it is a technique.  Karl argued for GP.

Like you,  I can live with either one.

My main point (which I didn't make clear), is that TAs are missing 
altogether now, and need to be incorporated somehow.

-Lofton.


>This was a generalization of the old Test Assertion GL/CP as well as other 
>things.
>We discussed this (are TAs a technique or GP) at the F2F.  I argued that 
>it is a technique.  Karl argued for GP.  I'm not sure that we came to 
>consensus.  However, given Karl's document structure and reason for it 
>being a GP, I can accept it being a GP as well as making other items that 
>I originally had as techniques (e.g., write sample code or tests).  As 
>Karl said, by having them as GPs rather than a technique, it is more 
>obvious that you can do more than one of these (e.g., do both TAs and 
>sample code).
>
>--lynne
>
>At 08:46 AM 7/2/2004, Lofton Henderson wrote:
>
>>At 04:38 PM 7/1/2004 -0400, Karl Dubost wrote:
>>>[...]
>>>I think this section is very important and could recommend many simple
>>>Good Practices.
>>
>>As I recall, this "quality control" section is a generalization of the 
>>old Test Assertions GL/CP -- TA extraction or identification were to be 
>>considered a technique for quality control.  Would you imagine TAs being 
>>a Good Practice instead?  Or a Technique (as below)?  Or ...?
>>
>>-Lofton.
>>
>>
>>>The Principle behind that.
>>>
>>>Principle:
>>>         Do quality control during the specification development
>>>
>>>What does that mean?
>>>         The more the specification work is organized, the more the 
>>> control on development process of your specification, the more chances 
>>> to move smoothly across the W3C Process, and to have a better final 
>>> product. Each time, a version of the document is publish, the WG must 
>>> ensure that individual sections, it can be a full section or simply the 
>>> explanation of a feature is coherent and complete.
>>>
>>>Why should I care?
>>>         Publishing a specification with incomplete section is very 
>>> damaging at many levels :
>>>         - Image of the WG
>>>         - Understanding of the technology
>>>         - Possibility of good review and comments from people outside 
>>> the WG.
>>>         All these issues will tend to slow down the process and the 
>>> advancement of the development of the technology.
>>>
>>>
>>>Related:
>>>
>>>Techniques:
>>>         1. Create at the begining a mini guide to help people to work 
>>> on the technology and write submissions for the specification.
>>>         2. Follow some or all of these following good practices
>>>         3. If you really need to put an incomplete section, make it 
>>> clear that
>>>                 3.a It's incomplete
>>>                 3.b comments are not encouraged on this particular section.
>>>         4. Divide the work in small units, so people can see regular 
>>> progress
>>>         (5. Quality can be fun, make it fun.)
>>>
>>>
>>>Examples:
>>>         Publication template for SpecGL
>>>         RDF/OWL organization for submitting tests.
>>>         SVG?
>>>
>>>--
>>>Karl Dubost - http://www.w3.org/People/karl/
>>>W3C Conformance Manager
>>>*** Be Strict To Be Cool ***
>>

Received on Friday, 2 July 2004 09:21:35 UTC