Re: QAH outline

Reading through the QAH and fighting against jetlag:
http://www.w3.org/QA/WG/2004/04/QA-handbook.html

Issues:

+ Pronouns:
	* Don't use 2nd persons. Though you can have some examples and use 
case scenario which explicitly use them, like in a dialog. A good 
verification tool, try to translate your sentence in another language.

+ Style:
	* I don't have precise ideas. I just wish we could find a stabilized 
style for W3C specs.

+ too vague sentence:
	* a hint, markup the sentence, with a span class="toovague" and make 
it pink. So we will be able to see when you think there's a room for 
improvement

+ Good practice/Recommended/etc:
	* difficult to answer. I think in French, it's a bit hard to 
translate. "Bonne pratique" Doesn't sound very well, it might be 
something like "Bonne habitude". Recommended seems very neutral and 
boring. "Good choice", "Good Techniques", "Good way" as in the bushido 
(hmm... does it seem like I'm coming back from Japan).

+ Scenarios:
	* Separate section: It might be a separate section if we could tell a 
story exactly like we will do in a book. A chapter of a book which is a 
story going through all the issues and giving a link to the relevant 
part of the specs. Though it's very difficult to write and needs story 
teller talents. Maybe we should put the scenarios throughout the 
document as Dom said.

+chronology diagrams.
	* use it but by making it a bit different. To think.

+ Why QA?
	* drop it. In the sense that the text itself should be its own 
advocate. You don't need to save it if the text is already convincing.


2. Early planning and commitment

-> Early planning = Reality Check. If you don't have enough resources, 
don't do it. It doesn't mean you have to drop the ball, just be 
realistic with what you can do.
	More features, More tests, more complexities, more difficult to 
implement, less participation, less reviews, less implementation, less 
interoperability, cost more.
	Evaluation of time for the projects is something which is hard to do 
but should be somehow organized by the chairs/staff contact.

How long does it take to
	Think about a new feature?
	Write the prose for it?
	Write the schema/DTD for it?
	Write the test case for it?
	Get the review of WAI, I18N, QA, DI etc for it?
	Get Implemented? (CR)

	( [ouside W3C] + Specs translated, features used in the world, etc.)


"""Tips for Getting to Recommendation Faster (section 3) also addresses 
(early) staffing decisions.
Examples: [Collect them here? or scatter them in the above practices; 
or some of both?]"""

-> The whole QAH is to get Recommendation faster ;)


"""Good Practice: Identify Web page(s) for test suites, announcements, 
and other QA deliverables. [was CP4.4]"""

-> http://www.w3.org/QA/WG/ for us?




reading not finished yet




-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***