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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: DITA 1.3 Proposal Process

This note is intended to start discussion about how to revise our process
for adding proposals into 1.3. I've already put this draft up on the wiki
[1], as I expect the final process will live there anyway. That page also
includes a summary of the 1.2 process and of problems with that process.

I suggest the following as a starting point for this discussion; we expect
to discuss this in more detail at the TC in 2 weeks (July 27).

Step 1. Proposals begin with a note to the OASIS TC list describing the
problem or use case, and optionally describing a solution. The TC discusses
the item at a meeting, and either accepts it or rejects it. To move
forward, the idea must be moved and seconded. If there are objections to
moving forward, we take a roll call vote, and the proposal only moves
forward if a majority vote "yes".

Step 2. The submitter and any interested parties fill out a proposal
document with a full solution to the original problem. This proposal
document is submitted to the TC for discussion. The chair should not put
the proposal on the TC agenda unless ALL sections are filled in; if a
section is not applicable, the proposal must include a short statement
explaining why. Once on the agenda, the submitter explains the proposed
solution at a TC meeting. If substantive changes are suggested, the
proposal must be resubmitted. Otherwise, the TC does a roll call vote on
the proposal; each voting member present must vote "yes", "no",
"abstain" (do not understand), or "sure, whatever" (not trying to
understand due to lack of interest, but no objection to moving forward). If
more than 50% vote "no" or "abstain (confused)", the proposal dies or must
be resubmitted with clarifications.

NOTE: If the proposal is considered minor in scope, approval at this stage
completes the process. This is only possible if the submitter and TC as a
whole agree that the scope is minor, and if the proposal already contains
all updates needed to the specification.

Step 3. The submitter returns with complete specification language for the
new proposal. For new elements, there must be a language spec topic for
every element. For new concepts, all new topics for the architectural spec
must be written. If the proposal requires modifications to existing topics,
those revised topics must be included (items with broad impact, such as a
new attribute with the same definition for 20 elements, may submit the
single definition rather than all 20 topics). The TC discusses the proposal
and then does a roll call vote; all voting members present must vote "yes"
or "no" to include the item in 1.3. If a majority votes "yes", the proposal
is included in 1.3; otherwise, the proposal dies, or must be resubmitted
with changes.

As part of this new process, the 1.3 template will also need to be revised;
Kris and I have offered to work on that document. I've also put a starter
for that into the wiki [1].

[1] http://wiki.oasis-open.org/dita/DITA_1.3_Proposal_Process

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

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