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: [draft] OpenDocument TC Work Flow


Dear TC members,

as discussed in the last TC meeting, here is a description of the
OpenDocument TC's work flow regarding proposals or change/enhancement
requests for the OpenDOcument specification.

Please note that this work flow never has been formally agreed by the TC.
Therefore, this mail describes not a formal work flow, but how the TC used to
work in the past.

Best regards

Michael



Proposals
---------
The OpenDocument TC's work is based on proposals. Proposals contain
enhancement requests for the specification, clarifications or suggests
other changes to the OpenDocument specification.

Proposals are submitted to the TC by TC members. Smaller proposals, like
the request to add a single attribute or attribute value, are submitted
to the TC by a plain e-mail. They may or may not contain the
proposed Relax-NG schema fragment and they may or may not contain a
formal description of the enhancement that could be included unmodified
into the specification. If the schema and/or the description are missing,
then the schema and/or description are drafted by the editors of the
OpenDocument specification when integrating the proposal into the
specification document.

Larger proposals are submitted to the TC as separate documents. They
contain Relax-NG schema fragments as well as a formal description of the
requested changes.

Proposals are discussed by the TC. If they contain no issues or if all
issues that exist have been clarified, the TC votes on including the
proposal into the specification document. While it is assumed that the
schema and description of the proposal, if they exist, are copied
unmodified to the specification, the specification editors still may
adjust the schema or wording when integrating the proposal into the
specification document if they feel that this is required. So formally a
sucessful voting is only the approval for the specification editors to
include the proposal into a new specification draft, but at the same
time it is the request to the specification editors to actually include
the proposal into the next specification draft, or a later version of
the draft, if this has been explicitly agreed.

All proposals are tracked in the TC's documents section in the
"Proposals" folder together with their current state.

Specification Drafts
-------------------
The TC editors periodically create new draft versions of the
OpenDocument specification document. The specification drafts include
the proposals for which the TC has agreed to include them into the
specification, and other changes the TC has agreed. The editors inform
the TC about the changes they made to the specification document, so
that all TC members may review them.

Committee Drafts
----------------
When the TC has agreed to provide a new committee draft, it starts a
review of the latest specification draft. This review takes at least a
week, but may take longer if issues that have to be resolved are found.
When no issues are found, or if the TC agrees to not resolve the
remaining issue for the current version of specification, the TC starts a
committee draft voting. Because this voting is about the full
specification document, it implies also a voting about the definite
schema and wording of the proposals that have been included in the
specification document.





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