Re: QAH outline

As I edit to produce first QAH draft, I'm going through Dom's comments 
(below), and also looking at the telecon minutes [1].

[1] http://lists.w3.org/Archives/Public/www-qa-wg/2004Apr/0010.html
[2] http://www.w3.org/QA/WG/2004/03/QAH-outline.html

I'm going to try to circulate a QAH draft by CoB Monday, for Wednesday 
review and discussion.  Recognizing that 3-day weekend has begun in Europe 
already, if I don't get feedback by CoB Monday, then some of the following 
might not be reflected in that draft.

Questions, comments, dispositions embedded...

At 01:45 PM 3/23/2004 +0100, Dominique Hazaël-Massieux wrote:
>Le mar 23/03/2004 à 02:28, Lofton Henderson a écrit :
> > http://www.w3.org/QA/WG/2004/03/QAH-outline.html
>
> > Comments welcome.
>
>Going through the identified issues:
>* "Issue: to what degree should QAH introduce the rest of QAF?"
>   "First issue: do we want QAH's intro sections to introduce: all of
>QAF? or only that old-OpsGL process & operational stuff that will
>survive in QAH?"
>
>To a very low degree ; that is, it may point to the other documents from
>the core of the text, and may have quick pointers to them from its
>introduction, but I don't think it should introduce the rest of QAF.
>My point is that the handbook needs to have the essential stuff, and
>introducing the QAF in too much details would put too much verbosity at
>the start of the document.

Agreed about this, with possible exception of the following...


>* "QAH & QAF Primer and Usage Scenarios
>
>Issue: would this section itself be better as an external, referenced
>document? It doesn't involve too much content from QAF-intro, so it
>could go either way -- in-line or external."
>
>hmm... To me, the handbook as a whole is a primer, and the usage
>scenarios would be used all across the document ; I don't think we need
>a specific section for the primer.

The telecon minutes [1] left me a bit uncertain about what we 
decided.  I'll consider transferring (from Intro+OpsGL) use cases and/or 
usage scenarios in an intro section of QAH.  With it in front of us, it 
will be easier to decide -- move, leave, delete, change, etc.


>* "Day to day operations and QAPD"
>
>re "why care", I would note that the W3C Process document organizes
>clearly the way a spec is developed through the Rec Track, but that it's
>not the case with other items of the WG life ; given the way the work is
>done in W3C (distributed, international, etc.), you need some
>organization rules to get the work done.

Good point, done.


>Also, I think it would be more appropriate to speak of "Test Development
>process" rather than the generic "QA" process, which will be too fuzzy
>for most of our readers.

I agree in principle.  But "Test Development process" is perhaps a little 
more limited than what we mean by "QA process".  (Or ... maybe not?) I have 
changed the generic "quality process" or "QA process" in a few places, but 
mostly I am flagging it in the draft and inviting specific suggestions.


>I would simplify the section by putting up front the few options
>available to organize the test development effort, with links to
>templates ; plus adding the pro/cons for each options, and generalizing
>a bit in the end to list the points a WG would need to address if it
>were to build a new process from scratch.

I'm still confused about this one.  Can you give specifics in terms of 
what's in the outline [2] now?

It seems to me that there are 3-4 natural subsections in Day-to-Day:
** general QA logistics (the QAPD itself, point-of-contact, comm, Web 
pages, etc)
** license & branding stuff (represented in @@QAPD@@, see below @@IANAL@@ 
for details).
** test dev't stuff (represented in @@QAPD@@, see @@testLite@@ for details)
** maintenance stuff (ditto)

So I turned to the minutes, which say:

At 07:27 AM 4/5/2004 -0400, Lynne Rosenthal wrote:
>[...]
>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.

The current QAPD [3] reflects several types of things:  comm & other 
logistics, license, test dev't process, maint, ...

[3] http://www.w3.org/QA/WG/2003/09/OpsET-qapd-20030922.html

I would envision reorganizing it to parallel this (Day-to-day) section of 
the outline [2].  As I understand your minuted comments, you would 
recommend splitting QAPD into separate QAPD and TDPD?

Opinion.  I guess I like "all in one place" better.  I'd like to go to one 
document and find process stuff for general logistics (section), license & 
branding stuff (section), test dev't process and especially contrib-review 
process (section), versioning/maint (section).

Am I missing your point completely?


>* "[Issue: is this an okay approach in the last two bullet lists, i.e.,
>mention the topics, suggest that they can be documented in QAPD (they're
>in template now), and point to TestLite for details?]"
>
>Yes, I think it is a good approach.
>
>* re "IANAL but..."
>There are still on-going discussions on the topic of TS licenses at
>various places inside W3C ;

This is mostly invisible to me.  Do you have some references subsequent to 
the work we did with Joseph?  That ad hoc task group arrived at some 
consensus with some major participants like IBM, Sun, Microsoft.

>we definitely need to document the simple
>way of doing it (meaning that we first need to know what's the simple
>way is), and probably warn about doing differently as a possible
>obstacle.

I propose that we should point to the work we did with Joseph, as OpsGL 
currently does.  "Chose Document or Software License, consider applying it 
separately to different components of TM."

Regards,
-Lofton.


>* "[Issue: is this worth keeping? It arose because of the XML TS
>transfer, and several of us in QA spent significant time moderating and
>helping plan the transfer, and we had to sort out a lot of bits and
>pieces. So it seems useful to capture that, yes?]"
>
>Quite!
>
>Dom
>
>--
>Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
>W3C/ERCIM
>mailto:dom@w3.org
>