[Mpi-forum] Voting in July (and beyond)

Jeff Squyres jsquyres at cisco.com
Thu Jun 14 10:53:21 CDT 2012

On Jun 14, 2012, at 11:25 AM, Dave Goodell wrote:

>> *** We =CANNOT= abolish "abstain" at the whim of one mis-guided decision from one meeting ***
> You are effectively asserting that your voting rules are more correct because you said that they came first, even though they were not clearly documented to anyone else.

Yes and no.  I'm saying that we've all been collectively crazy if, for the past 4 years of MPI 2.x and 3.0 meetings (and the MPI-2.0 meetings in the mid-90's), we've had an "abstain" position that meant nothing.  

Since I think we're *not* all collectively crazy, the only sensible conclusion is that "abstain" actually means something other than the other voting positions.

I have been asked about the voting rules many times, and I have discussed how I record the votes publicly in meetings.  I have *always* stated (and recorded) that pass = yes > no.  The PHP on the web site reflects this.  The spreadsheets in subversion reflect this. 

>> I do not think it is proper to change the voting rules based on any one meeting.  To me, changing the voting rules should require 2 formal votes (just like text) using the currently established rules.
> We have no procedure for this.  AFAIK we never voted the original rules into place.  

Agreed.  My statement above was intended as "To me (meaning: this is my opinion), changing the voting rules..."

Indeed, in my first mail on this thread, I stated "...discuss potentially changing the voting rules for future meetings ... and when/how to transition to new voting rules."

> At the Japan meeting we took consensus from the room because there was no clear ruling on this known to *anyone* in the room.  Both members of the steering committee that were present (Bill & Rich) felt the "abstains can't change the denominator" view was correct.

Regardless of end voting results, this is not how the votes have been computed and recorded for the past 3-4 years.  

We all know how the Forum can be completely swayed from one meeting to the next -- that's one reason we have the "text must be voted in twice" rule.  Indeed, look at what happened to Mohammad's ticket -- broad consensus one meeting, voted down the next.  Forum-swaying very much depends on attendance.

> I think that an in-person discussion about this on the first day of the upcoming meeting is the most appropriate way to deal with this debate.  

I am wary of this simply because of "the Forum can be swayed at a single meeting" effect.  That's why I propose:

1. Until voting rules are formally changed, we should continue as I have recorded the votes for the past 3-4 years (i.e., pass = yes > no)
2. We clarify/create new voting rules over a 2 meeting period

*** This proposal means that we will close out MPI-3 with a (mostly) consistent set of votes.  And we can start MPI-<next> with a potentially new set of voting rules.

> Perhaps a two-votes-over-two-meetings-scheme is appropriate, perhaps not.  When we have made other procedural changes, such as the "ticket 0" concept, I don't think that we used a two vote process.  I don't see this as substantially different.

My $0.02: it is substantially different.  Ticket 0 changes are broadly considered to be irrelevant -- we could not do them, and the standard wouldn't have a different meaning.  Non-ticket-0 changes have substantive changes.  Changing the voting rules is a substantive change, and must be done deliberately.  Otherwise, we could just change the rules every meeting.

> The most important thing for us to do is not bicker over which rules were correct at various points in the past, but instead we should attempt to agree on rules that work for the Forum going forward.  

Fair enough.  I don't think anyone wants to re-interpret old votes.

My point is that changing the computation in a single meeting should not be a basis for going forward.

Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

More information about the mpi-forum mailing list