Re: Revised outreach presentation outline

I like it - thanks...

Lynne Rosenthal wrote:

>
> Suggested changes to the SpecGL slide
>
> Scope: define the scope, identifying what needs to conform and how
> Conformance Clause: specify the conformance policy and requirements
> Divide and conquer:  use profiles, modules, functional levels to 
> subset the technology
> Extensions: define if extensions are allowed and under what conditions
> Tag for later use: Identify testable assertions, discretionary items, 
> etc  (those things that will be needed in developing tests)
> Claims:  specify how conformance claims and statements are made.
>
>
> lynne
>
>
>
>
> At 11:32 PM 2/25/2003 -0800, Patrick Curran wrote:
>
>> I'm sorry this is late - I've been overloaded. We only have a few 
>> days to finish this up, so please send feedback asap.
>>
>> Thanks...
>>
>> Stylistic notations:
>>
>> *bold*
>> @@link@@ (URL)
>>
>> ====================
>>
>>
>> * Why QA?
>>
>>   Investment in QA activies will:
>>     Promote better, more testable, more implementable specifications
>>     Reduce the cost of developing specifications
>>     Increase the quality and interoperability of implementations
>>     Reduce duplication of test-development effort
>>   Even a small investment pays big dividends
>>   Ask us about DOM, SOAP, SVG...
>>
>>
>> NOTES
>>
>> Originally we had two slides: why QA?, and business justification. I've
>> combined them, since the answer to "why?" should provide the business
>> justification.
>>
>> "Ask us about..." is the best we can do for now with test-cases, and
>> probably sufficient.
>>
>> TALKING POINTS
>>
>> The ops/spec guidelines will enable you to get the bugs out of your spec
>> early in the cycle. This will actually save you money due to fewer 
>> revision
>> cycles. Plus, the spec will be of higher quality.
>>
>> If you build a test suite, this will be expensive, but:
>>   participating companies will find bugs in their implementations,
>>      which will save them money
>>   it's cheaper to contribute to a 'shared' test suite than for all
>>      implementors to build their own test suites
>>
>>
>> * How the QA-WG can help you
>>
>>   We can't do your QA work for you
>>     We don't have the resources nor the domain-specific expertise
>>   We do provide guidance, tools, and processes
>>   We can help avoid duplication of effort
>>   Follow our guidelines, use our templates, measure against our and 
>> checkpoints
>>   Tell us what else you need
>>
>>
>> TALKING POINTS
>>
>> Our framework docs are nearing completion, and we're getting ready to
>> re-charter - tell us what you want from us.
>>
>>
>> * It's easy to get started/How to work with us
>>
>>
>> NOTES
>>
>> During last week's teleconference we talked about a "how to get started"
>> slide, and how this should provide some very practical examples. I
>> haven't received any suggestions for this content, and I'm having
>> trouble distinguishing this slide from the OpsGL slide that we propose
>> to move to the end of the presentation.
>>
>>
>> * Results
>>
>>   @@SOAP assertion list@@
>>     (http://www.w3.org/TR/2002/WD-soap12-testcollection-20020626)
>>
>>
>> NOTES
>>
>> We talked about the value of providing some real-world examples of 
>> the successful
>> application of our guidelines. I haven't received any suggestions for 
>> content.
>> Does this belong on a separate slide?
>>
>>
>> * Our Guidelines (the Seven Documents)
>>
>>   Introduction
>>     Roadmap, primer, guide to the other documents
>>   Operational Guidelines
>>     Planning, logistics, operation, and maintenance of WG quality 
>> processes
>>   Specification Guidelines
>>     How to write clearer, more implementable, more testable 
>> specifications
>>   Test Guidelines
>>     Technologies, tools, methods for writing test materials
>>
>>
>> * Operations Guidelines (think QA)
>>
>>   Appoint a QA lead
>>   *Integrate* -- commit to QA goals and scenario
>>   *Staff* -- assess and assign appropriate staffing
>>   *Coordinate* -- synchronize QA and specification deliverables
>>   *Plan* -- for for development, publication, maintenance
>>   *How?* -- use OpsGL's @@charter template@@ and @@process template@@
>>     (http://www.w3.org/QA/WG/2003/02/OpsET-charter-20030217.html)
>>     (http://www.w3.org/QA/WG/2003/02/OpsET-qapd-20030217.html)
>>
>>
>> NOTES
>>
>> Although I like the idea of having a positive, "here's what you can do"
>> slide towards the end, I'm concerned about what it would do to the 
>> structure
>> if we move this slide to the end. Specifically:
>>
>> How is this slide different from the "how do I get started/see how easy
>> this is" slide that we might want to put up front?
>>
>> If we move this to the end, wouldn't it be weird to present SpecGL
>> before OpsGL?
>>
>>
>> * Spec Guidelines (think Testability)
>>
>>   *Define* scope; identify what needs to conform, and how
>>   *Specify* conformance policy & requirements; provide conformance 
>> clause
>>   *Use* profiles, modules, functional levels to subset the technology
>>   *Define* extension policy
>>   *Identify* testable assertions, discretionary items
>>   *Specify* how conformance claims & statements are made
>>
>>
>> NOTES
>>
>> This slide's "chatty style" doesn't quite match OpsGL's. Can anybody
>> suggest an alternative?
>>
>>
>> * Feedback & Next Steps
>>
>>   What do you think of:
>>     Our last-call documents?
>>     Our tools and resources (Library, Matrix, Tools, ...)?
>>   Other feedback?
>>   What would you like us to do next?
>>     Review your processes and specs?
>>     Provide consulting services?
>>     Document existing best practices?
>>     Provide templates, tools, and test harnesses?
>>   Other suggestions?
>>
>>
>> * References
>>
>>   Our home page (and the seven docs) (http://www.w3.org/QA/WG/)
>>   The Matrix (http://www.w3.org/QA/TheMatrix)
>>   QA library (http://www.w3.org/QA/Library/)
>>   What else?
>
>
>

Received on Wednesday, 26 February 2003 11:17:15 UTC