[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]