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
