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

["JFC (Jefsey) Morfin" <[e-mail]>]

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

At 16:40 01/11/2005, Melinda Shore wrote:
>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
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/pesci-discuss


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