Subject: on WG milestones (was Re: I-D ACTION:draft-etal-ietf-analysis-00.txt)

From: Keith Moore <[email-masked]>
Date: Tue, 16 Apr 2002 13:20:40 -0400

> Query to the group:  If we believe we should not hold working groups to
> their milestones, why bother to have those milestones?

It's useful for a group to have a sense of direction and an anticipated 
timetable even if there is no penalty for changing the direction or failure 
to meet that timetable.  it's just like having a shared vocabulary - it
helps get people on the same page.

I don't think it's very useful to phrase the question in terms of whether
or not to have milestones or whether to hold groups to those milestones.

My first attempt at a better question would be: 

Why do our expectations of a group's progress so often fall short?

Some guesses:

- we often unrealistically expect that the energy that goes into creating
  the group will continue through the group's lifetime, so we pick 
  timeframes based on that level of energy.  

  the initial energy tends to run out within a year or so.  often, putting 
  the finishing touches on a document takes months or even years because 
  by the time this happens most of the participants are so burned out
  on that topic, and have started to work on other things, so they can 
  barely devote any attention to it.

- in choosing timeframes, we often overlook the difficulty and time 
  required to solve fundamental problems in a protocol, especially 
  security issues.

- there's a reluctance to pick realistic timeframes because of a fear that 
  the market will fail to wait for a standard solution if it's not expected 
  for two or three years, even if that's a realistic timeframe.  

- once the group's charter has been approved, hardly anyone in the group
  ever looks at the charter again.  most of the participants' attention is
  focused on the day-to-day mailing list traffic, not on the big picture.

- we have unrealistic expectations about the amount of time required
  to do external review (last call, IESG, etc), and to revise the 
  documents based on the results of such review.

- some groups don't limit the number of documents that they take on,
  failing to recognize that every additional document takes energy
  and meeting time away from the group.

Not meeting milestones is more of a symptom than a problem in itself.
The best way to relieve the symptom might be to focus on some of the
above problems.  Of course, groups that aren't making progress should
still be killed or reorganized, but what we really need to do is to find
ways to make the group more effective.

Suggestions:

- limit the goals: charter most groups to only do tasks that can reasonably 
  be completed within a year, or 18 months at the most.  allow a six month
  extension when necessary, but expect that the group will *shut down*
  (not be rechartered) after this period.

- the charter should specify which documents the group will produce.  
  every additional document should require a charter change with AD
  approval *before* the group starts working on it; until such approval
  is obtained the documents are individual submissions and outside of the
  scope of the group's work.

- try to identify likely solutions to the fundamental problems *before* the 
  group is chartered

- have the chair (or the AD) periodically send out the group's charter and a 
  status report to the mailing list, to remind people of where they are. 

- explicitly include last call and IESG review of each document in the 
  timetables.  also include at least one document revision cycle per
  document following such review.

Keith

---

From: Scott Brim <[email-masked]>
Date: Tue, 16 Apr 2002 13:58:31 -0400

>   (not be rechartered) after this period.

Yes.  Setting the goals correctly is critical in an environment like the
IETF.  Corollary: design the goals so that participants won't feel the
need for much feature creep once the working group is rolling.  

> - try to identify likely solutions to the fundamental problems *before* the 

I like the idea that a WG is chartered for either requirements or
solutions.