[Pesci-discuss] principles for decision-making

Melinda Shore <mshore@cisco.com> Tue, 01 November 2005 15:40 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyFq-0001Oj-7v; Tue, 01 Nov 2005 10:40:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyFp-0001Ob-5E for pesci-discuss@megatron.ietf.org; Tue, 01 Nov 2005 10:40:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27493 for <pesci-discuss@ietf.org>; Tue, 1 Nov 2005 10:40:32 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWyUC-00074G-NK for pesci-discuss@ietf.org; Tue, 01 Nov 2005 10:55:47 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 01 Nov 2005 07:40:42 -0800
X-IronPort-AV: i="3.97,274,1125903600"; d="scan'208"; a="359362593:sNHT26136020"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA1FeJK1017173 for <pesci-discuss@ietf.org>; Tue, 1 Nov 2005 07:40:40 -0800 (PST)
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Nov 2005 10:40:37 -0500
Received: from 10.21.113.117 ([10.21.113.117]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Nov 2005 15:40:37 +0000
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Tue, 01 Nov 2005 10:40:35 -0500
From: Melinda Shore <mshore@cisco.com>
To: "pesci-discuss@ietf.org" <pesci-discuss@ietf.org>
Message-ID: <BF8CF6A3.3317%mshore@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 01 Nov 2005 15:40:37.0418 (UTC) FILETIME=[9B0910A0:01C5DEFA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Subject: [Pesci-discuss] principles for decision-making
X-BeenThere: pesci-discuss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Process Evolution Study Committee of the IETF discussion <pesci-discuss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pesci-discuss>, <mailto:pesci-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pesci-discuss>
List-Post: <mailto:pesci-discuss@ietf.org>
List-Help: <mailto:pesci-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pesci-discuss>, <mailto:pesci-discuss-request@ietf.org?subject=subscribe>
Sender: pesci-discuss-bounces@ietf.org
Errors-To: pesci-discuss-bounces@ietf.org

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
Pesci-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/pesci-discuss