Re: [office] Thoughts on ODF-Next

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

Patrick,

On 14.01.2011 11:23, Patrick Durusau wrote:

1295000614.26257.3209.camel@ratatosk.home.org" type="cite">

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?
  

Yes. My assumption is that that the 2nd CSD contains all of the 1st CSD, the 3rd all of the 2nd, and so on. So, actually everything would be as before, except that we agree to have prepare high-quality intermediate CSD's every 6 months.

Best regards

Michael

1295000614.26257.3209.camel@ratatosk.home.org" type="cite">

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 
    

--

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

Oracle is committed to developing practices and products that help protect the environment