- From: Dominique Hazaël-Massieux <dom@w3.org>
- Date: Tue, 23 Mar 2004 13:45:49 +0100
- To: Lofton Henderson <lofton@rockynet.com>
- Cc: www-qa-wg@w3.org
- Message-Id: <1080042310.5460.1337.camel@stratustier>
Le mar 23/03/2004 à 02:28, Lofton Henderson a écrit : > http://www.w3.org/QA/WG/2004/03/QAH-outline.html > Comments welcome. Going through the identified issues: * "Issue: to what degree should QAH introduce the rest of QAF?" "First issue: do we want QAH's intro sections to introduce: all of QAF? or only that old-OpsGL process & operational stuff that will survive in QAH?" To a very low degree ; that is, it may point to the other documents from the core of the text, and may have quick pointers to them from its introduction, but I don't think it should introduce the rest of QAF. My point is that the handbook needs to have the essential stuff, and introducing the QAF in too much details would put too much verbosity at the start of the document. * "QAH & QAF Primer and Usage Scenarios Issue: would this section itself be better as an external, referenced document? It doesn't involve too much content from QAF-intro, so it could go either way -- in-line or external." hmm... To me, the handbook as a whole is a primer, and the usage scenarios would be used all across the document ; I don't think we need a specific section for the primer. * "Day to day operations and QAPD" re "why care", I would note that the W3C Process document organizes clearly the way a spec is developed through the Rec Track, but that it's not the case with other items of the WG life ; given the way the work is done in W3C (distributed, international, etc.), you need some organization rules to get the work done. Also, I think it would be more appropriate to speak of "Test Development process" rather than the generic "QA" process, which will be too fuzzy for most of our readers. I would simplify the section by putting up front the few options available to organize the test development effort, with links to templates ; plus adding the pro/cons for each options, and generalizing a bit in the end to list the points a WG would need to address if it were to build a new process from scratch. * "[Issue: is this an okay approach in the last two bullet lists, i.e., mention the topics, suggest that they can be documented in QAPD (they're in template now), and point to TestLite for details?]" Yes, I think it is a good approach. * re "IANAL but..." There are still on-going discussions on the topic of TS licenses at various places inside W3C ; we definitely need to document the simple way of doing it (meaning that we first need to know what's the simple way is), and probably warn about doing differently as a possible obstacle. * "[Issue: is this worth keeping? It arose because of the XML TS transfer, and several of us in QA spent significant time moderating and helping plan the transfer, and we had to sort out a lot of bits and pieces. So it seems useful to capture that, yes?]" Quite! Dom -- Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/ W3C/ERCIM mailto:dom@w3.org
Received on Tuesday, 23 March 2004 07:46:25 UTC