Subject: [Pesci-discuss] principles for decision-making

From: Melinda Shore <[email-masked]>
Date: Tue, 01 Nov 2005 10:40:35 -0500

As we discussed briefly last week, I see decision-making in the IETF
as both an ongoing problem and specifically as an impediment to making
changes in response to the "problem" process.  I'm proposing a set
of principles for IETF decision-making, although now that I look at
them I'm not sure that they'll actually be useful for this particular
process.  Still, I hope they'll provide a starting point for further
discussion, at least.  My specific concerns are that: 1) consensus-style
decision-making does not scale to an organization the size of the IETF,
2) there's an increasing number of disaffected participants who are
complaining about process and even threatening litigation and we need
a crisper decision-making and decision-recording process as protection
against those, 3) there's currently a lack of clarity about the
appropriate organizational response to a "bad" decision, and 4)
decisions often seem to be revisited over and over until someone
caves from exhaustion.

Melinda

--------
Principles for decision-making:

The decision-making process for both procedural decisions and
technical decisions must be transparent; participants should be
able to know 1) that a decision has been made, 2) how the
decision was made, and 3) who made the decision.  Decisions
should be recorded as part of a public record and should be
readily retrievable by researchers. Embedding results
in meeting minutes does not satisfy this requirement.  Exceptions
to the requirement to record decisions may include the private
deliberations of the IESG, nomcom, and so on, but those exceptions
should be limited and explicit.

Transparent decision-making also requires transparency in
question formation.  The entire question, including all alternatives
under consideration, must be presented and understood before
an answer is arrived at.  Note that in some sense question
formation is antithetical to consensus process, but is necessary
for decision-making on technical questions and almost certainly
for any question before an organization the size of the IETF.

Consensus is a process of synthesizing diverse elements into
one outcome that is mutually satisfactory to all participants.
It depends on shared commitment to both the outcome and the
process, and it requires specific skills in consensus building.
Consequently, while it can produce very high-quality outcomes
it scales very badly with the number and diversity of participants
and can completely fail when some of the participants are either
hostile or intent on disruption.  Decision-making in the IETF should
be robust and perform well in the face of a large number of participants.

Conversely, the ability to accommodate a large number of participants
should not also increase a vulnerability to "ballot stuffing."  This
implies the establishment of some sort of criteria for those who are
entitled to participate in decision-making.

If the IETF is to continue to be an organization in which physical
presence at meetings is not required in order to contribute, the
decision-making process cannot rely on decisions made at meetings.
Decisions involving participant input must continue to be made on
mailing lists or other appropriate mechanisms allowing remote
input.

Decisions must not be revisited without a clear and compelling
reason.  "I don't agree" on its own is typically not a compelling
reason, and allowing decisions to be reconsidered based on minority
disagreement with the outcome can keep working groups and other
spinning until an outcome is changed because of participant
exhaustion rather than because of merit.

Sometimes a working group or other body, lacking adequate
external review or sometimes undertaking an effort in a highly
specialized area outside its domain (for example, security),
may arrive at decisions that are simply wrong.  The IETF must
have clear guidelines for which bodies or individuals are
able to override decisions made by other bodies or individuals.
It is highly recommended that when a decision is overridden,
it is returned to the original decision-making body or individual
for revision rather than simply changed by fiat.

_______________________________________________
Pesci-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pesci-discuss

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Nov 2005 11:22:21 -0500

>>>>> "Melinda" == Melinda Shore <[email-masked]> writes:

    Melinda> As we discussed briefly last week, I see decision-making
    Melinda> in the IETF as both an ongoing problem and specifically
    Melinda> as an impediment to making changes in response to the
    Melinda> "problem" process.  I'm proposing a set of principles for
    Melinda> IETF decision-making, although now that I look at them
    Melinda> I'm not sure that they'll actually be useful for this
    Melinda> particular process.  Still, I hope they'll provide a
    Melinda> starting point for further discussion, at least.  My
    Melinda> specific concerns are that: 1) consensus-style
    Melinda> decision-making does not scale to an organization the
    Melinda> size of the IETF, 

I'm here because of the consensus process.  I believe it leads to
better quality technical work.  I have no interest in participating in
an IETF if "rough consensus and running code," is not the core
decision making principle.

So take this as at least one very strong voice for disagreement with
your approach.  I'm sure you expected that some people would hold my
position.

--Sam
 as an individual

---

From: Melinda Shore <[email-masked]>
Date: Tue, 01 Nov 2005 11:35:11 -0500

On 11/1/05 11:22 AM, "Sam Hartman" <[email-masked]> wrote:
> I'm here because of the consensus process.

Could you describe what you mean by that?  The reason I ask
is that what I'm seeing is that there really isn't a functioning
consensus process in the IETF in general, at least when it comes
to making decisions.  Collaboration, sure, but not consensus
decision-making.  Chairs tend to ask for votes on various
questions, dissenters tend to be brushed aside, and so on.  I
like consensus process, too, and have a pretty fair amount of
experience with it, but at this point I'm not convinced that
the IETF can get back on track with decision-making without
a fundamental change to the decision-making process.

I'll also note that in the security area you're more likely
to find the conditions that lead to successful consensus
decision-making, while in other areas you're not.  These
conditions would include things like a reasonably constrained
problem space, the participants have basic technical values in
common, and so on. 

There are other tweaks that can be made, as I mentioned (like
using clearer recording to improve transparency), and while I'd
like to find some way to fix consensus process in the IETF I
suspect the organization is just too big, too diverse, and too
competitive to permit that.  I'd be delighted to be wrong.

