Collected issues LC-60.3 thru LC-60.15

For email discussion and the OpsGL telecon agendas...

Ref:  http://www.w3.org/QA/WG/lc-issues#x60
Ref:  http://www.w3.org/TR/2003/WD-qaframe-ops-20030210/

Contents:
=====
Discussion and some proposals on LC-60.3 through LC-60.15.

Preface
=====

Since Last Call OpsGL is the 5th PWD, we have been working on it for 1-1/2 
years, and we are trying to go to CR and avoid 2nd Last Call, therefore I 
think our priorities should be:  minimize changes.  Fix what is broken, 
clarify where needed, but avoid improvements and changes which aren't 
critical to the correctness and comprehensibility of the document.  Many 
ideas which we would probably apply without much hesitation at 2nd PWD, 
should be considered very carefully at this stage.

LC-60.3.
=====
Guideline 2: I'd say "Allocate resources..." rather than "Define resources..."

Proposed resolution:  How about "Define resource commitments..." or 
"Address resource commitments..."?  (I'm thinking of other comments, 
indicating that it is not clear enough that GL1 & 2 are about early 
*commitment* -- Charter if possible, else later -- rather than later 
operations.)

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?

LC-60.5
=====
How is checkpoint 3.1 different from 1.5?

Discussion.  The difference clearly isn't made obvious enough.  1.5 (in 
fact all of GL1) is talking more about documenting the commitment/intent, 
and 3.1 is the act of doing. The discussion of 3.1 tries to draw the 
distinction, but doesn't seem to do a very good job.

Proposed resolution:  try to clarify the distinction, with better wording 
in 1.5, in 3.1 (and possibly assisted with the chronology/GL-CP map 
suggested in LC-57).

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.

LC-60.7:
=====
Guideline 4: Probably should be #1 (it's the first chronologically). When 
we summarized this document in our outreach presentation we made checkpoint 
4.1 the first bullet item...

Discussion.  This is a matter of preference.  GL1/2 are about early 
*commitment* to QA and QA deliverables.  Possibly even in the Charter, 
before the WG is rolling.  GL4 is about process within the functioning 
WG.  It is equally arguable that this is the best order.  By the way, the 
reason that we emphasize "Appoint QA moderator" is ... we were talking to 
existing groups, and this was a clear and simple first step that they could 
take, to help bootstrap their QA.

Proposal:  Keep the current order.

LC-60.8:
=====
Checkpoints 4.1 and 4.2 would seem to belong in Guideline 2 
(define/allocate resources) rather than here?

Discussion.  Again, GL1 and 2 are about early commitment (ideally Charter) 
to QA levels, staffing levels, etc.  GL4 is about performance -- specific 
staff assignments -- going forward.

Proposal:  Clarification?  (Suggestions?)

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.

LC-60.10:
=====
Checkpoint 4.5 uses the ambiguous term "framework" (we tried to avoid this 
in our re-write of OpsGL).

Proposal:  LC-72.7 also mentions this, with some proposed 
re-wording.  Reword and clarify.

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.  Assuming that we are not going to do a major chronological 
re-org (LC-60.1), it is equally arguable that this is okay where it 
is.  Perhaps not optimal, but it seems to work okay here.

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.  Well, I know of test suites that have been built entirely 
without any external contribution or contribution process.  No strong 
feeling about the priority here.

Proposal:  none.

LC-60.13:
=====
Guideline 6: Checkpoint 6.1 contains a mixture of stuff. The guideline 
addresses "publication" but much of this checkpoint addresses "management". 
Moreover, the bullet items in the Discussion section don't seem to relate 
to repositories at all.

Discussion.  Points well taken, especially about the bullet items.  One 
could argue that repository considerations are related to (pre-requisite 
to) publishing.  Perhaps the GL could say "Manage and publish" instead of 
just "publish"?

Proposal:  proposal needed.

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 priorities of 
"minimize improvements that don't fix something really broken", it might be 
preferable to cross link them.  (One could argue that it is broken, 
pointing to my horrendous botch of criss-crossing the verbiage for CP4.3 
and 6.2 in today's email).

Other thoughts?  Could we pull out the two licensing CPs and put them in 
their own GL, without creating the appearance of major changes?  Should we?

Proposal:  Cross-reference and clarify instead of re-structure.

LC-60.15:
=====
Guideline 7: This guideline is labelled "plan the transfer of test 
materials to W3C if needed", and explicitly states "all of the 
checkpoints... are not applicable if the WG does not transfer..." (should 
be "none of the checkpoints are applicable if..."). However, all the 
checkpoints seem to apply whether or not the materials are "transferred". 
It's obviously important to review the quality of submitted tests, to 
ensure that we have the staffing to deal with submissions, and to resolve 
IPR issues.

Discussion.  Doesn't all of the submission stuff get dealt with in 
GL5?  GL7 is about the wholesale transfer of an externally written test 
suite.  Granted, this could be considered as a "submission", but the sense 
of GL5 is I think more piece-wise submission during the building of a 
suite.  Btw, we (QA) have had experience moderating such a transfer, which 
I suppose is why GL7 exists.

Proposal:  Clarify?
### end ###

Regards,
Lofton.

Received on Wednesday, 30 April 2003 20:51:57 UTC