Re: QA Handbook "Pink" Rewrites

First, thanks to Mark for delivering his AI right on schedule!

Some of them I agree with right off (e.g., simply dropping "QA" as a 
modifier in some cases).

But about David's comments...

At 11:34 AM 4/23/2004 -0400, david_marston@us.ibm.com wrote:

>I was going through Mark's suggested changes, thinking each was a
>worthy change, but eventually "QA framework deliverables" began to wear
>on me and look too jargonistic.

I have a similar concern.  This issue began with Dom's comments, as you can 
see in the 2nd section of

[1] http://lists.w3.org/Archives/Public/www-qa-wg/2004Apr/0030.html ,

where he wrote, "the generic "QA" process ... will be too fuzzy for most of 
our readers."  He recommended that we need to evaluate at each occurrence 
whether we're talking about the generic (so fuzzy is okay), or specific (so 
we should change).

Proposal.  Continue email discussion, and do the point-by-point evaluation 
after FPWD of QAH.

(That is purely for pragmatics -- almost zero telecon time, and minimal 
editor's time before FPWD.)



>The key to this issue is the question is: Whose framework is it? Does
>the term mean
>(1) deliverables under *the* framework issued/imposed by QAWG
>or
>(2) deliverables under *a* framework of the WG's own designation?

Good questions.

Those, together with some of the ideas in your penultimate paragraph 
(below) should be discussed further -- email and meetings after FPWD.

-Lofton.


>In some cases, it may be best to enumerate the additional deliverables,
>or not all of them, if the impact of the framework on the WG's overall
>workload is too amorphous. For example:
>(C) Consider: asking in CfP for extra people who would specifically be 
>tasked to work on QA deliverables
>(MS) Consider: asking in CfP for extra people who would specifically be 
>tasked to work on QA framework deliverables
>(DM) Consider: asking in CfP for extra people who would specifically be 
>tasked to work on test materials, test assertions, or consistent treatment 
>of optionality across tests and documents
>I recognize that "QA framework" is broader, but I assume that the CfP
>was already going to account for editorial commitments that would be
>impacted by son-of-SpecGL. Likewise for the WG having a contact point:
>spec issues go to the [WGname]-editors list, but having a contact for
>son-of-TestGL issues or for test assertions may be novel. Am I making
>correct assumptions about what "QA framework" means to you, Mark?
>
>The QAH introduces a QA-centric (broader than testing-centric) point of
>view for a WG's activities, but that doesn't mean that it needs to
>preserve the unity of the "QA framework" as an ongoing obligation. It
>could serve as a guide (even a warning) to the WG that their work will
>be examined under the QA point-of-view at various milestones while
>breaking out individual activities and practices that the WG will
>allocate in their own fashion. In other words, it may serve to lengthen
>the list of deliverables without emphasizing that some deliverables may
>roll up into a "QA framework" and some don't. Extending that idea, the
>WG's QAPD becomes their own demi-framework that shows how they intend to
>justify their work when they reach a milestone where they are subjected
>to a QA-centric review. But their QAPD is not their charter, it's the
>document for one point of view.
>
>Another possibility is to use the term "conformance" (again, broader
>than testing) on some occasions, if that separates the improved WG
>practices from the well-established practices.
>.................David Marston