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

This was a generalization of the old Test Assertion GL/CP as well as other 
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).


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 ...?
>>The Principle behind that.
>>         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.
>>         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.)
>>         Publication template for SpecGL
>>         RDF/OWL organization for submitting tests.
>>         SVG?
>>Karl Dubost -
>>W3C Conformance Manager
>>*** Be Strict To Be Cool ***

Received on Friday, 2 July 2004 09:15:14 UTC