Re: [office] Thoughts on ODF-Next

[Patrick Durusau <patrick@durusau.net>]

Rob,

On Fri, 2010-12-17 at 13:26 -0500, robert_weir@us.ibm.com wrote:
> Patrick Durusau <patrick@durusau.net> wrote on 12/17/2010 08:53:52 AM:
> 
> > Michael,
> > 
> > On the whole I very much like the proposed schedule, although I would
> > use the more frequent CSD periods to incorporate comments from national
> > bodies.
> > 
> 
> Of course, we can incorporate comments in Working Drafts as well.  The 
> main thing a CSD does is allow us to hold a formal public review.  So I 
> think it is critical to get that first CSD/Public review out quickly. With 
> ODF 1.2, we iterated on WDs for too long, I think, before we got to a CD 
> 01.
> 
> On the other hand, a CSD/Public review does have overhead, both in the 
> length of the review, but also on the administrative checks.  Since the 
> initial review is the longer review (30-days), there is an advantage to 
> doing that as early as possible, to get that out of the way.  Of course, 
> once you've done that you have the burden of highlighting changes in 
> future CSDs.  But on balance I think we're better of to have a CSD/public 
> review early.
> 

+1! In part because with better division of the text, we can proof
material in easier to digest chunks.

> > Given the changes in OASIS process, I suspect new agreements will need
> > to be made between JTC1 and OASIS.
> > 
> 
> How do you see this?  The agreement with JTC1 concerns maintenance, mainly 
> around how we respond to defect reports.  Nothing on the OASIS side has 
> changed in that regard.
> 

We would have to ask OASIS to be sure but my impression was that we
wanted to avoid another ODF 1.1 type situation, so the two bodies were
going to remain in synch. But as I said, that is an agreement by OASIS
so would need to ask them.

> > I would not use the CSD status as a means to allow the implemented OASIS
> > specifications to get out of synch with the ISO version.
> > 
> 
> As I see it there are three mechanisms at play, and they move at different 
> speeds:
> 
> 1) Innovations in the applications that happen in an uncoordinated way, at 
> various speeds.  Large commercial products might release on a 3 year 
> schedule, while open source products may make more frequent, smaller 
> releases, say every 6 months. And cloud-based editors, they can deploy 
> updates instantly.  Vendors are not going to wait
> 

Interesting observations about the speed of vendors. 

> 2) Revisions of OASIS standards can come out every 18-24 months under 
> reasonable assumptions.  CSDs can occur more frequently.  These might be 
> useful for vendors as milestone specifications to implement.  But they are 
> not consensus standards, and don't carry that weight with some 
> stakeholders.  They also don't have the same implications for IPR as a 
> fully approved OASIS Standard.
> 
> 3) And then you have formal standardization, in the ISO/IEC sense, which 
> is another 12+ months on top of the OASIS 18+ months.
> 
> Note further than OASIS will not allow us to advance an OASIS Standard to 
> ISO until we have shown its interoperability via at least three 
> independent implementations in an InterOp Demonstration.  So we will 
> always see a lag between implementation of OASIS versions of the standard 
> and approval of the corresponding ISO versions.  We should also note that 
> the end-to-end standardization period of OASIS + ISO is greater than the 
> inter-release schedules of almost all vendors.
> 
> In any case, the respective attention we give to Working Drafts versus 
> CSDs doesn't really change the picture.  It is really the end-to-end time 
> that matters, if you are concerned with applications and the ISO standard 
> getting out of sync.
> > For several reasons:
> > 
> > First, as you will recall, having ISO status is important in a number of
> > marketing venues. 
> > 
> > Second, we have gone to a great deal of effort to not only secure that
> > status for current versions and to arrange for it to remain current.
> > 
> > Third, having both OASIS and ISO review means that a broader community
> > has feedback into ODF, making it a much stronger standard.
> > 
> 
> Maybe also reiterate that we welcome feedback at any time.  We've just 
> recently completed an enormous task of processing thousands of comments. 
> Very few of these came during an official public review period. 
> 
> So I'd divide the question of "what to review" from "when to review it". 
> The answer to "what" is "the latest posted draft", whether a WD or CSD. 
> The answer to "when" is "whenever you want".  There is nothing magical 
> about the CSD/public review other than it is a process requirement and 
> that OASIS advertises it. 
> 

The process as you describe it misses the triggers that operate in other
environments.

To take a wholly OASIS example, at present, you won't get Technical
Advisory Board (TAB) comments on working drafts.

Not that the TAB isn't interested.

Not that WD don't merit comments by the TAB.

Just that public review is the trigger for TAB comments.

To say that NB's can comment whenever they want, is to ignore the
defined triggers for those comments.

Hope you have started a great weekend!

Patrick











> Regards,
> 
> -Rob
> 
> > With that minor tweaks, I like your proposal very much!
> > 
> > The six month window is doable and will make it easier to get promise
> > prospective users when new capabilities are likely to appear. (I have
> > been telling people about the metadata for quiet some time.)
> > 
> > Hope you are looking forward to a great holiday season!
> > 
> > Patrick
> > 
> > On Fri, 2010-12-17 at 14:03 +0100, 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
> > > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > 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 
> > 
>