Killing old/slow groups - transition thinking

[Erik Guttman]

Randy,

You asked Marshall an excellent question.  I will try to answer it.

Randy Bush wrote:
> you keep focusing on missing deadlines with the a priori assumption
> that this is a really bad thing and everyone involved should be
> excoriated.
> 
> i keep asking so what?  i.e., what are the actual negative or
> positive results of deadlines being made or missed.  in terms of
> the goals of the ietf.

>From my point of view, the issue is timely delivery of quality results, 
not milestones per se.  Milestones are the only tool we have to predict
delivery and to account for timeliness.  We should 

 * try to be honest when we create milestones, and keep track

   Positive: We have a better idea where we are.

             We will have clear criteria on which to assess & push back.

   Negative: More paperwork, more brow beating will likely result.

 * really only schedule the amount of work we can do.  (Review progress.
   Make hard decisions along the way.)

   Positive: We might improve our throughput by avoiding the dangers
             of burnout, drift, ever-expanding scope, unclear goals

   Negative: We might refuse to take on high priority work.

             We might create a bureaucracy which will take on a
             life of its own, where justification exercises take
             a significant amount of our time.

 * strive to maintain and deliver in a *granularity* which takes
   only 18 months or so

   Positive: This discipline makes good engineering sense.

             We will be more likely to deliver stuff on time.

             We will have efforts of small enough scale they are
             feasible to review by a larger audience.

   Negative: Many projects will believe it is more work to do N
             phases than one big wad.

             To create a 'phased' protocol one must anticipate 
             later phases, which is not easy.

             Each phase would require separate review.

             We resist general frameworks.  Generality lengthens
             the design phase.

             WGs typically reinvent as much as they can, so
             small grain projects may not get reused well.

I submit we need more humility when it comes to chartering and to be 
more harsh when it comes to cutting off efforts of extravagent ambition.

I wrote:
>> Now, I believe that if the IESG is not keeping up, we (the rank and
>> file) should expect them to throttle back the IETF,

Randy Bush replied:
> the problem with this is that everyone thinks the ietf needs to say
> "no" more often.  but just as long as it is to someone else's work.

I explicitely referred to WGs I have chaired as good examples of work 
which the IESG could demand be better disciplined (specifically SVRLOC 
and ZEROCONF).  I have viewed my role as WG chair as fulfill the charter
*as defined by WG consensus and IESG input.*  I have pushed to narrow 
my WGs charters, but without WG support and/or IESG demand, it doesn't 
happen.

Many WG chairs will welcome an IESG that says "no" more often.  Pete
Resnick's posting supports this.

Erik