Re: [ws-tx] TX timeline strawhorse

[Alastair Green <alastair.green@choreology.com>]

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.