OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Formulating proposals: was Re: [office] Thoughts on ODF-Next


Michael,

I just saw your response on the CSDs to appear in an OASIS standard
response and the requirement that we prepare:


> high-quality intermediate CSD's every 6 months.
> 

I think the following, which I was already writing, might help in that
regard.

Since the TC meets only once a week there isn't a lot of time for
discussion of the details of proposals. 

I don't know that anyone would take advantage of it, but perhaps the TC
should consider a second call every week, perhaps at varying times to
accommodate members in different locations, for discussion/improvement
of proposals.

A call to last up to 2 hours. 

Anyone who has a proposal or who wants to make a proposal simply posts a
request to be on the agenda for such a call. The only requirement being
that a proposal be available for attendees to review prior to the call.

This would not take the place of sub-committees where more substantial
revisions are formulated but would be a way to get materials into the
best shape possible for later evaluation by the TC. 

Just thinking that if we are serious about adopting a train approach,
then we need to also be serious about devoting the resources to make
that approach work for everyone. 

Including people who may need help in refining their proposals. 

Such meetings would not count for voting requirements in the TC. 

To avoid over-burdening you and Rob, I would be happy to chair such
meetings. Or either one of you could, since I am concerned with using
this to advance editorial work on proposals. 

Hope you are looking forward to a great weekend!

Patrick


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 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]