Draft minutes of QA WG Telcon 29-March-2004

As always, comments and corrections are welcome......-L
?? Were last week's minutes published?  If so, can you point me to the URI? 
Thanks.


QA Working Group Teleconference
Monday, 29 March 2004
--
Scribe: Lynne

Attendees:
(PC) Patrick Curran (Sun Microsystems)
(DD) Dimitris Dimitriadis (Ontologicon)
(KD) Karl Dubost (W3C, WG co-chair)
(DH) Dominique Hazaël-Massieux (W3C)
(LH) Lofton Henderson (CGMO - WG co-chair)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(AT) Andrew Thackrah (Open Group)

(DM) David Marston

Regrets:
(MC) Martin Chamberlain (Microsoft)
(MS) Mark Skall (NIST)
(VV) Vanitha Venkatraman (Sun Microsystems)

Absent:


Summary of New Action Items: No new action item
AI-20040329-01 Lofton to reschedule meeting from 12 Apr to 14 Apr.   Due: 
31 Mar

Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2004Mar/0089.html

Previous Telcon Minutes:  (Patrick to publish)

Minutes:
1) Rollcall

2.) routine business
- Topics for 5 April:  TestLite
- June meeting: Room arranged.  PC to send details in Santa Clara
- KD future regrets until 12 Apr.
- Easter Monday, 12 Apr.  Reschedule to 14 Apr.  Next version of QAH and 
SpecLite milestones.

3.) QA Handbook
- proposed outline http://www.w3.org/QA/WG/2004/03/QAH-outline
Summary:
Starting with an overview of the Handbook (QAH), the discussion focused on 
the nature of the document, whether it is a primer, which has explanatory 
and tutorial information or a handbook, which is more of a reference.  No 
conclusion was made  it seems to be more of a hybrid. We will see how it 
progresses and then adjust accordingly.
It was agreed that the audience is Chairs and Team, that the QAH will be 
self-contained as much as possible and  will reference the other QAF 
documents where appropriate but not serve as an elaborate introduction to 
them.  There are five sections to the QAF, Introduction, Early planning and 
commitment, Day-day QA operations, IANAL, and All the rest.  The first 3 
were discussed, with consensus as to their general content.  Additionally, 
the overall direction of the document was endorsed by the group.

Details:
LH: About presented the QAH.  Some parts of QAF-Intro and QAF-OpsGL.  For 
Chairs and Staff, most already are experienced, but may be a few 
novices.  Assume their concerns and pressures are similar to Spec editors, 
as articulated in Wiki. First issue: How much should QAF introduce other 
QAF documents?
DH: don’t need to introduce the other documents.  QAH should stand on its 
own.  If reference other documents, may only want to indicate that audience 
may want to look at them.
LH: Possibly, have a list of the other documents and links to them.

Handbook or Primer?
AT: Clarification on what is a handbook.  See handbook as a reference, a 
summary of important information, not necessarily a primer or explanatory 
information. Assume audience is already familiar with the material.  Not 
tell you how to do it.
KD: Could be extensive prose or more like a list of all the things you need 
to do.
PC: We could change the name.
AT: Do we assume they already know the material, and just want to provide a 
quick reference (summarized form), no introductory material, hence a 
handbook.  Not need to explain purpose of QA.
KD: Are you familiar with O’Reilly “Cookbooks”?  Not give full theory but 
gives rough guidance and examples.  Is cookbook a better description of this?
AT:  Associate the O’Reilly Cookbooks with a reference guide, not a handbook.
[dd leaves]
LR: name it later. Focus more on what is in it.
AT: how do we imagine this will be used?
LH: In introduction, made reference to current QAF that got positive 
feedback  that being the Framework primer and audience. Audience and usage 
scenarios should still be part of this QAH.  How much of the old material 
should survive?
AT: First thing people will look at is a primer, which would map out where 
to go.
LH: Given who the audience is, is that useful?  Are we introducing it to 
the entire group, or to Chairs and Team?
AT: What would they want to look at first?  People want a document that 
maps out the major elements.  If introductory material points to detailed 
materials, then what is the purpose of the QAH?
LH: Assume Chairs and Team look at the QAH early on in WG life and then 
they would be referring to it later.  Introduction will go away.
KD: We will figure this out better as we progress our documents. If we find 
that we need more descriptive information (e.g., introduction), we can 
produce it later.
AT: Who will use the handbook and at what stage?
KD: Chairs and team.  At the start of the WG and revisit it during the life 
of the WG.
LH: Just looked at Introduction, specifically primer and audience.  Any 
problem with orienting Chairs and Team with condensed reworked version QAF 
primer and target audience (2.2)?  An extensive orientation of the 
audience, through usage scenarios, use cases, etc.   Worth taking a crack 
at this for now and can determine if it belongs somewhere else later.

Overview of document
LH: Proto-module is an outline of what is in each module.  Probably all the 
documents would have some or all of these parts.  QAH has 5 parts: (1) 
Introduction and Roadmap  orients to the rest of the QAF and perhaps to 
other documents. Then, 4 additional modules representing content we want to 
keep.  (2) Early planning and Commitment.  Day-day operations, (3) License 
and legal stuff, and (4) all the rest.

1. Introduction and Roadmap
LH: In old intro, had chronology diagram.  Would something like that be 
useful in the orientation material? AGREED.
LH: Introduction to QAH.  Shouldn’t get pedantic about QA, assume that 
people have bought into QA.  If we want to preserve some of this 
information, suggest pulling it out and making it a separate document on 
our web space  as a Why QA document.  AGREED.
LH: Scope and Goals.  High level view of what the rest of QAH 
is.  Preference is to have it as a diagram.  Agreed to introduce other 
documents in a condensed way.

2. Early Panning and Commitment
Any comments?
LR: make sure that it conveys that this is important beyond just 
chartering, but also during the life of the WG.

3. Day-day operations
LH: This is where most of the stuff goes.  The QAPD addressed most of the 
checkpoints in OpsGL.  We agreed that some of the test related checkpoints 
would migrate to TestLite. I preserved most of the checkpoints associated 
with QAPD. Some of them are purely operational, e.g., communications, 
contact; whereas some were about test development framework and 
maintenance.  Think it wouldn’t be bad to mention and include here, but 
point to TestLite for details.
PC: Reasonable, as long as we avoid duplication.
LH: There are some items, we can address in email, regarding where it 
should be discussed, e.g., test material publication.
DH: although the QAPD has a detailed list of items, e.g., license, there is 
not a similar document for QA related things.  It would be more appropriate 
for the QAPD to be a Test Development Process Document, rather than a 
generalized QA Process document.  This would be clearer to most people, 
since QA process is fuzzy.
LH: will address this via email, after thinking about it some more.

Overall comments?
PC: like the direction we are going in.  Try to avoid the number of 
external documents. Encourage putting it in here for now.
LH: Even stuff like Why QA? If we do have some cost-benefit analysis, it 
would be of interest.
PC: Don’t think we have much of that material for now.  Better to focus on 
developing our stuff and keep it all in one place.

Adjourn.