[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Thoughts on ODF-Next
Hi Rob et al, Just one correction: #3 in your timeline is 30-day review rather than 60. Mary On Dec 17, 2010, at 1:26 PM, robert_weir@us.ibm.com wrote: > Michael Brauer <michael.brauer@oracle.com> wrote on 12/17/2010 08:03:16 > AM: > > . > . > . >> >> - The OASIS TC process defines three levels of approval: Committee >> Specification Drafts (CSD), Committee Specifications (CS), and OASIS >> standards. While it of course should the objective of a TC to get >> OASIS standard approvals for the specifications it develops, a TC may >> decide to advance a particular specification only to the CSD or CS > level. > > And so everyone is on the same page, everyone should remember that > "Committee Specification Draft" is the new name for what we previously > called "Committee Draft". > > So general flow is: > > Working drafts (WD) are editorial drafts that have no level of approval > > Working drafts are voted on by TC majority to become Committee > Specification Drafts (CSD) > > A CSD can be sent out for public review, and at least one such 30-day > review (under new rules) must occur before advancing > > A CSD can then be approved by "special majority" of the TC (2/3 approval, > no more than 25% disapproval) to become Committee Specification (CS) > > CS can then be nominated for review as a Candidate OASIS Standard (60 day > review) and ballot as an OASIS Standard (an OASIS vote, not a TC vote). > > That's the general flow, though there are a large number of additional > details. > > >> - It takes a minimum of about two months to advance a CSD to a CS, and >> a minimum of about three months to advance a CS to an OASIS standard. > > That is best case, assuming that no changes are made in response to the > public review. There are also administrative delays when requesting > public reviews and requesting Committee Specification ballots. So I think > that in practice these "minimum" times are hard to achieve. > >> - There is an obligation to submit all ODF OASIS standards to ISO. The >> ISO standardization process itself takes at least 6 months. > > There is an additional review and approval stage that occurs after > approving an OASIS Standard and before we can send it to JTC1. We have > not done this procedure yet, but looking at the process requirements, I > think that adds another two months, and that is assuming that an Interop > Demonstration was already held previously. If you wait for the CS or > later stage to start on the Interop Demo that would add another 3-4 > months. > >> - Each specification document requires editorial work (including >> clarifying last details and issues). A rough estimate could be that for >> two months specification work, 1 month editorial work is required. >> - Our TC process is member driven: Individual TC members may propose >> enhancements for ODF, but they are also responsible for advancing their >> proposals into a state where enough details are specified so that the >> proposals can be voted on and integrated into the specification by the >> TC editors. Which means that it is to a large degree under the control >> of the TC members themselves when an enhancement is ready to be >> considered for integration into the ODF specification. >> >> Considering all this, it is realistic to assume that we cannot release >> OASIS standards more frequently than every two years, but even when we >> would only have a window of about 6 months where we can add enhancements > >> into a specification document. >> > > Suppose best case. We want to change a "should" to a "shall". The TC > agrees unanimously and there are no public comments. How long does it > take to get this standardized? > > 1) Start on a Monday meeting where the updated text has been provided. We > vote then to make it a CSD and send it for public review. > > 2) 1 week delay to review the text and start the public review > > 3) 60-day public review > > 4) one week delay before we can vote for committee specification > > 5) TC votes to request CS ballot > > 6) 1 week delay to create CS ballot > > 7) 1 week CS ballot > > 8) TC approves resolution to request a special majority ballot to request > an OASIS Standards ballot > > 9) 1 week delay to create ballot > > 10) 1 week ballot > > 11) 15 day administrative review of the ballot materials > > 12) 60 public review > > 13) 1 week delay if no comments are received > > 14) 14 day OASIS voting period > > So add that all up and the minimum theoretical turn around time, on the > OASIS side, is 27 weeks, so half a year. Add to that the time needed to > do the technical work of specification, time needed to discuss and gain > consensus, and time needed to respond to public and member comments, and > you end up with a longer schedule. But I think it is reasonable to do > releases every 18-24 months. > > Note that I don't think the ISO portion of the "train" should determine > our scheduling. IMHO, it is perfectly acceptable to start work on a new > ODF version in OASIS while the previous version is still under review in > ISO. In fact I think that will be the normal situation. > > >> What I'm therefore suggesting is that we >> >> a) make use of the CSD and CS levels of approval >> b) adopt a time-boxed or "train model" where we have previously agreed >> dates where we aim to have CSDs ready, and where we accept for a CSD >> only what is ready by when. >> c) decide for each CSD individually whether we want to get a higher >> level of approval or public reviews. >> > > We might even want to propose a more detailed template for the release. > For example, say for ODF 1.3 we say upfront that we will: > > 1) Produce monthly WDs until the specification is "feature complete" > > 2) Set a target date for CSD 01. Assume CSD 01 goes for 30 day public > review > > 3) Assume we get comments and revise once. Set a target date for CSD 02. > > 4) CSD 02 goes out for 15 ay public review > > 5) Move CSD 02 forward for CS. > > You could make other assumptions as well, such as maybe having an > additional 15-day review and a CSD 03, etc. But I'd recommend that we try > to set expectations for the entire schedule. > > >> How could this look like in practice? >> >> We may agree that we deliver CSDs every 6 months. This would mean that >> we would have a phase of 4 months open development where we integrate >> all proposals that are ready to be integrated, which means that they are > >> detailed enough to be integrated and have been approved. After this 4 >> months, we would have a phase of two months where the proposals get >> integrated into the draft. We when vote on the draft, and most likely >> get a CSD that is published. After the CSD approval, we start working on > >> the next CSD in the same way. >> >> When a CSD has been approved, we also discuss and agree whether we want >> to start a 30-day public review for the draft, and ask for approval as a >> CS. But even if we do so, we would continue our work on the next CSD. >> > > I think every CSD should go out for public review, except maybe the first > one. Note also that we have told SC34 that we will send them all CSD's > for comment. > >> Where are a lot of things to consider for this decision: For instance >> how much new content we have in the specification. Or whether we have >> other public reviews running. Or where we are in the approval process of >> previous specifications. For this reason, it appears reasonable to not >> set up any rules for this in advance, but to just use the CSD approvals >> as checkpoints, and to decide individually for each CSD how to proceed. >> >> When we decide to advance a CSD to a CS and got the CS approval, we >> would then discuss and decide whether want to advance it to an OASIS >> standard. >> >> Where may of course be features that need more than four months to be >> developed. For these, we may set up sub committees, and may consider the >> deliverable of the sub committee as a proposal that we treat the same >> way as the other proposals. >> >> Where are a lot of advantages this model has compared to the one we used >> for ODF 1.2: >> >> - Enhancements and new features are available on CSD level in less than >> 6 months. >> - Vendors may implement CSDs instead of extended conforming documents >> with vendor specific extensions. This >> -- provides a higher level of interoperability between ODF >> implementations that go beyond the last approved OASIS standard >> -- provides transparency to users >> - The "rush hour" we get when we are getting closer to the end of a >> feature definition phase is avoided, because if a proposal misses a >> specific CSD, the next opportunity is already 6 months later. >> - Assuming that we get comments in particular for new features, we get a >> better distribution of comments by having many "small" public reviews >> rather than a single "large" public review. >> >> Feedback to these suggestions is of course very welcome. I also did >> present these ideas at the last OOoCon. The feedback I got there from >> users of the ODF specification was positive. The slides of the >> presentation are available here: >> >> http://www.ooocon.org/index.php/ooocon/2010/paper/view/233 >> >> Best regards, and best wishes for the holiday season. >> > > I generally like the idea. I think this is the intent of WD, CSD and CS > work products, to be milestones. > > Another, entirely different approach, would be to investigate what would > be required to do a true multi-part standard, where the different parts > could be advanced through the entire process independently. So in the > train analogy, this would be parallel tracks. We considered this for ODF > 1.2, but some (including me) thought that we needed some modularization > work on the spec (and schema) before we could successfully and cleanly > separate the parts. But if we were able to do this for ODF-Next, then > that would allow additional flexibility. Of course, it would also cause > additional complexity in JIRA, and generally on the project management > side. > > Regards, > > -Rob > > >> Michael >> >> -- >> Michael Brauer | Oracle Office Development >> Phone: +49 40 23646 500 >> Oracle Office GBU >> >> ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 München >> Registergericht: Amtsgericht München, HRA 95603 >> >> Komplementärin: ORACLE Deutschland Verwaltung B.V. >> Rijnzathe 6, 3454PV De Meern, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]