Re: [Pesci-discuss] Principles for the process vs Principles for Process Change

[Brian E Carpenter <[e-mail]>]

Sam,

My reaction is that this is excellent input and germane
to the discussion and to the impending draft (which really
is impending; we have no intention to be secretive but the draft
was only started 3 weeks ago). So I think I'll delay responding
in detail until the draft is available, within the next 4 days.

As I said to you privately, it proves hard to write down principles
for change in a vacuum, but our desire is absolutely to focus
on principles for change. To the extent that we've failed, the draft
will need more work.

     Brian

Sam Hartman wrote:
> 
> Hi.  As sponsoring ADs for the BOF, Bert and I are concerned that the
> principles discussion is drifting into an area that will get us
> sidetracked, take up a lot of time, fail to get consensus and will
> prevent us from getting the community feedback we need on the pesci
> direction.
> 
> Based on the minutes, which is all we have seen, it sounds like a lot
> of the principles being discussed are principles the team would like
> to see in the final IETF process.  We think that what we need now is
> principles for the process change process.  In addition to being hard
> to agree to and taking up significant time, I'm concerned that long
> discussions of principles for the resulting process will  encourage
> revolutionary rather than evolutionary change.  
> 
> I talked to Brian about this.  he said you have been discussing the
> issue internally and find it very challenging to separate process
> change principles from process principles.  Can you help me understand
> why that's hard so I can figure out what we want to do to focus the
> BOF?
> 
> I tried a bit of brainstorming to figure out why it might be hard to
> come up with process change principles.  Sometimes you find why
> something is hard when you try to do it.  At least for me, I found it
> fairly easy to brainstorm process change principles.  I think the
> principles I came up with are fairly clearly process change not
> process.  Perhaps the complexity comes at a later stage of the
> process: evaluating, evaluating for completeness or something like
> that.  Your help is greatly appreciated.  I did find that while I had
> principles in my head, I was not able to crisply state these
> principles.  I've never been good at that and I also ran into troubles
> that while I think the principles are obvious, crisp statements would
> imply decisions I should not be making as an AD for a BOF.
> 
> Alternatively, perhaps there is a problem of understanding.  Let me
> give some examples of what I think are fairly obvious process change
> principles.  I think these are reasonably well accepted and so I'm not
> stepping outside of the AD role by suggesting them.
> 
> * This process change process is designed to support evolutionary
>   change to the process not revolution.  There may be a need for
>   revolution; there has been in the past.  However we are not
>   designing that process today.  (This comes from the title of the
>   effort; I understand some people believe that revolution is
>   necessary, but presumably that's out of scope for the design team's
>   thinking.)
> 
> 
> * We need to say something about the interaction of process change and
>    tools development/deployment.  The IESG has found that process
>    changes can have fairly high costs if not accompanied by
>    appropriate tool changes.  As an example, many parts of the proto
>    process are very manual.  In that instance I think we all agree
>    that the net result is positive.  In another example, the IESG
>    adopted a procedure for mandating normative downreferences to
>    documents be mentioned in last calls.  The IESG didn't have tools
>    to notice these references, so it largely ignored the procedure it
>    had adopted.  Bill wrote such a tool, but we do not yet have an
>    infrastructure around this tool or a list of documents for which
>    these references are not required.  Now, we're trying to apply the
>    procedure, noticing things fairly late, delaying documents and
>    generally not happy with the current state of things.  However as
>    Harald and others have pointed out, with the right tools, this
>    process would be fine and would not be a bad idea.  The general
>    principle is that we need to consider the impact on tools in
>    developing process.  
> 
> * The process change process is community focused in that there is a
>  mechanism for the community to propose process change and that the
>  process change process ultimately must build a community consensus
>  around the process.  (It may be community focused in other ways as well.)
> 
> * Something about the strong community consensus has the power to
>   effect process change.  Brian put this well on the ietf list and I
>   think in plenary slides.  But see below: that may involve changing
>   those tasked with implementing the process if they cannot buy into
>   the new process.
> 
> 
> * We need to get input from those affected by process change and make
>   sure we understand how process change would  affect them.  (Wiggle
>   words as appropriate; we cannot understand everything up front.)
> 
> 
> * Process change is only effective if you have buy-in from those
>   implementing the process change.  At some level, you need to either
>   make sure people can implement the process (preferably willingly),
>   drop the process change proposal, or find a new set of people who
>   will implement the process.  I'm not sure how exactly you want to
>   state this, but there is a principle about the process change
>   process in here.    
> 
> 
> * The process change process should support experiments.  You need a
>   way to make changes that you might later decide are bad ideas
>   and to evaluate the success of changes.
> 
> And here are some principles that I suggest as examples of things that
> may or may not be good ideas.  I can think of arguments for and
> against these and would be happy to give the arguments for both sides
> if asked.  I want to make it clear that I'm not expressing an opinion
> for or against the inclusion of these proposed principles.
> 
> * There should be a set of principles agreed to by the community
>   against which process change proposals can be evaluated.  In effect,
>   we should have a community consensus on where we're going.  I can
>   think of models where this is part of things and I can also think of
>   at least one model where this is unnecessary.
> 
> 
> * The process change process should minimize the number of process
>   documents.
> 
> 
> --Sam
> 
> _______________________________________________
> 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