W3C home > Mailing lists > Public > www-qa-wg@w3.org > February 2003

Re: Revised outreach presentation outline

From: Lofton Henderson <lofton@rockynet.com>
Date: Wed, 26 Feb 2003 18:18:22 -0700
Message-Id: <5.1.0.14.2.20030226172757.04680180@rockynet.com>
To: Patrick Curran <Patrick.Curran@sun.com>
Cc: www-qa-wg@w3.org
Hi,

Thanks Patrick -- it's shaping up well!

I have one overall question:  do you anticipate to apply the W3C slide 
maker once the content is all settled?  (Or is this to be left to The 
Outreach Five?).

I have some comments in-line.  Most of them are about polish, like more 
links, which you were probably planning anyway...

At 11:32 PM 2/25/03 -0800, Patrick Curran wrote:
>[...]
>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...

Possible alternative.  "Ask DOM, SOAP, SVG about their experience"

[Note.  Each WG name could be a hyperlink to the WG or their "test" 
page.  Doesn't necessarily have to be activated by the speaker, but these 
slides will be available somewhere in public space, for later browsing by 
audience and others.]



>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

I think a link or two would be nice on this slide.  E.g., "tools" could link to

http://www.w3.org/QA/Tools/

Admittedly, not many of these are direct products/deliverables of 
QAWG.  But we can talk around that.

In 2nd-to-last line, "guidelines" could link to:

http://www.w3.org/QA/WG/#docs ,

and "templates" could link to:

http://www.w3.org/QA/WG/2003/02/OpsET-charter , or
http://www.w3.org/QA/WG/2003/02/OpsET-qapd ,

and "checkpoints" could link to:

http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/qaframe-spec-ics#checklist-table 
, or
http://www.w3.org/TR/2003/WD-qaframe-ops-20030210/qaframe-ops-ics#checklist-table

[I'm a fan of links that give a quickly grasped snap view of what we 
mean.  Once again, the speaker doesn't have to activate them and talk -- 
but they're there for that option.  I do see that you have provided links 
later on in the more detailed sections.]


>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.

Maybe the OpsGL slide, done near the end of the talk, is approximately the 
right stuff.  So we would save the "it's easy to get started" for closing, 
for "punch", and deliver it with the OpsGL slide.  [TALKING 
POINT.  "Getting started is easy, and OpsGL gives a roadmap for how to do 
it.  Blah..blah...blah.."]



>* 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?

I like the idea of a separate slide.  I, as a presenter, would view it as 
optional.  Depending on the audience, I might just say "We have some 
interesting early results, ..." and skip to the next slide.

Lynne's example of UAWG SpecGL "AA" conformance (almost "AAA") would be 
excellent here.

But that still leaves us a little "thin".



>* 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

I'd suggest inks, probably to the current /TR/ versions (as opposed to 
dated versions).

http://www.w3.org/TR/qaframe-intro/
http://www.w3.org/TR/qaframe-ops/
http://www.w3.org/TR/qaframe-spec/
http://www.w3.org/TR/qaframe-test/

[Or else -- since the expansion of each one immediately follows, just link 
"Seven Documents" to
http://www.w3.org/QA/WG/#docs ]


>* 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)

Suggestion:  change first line to "*Get started* -- Appoint a QA lead"  (or 
else just "*Start* -- Appoint...")


>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?

It wouldn't bother me necessarily.  I think most of the focus and interest 
is about SpecGL.  It's where we spend most of our WG issues time, and where 
we get most outside comment.  It will just take a little "smooth talking" 
to make it seem right.  Maybe if we just swap OpsGL and SpecGL then the 
final three become:

SpecGL ("...blah...")
OpsGL (aka, "Getting started is easy, here's how...")
Feedback ("...finally, tell us what you think and what you want...")

What do you think of that ordering?

Notice also that we omit TestGL altogether as a detailed slide.  I'm okay 
with that for now, and it is still a bit young and unstable.



>* 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/)

Instead of pointing to /QA/WG/, should we point to /QA/?  (I don't know, 
I'm just asking).  And as a separate bullet, "The Framework Seven" 
(pointing to .../QA/WG/#docs)

Or to /QA/, /QA/WG/, /QA/IG/ (all three), e.g., "Our home pages for @@QA@@, 
the @@QA WG@@, and the @@QA IG@@"

>   The Matrix (http://www.w3.org/QA/TheMatrix)
>   QA library (http://www.w3.org/QA/Library/)
>   What else?

How about:  http://www.w3.org/QA/Tools/

That's all I have.

Thanks for all the great work!

-Lofton.
Received on Wednesday, 26 February 2003 20:18:03 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:12 GMT