Re: [wsbpel] New BPEL Issue process - please read - will effect yournew issues

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Danny,

    That is my recollection as well. It was deemed too difficult to 
achieve a super-majority of the whole voting membership, when meetings 
typically barely reach quorum.

-Ron

Danny van der Rijn wrote:

> i brought this point up at our last call, and i think we decided to 
> make it a supermajority of present members.  can't find the minutes 
> right now to confirm.
>
> Yaron Y. Goland wrote:
>
>> I had understood that we only required a super majority of present 
>> members, not a super majority of the entire group. I believe that 
>> requiring a super majority of the entire group penalizes those who 
>> show up for meetings.
>>
>>     Thanks,
>>         Yaron
>>
>> Diane Jordan wrote:
>>
>>>
>>> On the last call, I promised to send an email restating the process 
>>> for opening issues that we discussed and adopted on the call.  Here 
>>> it is and I've taken the opportunity to use Tony's proposal as an 
>>> example.   (Tony, hope you don't mind being the test case).   1. 
>>> proposed issues will be reviewed on the TC call if they are received 
>>> 7 or more days before the call.  (Thus this one will be reviewed on 
>>> the call Sept 15).  2. on that call, we will first ask if there are 
>>> any objections to opening the proposed issues as a bug.   If there 
>>> are none, we will open the issue, end of process.
>>> 3. If there are objections, we will have a vote (requiring simple 
>>> majority) on whether it is bug related.  This will be not be done 
>>> immediately - it will be done either by web ballot starting 
>>> immediately after the meeting or at the next meeting (in this case 
>>> the f2f on Sept 21-23).   The decision on whether to use the web 
>>> ballot or wait till the next meeting will be based on whether we 
>>> desire further discussion about whether it is a bug or not on the 
>>> next call before the ballot.        If the ballot results in it 
>>> being considered a bug, we will open the issue, end of process
>>> 4. If the ballot to declare it a bug doesn't pass,  there will be a 
>>> second ballot, held right away (for this eg, Sept 21-23), on whether 
>>> to allow it to be opened.  ---------> Note that since we've decided 
>>> this ballot to open a non-bug will require a super majority and that 
>>> is based on full voting membership rather than quorum, we may not be 
>>> able to hold it if there aren't enough members in the meeting.   If 
>>> there are enough attendees (ie, at least 2/3 of voting members), we 
>>> will vote immediately - if it fails, and the number of absences are 
>>> such that it could pass if they all voted for it, we will defer the 
>>> decision and vote via web ballot starting immediately after the 
>>> call/meeting.   The web ballot will run for 7 days per the OASIS 
>>> process.  From our general attendance rates, its probable we will 
>>> usually be able to have the initial vote on our call but will have 
>>> to go to the web ballot if there are more than a couple folks who 
>>> don't want it opened.  If the second ballot to open the issue 
>>> passes, we open the issue, end of process.    If the ballot to open 
>>> the issue does not pass, the issue will move directly to closed 
>>> status and the "revisitable" flag will be set, end of process. 
>>> Again, just as an example, best case we could decide this is a bug 
>>> and open it on the call Sept. 15, or worst case, it could be Sept 30 
>>> before we've resolved what to do.   (This is one week less than most 
>>> cases because the f2f in Sept means we have meetings 3 weeks in a 
>>> row). Any questions?   Regards, Diane
>>> IBM  Emerging Internet Software Standards
>>> drj@us.ibm.com
>>> (919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
>>>
>>>
>>>
>>> *"Tony Fletcher" <tony_fletcher@btopenworld.com>*
>>>
>>> 08/27/2004 12:54 PM
>>>
>>>     To
>>>     <wsbpel@lists.oasis-open.org>
>>> cc
>>>     Subject
>>>     [wsbpel] New BPEL Issue - add explicit conformance statements / 
>>> section
>>>
>>>
>>>    
>>>
>>>
>>>
>>>
>>> Dear Colleagues,
>>>  
>>> I move that we accept a new "bug" issue into the issues list 
>>> concerned with adding an explicit set of conformance statements, 
>>> preferably in a conformance section, to the specification for 
>>> 'BPEL'.  The rationale and a draft proposal is given in the attached 
>>> document.
>>>  
>>> Resolving this issue will not lead to the addition of any new 
>>> features..  However, it will enhance and clarify the text in a 
>>> significant manner and therefore is worth tackling at this time.
>>>  
>>> The process of adding such a conformance section will cause us to 
>>> think about and address the following questions:
>>>  
>>> For what sort of 'things' can conform to the BPEL specification?
>>>  
>>> For each type of 'thing' for which conformance can be claimed, what 
>>> precisely does that thing have to be / do / not do to be conformant.
>>>  
>>> Best Regards,
>>> Tony/                           /
>>>
>>> <http://www.choreology.com/>     Tony Fletcher
>>> Technical Advisor
>>> Choreology Ltd.
>>> 68, Lombard Street, London EC3V 9L J   UK
>>> Phone:       +44 (0) 1473 729537
>>> Mobile:     +44 (0) 7801 948219
>>> Fax:         +44 (0) 870 7390077
>>> Web:     www.choreology.com <http://www.choreology.com/>
>>> Cohesions™
>>> Business transaction management software for application coordination
>>> Work: tony.fletcher@choreology.com
>>> Home: amfletcher@iee.org <mailto:amfletcher@iee.org>
>>>
>>>  
>>>
>>
>> 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. 
>>
>>
>>
>
> 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. 
>
>