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

[Sam Hartman <[e-mail]>]

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