- From: Lofton Henderson <lofton@rockynet.com>
- Date: Sun, 27 Jul 2003 18:19:10 -0600
- To: www-qa-wg@w3.org
QAWG -- The last detail of which I'm aware, in order to publish next OpsGL: it must have some Use Cases, in order to be SpecGL compliant. Here are a few ideas. These summary-level descriptions would be in a subsection at the end of the introduction (see current editor's draft [1]), in the same way that SpecGL is doing its use cases. (If we follow the SpecGL lead further, then there would be a more detailed description, with actors and enumerated steps, in a parallel section of OpsET.) Comments? Critiques of the content of any of them? Should there be more than the 4 that I outlined? (If 'yes', then specifically what? In fact, how about writing it -- 5 or so sentences?) ### start UCs ### (1) A new Working Group is forming, and the charter is just being drafted. The Charter team, including prospective WG members, consults the "QA Framework: Introduction". Appreciating the value of early quality commitment and integration, the team refers to OpsGL. Using the Charter Template (linked from OpsET), it writes into the WG's draft Charter its quality-level commitments, test material plans, anticipated QA deliverables. It documents its intention to build the test materials within the WG (in this case), and in its Call for Participation it asks for participation by some QA specialists. (2) A Working Group was chartered several months ago, before a stable version of Operational Guidelines (OpsGL) was available. The WG has just finished writing its Requirements documents and Use Cases, and is beginning to draft its specification. Concurrently, it is starting to discuss test suite plans, at a face-to-face meeting. Consulting OpsGL, it immediately appoints a QA Moderator and a team that will work on the test suite (part time on QA, and part time on specification technical issues). Using the QA Process Document (QAPD) template that is linked from Operational Examples & Techniques), it has drafted and posted its first version of its QAPD by the time the meeting is finished. (3) A Working Group has been re-chartered to finish a Second Edition (maintenance release) of its standard, and to develop the next functional version, 2.0. No test suite development was done during the first charter, but some test suite development has happened by a collaboration of outside organizations and an industry consortium. The Working Group reaches agreement with the outside developers to transfer the suite to a stable home and repository in W3C. Operational Guidelines is consulted for a detailing of preliminary steps, requirements, and specific activities involved in making a smooth and trouble-free transfer. (4) A Working Group is almost ready to request Candidate Recommendation (CR), and has met its goal of having a comprehensive test suite (TS) built in time for the trial implementation period of CR. As it looks at making the TS publicly available, it finds numerous procedural issues about TS publication, that it had not anticipated. The issue of appropriate licenses for the TS is proving particularly hard -- some are adamant that the tests must be unalterable, to protect their integrity, but others point out that the TS cannot be applied by users without making some custom interface adaptations to their implementations. Consulting Operational Guidelines (OpsGL), the WG settles on a component approach to applying licenses (W3C Software and/or Document). In the bargain, other OpsGL suggestions about publication and promotion, including providing a WG sponsored Web space in which implementations can publish their TS results. [(5) ???another about a Contribution & Review process... using not-yet-written, but anticipated, OpsET templates and examples???] ### end ### Regards, -Lofton. [1] http://www.w3.org/QA/WG/2003/07/qaframe-ops-20030711.html#terminology
Received on Sunday, 27 July 2003 20:19:16 UTC