working group commitment

[Dave Crocker]

Ted,

Well, so much for hoping that others might comment on your note.
However, you are raising a topic that is far too interesting to let
lapse.


TH> 1) How do you know in the early stages of a working group how many
TH> people are willing to take on the work?

As listed in IETF documents, basic criteria for chartering a working
group include indication that there are:

      - people willing to *work* on the topic,

      - a reasonable likelihood of there being groups willing to
        *implement* it, and

      - a reasonable likelihood that people will *use* it.

We certainly have tended to pay less attention to assessing work and
implementation indicators than we used to. Or perhaps the lack of
working group follow-through has become worse. In any case, we cease
usually to pay much attention, once a working group is chartered.

This can -- and in my opinion sometimes does -- lead to a working group
being controlled by a very few people, with no real underlying
constituency doing work or even likely to do implementation. By the time
of WG last call, there is essentially no one even doing reviews.

So, yes, I think the concern over commitment is entirely valid.

Where we seem to differ is between "assessing" adequate involvement, vs.
"assuring" adequate involvement.

This underscores an historical IETF precept that we seem to have lost:

     Organic filters to success should be noted, rather than "fixed".

Alternate wording:

     The IETF is primarily a place that "allows" work to be done, rather
     than one that "initiates" work being done or "makes" work get done.
     We decide on what work gets done based on a showing that enough
     people want to do it. If there are not enough workers, we do not do
     the work.

That is, failure to get the work done is an excellent indicator that
there is not enough community "pull" to warrant pursuing or approving
that work. If there were pressure, it would get done.


TH> 2) How do you ensure timely review by the wg in the face of the
TH> "someone else will do it" problem?

Simply require it.

If it is not done, the group is terminated. Hence, let the group figure
out how it wants to satisfy the requirement.


TH> 3) How do you manage the working group as energy fades (typical for many
TH> IETF wgs)?

Terminate the working group.

If energy fades, folks have lost interest.  If they have lost interest,
then community pull has gone away.

So the deeper question is how to avoid having energy fade? The obvious
answer is to move more quickly.

(And, yes, any nascent psychologist will note that the other lever to
the energy mechanism is to feed the group periodic rewards, by virtue of
the group perceiving itself as having successes.)


TH> I'd summarize these as:  "how can working group chairs, ADs, and those
TH> external to the working group assess the commitment to the working group
TH> deliverables over the life of the group?"

If work gets done, there is commitment.  If it doesn't, there isn't.

Not very difficult, though of course it is not emotionally satisfying to
take that passive a view.


>> My rule in projects is that critical dependencies on outside forces
>> vastly magnify risks. As distasteful as this suggestion might be, the
>> right solution is to avoid them.

TH> The right solution isn't always available.  We do have a problem that
TH> working groups are chartered to take on specific tasks and their success
TH> at those tasks may depend on work in other working groups.  Making
TH> that process work when it is needed seems to me a requirement.

And, yes, I did note that the fact of inter-working group dependencies
was the driving force.

This is another argument against having large projects.  It creates
real-time dependencies.

If there is enough community interest/pressure, then the dependencies
won't be a problem.  Each group will proceed nicely.  Otherwise, one of
them suffers from the other's delay, as you note.

This is why some work must be sequenced, rather than done in parallel.
It is also why some work must use existing component solutions, rather
than waiting for the latest, spiffiest one.

At base, there is a simple and frequently-demonstrated reality that any
new effort with dependencies on other new efforts is massively at risk.
It is not just an IETF issue.  It often occurs with startups, such as
those noting the early stage of an industry trend and then betting the
company on that trend developing (usually exponentially.)

The answer is not to "fix" the effort being depended upon, but instead
to find ways to eliminate it.  And, yes, I know that that can be
problematic.  However it is far better than trying to fix something that
cannot be fixed.


TH> If we decide we won't do that to avoid the problem, we run both
TH> serious risks to our ability to scale as an organization and to the
TH> quality and interoperability of our technologies.

Interesting.  I do not see this as a scaling problem for individual
working groups.  I see it as a problem of trying to take on large,
complicated projects.

We have never done those well, so in reality you are not trying to fix a
problem, so much as expand the scope of IETF working style.


TH>   (At the absurd end of the scale would be every
TH> application
TH> layer protocol reinventing the transport protocol rather than depend on
TH> the application protocols development process

Wrong model.

We got TCP.  Then we got a lot of applications.  We did not develop them
in parallel.  You want development in parallel.  To repeat:  we do not
have a track record of doing that.

(ps.:  To the extent that parallel development really is unavoidable,
this speaks strongly to making sure that the efforts are kept very, very
constrained, so that near-term delivery is feasible.)


>> If you cannot avoid them, the risk does not get lower by virtue of
>> having someone signed up in "commitment".  It just means that you have
>> a particular person you can blame when there is failure.

TH> I disagree.  I've seen strong differences in the way folks respond to
TH> work
TH> they've individually committed to take on (even as volunteers) and the
TH> way they
TH> respond to work that is assigned to a pool that they are  part of.

If they only issue is whether a chair makes sure that a work item has
someone signed up for it, then we do not have a systemic problem, other
than making sure that wg chairs manage their groups well.

     Accountability is Good (tm).

However I heard you trying to address a deeper kind of problem, namely
getting people to sign up when they won't do it on their own (or when
asked.)


I'll assume that you are pursuing something more than simply improving
basic project management.  I think we differ on whether failure to get
people to work is something to fix or something to respect.  You want to
fix it.  I believe we can't.  I believe we respect it as an indicator
that the group is no longer viable.

d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>