W3C home > Mailing lists > Public > www-qa-wg@w3.org > February 2003

Re: Quick Tips volunteers -- an offer

From: Lofton Henderson <lofton@rockynet.com>
Date: Sat, 15 Feb 2003 16:41:29 -0700
Message-Id: <>
To: Karl Dubost <karl@w3.org>
Cc: www-qa-wg@w3.org

Thanks Karl.  I updated the reviews matrix to show that your SpecGL review 
obligation is done.


[1] http://www.w3.org/QA/Group/2002/06/reviews.html

At 03:24 PM 2/11/03 -0500, you wrote:

>At 8:14 -0700 2003-02-11, Lofton Henderson wrote:
>>OpsGL:  Peter, Kirill, Dom, Lynne, Andrew, Olivier (optional)
>>SpecGL:  Dimitris, Karl, Peter, Lofton, Lynne, Andrew, Olivier (optional)
>SpecGL: Plan Conformance requirements for your specification.
>The meaning of that is to organize and specify clearly what needs to be 
>done for the Conformance. It doesn't mean that you will be able to define 
>everything the first day of the WG, but that people can have a kind of 
>Roadmap or todo list for the Conformance.
>How-to organize your conformance plan.
>1. Identify someone to take care of the Conformance requirements.
>         Often it will be the QA person. This person will be in charge to 
> write the materials for the editors of the spec or to push people in 
> achieving their requirements.
>2. Identify all classes of product:
>         Write down in an email all products that your spec will address 
> and send it to the WG mailing-list. Often if you have written a 
> requirement doc for the technology, you will have the class of products.
>3. For each product define the conformance requirements
>         In the  list you have made you can write down the list of 
> requirements for each product. See Ruby Spec
>4. Be consistent in the vocabulary
>         It will be easier if you define a clear vocabulary in your spec 
> and you stick to it. try to use the QA Glossary
>5. Define minimum functionality
>         After drafting your requirequements for each product, you define 
> what's absolutely necessary to pretend to have a basic implementation.
>6. Deprecated feature
>         Read the old version of the spec and identify if something has 
> changed. How the new classes of product should deal with this new 
> features. Discuss that with the WG.
>7. Conformance section
>         The conformance section MUST appear in the table of contents, so 
> organize that with the editor of the Spec.
>8. Define Branding
>         In fact, It's how people will be able to make a claim that they 
> are conformant implementing the spec in one way or the other, authoring 
> content or tools implementing the spec, etc... It's why it's important to 
> define the class of products.
>9. Give an ICS
>         It will help the user of the spec to claim how he has done the thing.
>Karl Dubost / W3C - Conformance Manager
>           http://www.w3.org/QA/
>      --- Be Strict To Be Cool! ---
Received on Saturday, 15 February 2003 18:41:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:30 UTC