[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] TX timeline strawhorse
I have no desire to frazzle you. :-) Alastair Ian Robinson wrote: > 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]