Re: [wg-review] Confusion between majority vote and consensus

[Greg Burton <sidna@feedwriter.com>]

Kent, thank you for the time and care you took in responding. I hope I've 
taken as much care in this reply.

At 10:00 PM 1/5/01, Kent Crispin wrote:
>On Fri, Jan 05, 2001 at 04:30:46PM -0700, Greg Burton wrote:
>[...]
> > "Quaker consensus" is the most  common form of consensus process in 
> general use, though there are others.
>
>The consensus process upon which ICANN was based is the one upon IANA is
>based: the IETF model.  Consequently, whatever you know about the Quaker
>model may or may not be relevant.

This is rather like saying "our web server is based on the Microsoft model 
- consequently whatever you know about Apache may or may not be relevant to 
a discussion of how browsers render the web pages we serve."

>The term is more precisely "rough consensus", from the IETF mantra "rough 
>consensus and running code".

I can accept that the INTENT was to mean "rough consensus", but it doesn't 
say that. It says "consensus" - unmodified and unqualified. I think we can 
agree that the process is NOT that. While the process as it stands may 
indeed correspond to something called "rough consensus" within the IETF, I 
would note that it is therefore still improperly identified and hence 
misleading in the bylaws.

It's worth commenting that the "IETF mantra" indicates that "rough 
consensus" by itself is necessary but not sufficient for the process of the 
IETF - it also requires "running code". (I take "running code" in it's 
broadest sense to be a shorthand for "look, it works and you can see it 
working".) Absent "running code" in this sense, which is impossible to 
generate in the social policy realm prior to the implementation of a 
policy, it should be clear that since "rough consensus" alone is not 
sufficient in the technical realm, it can't possibly be sufficient in the 
social and policy realms that the DNSO also addresses.

Let's take another tack for a moment. If we stretch metaphors and call the 
bylaws the organizations' "operating system", it should be clear that the 
implementation of input-process-output algorithms in the DNSO module is 
leading to system crashes. It's either a design flaw, poor implementation, 
or both -  "running code" that crashes the system whenever it's invoked is 
NOT running code in any shop I've ever worked with.

(admittedly unfair aside - If "consensus" as used here is "based on a 
mantra", no wonder Karl A thinks it's New Age woowoo. Sorry - I couldn't 
resist.)

>It most definitely does *not* mean "unanimity".

hmmm.....If a musical score indicates that a piece is in the key of C, and 
you complain that I'm out of tune, is "It really means C if you've tuned 
down a half step" a response the rest of the band will accept? (unless I'm 
the one paying them, that is)

>These provisions have to do with a decision
>process in the NC concerning how to forward (or not forward) proposals
>that are developed through separate consensus processes (which are in
>fact left largely undefined).

So if we read it your way, it gets even more interesting. "Largely 
undefined" becomes an understatement - there is NO explicit requirement in 
this section that any procedure or policy adopted by the NC actually itself 
be a consensus process. Again, the intent may be that such processes and 
policies conform to either "rough consensus" or "consensus", but it doesn't 
actually require it. The NC may design any procedure it wishes, AS IT SEES 
FIT, and declare that it is for the management of the "consensus building 
process".  Requiring that output be a sequential stream doesn't mean that 
all processes involved in producing that stream must run sequentially.

Read that way, Milton is absolutely correct that we are not required to 
operate by any form of consensus.

---bylaw excerpt---
(b) The NC is responsible for the management of the consensus building 
process of the DNSO. It shall adopt such
    procedures and policies as it sees fit to carry out that 
responsibility, including the designation of such research or
    drafting committees, working groups and other bodies of the GA as it 
determines are appropriate to carry out the
    substantive work of the DNSO. Each recognized Constituency shall be 
invited to participate in each of such bodies.
    Each of such bodies shall provide appropriate means, as determined by 
the NC, for input and such participation as
    is practicable under the circumstances by other interested parties.
---end excerpt-----

Let's go on:

> > The significant fact here as far as this discussion goes is that
> > "consensus" as used here in the by-laws does not describe actual
> > consensus.
...
>It takes a 2/3 majority of the NC to forward a proposal to the board
>with the label "consensus" on it.
>
>That's all.  This has nothing to do with the process by which the
>proposals themselves are developed.
...
> > The NC is placed in an impossible situation through this corruption of the
> > term.
>
>Nope.  The vote above is not part of the "consensus building process".
>These two provisions of the bylaws refer to two different things
>entirely.

The LABEL of consensus is misleading.  Allowing a group of 13 people to 
unilaterally label a report that 150 people worked on and only 80 agreed on 
"consensus" (a hypothetical case, but one that could happen) cannot be part 
of ANYTHING that legitimately claims to be a consensus process. Nor can you 
simply separate the forwarding of proposals from the process. The label 
matters. Significantly.
...
>
> > So - here is another statement - can we agree on it?
> >
> > Calling the current DNSO process "consensus" is misleading.
>
>Nope.  The wording of the bylaws may not be clear enough in
>distinguishing two very different things (the internal processes of the
>NC itself, and the consensus processes of the DNSO), but you are in
>fact seriously misreading it.

Somehow I doubt you like the implications of reading it as two different 
things....

Regards,
Greg

WG-Review says to Louie the King, I've got 40,000 red white and blue 
shoestrings and a thousand telephones that just won't ring....(parody of a 
Bob Dylan lyric - Kent gets the reference, I'm sure)

--
This message was passed to you via the wg-review@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe wg-review" in the body of the message).
Archives at http://www.dnso.org/archives.html