Re: [wsbpel] Schedule for specification

[Frank Leymann <LEY1@de.ibm.com>]

Diane,

did we discuss the schedule for the primer?

Regards,
Frank







To:    ws bpel tc <wsbpel@lists.oasis-open.org>
cc:
Subject:    [wsbpel] Schedule for specification



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
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.