Re: Outline of Boston presentation

Patrick et al,

Good first draft, thanks.

Sorry that I don't have time right now for more extensive comments -- let's 
try to flush some out during the telecon.  Particularly, 
discuss/endorse/change the overall shape.

Some quick comments, embedded below...

At 12:54 PM 2/17/2003 -0800, Patrick Curran wrote:
>For discussion tomorrow. I don't know if I've captured everybody's 
>thoughts, but at least this is a start...
>
>
>
>
>* Why QA?
>
>   Development of conformance test suites leads to:
>     Better, more testable, more implementable specifications
>     Better quality implementations
>     More interoperable implementations
>
>
>* Business Justification
>
>   QA activities are expensive
>   So is development of specifications and implementations
>     Examples?
>   Investment in QA activities:
>     Reduces cost of developing specifications and implementations
>     Reduces duplication of test-development effort
>       All implementors need test suites!
>   Even a small investment pays big dividends
>
>
>* How the QA-WG can help
>
>   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, measure against our checkpoints
>
>
>* 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 QA into Working Group activities
>   Define and allocate resources for QA activities
>   Synchronize QA activities with the specification milestones
>   Define the QA process
>   Plan for development, publication, maintenance of test materials
>
>
>* Spec Guidelines (think Testability)
>
>   Define scope; identify what needs to conform and how
>   Specify conformance policy
>   Use profiles, modules, functional levels to subset the technology
>   Identify testable assertions
>   Define discretionary items and extension policy
>   Identify conformance requirements; provide conformance clause
>   Address how conformance claims & statements are made

I like these last two slides -- each one is a 1-slide summary of the 
essence of the GL document.

I think that we might do a little tuning of the wording, as some of it is 
too close to the terse wording in the GL documents.  Huh?  Isn't it 
supposed to be close?  What I mean is that it could be slightly more 
conversational.  E.g., instead of "define & allocate resources for QA" I 
would be more inclined to say, "Estimate requirements and assign staff for...".



>* Feedback & Next Steps
>
>   What do you need from us?
>   What can we do to help?

It would be nice if we could develop a handful of sub-bullets, that are 
suggestive of some possibilities.  For example (these are just an 
illustration, I don't necessarily think these are the right ones)...

* Consultation about SpecGL reviews
* Forms and tools to help implement OpsGL
* A "SpecGL validator"
* A TTF (or TWG) of approximately XX (?) people
* (...some of the proposed TTF deliverables...)

"We are re-chartering in 6 months.  Which direction should we move?)

(maybe brainstorm this in telecon)...


>
>* References
>
>   Provide URLs for:
>     Our home page
>     The seven docs
>     The Matrix
>     What else?

The W3C QA Library (.../QA/Library)

Regards,
-Lofton.

Received on Tuesday, 18 February 2003 09:31:25 UTC