ODF-Next Proposal

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