Re: Quick Tips volunteers -- an offer

High on my list of things to call to attention is:

** Give careful consideration to interoperability implications of 
extensions, optionality, and discretionary features.

A shorter title for this items would be better.  How about "Avoid 
extensibility and unnecessary variability"

This could perhaps replace or be integrated with #6, if we think the list 
becomes too long by adding more items.)

Regards,
-Lofton.

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 Tuesday, 18 February 2003 10:31:43 UTC