Re: [office] Thoughts on ODF-Next

[Mary McRae <mary.mcrae@oasis-open.org>]

Just my $.02, but I would be careful of this approach since anyone who must follow the ISO path vs the OASIS one would not be able to implement new features/improvements/etc until a new OS submission to JTC1 occurred and was approved. The TC was greatly criticized for not sending v1.1; intentionally avoiding OS approval would, I think, be frowned upon by SC34.

Best regards and best wishes to all for a very happy holiday season,

Mary





On Dec 17, 2010, at 8:03 AM, 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
> 
> -- 
> 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
>