Melinda

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Nov 2005 18:44:15 +0200

>your approach.  I'm sure you expected that some people would hold my
I'm also in for "rough consensus" (sometimes we try to
make it too smooth) as well as "running code" (we need
more of that).

However, I'd like to make an observation that there
may be different decision processes depending on
the type of decision involved. I believe very much that
on our basic technical work RCRC should apply. But
we already apply different principles in different parts
of the organization. For instance, nomcom has its
special procedures. IESG has its special procedures --
not sure how I should classify them, would "absolute
consensus" or "voting" describe the final IESG review
model better than RCRC? And I'm fine with having these
specific processes. Not even sure that, e.g., the specific
IESG decision process is very significant as long as we
ensure IESG will review work and has a possibility in
affecting the outcome.

Anyway, what I wanted to say was that I would be open
for other types of decision processes for the process
work, too, or at least not dismissing them immediately.
(At least if they are not the "dictator decides" option.)

--Jari

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Nov 2005 11:57:03 -0500

>>>>> "Melinda" == Melinda Shore <[email-masked]> writes:

    Melinda> On 11/1/05 11:22 AM, "Sam Hartman"
    >> I'm here because of the consensus process.

    Melinda> Could you describe what you mean by that?  The reason I
    Melinda> ask is that what I'm seeing is that there really isn't a
    Melinda> functioning consensus process in the IETF in general, at
    Melinda> least when it comes to making decisions.  Collaboration,
    Melinda> sure, but not consensus decision-making.  Chairs tend to

In the working groups where I participate, we do work very hard to
reach consensus.  There are typically at most one or two people who
feel that their concerns have not been addressed on any given issue.

One aspect of it is that the effort would fail rather than produce a
sufficiently unacceptable result.

I'm sorry your experience in the IETF is not the same, but I'm very
reluctant to give up the good qualities I have.

---

From: Scott W Brim <[email-masked]>
Date: Tue, 1 Nov 2005 13:43:07 -0500

On Tue, Nov 01, 2005 10:40:35AM -0500, Melinda Shore allegedly wrote:
> discussion, at least.  

Melinda, these are a great start for "how to make a decision".  I
think that until we make the more fundamental principles explicit --
"why" are we making this decision, what our common goals are -- it
will be hard to agree on principles for decision making.  If we can
get the fundamentals down, e.g. as an extension to rfc 3935, that will
save a lot of time in agreeing on things like this.  That said ...

> My specific concerns are that: 1) consensus-style

As you've said before, there are many approaches to consensus.  Can't
we still have rough consensus, but reach it in different ways?

> decisions often seem to be revisited over and over until someone

All true.

Thanks.

swb

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 01 Nov 2005 18:15:52 +0100

Reality is that decision-making is with the user. There are/will be 
different SSDOs which may compete with the IETF (all the more when 
the IETF is used to oppose/exclude other solutions) and various versions.

Another approach would be to simply register user needs in a 
structured way (charters), proposed solutions (RFC), user comments 
and experimentation results and source codes. Something we use all 
the time on download sites.

Rather than consensus by exhaustion over exclusive solutions, we 
would have competition between RFCs. The common interest of the 
authors would probably to be smarter than others in providing 
compatible, simpler, easier, more inclusive solutions. Other SSDOs 
could share in the repository and a faster convergence by supported this way.

The RCRC processes would work among author but there would be no more 
dissenters. The decision-making you describe would only be for 
optional QA labels over charters and the proposed solutions, before 
registering them. Nothing would oppose different label depending on 
the type of usage.
jfc

---

From: Sam Hartman <[email-masked]>
Date: Sat, 05 Nov 2005 19:00:53 -0500

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    Jari> I'm also in for "rough consensus" (sometimes we try to make
    Jari> it too smooth) as well as "running code" (we need more of
    Jari> that).

    Jari> However, I'd like to make an observation that there may be
    Jari> different decision processes depending on the type of
    Jari> decision involved. I believe very much that on our basic
    Jari> technical work RCRC should apply. But we already apply
    Jari> different principles in different parts of the
    Jari> organization. For instance, nomcom has its special
    Jari> procedures. IESG has its special procedures -- not sure how
    Jari> I should classify them, would "absolute consensus" or
    Jari> "voting" describe the final IESG review model better than
    Jari> RCRC? And I'm fine with having these specific processes. 

I think the IESG actually follows RC RC although we've defined an
explicit measure of what rough is for documents at least.  Rough is
two ADs left out on an override vote.

I do agree that special processes for some things such as process
change may be appropriate.  I think the community would need to agree
to these processes.  I also think that ultimately the community needs
to at least have a consensus to consent to a process change.  We might
decide that community level line item editing of process changes is
something that doesn't work, but at least a community consensus call
at the end seems important.

--Sam

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Nov 2005 08:40:36 -0500

Melinda Shore <[email-masked]> writes:

> to making decisions.

IMO, this is an oversimplification. Yes, in some cases, the consensus
process hasn't worked. We can all probably cite ecamples.  But in
other cases it does. 

But, (surprise surprise!!), building a consensus is a skill that some
are much better at than others. It's also a skill that can be learned
(at least to some degree).

Seems like improving our consensus building culture by training
chairs, editors, and participants is a concrete thing that could be
done (e.g., by the EDU team) that would produce concrete results.

Thomas

---

From: Melinda Shore <[email-masked]>
Date: Mon, 14 Nov 2005 10:54:32 -0500

> done (e.g., by the EDU team) that would produce concrete results.

I think so, too, which is why I've been proposing it for 3 or 4
years now.

Melinda