[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bpel4people] BPEL4People TC - 5/14 Draft Agenda
Dave / All: to help the discussion on agenda item 5 “Discuss
TC Issue Collaboration Model” I’ll recap below the issue we need to
resolve. See comments inline Luc Clément Active Endpoints, Inc +1.978.793.2162 | luc.clement@activevos.com From: Dave Ings
[mailto:ings@ca.ibm.com] Here's the draft agenda for this week's TC
meeting. Suggestions welcome. [lc] Recall
from the attached the following: At issue is that only “a resolved issue whose applied
changes have been incorporated into a committee draft” can be closed.
There are three problems with this: 1) the need to emit a committee draft, 2) items
can’t be closed until applied to a CD, and 3) ensuring that we have
consensus on an issue cannot truly be determined The Editor’s SC proposed the following at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=bpel4people-editors
with the intent to allow issues to be closed as we collectively review working
drafts and approve the changes applied: Periodically, the SC will submit to the TC a list of changes
applied to the specs/WSDL/XSDs for review. The rate and number of issues
incorporated and submitted to the TC will depend on a number of factors. Ease
of review will be the primary criterion dictating when a version of a document
should be submitted to the TC for consideration. “Closing” an issue is agreement (by way of vote)
that what the Editors incorporated in the spec meets the TC’s approval.
The rules that apply for reopening an issue (per the attached) would apply.
Approving an issue is not approval of the document as a WD or a CD. Martin argues that: The issues process that the TC
has already adopted says that an issue will only be closed (moved from
resolved/applied) once the whole document is approved. If we want to change
this process a concrete proposal should be made to the whole TC. Since I am not
proposing any changes to what we have already adopted I think the onus is on
you to make a proposal to the TC. In particular I do not understand how a
working draft is marked to say that it includes some "approved" edits
especially if changes bars have been accepted; this would need to be spelt out
along with any changes to the issues state diagram. The reason the process is as it
is, is quite simple. While the edits to a single issue may be approved in
principle, it is not until you consider the whole document that you can assess
whether one issue's edits affected another's. This is akin to unit and system
testing. Using Martin’s analogy, what the Editor’s SC
proposed is closing an issue is akin to passing a unit test and that you can
proceed to a “check-in”. This does not imply that we’ve “released”
the product. I propose that we discuss these views and decide one way or
another during the call. I side with the Editor’s proposal given that it
will allow us to build consensus throughout the process rather than leaving
this to the end. [/lc]
|
SCA TC Proposed Issues Processv3.ppt
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]