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

["Tschofenig, Hannes" <[e-mail]>]

hi melinda, 

please find some comments inline: 

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Melinda Shore
> Gesendet: Dienstag, 1. November 2005 16:41
> An: [e-mail]
> Betreff: [Pesci-discuss] principles for decision-making
> 
> 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,

the phrase 'does not scale' seems to be quite popular. 
what does it mean in this context?

> 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,

i am not sure that the current situation is as bad as some people see it. there are potentially a few people complaining about things here and there. if someone looks at the ietf mailing list then you can easilz get the impression that something is going wrong. 


> 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.

i will comment these two issues below:
#> 
> 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.

what type of decisions do you have in mind?


> Embedding results
> in meeting minutes does not satisfy this requirement.

i took meeting minutes for a number of working group session (particularly in the nsis working group). 
this is a tough job and as a chair you have a hard time finding good minute takers. 
since many decisions are taken during the meeting (and the impact of them is sometimes not fully obvious) i wonder what exactly you would like to write down and whether you have a particular style in mind. 


>  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.

this sounds quite simple and obvious but in reality this is not really possible. 

to me this sounds very much like "we need to understand all requirements in order to start our work on the solution." this might work in some cases but often the problem space is quite complex (often involving expertise different working groups). 

>  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.

what is so special about the size of the ietf? even if the ietf is quite large there aren't too many active participants in each working group. if you consider those people that are active over quite some time then the number is actually limited, for most working groups at least. i bet there are some counterexamples. 
 
> 
> Consensus is a process of synthesizing diverse elements into
> one outcome that is mutually satisfactory to all participants.

you know that this is not really possible.

> It depends on shared commitment to both the outcome and the
> process, and it requires specific skills in consensus building.

what are those skills? 

> 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.

i am happy very happy about this approach. to me this does not sound like rough consensus and running code principle. 

> 
> 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.


i agree that the review process is very important. during this year i worked on documents that involved several working groups. there is sometimes indeed a problem with the different style of how working groups are handled. 

during my work in the ietf i have noticed that there are not many "wrong" decisions -- it is often a matter of taste, architectural philosophy, assumptions you make, etc. that lead to different approaches. 

> 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.


many of the proposed changes in your mail might require the introduction of a lot of formalism. i think that this is not a good way forward. i do, however, think that some decisions need to be better justified and more transparent. i like a pragmatic approach. 

ciao
hannes
> 
> 
> _______________________________________________
> 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