Re: Framework documents nature

At 09:45 AM 1/8/02 -0700, Lofton Henderson wrote:
>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?


Huh???  I did not interpret that issue as addressing my question - What is 
required and what is not required.  I guess it depends on your definition 
of "deliverables".  This issue also says that "the QA Framework will 
require it."  So, if we're talking about the same issue there seems to be a 
contadictory conclusion; requirements in the Framework document and 
non-requirements in the Process document.

In any case, I feel the issue should be couched in terms of what we want in 
order to accomplish our objectives - not what should be in each document. 
Let's determine our strategy and then figure out how to say it, rather than 
the other way around.  As I said/implied somewhere (I don't remember 
where), it would make more sense to resolve the issues BEFORE we write the 
document.  Since we've done it the other way around, I think it makes sense 
to at least address the issue at the highest level and resolve it.


>>(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.


I don't think doing the issues first is as onerous as you might think.  At 
some point, all major decisions that are reflected in the document need to 
be discussed and resolved.  If we don't do this, we don't have 
consensus.  Why would it take more time to do this up front?  As we know 
from programming, doing a good job in design prevents errors downtstream. 
We could use our bi-weekly conference calls to discuss the issues.  We 
could then use the time between calls to reflect on the issues and come to 
conclusions.


>>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.


I think this approach makes sense but I think it's really obviated by 
Daniel's strategy of modeling it after WAI.

>-Lofton.
>

****************************************************************
Mark Skall
Chief, Software Diagnostics and Conformance Testing Division
Information Technology Laboratory
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Stop 8970
Gaithersburg, MD 20899-8970

Voice: 301-975-3262
Fax:   301-590-9174
Email: skall@nist.gov
****************************************************************

Received on Tuesday, 8 January 2002 17:54:49 UTC