Re: Framework documents nature

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