RE: [dita] DITA 1.3 Proposal Process

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

I've updated the proposal process again based on yesterday's meeting. If
you've got additional comments or suggestions, please send to the list, or
add them at the bottom (Su-Laine started a section on the page for
comments).
http://wiki.oasis-open.org/dita/DITA_1.3_Proposal_Process

Thanks -

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

"Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote on 07/16/2010 03:59:31
PM:

> "Su-Laine Yeo" <su-laine.yeo@justsystems.com>
> 07/16/2010 03:59 PM
>
> To
>
> "dita" <dita@lists.oasis-open.org>
>
> cc
>
> Subject
>
> RE: [dita] DITA 1.3 Proposal Process
>
> Thanks Robert and Paul. The process that you've described on the wiki
> page looks like it will help a lot in keeping the scope reasonable.
>
> What do you think of requiring that in order to be approved, each
> proposal have a named spec writer and two named reviewers? This should
> help to ensure that writers are not overloaded and that review is prompt
> and adequate. We could also go further and say that if a named writer or
> reviewer drops out of the project and is not replaced by another
> volunteer within a certain number of weeks, the proposal is
> automatically deferred to DITA 1.4.
>
> Regards,
> Su-Laine
>
>
> Su-Laine Yeo
> Solutions Consultant
> JustSystems Canada, Inc.
> Office: 778-327-6356
> syeo@justsystems.com
> www.justsystems.com
> XMetaL Community Forums: http://forums.xmetal.com/
>
>
>
> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com]
> Sent: Tuesday, July 13, 2010 1:14 PM
> To: dita
> Subject: RE: [dita] DITA 1.3 Proposal Process
>
> 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
> >
>
>
> ---------------------------------------------------------------------
> 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
>