Thoughts on ODF-Next

[Michael Brauer <michael.brauer@oracle.com>]

Dear TC members,

while we are waiting for the ODF 1.2 public review, I think it may be a
good time to share a few thoughts how I could imagine that we adapt our
specification process and schedule for future ODF versions to deliver
specifications more frequently, and how to lower the time from a first
feature proposal to a specification that contains the feature.

I don't want to start with too many introductory words, but think a few
observation may be reasonable, in particular for those who are new in
the TC:

- 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.
- 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.
- There is an obligation to submit all ODF OASIS standards to ISO. The
ISO standardization process itself takes at least 6 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.

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.

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.

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.

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