W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2005

Coments, please (was Re: Working group process and the future of the WG.)

From: Ted Hardie <hardie@qualcomm.com>
Date: Fri, 3 Jun 2005 11:24:32 -0700
Message-Id: <p06210201bec65037d8e1@[]>
To: w3c-dist-auth@w3.org

	I've gotten a very small number of comments back
to this either on-list or in private; if you have a comment,
even a short "My level of interest is ....", I would appreciate
your taking the time to send it.

At 1:12 PM -0700 5/27/05, Ted Hardie wrote:
>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
>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, 3 June 2005 18:25:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:34 UTC