RE: [dita] DITA 1.3 Proposal Process

["Grosso, Paul" <pgrosso@ptc.com>]

As in the past, I'm assuming (and I think others will assume)
that a "no" vote means you object to the proposal on some
explanable grounds.  I suspect few of us feel comfortable
voting no for "no reason".  However, I fear that is how the
DITA 1.2 process got out of hand.

For step 2, you allow for:

> "abstain" (do not understand), or "sure, whatever" (not
> trying to understand due to lack of interest, but no
> objection to moving forward)

You do not have "I'm not sure can or care to invest the time 
to understand this fully, but I don't think your explanation
of the use case warrants going any further with this."  I
think we should allow for such an opinion which counts as
a vote against going further with the proposal.

For step 3, you suggest:

> 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....

Again, this doesn't fix the problem we had with 1.2 because
it will be very unlikely that any proposal would not pass.
Instead, I'd suggest for step 3 that we have "yes", "no",
and "abstain for any reason (either because I still don't 
understand it or I'm still not convinced this is important 
enough or I just think we've got enough already in this
release of DITA)", and that more than 50% of those present 
must vote "yes" for it to be included.

paul

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com]
> Sent: Tuesday, 2010 July 13 14:24
> To: dita
> Subject: [dita] 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php