Re: [office] Thoughts on ODF-Next

[robert_weir@us.ibm.com]

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 
>