OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Schedule for specification


 
We should be able to start building the (non-normative) primer now,
based upon some of the materials from the abstract BPEL effort.  Since
the primer should contain links back into the spec, the delivery of the
primer cannot occur prior to the spec itself.  

I've started working on a draft and will make it available on the Friday
abstract call.
 

> -----Original Message-----
> From: Frank Leymann [mailto:LEY1@de.ibm.com] 
> Sent: Thursday, June 24, 2004 10:37 PM
> To: Diane Jordan
> Cc: ws bpel tc
> Subject: Re: [wsbpel] Schedule for specification
> 
> 
> 
> 
> 
> 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/le
ave_workgroup.php
> .
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]