Minutes of F2F meeting, June 16 PM

Attached. Please respond with comments before end of day June 18

=============================

QA Working Group F2F Minutes
Tuesday, 16-June-2004 - PM
--
Scribe: Patrick Curran

Attendees:
(PC) Patrick Curran (Sun Microsystems)
(KD) Karl Dubost (W3C, WG co-chair)
(DH) Dominique Hazaël-Massieux (W3C)
(LH) Lofton Henderson (CGMO - WG co-chair)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)

Regrets:

(DD) Dimitris Dimitriadis (Ontologicon)
(AT) Andrew Thackrah (Open Group)
(VV) Vanitha Venkatraman (Sun Microsystems)

Absent:

Summary of New Action Items:

AI-20040616-2 DH to email Bjoern to check that we understand him correctly. Due June 30
If we have understood him correctly, we agree that we should address this
in SpecGL.

AI-20040616-3 KD to rewrite principles and good practices from section D3 and
D4, using shorter sentences. Due June 25.

AI-20040616-3 LR to respond to Jeremy Carroll, addressing his comments. Due June 21.


Minutes:

o SpecGL discussion

BH clarification of CR-29 issue
-------------------------------
http://lists.w3.org/Archives/Public/www-qa-wg/2004Jun/0020.html

Requests that conformance-related terms be defined, and that
specifications define labels (names) for implementations that conform in
a particular manner.

It's not enough to say "your implementation conforms if it does a, b,
and c" must also add "and it can then be refered to as a
'foo-conformant' implementation.

Issue: some specs have a discontinuity between the prose of the spec and
the conformance clause (prose may say "must do a, b, c" but conformance
clause may not reference those requirements).

DH took AI to email Bjoern to check that we understand him correctly. If
we have understood him correctly, we agree that we should address this
in SpecGL.



DH comments (no reference)
--------------------------

* We claim we use RFC keywords, but are doing so inconsistently
LR: is trying to avoid using them
Decision: remove the 'boilerplate' RFC keywords section (and also from the normative
section)
* Avoid using abbreviations as much as possible
* Text inside "good practice" sections should make sense "out of context"
(if extracted into a separate list, for example)
Eg, from B1, change "Be direct...  to "When defining the scope, be direct...".

A1: "Why care" justifications sometimes don't address benefits in terms that "appeal to"
the spec author. Show how their self-interest will be served by following our
recommendations - to say "you will meet our recommendations" is insufficient.

Avoid using the term "DOV" in section A1, provide specific examples
instead.

* Need a smoother transition (segue) between guidelines (eg, from A to B)


Jeremy Carrol comments
----------------------
http://lists.w3.org/Archives/Public/www-qa/2004Jun/0007.html

"A.2 I have a weak pref for this principle to be a GP"
We agree

Use the term "conformance designation" in Technique section 
(addresses the need for a "label" discussed earlier)
This should be a link to an explanation of this term in A1
(which is where it belongs)

Editorial: "What does it mean? Most of those items... " - 'those'
was a backward reference to the items in the list that is now below.

What should be the principle? 

Should it be "how to make the claim"? We are relunctant to go this far;
danger of getting into licensing, branding, certification issues.

Provide simple and a complex examples?

MS: "the specification should require..." seems odd (we suggest that the
spec make an absolute requirement...)
Combine this with "a well-formed conformance claim..." above


----------------------
NOTE: discuss later structure/organization of our docs. Eg, what makes
a principle as opposed to a good practice? What is normative, and what
isn't?
----------------------


B.1 first GP suggest delete "Don't specify requirements"

We agree that requirements don't belong in the scope section. Must explain
this in more detail, as JC suggests. 

D.2 first GP suggest delete "Determine the need for each option" - the
GP is conveyed by the second sentence in the box
Agreed.


D.2 third GP "Address" unclear, perhaps replace with "Adequately consider"
TODO: Change to "Consider", not "Adequately consider"

D.3 (and D4)
I note an editorial inconsistency in the style of the Ps and GPs in this 
section from the earlier ones. Personally, I prefer the simple short 
imperatives in the earlier sections, with detailed comment below. I 
believe the document would benefit from consistency.

We agree...

First principle should be simply "Consider whether some parts of the
specification will benefit from extensibility."

Rewrite good practices in short sentences.

Make "define a mechanism to allow for any extensions" another principle?


[Discussion of KD's restructuring of this section into several (short)
good practices...


E - thank you for including this section...

Generally agree.

We should link to the editor's homepage (which links to all the tools) rather than
mentioning/listing them specifically here.


"By-the-way, this section goes along way to addressing my earlier comment 
on the QAH, as to whether this is a Quality framework, or merely a test 
framework - I suspect a sentence or two (in QAH?) acknowledging further 
W3C 'quality' issues such as WAI and I18N, but noting that they are 
currently out of scope, and handing off to appropriate pages - would 
cover all the ground."

Sounds good...

1) delete the ref to RFC 2119 and don't use those keywords. 
Agreeed

2) I think the GPs should be normative as well as the Ps.
We will discuss this later

3) Provide an ICS which lists the Ps and GPs and allows the spec edtor 
to drop URLs in to a form.
Agreed



Jeremy Carroll additional comments
----------------------------------
http://lists.w3.org/Archives/Public/www-qa/2004Jun/0009.html

Yes: we would like to use his story

Re suggestion that we don't make "negative stories" anonymous...
We prefer to continue to preserve privacy...


-----------------------------------------
Todo tomorrow: Test Case model discussion
-----------------------------------------

Karl Dubost plan for SpecLite advancement
-----------------------------------------
http://lists.w3.org/Archives/Public/www-qa-wg/2004Jun/0023.html

We agreed that Karl's proposal is a good one.
Allocation of work: Lynn, Karl, Dom will write - others will review

A: Karl
B: Lynn
C: Dom
D1: Lynn
D2: Mark to review
D3: Karl (see earlier AI)
D4: Karl (see earlier AI)
D5: Dom
E:  Karl

TODO: need a definition of "Quality Control"


Discussion of principles/practices/normativity
----------------------------------------------

LR: Principles are normative - they are the requirements.
Where are the conformance requirements?
PC: the word "principle" seems wrong for something that's normative.
Reopening the discussion of should we have "strict" normative
language?
LR: rename the A, B, C headings "principles", and rename the principles
as requirements. 
Are good practices normative? 
Do we need a new definition for normative...
Narrow: prescriptive language - you must (what is required for conformance)
Broader: can be explanatory text that provides further explanation of (narrowly)
normative text
No resolution....

Beware overly authoritarian language...