QAWGPD at Boston

QA WG participants --

According to Dom's OpsGL assessment of QAWG ([1], [2]), we fail.  A lot of 
the problems are related to our lack of a QAPD (QA Process 
Document).  About a dozen of OpsGL's checkpoints rely on addressing 
required items in a QAPD.

Our QAPD is supposed to be part 3 of our combined QAWG Process Document 
(QAWGPD).  The current draft is at [3].  It is on our agenda for Boston, 
and we should set the goal to finish it.  Please have a look in advance, 
and be ready to raise any issues that you have with it.  Advance comments 
by email are preferable, as always.

Here are some comments of my own.

There are numerous "@@@".  A lot are editorial tasks to be completed, some 
are substantive issues.

Sec1.1, last "@@@":  we need to decide between chair or vote, for accepting 
invited experts.  While I think it's a good idea to record a well-defined 
way to handle invited experts, on the other hand it should be consistent 
with our generally low-key and flexible approach (we *rarely* vote on 
things).  So I would opt for "chair" or "chair, after consultation with WG 
members."  I.e., we make sure everyone is aware, and then chair makes 
decision (this gives the opportunity for any significant negatives to be 
raised).

Sec1.2, last pgph:  I think the answer to the "@@@" question is "no". Also, 
if we agree that invited expert should not force a necessary vote, then 
should "Topic expert" be any different?

Sec3.2.  This section needs work -- guidelines about what things we to the 
IG and when.  It arises again later, in the section about issues.

Sec4:  Notification of AI completion should be "Cc:" to QAWG.

Sec5.1, 2nd pgph:  I guess the right way is to formally enter issues, but 
for expedience (when we have been pressed for time), we have taken 
short-cuts.  E.g., the 25+ AR SpecGL comments before Seattle.  We ended up 
doing the equivalent of Issue List processing (numbered, discussed, 
resolved, replied to commenter).  It is nice to have all of this stuff in a 
single place, but time pressure sometimes prevents.  Actually, I think if 
we just delete the 2nd paragraph we don't lose anything, and the essential 
process requirements remain.

Sec5.2.  "Chair (document editor?)"  -- probably "Chair".  Note that 
document editor is typically assigned to be the owner, as we are now doing 
things.

Sec5.2:  All issues should have a proposed resolution before they are 
logged/queued.  I would assign that to the owner, to ensure that they have 
such.

Sec5.3:  This should address and make clear whether issue discussion is on 
IG list or WG list.  Or sometimes IG, sometimes WG (and what is the 
criterion to decide.)

Sec 5.x:  Should we indicate that Sec 5 describes the normal or nominal way 
of handling issues, but we can make "reasonable" exemptions by WG 
consensus?  Reason.  What we did with the 28 AR issues (on SpecGL) was 
reasonable and equivalent, and observed all of the necessary aspects -- 
discussion, consensus, notification -- but was an expedient.  (And violated 
our processes as written.)  We should ensure that we are using reasonable 
processes -- like these described ones if possible -- but not inflexibly 
tie our hands.

"Test Material":  This final 1/3 (major section) is our QAPD.  A couple of 
global comments:

** We need to measure what is in here against Dom's comments ([1], [2]).

** We need to consider and define, what are test materials for our three GL 
specs?

** Should we try the exercise of filling in the QAPD template [4], and 
putting it here instead?

All for now,
-Lofton.

[1] http://lists.w3.org/Archives/Public/www-qa-wg/2003Feb/0116.html
[2] http://www.w3.org/QA/Group/2003/02/qaframe-ops-qawg
[3] http://www.w3.org/QA/WG/2003/01/qawgpd-20030103.html
[4] http://www.w3.org/QA/WG/2003/02/OpsET-qapd-20030217