Final Minutes QA Working Group Teleconference 2002-10-16

  These are the final minutes for the QAWG telcon, 16 October 2002

  -Andrew

  QA Working Group Teleconference Final Minutes
Wednesday, 16-October-2002
--
Scribe: Andrew Thackrah

Attendees:
(DD) Dimitris Dimitriadis (Ontologicon)
(DH) Dominique Hazael-Massieux (W3C - Webmaster)
(LH) Lofton Henderson (CGMO - WG co-chair)
(KG) Kirill Gavrylyuk (Microsoft)
(SM) Sandra Martinez (NIST)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(AT) Andrew Thackrah (Open Group)

Regrets:
(KD) Karl Dubost (W3C, WG co-chair)
(JM) Jack Morrison (Sun)

Absent: (PF) Peter Fawcett (RealNetworks)


Summary of New Action Items:

AI-2002-10-16-1: LH to start email discussion about possible presentation 
material 					for outreach to other 
groups.

AI-2002-10-16-2:  LH to start discussion on IG list of last bit of 
Issue 				  19, per-document definitions 
(supplemental to and starting 				  from  QA 
Glossary definition.)


Agenda:
http://lists.w3.org/Archives/Public/www-qa-wg/2002Oct/0054.html

Previous Telcon Minutes:
http://lists.w3.org/Archives/Public/www-qa-wg/2002Oct/0074.html

Preceding F2F Minutes:
http://www.w3.org/QA/2002/10/f2f-minutes

Minutes: 

2) Logistical topics
~~~~~~~~~~~~~~~~~~~~

LH: We have approval for new bridge . We start next Monday,  meeting 
weekly  	time: 1100 -1230 US Eastern (To be confirmed)    	 
Think it's the same bridge info (phone number, password etc). We should 
aim for 	1 hour meetings with the final half hour in reserve for 
extra work.



3)  Tech plenary [1]- any "meet with" requests?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	[LH asks if anyone has any special requests to meet with other 
groups during 	 the Tech. Plenary]
	 LH: Item #1 has a preliminary meeting schedule. We have 
Thursday/Friday for our meeting.
	We should think about whether we want to meet with groups 
face-to-face, pay visits 	and present something or sit in and see 
what they are doing.
	 
	[The are no comments or requests about this]
	 
LH: We could make a 15 minute presentation for telcons and outreach use. 
Continue 	this discussion on email.
	 
	[Action: LH to start email discussion about this]
	 

4) QA and new Errata proposal - adopt DM positions? (DM: David Marston)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

LH:	Original req came out 19 Sep. - I noticed they ask for feedback by 
3 Oct.
	Do they still want comments? I asked for comments from QA 
perspective.
	DM has given comments. In GL docs we do address (it) so we should 
point 	out QA implications of the err. proposal.
    KG:	We should give comments (if we are not too late). Re. DM's 
comments about process: 	communications of issues that would have 
effect on conformance requirements of a spec. 	but proposal also had 
something about breaking changes - 	 
LH: That's the definition of substantive. The Err. proposal does a good 
job of classifying. 	As DM says - it has a good, careful definition of 
substantive changes ....

KG:	That should be of most interest to us

LH: This affects whether one can have test cases or not. Groups maintain 
errata lists - 	they don't become normative until new doc is published. 
Tying test to errata levels needs 	to be looked at more carefully 
since we are going be tying them to errata levels.
	Also seems to downplay the barrier to republishing a TR (every 3/6 
months?). The review 	processes are fairly light. Editors with heavy 
workloads are not going to view this as 	a small activity - to 
republish. The errata doc considers carefully implications of what 	 
should be normative. It points out that errata, like anything else, must 
be in /TR/ to 	be normative.  And from that, recommends republication of 
the whole spec, with 	approved errata folded in, as the way to finally 
make them normative.
   KG:	We still need to figure if we can give feedback 
LH: Assuming that they are still interested - since DM is the only 
commenter so far - if he's 	willing to work on it more - we could take 
it as a QAWG response.
	 
KG: I'd like to have input to that. 
LH: lets say Noon (US Pacific) Friday this week for comments. Any one else 
want to participate?

	[No response from others]

LH: In that case we'll go ahead with DM's email


5.) A couple of issues: #19 and #99 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


