- From: Dan Connolly <connolly@w3.org>
- Date: Fri, 29 Aug 2003 09:49:11 -0500
- To: www-qa@w3.org
Regarding the intro to the QA ops document http://www.w3.org/TR/qaframe-ops/#introduction http://www.w3.org/TR/2003/WD-qaframe-ops-20030210/#introduction (and http://www.w3.org/QA/WG/2003/08/qaframe-ops-20030905/#introduction) It's clear that a lot of work has gone into this document, but I'm afraid the first few pages are so dry that they'll turn away 80 to 90% of the intended audience. Don't start the abstract with "This document..." An abstract is not a description of the document but rather an abstract of the contents. The status section is over a screenful. I bet you can say what you need to say in 4 short paragraphs. For example, trim this... "Future progression of this document beyond Working Draft is planned, but the final status has not been determined at this time. See QAWG issue #18 and issue #71. It is anticipated that this specification will eventually advance to Candidate Recommendation (CR), after successful discussion and resolution of any and all issues that arise during Last Call review." down to... Provided this last call review confirms that issues have been resolved to the satisfaction of reviewers, the QAWG intends to request Candidate Recommendation. See also issues issue #18 and issue #71. If readers are turned off by the first few pages of materials, that's a huge opportunity missed; an opportunity to show that integrating testing and QA into the whole experience makes it *more fun*... an opportunity to say "hey! if you're not doing test-driven development, you're missing all the fun!" and "if you want your technology to get deployed, we have lots of experience that integrated test development is the way to get there." I suggest the QA ops guidelines start by telling two stories: Project A did all their spec work assuming they'd do testing and QA later. The spec was finished in 9 months, but early adopters moaned and groaned about the ambiguities in the spec and the marketplace was rife with confusion. It wasn't until 3 years later that folks were motivated to develop a test suite. The technology was eventually deployed, because it was very much needed; but not gracefully at all. Project B did test driven development from the start. The spec and test materials took 18 months to develop, but by the time they went to REC, they had 4 interoperable implementations; two of which passed all the test and two of which were successful commercial products. Developers raved about the ability to use the test materials in their development, and to give feedback on the design before it froze. The user community was able to use the test materials to objectively point out defects in the commercial products, allowing them to be fixed straightforwardly in point releases. 9 months after the spec went to REC, the marketplace of interoperable implementations was so well established that the technology became ubiquitous, and everybody wanted to be part of the W3C process where the next new technology was developed. I see that some of that material is in the QA intro... http://www.w3.org/TR/2003/WD-qaframe-intro-20030210/#b2ab3c47 but readers have to be pretty motivated to get that far. Perhaps copy/move some of it to the ops guidelines. Is the QA Framework intro supposed to go to CR with the ops guidelines? By way of example, the WebArch document http://www.w3.org/TR/webarch/ has some scope and intended audience stuff too, http://www.w3.org/TR/webarch/#about but we put it *after* the start of our story. http://www.w3.org/TR/webarch/#intro -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Friday, 29 August 2003 10:49:36 UTC