- From: Lofton Henderson <lofton@rockynet.com>
- Date: Tue, 08 Jan 2002 09:45:50 -0700
- To: Mark Skall <mark.skall@nist.gov>
- Cc: www-qa@w3.org, ij@w3.org
At 10:51 AM 1/7/02 -0500, Mark Skall wrote: [...] >Is the "not-required" philosophy our strategy, or is this imposed by the >W3C process? If it's the former, I would prefer to see much more >discussion on this. As a minimum, we should document this as an issue and >resolve it. See http://www.w3.org/QA/WG/qawg-issues-html.html#x16. This may not be quite as broad as you are suggesting. But it was marked as "closed", due to the Brussels discussion. I think you're suggesting that it ought to be re-opened? >(As an aside, I think the Issues List needs to be expanded in general to >include other more substantive issues (e.g., the decisions that were made >about what actually ends up in the checkpoints should be itemized as >issues with the resolutions determined by consensus)). Opinion. We (QA) may not have the time resources to do it this way. We'd be talking about scores of new issues, considering the main Framework documents. We would need lots more f2f meetings, of longer duration, and lots more teleconferences. This is my guess, from the pace of issues resolution in e.g. SVG (2.5 hours per week of teleconference). As a practical necessity, we may have to go with the approach: draft (strawman), review, raise issues, resolve. >In any case, I see many reasons why requirements would be much more >effective. The only advantages to softening these to non-requirements >seem to be political. That may be a key consideration, as we (QA) get started. >>In any case, the QA Activity will need to get buy-in >>from WGs, > > >I certainly agree that buy-in is important and we should do everything we >can to obtain that. However, I think this issue is orthogonal to whether >or not to make our processes requirements or not. One can obtain buy-in >and still make things requirements. In fact, I would say that obtaining >buy-in is even more important if we are to impose things on the WGs. I think there is some sense that a QA strategy of going aggressively and immediately to requirements in the Process Document might inhibit buy-in. But that might be an ultimate goal, in an incremental fashion. Ultimately, I'm not completely sure that it is our decision to make, in any case. >Coming from a conformance background, I'm still disturbed by providing >recommendations rather than requirements when the implications of not >following our processes could have a catastrophic impact on >interoperability and the quality of implementations. If we believe what >we say about the importance of our activity, and we don't require many of >the things we're asking for, then, by our own admission, we are inviting >disaster. What do you think about a phased approach? Produce our Frameworks, assess their quality and utility, try them out, and possibly progress them to requirements (whether Process Document, or de-facto like pubrules) based on the results. -Lofton.
Received on Tuesday, 8 January 2002 11:45:48 UTC