RE: [dita] DITA 1.3 Proposal Process

[Robert D Anderson <robander@us.ibm.com>]

Hi Paul - those suggestions both make sense to me. I've put them into the
wiki page.
http://wiki.oasis-open.org/dita/DITA_1.3_Proposal_Process

Thanks -

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

"Grosso, Paul" <pgrosso@ptc.com> wrote on 07/13/2010 03:49:17 PM:

> RE: [dita] DITA 1.3 Proposal Process
>
> 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
>
>
> ---------------------------------------------------------------------
> 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
>