working group commitment

[Ted Hardie]

So, there have been a number of comments on the list since
this question was asked, but to circle around to this, I have
responded in-line.
					Ted
On Saturday, March 22, 2003, at 09:09 PM, Dave Crocker wrote:

> Ted,
> Friday, March 21, 2003, 8:11:15 AM, you wrote:
> TH> I also think that it might continue the issue that it will be
> TH> difficult to identify who in a working group has committed to
> TH> taking on a particular set of work.
>
> I was confused about this topic during the meeting, and remain so.  It
> is simply not clear to me how this is a problem, rather than an
> indicator of a problem.
>
> Let's take the simple perspective:
>
>    A working group has an active set of productive participants.
>    vs.
>    A working group does NOT have an active set of productive
>    participants.
>
> In the former case, you do not need an accounting system for
> "commitment" because the work is getting done.
>
> In the latter case, an accounting system won't help because the
> working group lacks critical mass of productive workers.

I agree with Dave that you fundamentally must have a set of people
willing to do the work and that counting them doesn't increase their
number.  There are some related issues, however:

1) How do you know in the early stages of a working group how many
people are willing to take on the work? (before you have much history,
this can be difficult--especially as the transition from BoF to WG 
sometimes
involves scope changes)

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

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

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


> So, having folks someone put themselves on some list does not seem
> like there is much of a win, unless there are incentives and penalties
> that are clear and provide meaningful leverage.
>
>> From the response to my question about all this, at the meeting, the
> primary need that I heard was predictability of work, due to
> dependency by other groups.
>
> Clearly such dependencies are important and fragile.  But will
> "commitments" really do anything to fix them?  For that matter, we
> might want, instead, to worry about basing one set of work on the
> simultaneous work of another.
>
> 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.

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

If we decide we won't do that to avoid the problem, we run both serious 
risks
to our ability to scale as an organization and to the quality and 
interoperability
of our technologies.  (At the absurd end of the scale would be every 
application
layer protocol reinventing the transport protocol rather than depend on
the application protocols development process; we'd end up with 
duplicates
of TCP a dozen times, with just enough tweaks different to eliminate
code re-use and interopability.  This is not a likely outcome, of 
course, as
it would mean not depending on existing technology rather than not 
depending
on the outcome of another group; it's just the problem carried to a 
logical
extreme to demonstrate the bound).

> 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.

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

>
> Unfortunately, that does not reverse the failure.
>
> 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>
>
>