Working group process and the future of the WG.

Several folks have asked where the discussion of the updated
role of the WG Chair is documented.  This is an output of the
PROTO team in the General area, and it is documented in
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt.

Though this is not yet an RFC, the IESG agreed to work using
these rules on an interim basis in February, and Scott Hollenbeck
announced that the APPs area would be using it at the most
recent Minneapolis IETF.  As most of you know, I was not at
the meeting because of family commitments, but he did so
with my full agreement.

Though this updates the methodologies by which a working group
chair and AD split the work of shepherding, it in some ways
codifies the way good working groups have always worked--active
working group chairs have always been involved in assuring that
adequate review inside and outside the working group has been
completed, that issues raised in Last Call or in IESG deliberation
are handled, and so.  It has also long been the case that the
IESG's reading of RFC 2418 on the role of the WG chair has seen
a Working Group chair as responsible for assuring the community
that a document put forward to meet a working group milestone
is appropriate to the task (see Section 6.1).  Chairs can do that
in multiple ways, but their own technical judgement is always
expected to form a part of that assessment.  It is entirely appropriate
for a chair to state a technical problem  with a spec and expect
the working group and editors to either resolve the problem or
document why the problem isn't an issue (usually in the spec).

In cases where the working group chair has to call whether or not
there is working group consensus on a particular resolution to
a technical issue raised in this way, we can run into problems.
The usual way of doing that is to have at least two chairs, so that
one can handle the process call for technical issues raised by
the other.   That strategy has been in place for this group since
I came on as AD, though I have to say a series of time commitment
issues has made it very hard to implement:  Jim had very few cycles
at the time he stepped down; Patrik had to withdraw very shortly
after agreeing to take the role; Joe has had issues with his organization
supporting the time required.  Joe attempted to augment the usual
mechanism by implementing a ticketing system, but those using
it seem to have plural opinions even on what it takes to close a ticket
so that it takes more, rather than less, effort to use it effectively.

The forward progress in the face of that strategy's failure has not been great.
At this point, I want to reiterate that Lisa's actions as Chair have been
both within my expectations as the AD for the group and that they have
had my support; we have discussed the working group's progress
on many occasions and the actions she and her co-chairs have taken
have had gone forward with my knowledge and consent.
She would be the first, I believe, to agree we have a problem in making
forward progress.  She's also had the brunt of trying to resolve it,
and I thank her for her efforts.

The question I have now is how to make that progress
when the existing strategy has failed multiple times.  We can change
chairs, of course, and this might help clarify the process role vs.
the contributor roles.  I am concerned, though, that is will not
be enough given the very small size of the working group's active
membership.  Judging rough consensus on a technical topic among
only a few people when even one disagrees is tricky; if you solve
that problem by ensuring that the chair has sufficient technical
depth in the subject to adjudicate, you are back exactly where we
are now.

We can decide that the problem of size does not admit of solution,
and we can shut down the working group.  This leaves a lot of
WebDav's published specs augmented by unpublished "lore" that
is needed to get things done.   I'm not thrilled by that, but if
there is no way to get further, we may have to do it.  I will
be very reluctant to accept individual submissions for the
standards track on WebDav core issues if we go this route,
since that forces the IESG to resolve issues the WG could
not.  It might happen, but it would take work on the
part of the proposers that is probably easier to accomplish
in a working group setting.

We can also try to radically limit what the working group is trying
to accomplish and set out a firm deadline, after which the working
group MUST shut down.  This helps focus energy and may encourage
folks who cannot commit to long term energy to commit to the short
term working group program.  If we go this route, I strongly suggest
the working group consider a very draconian approach to reaching
compromise.  One example I have seen outside the IETF that worked
was to say that if an issue could not be resolved within a set period
of time, the whole document involved sank to the bottom of the
WG's agenda--so everyone is clear that the failure to compromise
may mean that the document does not get out at all.  This
requires a great deal of discipline and forces everyone to ask
a new question ("Is this issue big enough that the document should
not go forward at all if it is not fixed").  It can, however, work to
get out the documents for which the WG is close to consensus
and to focus work on others.

I'd like to see the working group discuss these or other future paths.
I do remind folks to remain professional in their discussion and
that ad hominem comments are not tolerated; please think constructively
about what *you* can do to move us forward and especially about
what commitments *you* can take on.
			regards,
				Ted Hardie
				as Area Advisor.

Received on Friday, 27 May 2005 20:12:44 UTC