Re: Last Call: <draft-leiba-extended-doc-shepherd-00.txt> (Document Shepherding Throughout a Document's Lifecycle) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 07:40 25-09-2012, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Document Shepherding Throughout a Document's Lifecycle'
  <draft-leiba-extended-doc-shepherd-00.txt> as Informational RFC

The author is documenting his own opinion, and he is presenting that
opinion to the community for consideration.  The author is not
proposing any formal change, but he is interested in community
comments.  Since this is the authors opinions, changes to the document
based on received comments be at the author's discretion.  As a
result, the finished document will not claim to reflect IETF community
consensus.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2012-10-23. Exceptionally, comments may be

This Last Call is highly unusual. If the changes that are accepted is a matter of author discretion, why is there a Last Call and what is the role of the IESG here?

My reading of the draft is that it is a mix of RFC 4858 and the document life cycle (see RFC 6174).

In the Introduction Section:

  "It seems reasonable and helpful to begin shepherding at the time there's
   a call for adoption as a working group document, and this document
   gives one Area Director's view of how that extended shepherding
   function might work, and what tasks might be involved throughout the
   document's lifecycle."

This is good advice. It is however problematic to implement in my humble opinion. The shepherding process does not always work well. There are diligent shepherds and absent shepherds. Some authors end up with a bad IETF experience because of that. In my humble opinion, it cannot be fixed through methodologies. I don't know whether that problem can be solved. Extended shepherding means more work. It leaves less leeway for choosing a shepherd based on individual availability.

In Section 3.1:

  "This is the time to choose a Responsible Chair for the document, much
   as it will eventually have a Responsible Area Director later in its
   life."

With the introduction of "Responsible Chair" the other Chairs might consider themselves as spectators. Whether a Chair should take the lead on a document is up to the Chairs to decide. In simple terms, they have the latitude to decide how to get the work done.

  "Giving significant responsibility can be an excellent training
   exercise, preparing participants to take on future roles as
   Working Group Chairs."

Once a draft clears the AD review stage it won't get published if it is not kept "moving". This is where the document shepherd can be useful. I would suggest having someone with adequate experience instead of using this stage as a training exercise. The IETF idea of a training exercise is sending someone to face live rounds without an instruction manual.

  "And in a busy working group, offloading work from the Chairs to
   senior, experienced people (perhaps former Chairs or former ADs)
   can prevent the Chairs from being overcommitted, enabling the work
   to move forward much more efficiently."

Yes.  This is less about document shepherding though.

  "The issue tracker can be used to record not just the issues
   themselves, but significant parts of the discussion on both sides,
   helping to make it clearer what the resolution was and why, and
   whether a particular request to re-open a closed issue really
   involves new points or is just a re-hash."

This is significant work.  It is also a matter of style.

  "And as RFC 4858 says, the Shepherd should also email the writeup to
   the working group's mailing list, so the working group is aware of it."

There is a fairly good write-up at http://www.ietf.org/mail-archive/web/precis/current/msg00327.html :-)

The draft may be a better fit as Wiki material. If the draft is meant to help shepherds, I suggest discussing cases where things could be improved. For example, "documents spend *months* in AD Review state, largely because of lack of good shepherding". How long should the shepherd wait before sending the AD a reminder? "Use your judgement" only works if one is aware of existing practices. Sometimes it helps to say "remind me in a week or two". The dead zone is from AD review to IESG evaluation. I suggest focusing on that part instead of creating an extended shepherding process.

If I could paraphrase the draft, I'd say that the intent is to change shepherding from a mechanical exercise into a information gathering/input for decision-making/process-stumbling avoidance exercise. The hurdle is political inappropriateness.

Regards,
-sm


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]