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

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

Received on Friday, 3 June 2005 18:32:02 UTC