Re: Revised outreach presentation outline

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:03:28 UTC