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

I agree with Eric.  We are adding WebDAV access to a variety of our 
repositories, and plan on using the BIND protocol.  We also are eager to 
see the locking protocol officially cleaned up.

Cheers,
Geoff

Eric wrote on 06/03/2005 02:31:55 PM:

> 
> We'd certainly like to see the WG complete the specs it has been working 

> on.  We are
> planning on implementing other DAV specs in our next database release. 
> Quota and BIND
> are certainly very nice to standardize as well.
> 
> Thanks,
> 
>   Eric Sedlar
>   Architect
>   XML Database / Server Technologies
>   Oracle Corporation
> 
> 
> Ted Hardie wrote:
> 
> >
> > Howdy,
> >     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.
> >             thanks,
> >                 Ted
> >
> >
> > 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
> >> 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.
> >
> >
> >
> 
>