W3C home > Mailing lists > Public > www-qa-wg@w3.org > January 2003

[www-qa-wg] <none>

From: <lsr@nist.gov>
Date: Tue, 7 Jan 2003 11:40:57 -0500
Message-ID: <1041957657.3e1b0319ad264@imp.nist.gov>
To: www-qa-wg@w3.org
The following are the draft, raw minutes for Jan 6 morning meeting.  

Minutes:  F2F Seattle IG Meeting
06-January 2003, morning

Attendees:
Attendees:
(KD) Karl Dubost (W3C, WG co-chair)
(PF) Peter Fawcett (RealNetworks)
(LH) Lofton Henderson (CGMO - WG co-chair)
(OT) Olivier Thereaux (W3C)
(KG) Kirill Gavrylyuk (Microsoft)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
Guests:
(WC) Wendy Chisohlm (W3C)
(MM) Mathew May (W3C)
(JD) Janet Daley (W3C) (joined mid morning)
Tele-connection
(DD) Daniel Dardailler 
(DM) David Marston (joined mid morning)

Absent: 
(dd) Dimitris Dimitriadis (Ontologicon)
(DH) Dominique Hazael-Massieux (W3C)
(AT) Andrew Thackrah (Open Group)
(JM) Jack Morrison (Sun)
(SM) Sandra Martinez (NIST)

Agenda: http://www.w3.org/QA/2003/01/agenda-detail

Action Items:
OT:  Proposals for Glossary discussion and presentation at Tech Plenary íV Jan 9
KD, MS, and WC (owned by KD): coordinate with WAI and develop a how-to draft 
for entering definitions into the glossaries íV due Feb 17
LH: Executive Summary of OpsGL íV due April 15
JD: send to LH a template or examples of executive summaries
KD: Ownership of Kit.  Write a summary of what needs to be done for the kit íV 
due Jan 8
OT and JD: need to find someone to interact with MMI - 
OT: plan for outreach with WGs during Tech Plenary íV Feb 1

Introductions
Review of agenda for first morning

Logistics
Lunch at local restaurants and boxed
Dinner hosted by Microsoft, Tuesday. 
Visit to Microsoft company store, Wednesday 

