DRAFT - Afternoon 1 - F2F QA WG - TP - Mandelieu 2004

DRAFT - Afternoon 1 - F2F QA WG - TP - Mandelieu 2004
Scribe: Lynne Rosenthal

Participants:
LH Lofton Henderson
MS Marc Skall
PC Patrick Curran
DH Dominique Hazaël-Massieux
LR Lynne Rosenthal
KD Karl Dubost
OT Olivier Théreaux

Observers:
MB Mary Brady, NIST
        JC  JeremyCarroll, HP

Topics:

*Future options for QAF proposal
Impossible to implement QAF as is.  All agree that we need to improve the 
organization and readability of the documents - documents need to be 
restructured, address information at a higher level and include examples. 
Make people want to use it. Not impose process for process-sake. Need to 
provide useful tools in order to help people achieve the goal. People don’t 
even have to know that it is QA, however at some point, it is important 
that people be educated as to the QA principles that they have implemented.

  [PC] Sympathy for people who think it is too complicated and 
restrictive.  Open to restructuring.  Much of trouble related to process.
[MS] Need a different approach.  Need to change people’s their mindset and 
direction.
[KD] Mandatory-ness can evolve. Go back to the practical  how to implement 
to achieve quality.  Trojan horse approach  once they are using the tools, 
then you tell them
[MS] People need to be aware of QA principles and what they need to know
[OT, LH] Process is already considered a burden. Perceived as hoops.
[DH] Need to improve the organization and readability of the 
documents.  Need to convince WGs that it is useful.  Achieve the goal we 
are setting, by providing various examples and alternatives.  Not worry 
about what is mandatory now.  Need to look at the global picture of the 
framework.
[LH] Need to keep only checkpoint that are truly important, rest of stuff 
may be good, but not critical.
[KD] Really a working handbook for team and WG chair.
[PC] Essence is the Guideline, the rest is redundant or next level down.
[MS] What is the right thing to do, how do we do it, and then how do we 
sell it.

*Plan of Action  How to proceed.
OpsGL repackaged as a handbook.  Work to continue on SpecGL and TestGL, but 
at a higher, simpler level. Work on a specific issue, complete it and then 
more to the next one.

[MS] go through CP and identify high level CPs.
[KD] CPs must be applied. Must make it useful.  We have failed at this.
[DH] What are the biggest problems in W3C is it how specs are written, 
tested, etc?
[PC] Specs and tests are 2 different things. People are developing tests, 
but not necessarily conformance test suites. Perhaps the standards we are 
setting are too high for people to meet.
[DH] What type of documents are we trying to produce?  What should be 
mandatory? How mamy resources in this effort vs future 
efforts?  Applicability beyond W3C?
[PC] Not able to add requirements to other WGs.
[JC] Higher you pitch, the easier it is to sell.
[MS] Not imposing process for process sake.
[DH] Usability vs abstract and widely useful.
[LR] DoV is complicated, advanced  good information, but start with 
something simple, like optionality can hurt interoperability.
[JC] DoV was helpful information and something that the WG needed to 
address.  Need to sketch out the various possibilities.

* Proceeding on Ops.
Identify high level principles.  Enumerate QA deliverables and milestones 
at a high level principle and all others follow this, e.g., staffing 
resource, licenses. Specifics:
-- Make CP 1.4 a high level principle. Guideline 2 is a detail of CP1.4, 
necessary to accomplish CP1.4.    CP1.5 adds an additional requirement to 
CP1.4.
-- Guideline 3 reminds people of the importance of synchronization.
-- CP4.3 Process document is useful.  Much of this can be accomplished via 
the template and thus, doesn’t need to be a checkpoint.

  [DH] Need someone to make a proposal for what Ops Handbook looks like.
[LH] 3 Ops problem topics are: not enough staff, stuff being done too late, 
licenses.
[JC] Problem is not insufficient staff, but insufficient motivation. RDF - 
tests were useful, so everyone developed tests, ran tests, etc.  WebOnt 
more difficult to motivate.
[MS] What need staff to do and how to energize staff.
[MS] Define commitment level.
[LH] General commitment, since you don’t know what you are doing yet.
[PC] Enumerate QA deliverables and milestones. The rest becomes details 
that follows.
[KD] This has not been the case in the past, i.e., QA deliverables were not 
identified in charters. Useful to have a model.  Need to find a strategy to 
convince people to do this.
[JC] Test work usually gets done after specification finished.
[MS] CP 4.4 why is this needed, it is already required by W3C process?
[MB] Some of the things in a process document include, how to submit tests, 
what happens to them, errata process.
[JC] Getting rid of checkpoints will be a great help.  Putting it into the 
template is an easy way to get people to do it  e.g., mailing list in the 
process template rather than having it as a checkpoint.

  *How to progress work
Make more progress if we work on smaller modules, working as a group and 
moving on when a piece is completed.  Focus on high level principles and 
progress them, including tools and templates. Target for deliverable in 6-8 
months, then target next more detailed edition.  Pick a small number of 
areas/topics to work on.  Start with one, write the prose, examples, tools, 
templates, etc., and when done, start on next topic. Need to go through 
checkpoints and sort through them, rating them as to which are high level, 
duplicative, etc.  Each editor to lead discussion and go through each 
document, identifying major principles.

[PC] Due to the interrelationships between documents, we need to proceed 
together.
[DH] Need to start with a model  the big picture.
[KD] The CSS WG have multiple modules they are progressing. Problem is that 
there is no big picture, tying it all together. But, we have the big 
picture.  By making it small, we can complete it, making everyone work on it.
[LH] don’t know if having small modules will help us to progress in a more 
timely manner.
[KD] Advantage is that if we can’t achieve something, we will know early on 
that it doesn’t work.
[DH] This applies QA practices to our own work. Also help to ensure 
consistency among various components.
[PC] Concerned that to do all the pieces within a module, we may not be 
able to finish.  What about taking what we have and make them friendlier 
and at a higher level.  Better to finish something with a few things in it, 
then something we lots of things and is incomplete.
[KD] Even if we do that, we still need to provide all the pieces  e.g., 
examples, tools, templates, etc.
[JC] Suggest going through all the documents and pick a small number to 
work on over the year.
[KD] For each topic, create prose, tools, examples, etc., then go to next 
topic.  What do people need?
[OT] Asked for help on charter and tests
[DH] Asked for spec.
[PC, MS] evidence that spec is a problem.  Develop various living 
documents  e.g. FAQ, quick tips, Wiki - evolving over time.
[JC] DoV valuable contribution, rather than define your scope.
[PC] software engineering practices for writing spec (e.g., define your 
scope). Value in looking at the various checkpoints and sort out the 
obvious.  Some is good advice, but we don’t need to spend a lot of time on 
it.  Refactoring.  Need to figure out the form we want to present stuff.
[JC] Target specific WGs and specs, not try to address everything. 
Concentrate on the core W3C spec and exclude other things.

  [QAF options] http://www.w3.org/QA/WG/2004/02/QAFproposal.html