Re: [office] Thoughts on ODF-Next

[Patrick Durusau <patrick@durusau.net>]

Michael,

A question on your scheduling:

> > > 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. 

OK, but what would be the content of that OASIS standard?

I am assuming, perhaps incorrectly, it would be at the three prior CSD
bundled up for that OASIS standard. 

Yes?

Assume Jan. 1, 2011 the train starts up:

1st CSD - 6 months

2nd CSD - 12 months

3rd CSD - 18 months

so isn't the sum of all three going into

CS - 24 months?

I think you imply as much but just wanted to be sure.

Hope you are having a great day!

Patrick

PS: I do recognize that current OASIS mechanisms make collaboration with
other standards organizations difficult but that isn't an issue we can
resolve in this forum.


On Fri, 2011-01-14 at 10:10 +0100, Michael Brauer wrote:
> Hi,
> 
> thanks for all the contributions to the discussion since yesterday. It
> seems that all concerns that have been raised are regarding the
> question whether or not we should encourage vendors to implement CSDs.
> That's a very interesting discussion, but only one aspect of my
> suggestions. I'm therefore interested to learn if there are other
> concerns, or if you otherwise agree to the suggestions.
> 
> Best regards
> 
> Michael
> 
> On 13.01.2011 11:39, Michael Brauer wrote: 
> > Dear TC members,
> > 
> > thank you very much for the feedback to these suggestions. That is
> > very helpful. I will answer to a few concerns on the mailing list,
> > but would like to discuss this topic in one of our next TC calls. We
> > are will start to work on ODF-Next very soon, and I think we need
> > top agree on a schedule for our future work very soon.
> > 
> > Best regards
> > 
> > Michael
> > 
> > 
> > 
> > On 17.12.2010 14:03, Michael Brauer wrote: 
> > > 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 
> > > 
> > 
> > -- 
> > Oracle
> > Michael Brauer | Oracle Office Development
> > Phone: +49 40 23646 500 | | 
> > Oracle Office Global Business Unit
> > 
> > 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
> > 
> > Green Oracle Oracle is committed to developing practices and
> > products that help protect the environment 
> 
> -- 
> Oracle
> Michael Brauer | Oracle Office Development
> Phone: +49 40 23646 500 | | 
> Oracle Office Global Business Unit
> 
> 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
> 
> Green Oracle Oracle is committed to developing practices and products
> that help protect the environment