Issues & Checkpoints (was Re: Framework documents nature)

(Note -- I have moved this part of the discussion to WG list, which seems 
like the right place for it.)

What I said in yesterday thread is slightly incomplete...

### begin excerpt ###
>>>(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.
### end ###

This is not actually what is happening now.  In fact, the editors are 
exercising discretion to log issues in those areas where they are not 
comfortable or feel that group attention is warranted.  Kirill has done a 
lot of this for Proc&Ops.  I have tried to do it for Intro, and Dimitris 
has initiated some as well.

In addition, any WG member can enter an issue at any time that she/he 
wishes.  Send an email message with your chosen issue Title, brief 
Description (and argumentation if you wish), optional pointers to email 
archive and/or other URLs, and optionally your Proposal for 
resolution.  Before too much longer, I hope that we will put a documented 
version of the XML issue template on the Web site, for those who would 
rather edit and submit it that way.

I feel that this ensures proper consensus, without adding too much 
additional process.  But once again...

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:48:12 UTC