[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [wg-d] Voting (Was "WG Principles")




On 5 August 1999, "Bret A. Fausett" <baf@fausett.com> wrote:


>Another question is when voting ought to occur and where it out to occur. 
>In other words, (i) are we talking about voting on each iteration of a WG 
>draft, pieces of a product, or only on the final version as a whole, and 
>(ii) are we talking about voting inside the WG or in the GA, or both? 


Well, here's what I meant when I refer to formal voting procedures.
Hopefully, this will address some of Kent's concern that every little
thing would be voted on:

Actual Voting Procedure:

The vote itself would initially be open ballot on mailing lists.  That is
to say, the chair would call a vote, and post a list of all those 
currently subscribed and therefore eligible to vote.  The chair would
set a deadline for voting (It'd be best to use GMT to avoid any confusion
over things like Daylist Savings Time in the US), and then those eligible
would simply submit to the list their vote.

In this way, everyone knows who is and isn't eligible to vote.  Everyone
can tally the votes.  The membership becomes a check against fraud.

When the deadline passes (based on some accepted standard clock, e.g.,
the timestamp on the votes placed in the Received: header by the system
running the mailing list, e.g., dnso.dnso.org), the vote is closed and
a final tally is posted by the chair, and may be verified by any who
wish.

Secret ballots could also be used, but this would require that
everyone trust the individual(s) handling the secret ballot.  In the
absence of "disinterested third parties" who could handle this, it
is perhaps not the best approach.

In f2f meetings, the more standard "show or hands" or verbal "aye/nay"
votes could be used, followed by roll call or secret balloting, if
necessary.


Times Voting is Implemented:

There would be only a handful of places where votes would be necessary:

1)  When a chair declares "consensus and time to move on" on an issue
    that is part of a WGs charter/goals, it would be time to vote on 
    the issue.  E.g., the WG has spent weeks debating X. The chair sees
    that the debate isn't being productive any more, and declares 
    consensus.  A vote is then called.  This has the benefit of not only
    being more accurate than "rough consensus", but allows for an
    exact count of those (not) in favor of the issue as summarized by the
    chair.

    I'm proposing this with the expectation that the chair would not be
    doing this every other day.  It should only be necessary for the 
    chair to declare consensus in this fashion after major parts of the
    WGs goals/charter have been addressed in debate.  I.e., the 
    consensus as declared would be worked into a major section of the
    final report; in essence, the WG would be voting on the content
    of a portion of the final report (note here that I'm referring to
    content in spirit, not letter.  Read on for that.)

2)  When the WG (or the subgroup working on a section of the actual
    final document) has produced a document for presentation and approval
    outside the WG, a vote would be called for approval of the document
    *as a whole*, not on each paragraph, as Kent jested.  

    This serves two very important functions: it prevents cries of
    foul play, underhandedness, etc. outside the WG after the document
    has been released (cf. WG-A's report in the GA list), and it also
    prevents the debate outside the WG from rehashing arguments held
    inside the WG, to a great extent.  There's a very nice feature of
    the formal voting process:  It has a tendency to shut up those 
    "vocal minorities" who turn out to be only one or two people in the
    group.  When faced with raw numbers, the vocal dissenters are forced
    into realizing their position is not that of the group, or even a 
    subset of the group.  This cannot happen with rough consensus, because
    there is no certainty about it.

    By allowing the WG to vote on the final document(s), the chair(s)
    can observe whether there is a significant minority or even a 
    majority that is dissatisfied with the document as it stands, which 
    would be an indication that the deadline should be extended and those
    portions of the document that are in dispute reworked.  Assuming all
    works as planned in (1) above, the only remaining issues should be
    those of style, and not those of substance.  

As you can see, my vision for formal voting would only interrupt the
WG process two or three times during the course of work, and once at
the end.  If a particular methodology could be chosen that is accurate
and simple, there's no need for votes to take a week.  At most, 3 days
should be sufficient.  3 days may seem like a long time, but the price
you'd pay in time is buying accuracy, the weight of numbers,
legitimacy, and an appearance of group coherence around the finished
product.

Finally, I'd like to point out that the (in)famous IETF "hummm" that's
been brought up more than once is nothing more than a sloppy formal
vote.  In mailing lists, it tends not to work that well.  In person,
it's nothing more than an "Aye/nay" verbal vote, or a show of hands,
both of which are formal voting procedures.  Additionally, both of
which typically yield to more stringent votes (e.g., roll call, secret
ballot, open ballot) when there's any doubt whatsoever to the outcome,
where "rough consensus" would rather plow ahead.

-- 
Mark C. Langston	     			Let your voice be heard:
mark@bitshift.org				     http://www.idno.org
Systems Admin					    http://www.icann.org
San Jose, CA					     http://www.dnso.org