[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] TX timeline strawhorse
Speaking as a co-chair, I would prefer to chase and harry 15% of the OASIS
membership just the once. It frazzles me. I see no compelling reason to
separate these and go through the process twice. If WS-BA turns out to
consume more of the TC's time than we have planned then we can revisit the
timeline later; for now I'd prefer that we aim for a single submission of
all 3 specs.
- Ian
Alastair Green
<alastair.green@c
horeology.com> To
"Newcomer, Eric"
15/06/2006 09:06 <Eric.Newcomer@iona.com>
cc
ws-tx@lists.oasis-open.org
Subject
Re: [ws-tx] TX timeline strawhorse
Eric,
I think this is a good general timeline, and it's a good point to reset the
schedule.
To avoid delay, we might want to consider submitting WS-C and WS-AT for
approval as OASIS specs earlier than WS-BA.
Detailed comments:
a) The WS-BA interop is too early. I think this should start after the
August face-to-face. The focus of the August face-to-face should be getting
WS-BA to design-finished, interop-testable state. Getting WS-AT/WS-C to PR
state is unlikely to be a major work item for the TC as a whole by that
point, whereas time at the F2F is critical for resolving design issues, as
we have seen with WS-AT.
b) We should take a different tack on controlling the issue/work flow,
based on two principles
i) WS-BA is not as advanced as WS-AT/WS-C in terms of passage through the
process, and
ii) design issue raising should be stopped at well-defined points, but
editorial issue raising should not be stopped until we've produced the PR
drafts.
This avoids "issue acceptance" firefights, which are a low-grade substitute
for technical debate, but does concentrate the mind. It also allows
editorial fine-tuning to continue without impedance, which is important as
PR drafts are finalized.
Concrete proposals:
1) Start WS-BA interop on September 4, and complete on September 18. The
whole infrastructure/set up aspect of the interop tests will have been
chewed away by the WS-AT process, and the WS-BA tests are less numerous. It
can take less time, therefore, than WS-AT.
2) Impose a bar on WS-AT/C design issues (other than ones that arise
directly from interop testing) of June 30. Continue to prioritize handling
issues that affect interop tests. Find a way of handling editorial issues
more in parallel (delegation of details, rather than writing by committee).
3) Strongly encourage all known, "canned" WS-BA issues to be submitted by
June 30.
4) Impose a bar on WS-BA design issues of end of August F2F. It would be
artificial to prevent issues being raised in the midst of a working session
that is concentrating on finalizing the interoperable features of the spec.
5) Impose no bar on editorial issues prior to PR production: fine-tuning is
a feature of moving a spec to public review -- the wording, clarity,
structure etc becomes a focus in that phase, and we will end up breaking
our own rules non-stop if we attempt to prevent editorializing.
6) Allow exceptions to the bars on design issues only by Kavi ballot: i.e.
create a great big ramp against breaking the self-imposed ordinance, but
have a mechanism ready for genuine exceptions.
7) I can't see the point of a face-to-face so late in the process. Change
at that point is extremely expensive in terms of OASIS process.
I assume that the October 13 start PR is for BA, not AT (a typo).
Thanks,
Alastair
Newcomer, Eric wrote:
Hi,
Ian and I have spent some time roughing out what we believe might be
a
doable schedule for completing the WS-TX work. We are about halfway
through the year and I think it will be important for us to complete
our
work in as close to the year timeframe as possible.
Therefore as a general statement I would say we intend to lead the TC
into a transition phase from "discovery" or raising issues into a
phase
of thinking about finalizing the specs.
The interop events are a key part of this, and so we created the
timeline more or less around these, and after a certain point trying
to
focus the TC effort on fixing problems identified during the interop.
This draft timeline (below) is scheduled for discussion this Thursday
-
Agenda item 7. We look forward to your feedback, reaction, and help.
Thanks, and talk with you then!
Eric
+1 781 902 8366
fax: +1 781 902 8009
blog: www.iona.com/blogs/newcomer
Making Software Work Together (TM)
---------------------
June 30: All non-interop-related C/AT/BA issues to be submitted to
the
TC. After this date the bar will be raised and the chairs will
organize
a
ballot (orinary majority ballot) to accept any new
non-interop-related
issues.
July 14: live endpoints for AT scenarios to become available
Aug 18: AT interop testing complete. All interop-related C/AT issues
to
have been submitted to the TC. Work to resolve any issues. BA
interop
testing to start immediately after the completion of AT interop
testing.
Aug F2F (30/31): Approve WS-C, WS-AT public review (PR) drafts in
order
to start 60-day public review. Initiate public review process with TC
Admin.
Sep 4: Start 60 day PR for C/AT
Sep 15: BA interop testing complete. All interop-related BA issues to
Have hbeen submitted to the TC by this date. Work to resolve any
issues.
Oct 6: Produce/approve WS-BA public review (PR) drafts in order to
start
60-day public review. Initiate public review process with TC Admin.
Oct 13: Start 60 day PR for C/AT
Nov 3: C/AT PR ends. Work to resolve any issues. [1]
Nov 17: Produce/approve WS-C/AT PR report. Produce/approve committee
Specs for C/AT.
Nov ??: F2F (to be arranged) ??
Dec 13: WS-BA PR ends. Work to resolve any issues [2].
Jan 12: Produce/approve WS-BA PR report. Produce/approve committee
specs
for BA.
Jan 15: Submit C/AT/BA committee specs to OASIS for OASIS standard
ballot.
Feb 1: OASIS to inform membership of forthcoming ballot
Feb 16: Membership ballot starts.
Feb 28: Voting period ends. All being well, we have an OASIS
standard.
[1], [2]. Any substantive changes made following the 60-day public
Review require a further public review period of 15 days. This will
move
the
schedule out.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]