LC-60.4, 60.6, 60.9, 60.11, 60.12, 60.14

This is the SECOND piece of several pieces that will collectively propose 
*specific* resolutions for LC-60.3 through LC-60.15.

First:  LC-60.3, 60.5, 60.7, 60.8
http://lists.w3.org/Archives/Public/www-qa/2003May/0028.html

This Second deals with:  LC-60.4, 60.6, 60.9, 60.11, 60.12, 60.14 ( 3 of 
these are moot or "no change").

See [4] for illustration of implementation of the proposed resolutions.

Overview
-----
For resolutions of LC-60.3 through LC-60.15, a proposal for resolutions was 
circulated a couple weeks ago at:
[1] http://lists.w3.org/Archives/Public/www-qa/2003Apr/0064.html

Since then, we have resolved LC-60.1 to "clarify and solve the particular 
problems, but try to avoid major re-org".

Proposed resolutions follow.  Discussion is welcome on this list.

LC-60.4.
=====
Guideline 3 begins with some text ("The benefits of....") that seems to be 
a rationale. Other Guidelines jump straight into the Conformance 
requirements - this one should too.

Discussion.  Clarification needed:  In fact, every GL has some verbiage in 
front of the Checkpoints, and several of them can be construed as 
rationales for the GL's collection of checkpoints.  Is the issue about the 
style of this particular verbiage?

Resolution.  Moot (Originator has withdrawn this one.)

LC-60.6:
=====
Checkpoint 3.2 doesn't seem to be directly related to the Guideline under 
which it's classified. The Note for 3.2 points out that checkpoint 8.2 is 
related - doesn't this suggest that the overall structure should be 
re-worked (if they're related, why are they so far apart numerically?)

Discussion.  3.2 is about ensuring that the published TM have the technical 
facilities or capability to support versioning/errata.  8.2 is about 
ensuring that the maintenance procedures are set up.  The presence of 3.2 
in the "synchronize" GL is not completely obvious, but ... an argument 
could be made.

Proposal.  Although there is some discussion about 3.2 and 8.2 already, 
improve it to sharpen the distinction as indicated in the 
following.  Concurrently, incorporate the (telecon/email) change from P3 to 
P2, and the clarifications of the meaning of "versions" (from 
telecon/email).  Specific changes...

Change 2nd sentence of "Rationale" of CP3.2 to:  "Building specification 
versioning/errata support into the test materials' infrastructure is an 
effective way to enable users to select and apply the appropriate test 
materials for a given product."

Delete the 2nd sentence of "Discussion" of CP3.2 and add this 
one:  "'Versioning' in this checkpoint means at least 'Editions' -- 
editorial revisions that incorporate errata and small changes -- rather 
than major versions with major functional increments."

Replace the final "Note." of CP3.2 with:  "Related checkpoint. This 
checkpoint concerns versioning/errata support functionality in the 
infrastructure or framework of test materials. The related @@checkpoint 
8.2@@ is about defining maintenance procedures for test materials to track 
specification versions or errata levels."

Delete the (only) sentence of "Discussion" of CP8.2 and add this 
one:  "'Versioning' in this checkpoint means at least 'Editions' -- 
editorial revisions that incorporate errata and small changes -- rather 
than major versions with major functional increments."

Add to the end of CP8.2:  "Related checkpoint.  This checkpoint is about 
defining maintenance procedures for test materials to track specification 
versions or errata levels. The related @@checkpoint 3.2@@ concerns support 
functionality for versioning/errata in the infrastructure or framework of 
the test materials."

LC-60.9:
=====
The Discussion for checkpoint 4.3 says "To summarize...". This implies that 
somewhere there's a more detailed description of what the QAPD must 
address, but I don't think there is. This checkpoint really seems to amount 
to "document how you meet these other checkpoints", yet the list of "other 
checkpoints" that must be implemented is incomplete. Why doesn't this 
simply require that *all* checkpoints be documented?

Discussion.  See previous LC-58 discussion/proposal.  The other checkpoints 
are all ones (of differing priorities), that require something be done, 
whose verifiable proof is via documentation in the QAPD.

Proposal:  clarify this, in conjunction with solution to LC-58.  To satisfy 
LC-58, add at the beginning of CP4.3 "Discussion":

"The primary goal of a QA Process Document (QAPD) is a single starting 
place to find critical QA information about the Working Group.  A single 
document is preferred, and a template for writing such is included in 
Operational Examples & Techniques.  A table of contents comprised of links 
to distributed WG documents is another way to satisfy the QAPD goals."

Change the two sentences of the current (LC) "Discussion", preceding the 
bullet list, to:  "The QAPD may contain more, but must address at least the 
requirements of these other checkpoints:"

Add "Related checkpoints. " to the start of the last paragraph.

LC-60.11:
=====
Checkpoint 4.6 addresses branding - another argument for a chronological 
rather than a 'logical' grouping (this should be at the end).

Discussion.  It is equally arguable that this is okay where it is -- 
branding policy decision has potential knock-on effects on other aspects of 
the WGs QA life, process, TM, and operations.  Therefore its early 
consideration is beneficial.  Given the resolution that we are not going to 
do a major chronological re-org (LC-60.1)...

Proposal:  Keep it as is.

LC-60.12:
=====
Guideline 5: Checkpoint 5.2 - Define a contribution process. Why only 
priority 2? Without a contribution process you have nothing, surely?

Discussion.  There are test suites that have been built entirely without 
any formal or defined contribution process -- mostly by a single person, 
with ad-hoc acceptance procedures for internal contributions.  Certainly 
not optimal, but also not critical (at least, not in all cases -- perhaps 
in some).  If possible, we should avoid increasing the number of P1 
checkpoints unless we feel they are pretty critical.

Proposal:  No change.

LC-60.14:
=====
Checkpoint 6.2 (defining the license for published test materials) is 
closely related to 5.3 (defining the license for submissions). Should these 
be grouped together (under a guideline that addresses submission processes)?

Discussion.  That would be a possibility.  But, to follow the LC-60.1 
resolution of "minimize improvements that don't fix something really 
broken", we should instead clarify and cross link them.

Proposal:  Cross-reference and clarify instead of 
re-structure.  ***Note.  QAWG and W3C Legal have discussed and have reached 
consensus wording for 5.3 and 6.2, under which it is agreed we can move 
ahead with OpsGL.  This is also bundled in.  See [4].***

To the end of CP5.3 add:  "Related checkpoint.  This checkpoint is about 
the terms under which the WG accepts contributions to be integrated into 
its test materials. Checkpoint 6.2 is about the license(s) under which the 
WG will publish and distribute its test materials."

To the end of CP6.2 add:   "Related checkpoint.  This checkpoint is about 
the license(s) under which the WG will publish and distribute its test 
materials.  Checkpoint 5.3 is about the terms under which the WG accepts 
contributions to be integrated into its test materials."

### end ###

Regards,
Lofton.

[2] http://www.w3.org/QA/WG/lc-issues#x60
[3] http://www.w3.org/TR/2003/WD-qaframe-ops-20030210/
[4] http://www.w3.org/QA/WG/2003/05/qaframe-ops-20030513