ODF-Next Proposal

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

Hi,

as promised, here is a revised proposal for the development of ODF-Next. I've tried to integrate the feedback I've received on my first suggestions, and have grouped the proposals into general things about the next ODF version, the schedule, and proposals how to use JIRA.

I welcome your feedback, but would like to ask for two things if you disagree to a particular item: 1) Please indicate whether you agree to the other items, and. 2) Please provide an alternative suggestion.

I have intentionally left out the question of whether we encourage vendors to implement CSDs, since this is, as Rob correctly noted, out of our control.

I have further intentionally left out the question whether or not we want to identify the CSD numbers in documents, and if so how. This is a question that best is discussed as a proposal for ODF 1.3.

General
- For now, the version number (as defined by the OASIS naming directives) for the next version is "1.3" (but that's not necessarily the value of the office:version attribute). However, the version number may be changed to "2.0". This may be because the TC agrees on a change that makes the next ODF version incompatible with ODF 1.2, or because of major enhancements, or other not yet known reasons.
-  ODF 1.3 for now will remain backward compatible with ODF 1.2, except that individual features may be incompatible. That is, an ODF 1.2 implementation shall be able to read ODF 1.3 documents. But for some ODF 1.2 features or elements/attributes, there may be improved variants in ODF1.3, and these may not be backward compatible. Like any other proposal, a proposal for backward incompatible changes requires an (informal) approval by the TC (see also below). Actually this is not different than what we did for ODF 1.2.
- The TC may revise this decision that ODF 1.3 is backward compatible with ODF 1.2 based on individual proposal for changes. That is, the TC decides that ODF 1.3 (or 2.0, as it may be called then) shall get incompatible to ODF 1.2 in general if and when it gets a proposal that includes an incompatible change.

Schedule
- ODF 1.3 will be developed as a sequence of committee specifications. Committee specifications shall be ready for approval by the TC every 6 months.
- The first committee draft (CSD01) shall be ready for approval in September 2011, CSD02 in March 2012, CSD03 in September 2012 and CSD04 in March 2013.
- CSD04  shall be advanced to an OASIS standard. It may be approved earlier than March 2013 if no proposals or severe issues are outstanding.
- Before a committee draft is approved, there shall be a period of 2 months where no proposals are integrated.
- Between CSD03 and CSD04 no new features shall be integrated into the ODF specification. Which means that the last month where features may be integrated is July 2012. Exceptions from this rule shall be granted only if the TC is confident that the new feature does not break, and that it further gets implemented.

JIRA/Feature approval process
- The progress of proposals shall be tracked in JIRA.
- New "fix for" fields "ODF 1.3 CSD1", "ODF 1.3 CSD2", "ODF 1.3 CSD3" and "ODF 1.3 CSD4" will be created. With the exception of "ODF 1.3 CSD04", these targets may be set by TC members at any time, but only if the issue is assigned to a TC member who feels responsible for advancing the proposal into a state where it can be integrated into the specification within the timeline for the chosen target.
- Proposals shall only be integrated if they contain the text and schema changes that shall become part of ODF 1.3, or at least enough information that the TC editor can prepare the text and the schema, and if no objections have been raised to the proposal in JIRA. If objections are raised, A TC member can request a formal vote to include the proposal.
- If a proposal is not in that shape 2 months before the planed approval of a CSD, it will be deferred to the next CSD. "ODF 1.2 CSD3" issues will only be deferred to "ODF 1.2 CSD04" if the TC grants an explicit exception for this.
- TC members can raise objections to a proposal by a "-1" comment, or agreement by a "+1" comment.
- Proposals are only discussed in a TC call if they get a component "Needs discussion" assigned.
- JIRA issues for proposals shall only be opened if the work on a proposal starts.
- JIRA issues that contain a complete proposal shall be set to resolved. They may be integrated into the specification if no objections is raised to the issue within one week.
- All voting within a JIRA issue is informal and preliminary. The formal approval of  proposal takes place when a CSD that includes the proposal is approved (that's a consequence of the TC process, but it is worth mentioning this).
- Proposals approved in a CSD may be modified by follow-up proposals for a subsequent CSD.

I hope I didn't miss anything.

Best regards

Michael

--

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