W3C home > Mailing lists > Public > www-qa-wg@w3.org > July 2004

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

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Fri, 02 Jul 2004 09:12:15 -0400
Message-Id: <5.1.0.14.2.20040702090543.01e53d08@mailserver.nist.gov>
To: Lofton Henderson <lofton@rockynet.com>, Karl Dubost <karl@w3.org>
Cc: www-qa-wg@w3.org

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:15:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:36 UTC