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