Subject: Working group process and the future of the WG.

From: Ted Hardie <[email-masked]>
Date: Fri, 27 May 2005 13:12:33 -0700

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.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 29 May 2005 16:40:06 +0200

Ted,

thanks for the summary.

Below a few thoughts and clarifications...:

PROTO

I absolutely agree that the PROTO procedures make a lot of sense, in 
particular the requirements to come up with a detailed write-up when a 
document is to be submitted. If the WG chairs feel that they need help 
in collecting and summarizing this information, they should point that 
out, so that the WG can assist.

Ticketing System

I explicitly disagree on the comments about the ticketing system that 
was installed by Joe H. As far as I can tell, we had a WG consensus on 
how to use it for the WG Last Call for BIND, but for some reasons the WG 
chairs at some point decided not to follow that procedure anymore 
(without actually stating that). Reminder: that procedure was defined in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0001.html>, 
and as far as those rules are concerned, the BIND spec finished last 
call successfully. It would be really good if the WG chairs would either 
acknowledge this, or, alternatively, spell out exactly what they think 
is left to do.

WG future

I think it makes sense to distinguish different types of drafts the WG 
is currently working on.

Group #1: Advanced Collections

BIND and REDIRECT have been through a WG last call back in 2000 (as 
their sibling ORDERED COLLECTIONS, which we successfully finished in 
2003). Both specs are stable in that their authors are not aware of any 
open issues and in that there are implementations out there. As 
mentioned before, BIND went through a second WG last call in January.

At this point, the WG needs to decide whether these specs should be 
published through the WG at all, and if so, at which level. Not 
publishing these specs at all IMHO will negatively affect 
interoperability of existing implementations, though.

BIND is currently implemented in (at least) two server projects (one of 
which open source), and one client. Looking at the RFC Standards Process 
(as pointed out by Jim W on Friday), it really falls into the "Proposed" 
category.

REDIRECT is currently implemented in (at least) one server and two 
clients (one of which only implements discovery, but not creation of 
redirects). Again, this spec seems to fall into the "Proposed" category.

On the other hand, if we can't get consensus for publication as 
"Proposed", I think it would be the right thing to do publish as 
"Experimental". Not publishing at all clearly harms interoperability and 
causes valuable information to disappear from the set of documentation 
implementers usually can find.

Group #2: Quota

This spec has been added (without prior discussion) to the WG's work 
items; and has been extremely slow progressing. It now has reached a 
status without known issues. Unfortunately (but not surprising giving 
the very slow speed it has progressed), both authors do not work anymore 
for their respective companies, so what we should do is to find out 
whether the current document actually meets the requirements of those 
who originally wanted it (Xythos and Apple; as far as I can tell, we 
already got a nod from Apple's Jim Luther in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0069.html>).

Group #3: RFC2518bis

This is certainly the most important piece of work. It's really 
frustrating that all the effort spent on clarifications and 
simplifications (in particular for locking) hasn't led to a publication 
yet. For instance, just a few weeks ago the Subversion developers wasted 
a lot of time trying to implement the deprecated lock null resource 
semantics. I have offered by help in getting things done multiple times; 
and now that BIND and REDIRECT seem to be done I'm really looking for that.

To summarize: I personally think that the problems this WG has are caused by

- Draft editors responding too slow to issues (or not responding at 
all), and

- inability of the WG to manage the document submission once the 
technical and editorial work is done (meaning to either actually submit 
the document, or to precisely point out what's left to do).

If we fix these problems, we can submit BIND/QUOTA/REDIRECT quickly, and 
then focus all of our energy to get RFC2518bis done.

Best regards, Julian