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, wrote:
> Michael Brauer <> 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
>
