- From: Lofton Henderson <lofton@rockynet.com>
- Date: Tue, 18 Feb 2003 08:31:46 -0700
- To: Karl Dubost <karl@w3.org>
- Cc: www-qa-wg@w3.org
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