Schedule for specification

[Diane Jordan <drj@us.ibm.com>]

At the f2f, we held a lengthly discussion
of possible schedules for the production and approval of a committee draft.
   While we did not finalize a full plan, as a result of the
discussion, the TC passed two resolutions regarding immediate steps we
should take.  Here they are - please review them as they may have
implications for your action:  
1.  We resolved to establish a
deadline for non-bug issues of Aug. 15.  A process will be established
to monitor issues opened after that date – for example
–        Non-bug
issues submitted after that date will require a supermajority approval
to open
–        The
TC will review all opened issues
–        If
there is an objection to an issue being opened as a bug, the tc will vote
on whether it is a bug or enhancement (normal majority), and if an enhancement,
it will require a supermajority to open.  
–        Timing
needs to be clarified
I will provide more details on how this
will operate by Aug. 15.  Motion made by Satish, seconded by Martin,
passed with no objection.   
2.  We resolved that within 30
days of the editing committee releasing an updated draft with resolutions
for all issues closed in June f2f, the TC will review and open all bug
related issues.    
–        Target
dates: mid august for spec release, mid sept for issues opened, review
at sept f2f
Motion made by Martin, seconded by Satish,
passed with no objections.  
 
On our next call, we will discuss the
next level of schedule planning - eg, when we should expect to see proposed
resolutions to outstanding issues, when they need to be incorporated in
a draft of the spec and when we can expect to have a final draft for "polishing"
before approval. I've summarized a few of  the discussion points below
(see minutes for more info) and have attached a few slides that were made
during the meeting to clarify proposals that were under discussion.

Some discussion points: 
- it might be worthwhile for TC members
to identify the issues that they believe are "must haves" and
make them visible to the rest of the TC.   
- We may want to consider putting an
aging factor on the issue list - ie, we would call for proposals for all
issues (non bug) by some date and any issues with no proposal after that
date would be closed with no action.   (This would require categorization
of all issues into enhancement/bug).
- We should establish a timeframe for
when issue resolutions will be included in a draft of the spec after they
are closed.  Editors could flag those that aren't able to be completed
in this time.  It was noted that the editors can call for a vote to
reopen issues that lack clarity or sufficient detail which they have alread
done.   
- The member who proposes a resolution
should be prepared to work with the editors on the spec updates required
to implement it especially in the case of those proposals that do not include
details.  
- We should increast the frequency of
spec updates and TC reviews.
- we should consider asking that owners
of non-bug issues propose solutions by mid-sept for review at the Sept.
f2f meeting.
- we are expecting the TC members to
do at least two careful reviews of the spec - one in the Aug/Sept timeframe
to pick up errors and open issues to get us to a baseline, and then another
one after we have closed all open issues and included resolutions for those
we adopt in the draft.  This would be the final review before the
approval for committe draft.  There was discussion of targeting the
final review for Nov/Dec and concerns were raised that this was too aggressive.
   
- after the Aug review, we can clear
the change mark ups so that it will be easier to focus on the changes to
that version.  
- following committee draft approval,
there will be a 30 day public review period.  Depending on comments
received, at the judgement of the TC, this may be repeated.  After
this, the spec may be submitted to OASIS for approval as an OASIS Standard.
 That involves review by full membership and a number of other steps
outlined on the OASIS web pages.  See  http://www.oasis-open.org/committees/process.php#standards_approval
or http://www.oasis-open.org/committees/guidelines.php#spectostand
for details.
- the OASIS process allows for errata
following publication.  We do not think there is a specific process
for this - I will look into the OASIS process.
 

Regards, Diane
IBM  Dynamic e-business Technologies
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123

June f2f schedule proposals.ppt