LH: There was a request in Tokyo that this be reopened. I want this (#99) 
to be reopened:
	It is dependent on issue #19.

	[summarizes issue]
	 
	GL docs may have definition in addition to a glossary - but must 
not contradict it.

MS: What are the choices? It's redefining words - are we going for 
separate glossaries?

LH:	I called it a definition section so would not be confused with or 
challenge the 	QA glossary.
	Definition should start with reference to glossary and then 
provide extra 	qualifications - but not contradict it.
	  MS:  So the assumption is that the glossary is not complete - so 
could we expand a definition in 	body text of a document?
   LH: I don't think that works - I myself couldn't find in situ 
definitions in my own docs. It's 	hard to remember where all 
explanations are if they are spread through the body of a doc.
	  MS: Ok. Then could you point to specific examples of why this is 
needed?
   LH:	Definition of  Test Assertion - look back to May, there is 
discussion about this 	[ 
http://lists.w3.org/Archives/Public/www-qa/2002May/0000.html ]. This 
thread shows that 	e.g. TestGL or SpecGL needs more than a terse 
definition.
	  
LH:	So we are talking about a specific type of definition. The 
glossary definition holds but 	now we are talking about a specific type?
   LH: Yes  [gives more examples ]
   SM: Wouldn't that go in the ExTech doc?
   LH: It's a question again of findability - a definition needs to be to 
hand in the current doc.
   KG: There's no way we can keep a glossary during editing of working 
drafts. until publication 	most of the useful definitions will be 
inside the specific docs. Then when complete - we can 	propagate these 
definitions back up to the glossary.
   LH: I think it should be up to editors/working group to add definitions 
where needed.
   MS: But what about consistency across documentation? We may end up 
redefining glossary definitions
	that we disagree with. Doing this at the end is fine - but let's 
keep a single definition in one place.
   LH: We can link from document definition to QA glossary as first 
step.   DH: We could chose a point during the documents life where we 
synchronize with the glossary.   LH:	I'm not yet convinced that the 
glossary is sufficient for GL docs.
   DH: But eventually it should be

KG: I prefer per-document definitions.   LH: Can we take discussion on to 
the IG list?
   MS: On IG list - let's not use Test Assertion as the working example- 
too controversial. 	We need another example.
   	[ Action:  LH to start discussion on IG list of last bit of 
Issue 	19, per-document definitions (supplemental to and starting from  
QA 	Glossary definition.) ]
	 

	 
6)  OpsGL issues #60, #59 [, #32?]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	[ Postponed - Moved to Agenda for Monday 21 October 2002 ]
	 

7) SpecGL - editing questions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DH:	I began to redraft a good number of check points - each contains a 
testable assertion. 	I deleted a lot of text - some irrelevant, some 
moved to ExTech.   LR:	I like the changes
   MS: I agree. I like the format. How much deleted text will move to 
ExTech? 	is it just the yellow blocks?
   DH: Most deleted material concerns DoV [Degrees of Variability]. I'm 
trying to simplify this.   MS: Check points are irrelevant to determining 
level of conformance?
   DH: Yes.   MS: We should go through instances of 'Should' and check if 
they should be 'Must'
   DH: Agreed, please do
   LH: Let's do it after publication
   DH: Even better, yes
   LH: For Ops. and Spec. we have to verify all keywords.   DH: We are 
unlikely to be using 'May'
   LH: Dom -  how do you feel about reviews of the doc - before or after 
publication?
   DH: I'll be away last week of November - so I won't have time to work 
then.
   LH: Let's postpone then. Do it on Nov. 6 version at start of next cycle
   DH: Ok. Red borders mark the most important text for feedback. GL12, 
ckpt#1 needs review.
     [DH and LH do some editing]
   LR:	Re minimal support - this is a level. Often have multiple classes 
of product - 	 
	It's not clear that a single minimum level applies across all 
classes.
   LH: Re. minimal support requirements - E.g. for a graphics generator 
this is a kind of 'maximum'. 	so 'minimal' is not necessary a good name.

LR: I've seen this in the VRML spec. Levels would take care of it. It's a 
matter of understanding 	what a level is.
	  LH:	This checkpoint could be made a conditional of previous 
checkpoint- or an example in ExTech.
   LR: Are we confusing people by adding this extra caveat?
   DH: Re. text of GL#3: about non-applicability of profiling. is this 
useful/true?
   LH: It's true, but useful?

DH: I will remove it.
   LH: It's easy to get mixed up in DoV - new design should make it easier 
to avoid this?
   DH: I Will have a new design by Monday's call   LH: The last paragraph 
re. excessive variability - is this deleted?
   DH: It can be moved to  informative section or a general warning in 
introduction.
   LH: It's useful as a 'Should'. And it was put in there to resolve an 
issue so should stay 	in somewhere
   DH: It will be in there - maybe as a generic guideline for DoV.

LH: I'll circulate proposals for rewrite of the intro.

---
Adjourned
--

Received on Monday, 28 October 2002 13:08:47 UTC