[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
- [Pesci-discuss] principles for decision-making Melinda Shore
- Re: [Pesci-discuss] principles for decision-making Sam Hartman
- Re: [Pesci-discuss] principles for decision-making Melinda Shore
- Re: [Pesci-discuss] principles for decision-making Jari Arkko
- Re: [Pesci-discuss] principles for decision-making Sam Hartman
- Re: [Pesci-discuss] principles for decision-making Scott W Brim
- Re: [Pesci-discuss] principles for decision-making JFC (Jefsey) Morfin
- Re: [Pesci-discuss] principles for decision-making Sam Hartman
- Re: [Pesci-discuss] principles for decision-making Thomas Narten
- Re: [Pesci-discuss] principles for decision-making Melinda Shore