[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]