Glossary 
OT summarizes: We have a QA Glossary (http://www.w3.org/QA/glossary), a 
glossary in each spec, and are also involved in gathering glossaries among 
various other groups. 
WC: There is a combined WAI glossary, trying to harmonize terms from the 
various WAI documents into one place.
OT: Many are using the same terms with different definitions.  In QA, it is 
important to have consistency across specifications with respect to the wording 
and meaning of the words.  We could look at existing glossaries and pull 
together into 1 document or start by creating a global glossary.  We need to 
discuss our approach and what we need to do for Tech Plenary. 
www.w3.org/QA/2002/01/Glossary-req gives a summary of a global framework for 
people to input terms and definitions. Our glossaries will be tied to some 
instance in a document and not to the group itself íV context sensitive.
 (david marston joined)
Do we plan for the unification of glossaries or plan a discussion that would 
lead to a task force for a glossary unification effort. 
LH: Issue 19 was reopened íV should there be glossaries in each spec?  How do 
definitions in each spec relate to a central QA Glossary?  A summary and 
proposal is at http://lists.w3.org/Archives/Public/www-qa/2003Jan/0002.html.  
The WAI model is a good one.  For each spec, there would be a section called 
Definition, with a definition section specific to that spec.  The QA Glossary 
would have a terse general, central definition of the term.  The specific 
context sensitive definitions in the specs caníŽt contradict the central 
definition. 
WC: To implement this, is the plan to have everything in 1 place and pull from 
there, or to have terms distributed and pulled into 1 place?  It is important 
to make sure that there is consistency between what QA does and WAI.  
KD: What is important is to agree on the model and then we can figure out the 
Pubs Rules for it.  Once we have this, we can encourage other groups to do this 
as well.
OT: QA could orchestrate, coordinate the effort.  
WC: Glossary would be a good topic for WednesdayíŽs Plenary.  We can have an 
open discussion and start gathering requirements. WAI is planning on spending 
several hours discussing glossaries.  They just doníŽt have room to host it.  
OT: We need to do 3 things - interest people in having every group input to the 
glossary, get them interested in formulating the glossary model, and to do a 
Call for Participation.  
KD: There maybe a problem with markup.  Maybe we could define simple tools to 
help build markup for glossaries.  If you want to encourage people, you need to 
give them the tools to do it. 
MM: We will need a process to mediate between groups with different 
definitions.  Ultimately we want definitions that are consistent across groups.
LH: Propose that we take our model (his proposal) and build it, showing how 
this would fit into a universal glossary and this could be used by other 
Groups. 
OT: Proposed course of action:
1. List group with glossary - who has what, who doesníŽt have glossaries
2. Call for participation ä│ model íV create a model and see if it scales
  The Planning Group could work on the call for participation
3. 1st prototype with QA glossary íV 
OT to seek out interest in glossaries. WC will help.  Also, discuss with Janet 
getting a session at Tech Plenary. The goal for Tech Plenary is to have open 
discussion, form a group, and if possible have a prototype.
LH: There is the concept and there is the problem of resources.
OT: Will take some of this responsibility. 
DD: I may have a candidate to work on the Glossary, in February.
WC: There may be some resources from WAI and I18N íV we should pool resources. 
OT: For Tech Plenary, we will discuss with WAI on Friday, and talk more with 
Daniel LH: Is the proposal O.K.?  All accepted.  Issue 19 closed.  Affirm that 
each spec can have a Definitions section with context sensitive definition and 
it relates to the QA Glossary.  
KD: There are still some process issues to work out. Need to define the 
mechanism to enter definitions, review it for consistency, etc. 

Outreach íV Success criteria from QAWG charter
LH: Review of success criteria in Charter íV with what we are doing and what we 
have not done.  
JD: There is already coordination with Comm.  The Comm role is almost a 
production role with respect to getting the documents published.  Comm fully 
supports QA.   
KD: There may be a misunderstanding with the Comm team role.  The part of 
quality having to do with publishing our documents is met.  We need to define 
the mechanism to have the WGs apply the documentation we are writing into the 
Comm process.  Having a QA person in each WG would be great, but we doníŽt have 
this yet. 
JD: As good ideas mature as best practices in QA, it would be good to have 
those incorporated into Pub Rules. To be in Pub Rules, we try to make rule as 
clear as possible, implementable, and to make sure all document templates are 
kept up-to-date.  
KD What happens when a change is made to Pub Rules? 
JD: Some things go smoothly, others doníŽt.  Get suggestions from Chairs, the 
Team, WG members; we doníŽt usually get suggestions from the public.  The Comm 
Team and Web Master go over the proposed suggestion to determine how easy to 
implement, the burden to implement, etc.
KD: Conformance section is a nightmare.  Some groups refuse to include 
conformance, think the IETC MUST, SHOULD statement is enough.  Requiring the 
inclusion of  a conformance section through Pubs Rule would be too much a shock 
for some groups.  

Re Charter QA
LH: Do we think we will be rechartered? Approaching last call on 3 of our 4 
documents. 
JD: Rechartering process straight forward.  Look at this 3 months out.  Domain 
leader becomes aware of expiration of charter, the status of the documents and 
the amount of time needed to continue.  QA was chartered before the CPP (patent 
policy)was in place.   If there are deliverables with IPR, then the charter 
needs to go before the membership again. 
LH: Does the group think it will continue or pack up and go home?  Implicit 
that we go on. 
OT: Do we recharter with current work plan or recharter with new work plan.  
LH: Should recharter with emphasis on testing task force, recognize that 
heaviest effort on writing the framework is done. 
KD: To reach Rec stage, must have 2 implementations.  So need 2 WGs to 
implement the guidelines. 

Outreach to WGs and Team
OT: Presents the following plan for outreach,
1. Goals:
1.1 Awareness
1.2 Commitment íV to QA, of resources
2. Means:
2.1 Requirements they Groups must meet
- - - QA involved in Charter review 
- - - Review calls
2.2 Direct outreach íV partly for the Team
 - - - Domains
- - - Groups (TP)
- - - Project review - team
2.3 Kits and Documents íV for the WGs
- - - Framework is for WGs, especially for WGs
- - - How to contact WG íV benefits, success stories
- - - How to start task
- - - Business cases (for AC, for WGs)
- - - Tutorials(?)
2.4 Interface
- - - WG (process)
- - - TTF
2.4 Side benefits íV done for the AC
- - - Image or representation (if companies think that if do more QA then get 
more voice in WGs)

OT: Propose that we come up with a plan for the next few months.  Prioritize 
the order and develop a plan to build up our arsenal.  Put up or shut up íV so 
when we say, we are here to help you.  The answer isníŽt go away or if invited 
to help, we say sorry, no resources. 
LH: Has outlined some ideas for an outreach kit and how to talk about QA at 
Tech Plenary
OT:  Asked for comments from guests and what has been done in WAI.  What 
lessons have been learned when asking people to take on horizontal work.  
WC: WGs are often frustrated because you caníŽt always review everything, so it 
doesníŽt get reviewed to last call, when people are more resistance.  Lesson 
learned is to review requirements document.   Having a QA person in each group 
would also be interesting to see how that would work out. 
KD:  It may be interesting to have a checklist as part of the Pubs Rules 
checker to remind people about QA and things that should have been done. 
JD: That is not a bad idea, but the checker isníŽt usually used until the last 
minute and people only want to get it to pass and be done.  Things that are 
successful include: person to person communication and having someone from the 
QA WG available to help them meet their requirements.  In the kit, show why it 
is to the WGs benefit to have the work done in their language, not W3C 
language. 
LH: The kit should include success stories íV showing how it can shorten their 
process or improve their documents and implementations. 
MS: If we look at this narrowly, this is to benefit of the community, not the 
WG.  The Rec isníŽt the final goal, the goal is good implementations.  This 
doesníŽt shorten the time to get to Rec. 
LH: Chris Lilley will say that they got to Rec faster in SVG. 
JD: You need both.  You need to win over the people in the WG.  What will move 
them is to help them succeed with 1 CR period.  You do this by helping them 
build a clean CR, with clear requirements that can be implemented. 
KD:  Even giving examples, you caníŽt always convince everyone. 
MS: The AC is strong willed. If they doníŽt agree with the higher level goal, 
then we can never be successful in getting QA accepted.  
JD: People are all for QA until you need to do QA.  
KD: For the kit, need to identify the target audience. Is it for new people, 
people inside the WG, etc?  The key is who the kit is for and then target the 
information to that person.
OT: New groups are an interesting and possibly the best target. Specifically, 
DI (Device Independence), they have been very curious about QA.  
LR: It is necessary to target various levels (e.g., Team, AC, WG members), 
tuning the message to each group.  
JD: Writing documents isníŽt enough, but need to talk with people directly. 
OT: But, you need to have documents to backup what we talk about. 
JD: Multimedia Interaction is a new group; QA may want to engage them now. 
There are some groups that have more resources than others. Look at WGs that 
are Team heavy, but look at those groups that the Team is not a major force, 
e.g., Multimedia.  So if you get QA buy-in, you will have a real success 
story.  ItíŽs a young group with lots of industry support.  Think about the ones 
that are getting more play íV those getting new members joining.  

Outreach íV attracting interest in QA: Executive Summary and quick tips
KD: It isníŽt necessarily getting resources into QA, but to get consistency and 
continuity. Often you get someone for a few months and then they go away.  We 
have said that we wouldníŽt do the QA for you.  What is important is to have a 
QA contact - a person responsible in the WG to check and ensure QA happens.  
Depending on a WG charter, you can have more than 2 people from 1 company on a 
WG.  So a company can put 1 person for testing in each WG.
OT: OpsGL goes to Last Call soon.  It may be good to have a OpsGL primer that 
is more AC oriented. Based on JDíŽs comment regarding primers (e.g., born out of 
unreadable specs), change that to sales pitch.
KD: If companies can add people to WGs to focus on testing, that may result in 
other companies also wanting to add people for testing. 
WC: Quick tips have been a tremendous help. An executive summary is also very 
helpful.  Boiling things down is appealing to people. 
OT: summarizing:  We can have the kit include executive summaries for Ops and 
then later for Spec and Test.  Need owners.  Target is the AC.
JD: Should be like a press release íV what is this all about íV 3 bullets.  Quick 
tip list is like an operational summary. An Exec Summary could be included in 
the new project review and be put it in the newsletter and on the home page. 

Outreach Topics for Tech Plenary
JD: It may be interested in having the presentation be specific, e.g., to a 
spec where it really helped, testimonial, SVG may be interesting, talk about 
what goes wrong, or hearing about how QA is useful. 
MK: There are two goals íV sales pitch and inform them of what they will need to 
do.  
LH: We could go through the SpecGL and talk about what needs to be done and 
how íV basically an Extech of the document.  
JD: What you doníŽt want to do is have a session where everyone pays attention 
to the screams about, look what W3C is making us do now.  Think about what 
would be important to the audience and what will they respond to.  Be careful 
of the challenge that you present.  You doníŽt want to be the QA cop. 
WC: you can use the glossary as an example of what QA does and can show an 
example, using RDF of what can be done.  Give them something to play with, so 
that they can understand.  You can also tie in the other horizontal groups. 

Lunch. 



  



   
Received on Tuesday, 7 January 2003 11:41:09 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:12 GMT