Re: Framework documents nature

(I sent this with incomplete distribution, hence I'm sending again... -LH)

Mark,

(I see that another message arrived from you ... you have addressed in it a 
couple of points that I made below.)

At 05:41 PM 1/8/02 -0500, you wrote:
>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 the ellipsis above -- "[...]" where I cut out Ian's original 
comment -- may have been a mistake.  Ian said:

### begin IJ quote ###
I think that the deeper question is: how formal will the
QA requirements be on other W3C Working Groups? My understanding
so far is that the QA Activity will promote processes that
will improve specs, implementations, etc. but that these
processes will not be required (e.g., at the Process
Document level).
### end IJ quote ###

It appeared that your reply to Ian was using "not required" in the sense 
that Ian used it at the end of his pgph.  And that is what Issue #16 is 
about, albeit it focused on a couple of QA requirements for the WGs.  I.e., 
I thought we were talking about (as Ian's mail implied) whether we promote 
our "QA Requirements"  to be W3C requirements by somehow instantiating them 
in the W3C Process (big "P") Document.

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

I don't see any contradiction.  I think Daniel summarized it succinctly:

### begin DD quote ###
I think we should have the same approach as for the WAI guidelines
(Lynne seems to agree with me here): our QA framework specifies
requirements, with various level of importance (MUST, SHOULD, MAY, P1,
P2, A, AA, etc), and someone else decides what to do with them.

This someone else can be the W3C Advisory Board stating that all WGs
must comply with the QA Framework Spec Guidelines to level AA, or with
the QA Framework Process Guidelines level A.
### end DD quote ###

This is the way that we have been proceeding.  See for example, these two 
sections of the Introduction, at:

http://www.w3.org/QA/WG/qaframe-intro.html#b2ab3d184

If the language there does not in fact capture the sense we intend, then we 
should adjust it.

(The "Terminology" is repeated in Procs&Ops.)


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

I think our strategy is as Daniel summarized, which is more or less stated 
in the Framework.

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

I'd be happy to add an issue to the Issues List, if you'll send a message 
with a "Title" and a brief "Description".  I can add hyperlinks to this 
mail thread and to the Framework (current de-facto resolution).



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

We disagree here.  There are almost 20 checkpoints in Procs&Ops, and it's 
probably incomplete. Wild guess, I'd say we're going to ultimately have 
100-200 in the whole Framework family.  Writing each as an issue, and 
processing it in "plenary" (f2f or telcon), is going to take time.  Just 
the editorial overhead is significant (I can vouch, as issue's editor).

(Possibly irrelevant comparison, but SVG has been working on 1.1 spec since 
summer, has an advanced draft almost ready for last-call WD, has resolved 
25 issues, and has 10 still open.  That is with two 3-day f2f meetings, 
plus 2.5 hours *per week* of teleconference time, and a very active WG 
email list.)

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

I disagree again.  If a strawman is put out for review, and it has 20 draft 
checkpoints, then:

** all interested parties should read them;
** they should raise issues on those that they have problems with;
** they should raise issues on ones they think are missing;
** no issue means everyone agrees with strawman draft.

I don't see how consensus that way is inferior to the alternative, which is 
explicitly pointing at and discussing, in advance before we can even post a 
FPWD, every "SHALL", "SHOULD", and "MAY" in a document.

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

Should we formulate and resolve an issue here, about how we as QA WG want 
to work?  Whether every checkpoint has to have a corresponding issue, and 
be explicitly reviewed and approved before any publication?

-Lofton.

Received on Wednesday, 9 January 2002 08:33:15 UTC