RE: [dita] DITA 1.3 Proposal Process

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

... and I forgot the most important aim of this process: that we move
ahead with productive work and get a new version out to public review
and release. This process statement puts that front and center; kudos
for that.

In that spirit, I too prefer having the five types of vote rather than
two with decorations, because it requires people to be explicit at a
stage when the proposal has been fleshed out fairly well and the
committee is reviewing it as a whole. A simple No vote is just that and
no more. 

In the interest of moving committee business along productively and
expeditiously, the qualifications to a No vote should be thought of as
instructions to the proposers. Seems to me there can be three kinds
(dividing one of yours in two):

a. It doesn't work for me. I'll move toward Yes if you address the
following problem(s).
b. I don't understand it. I can't vote Yes until I have the following
information.
c. I don't see the need for it. Why bother? The use case is
unconvincing. 

This last one should have been caught in phase 1, but I suppose someone
could wake up, pay attention, and come to this conclusion in phase 2, if
they missed the call, the minutes, the web content, and the email about
the proposal in phase 1. Or maybe the use case wasn't sufficiently clear
in phase 1--but that's something we should trap at phase 1 too. Still,
'should' is no guarantee. Is that reason enough to keep (c) in phase 2?

A plain No gives the proposer no direction. It basically says "This
can't be fixed, give up." But I think we expect to be told why someone
is voting No, at least in discussion leading to the vote. Obviously,
this applies to a No vote in Phase 1 or Phase 3.

Breaking it out into separate vote types:

1. Yes.
2. Sure, whatever.
3. No.
4. Fix this first.
5. Explain this first.
6. Why bother? (My bad, should have caught this in phase 1.)

In phase 3 we rely on assigned reviewers to raise and track concerns,
and report unresolved issues to the committee when it comes up for a
vote. They should explicitly be tasked with tracking issues surfaced by
votes of types 4 and 5.

A "Sure, whatever" vote (2) doesn't have the obvious utility that (4-6)
have. If a proposal passes with a lot of those, what does that tell us?
Maybe it's likely to be considered minor in scope and therefore be
approved without moving on to phase 3? If not, maybe it's particularly
important that the assigned phase 3 reviewers understand it well.

	/B

> -----Original Message-----
> From: Bruce Nevin (bnevin) 
> Sent: Tuesday, August 03, 2010 4:56 PM
> To: Robert D Anderson
> Cc: dita
> Subject: RE: [dita] DITA 1.3 Proposal Process
> 
> Any of the three flavors of a No vote indicate problems with 
> the proposal that should be addressed, even if only to 
> acknowledge them and say "but we nonetheless did it this way 
> because of these reasons."
> Ideally, we reach agreement. Lacking full agreement, we aim 
> to have dissenters brought along with the majority perhaps 
> grumbling but not kicking and screaming because we all have 
> to live with the ramifications down the road.
> 
> > -----Original Message-----
> > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > Sent: Tuesday, August 03, 2010 1:48 PM
> > To: Bruce Nevin (bnevin)
> > Cc: dita
> > Subject: RE: [dita] DITA 1.3 Proposal Process
> > 
> > Hi Bruce,
> > 
> > As indicated in your note, and in a couple of the comments today, 
> > there is some hesitation about having so many options for voting at 
> > step 2.
> > 
> > So, as a reminder - with 1.2, those on the call essentially had 3 
> > options:
> > 1. Outspoken agreement, from the two who moved and seconded 
> 2. Silence 
> > 3. Vocal objection
> > 
> > There's been a suggestion that some proposals only got in to
> > 1.2 because nobody was willing to be the one to say "No". 
> > There's also been a suggestion that this unwillingness to say "No" 
> > will not change, which is why we ended up with several options.
> > 
> > So - I think your breakdown is accurate. It comes down to 
> Yes, Yes (no 
> > objection), No, No (doesn't make sense), and No (not worth 
> it). If we 
> > want to describe the votes that way, that's fine - but I 
> think going 
> > to a flat yes or no, with optional clarification, will get 
> us back to 
> > the original problem that people seem unwilling to vote 
> "No" directly.
> > 
> > As for the "Standing aside" vote - I'm a little reluctant 
> about that 
> > only because I'm afraid it would end up being an easy vote 
> for people 
> > who don't really want to think about the proposal or register any 
> > opinion at all, much like the "silence" option in 1.2. It 
> also feels 
> > like this should qualify as a "no" vote if the vote is 
> already close. 
> > That is
> > - standing aside to allow for unanimity doesn't make sense 
> if people 
> > are already voting no, right? It seems to me that if you have 
> > objections, that should be a no; if you don't have 
> objections, there's 
> > the "Allow, but it's not necessarily something I want" option.
> > 
> > Thoughts?
> > 
> > Robert D Anderson
> > IBM Authoring Tools Development
> > Chief Architect, DITA Open Toolkit
> > 
> > 
> >                                                               
> >              
> >              "Bruce Nevin                                     
> >              
> >              (bnevin)"                                        
> >              
> >              <bnevin@cisco.com                                
> >           To 
> >              >                         Robert D               
> >              
> >                                        
> > Anderson/Rochester/IBM@IBMUS,       
> >              08/03/2010 12:22          "dita" 
> > <dita@lists.oasis-open.org>  
> >              PM                                               
> >           cc
> >                                                               
> >              
> >                                                               
> >      Subject 
> >                                        RE: [dita] DITA 1.3 
> > Proposal        
> >                                        Process                
> >              
> >                                                               
> >              
> >                                                               
> >              
> >                                                               
> >              
> >                                                               
> >              
> >                                                               
> >              
> >                                                               
> >              
> > 
> > 
> > 
> > 
> > Nudged by Gershon's spoken desire to look a bit longer at 
> phase 2 of 
> > the process, I revisited it. Five voter responses are 
> listed for phase 
> > 2:
> > 
> > 1. Yes.
> > 2. Sure, whatever. Not enough interest to try to understand 
> fully, but 
> > no objection to moving forward.
> > 3. No.
> > 4. Do not understand - the proposal as written and 
> described does not 
> > make sense.
> > 5. Have reservations (or some better name) - meaning "I'm 
> not sure I 
> > can or care to invest the time to understand this fully, 
> but I don't 
> > think the explanation of the use case warrants going any 
> further with 
> > this."
> > 
> > Essentially, this amounts to Yes vs. No, with an invitation to 
> > elaborate on the reasons for one's vote--especially a no vote.
> > 
> > 1. Yes.
> > Optionally can stipulate that this is an uninformed 'no objection' 
> > vote.
> > 
> > 2. No.
> > Optionally can stipulate:
> > a. Need clarification or more info.
> > b. Don't want clarification or more info, it doesn't seem worth the 
> > effort. This is an uninformed (don't care to drill into it) 
> vote, but 
> > the use case is unconvincing.
> > 
> > The 'annotations' to a No vote are to guide the proposer(s) in 
> > recasting the proposal for a new submission (or not).
> > 
> > Obviously, phase one may also run into objections, 
> reservations, and 
> > requests for more information. The difference is that at stage 2 
> > everyone expects to understand the proposal well (or not care). At 
> > stage
> > 1 all that must be clear is the problem or use case, and if 
> a solution 
> > is proposed no one expects it to be water-tight.
> > 
> > There's a second 'annotation' possibility for a Yes vote, 
> what Quakers 
> > call 'standing aside'. A person may register their concerns or 
> > reservations for the record, but be willing to stand aside 
> so as not 
> > to block approval. This can be an important option if the vote is 
> > close or if (like the
> > Quakers) we seek unanimity.
> > 
> > 		 /B
> > 
> > 
> > 
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
>