Process Experiment: Document Shepherding Throughout a Document's Lifecycle
draft-leiba-extended-doc-shepherd-03

1. Summary

Murray Kucherawy is the document shepherd.
Jari Arkko is the responsible Area Director.

  RFC 4858 talks about "Document Shepherding from Working Group Last
  Call to Publication".  There's a significant part of a document's
  life that happens before working group last call, starting at the
  time that a working group begins discussing a version of the idea
  that's been posted as an individual draft.  This document extends RFC
  4858, discussing the potential for extending shepherding and what
  tasks might be involved throughout a working group document's
  lifecycle, from start to finish.

Informational status has been requested.  As this does not impose new process, does not declare an experiment, and does not introduce a new standards track protocol, those other status options are not appropriate.

2. Review and Consensus

There was lively discussion of this work in 2012 when it was put through an IETF Last Call in the GEN area after a period of review and feedback.  One point of contention was that the author wished to retain editorial control over the content rather than ceding to consensus; the IESG at the time was fine with publishing it with changes to the boilerplate to reflect this.  There was debate at that time about the handling of the document since it is the product of one person and not of IETF Consensus — which would suggest the Independent Stream — but because it makes suggestions about a potential IETF process change, it was decided to process it as an Individual Submission.  The resulting discussion certainly reflected the confusion this caused, but there was no clear path forward.  As a result, it has sat in limbo since then.

I believe the document has had ample community review and, in fact, has had some successful implementation in the Applications Area Working Group (APPSAWG).  It therefore seems to me that the content of the document is not in question.  The process question, however, is unresolved.

Given that this is merely the summation of some ideas around document shepherding and does not rise to the level of BCP, I’m not sure either solution is preferable, so we should just pick one and move it forward.

3. Intellectual Property

The author has affirmed to me that he knows of no IPR on the material in this document that has not been declared as required by BCPs 78 and 79.

4. Other Points

Nothing of note.

[Ballot discuss]
As it has been pointed out during the discussions about this draft, it is unusual and probably problematic to publish the opinion of a single AD about our processes as an Informational RFC. If we recast it as a process experiment, we will need to agree on the type of consensus we will seek to run such an experiment.

[Ballot comment]
I am torn between a Discuss and an Abstain.

Apart from the fundamentals of the approach that Adrian calls up, this could be considered as a de facto written standing order to APPS Area WG Chairs, and I do not think we should be issuing such written instructions other than though the normal consensus process for IETF process change.

[Ballot comment]
I support Adrian's DISCUSS, and the solution to go for the process experiment per RFC 3933.

I see potentially a couple of advantages to this new process (delegation, potentially involve junior IETF people, potentially faster document deliveries with active management). However, while reading the document, I've been wondering: which problem does the new process try to solve? This should be explained better.

Right now, the draft reads

  This document proposes an extended set of Document Shepherd tasks,
  well beyond those covered in RFC 4858.

So, somehow, this is an update from RFC4848, but actually, not quite, because this is one AD's opinion.
I read RFC4848, and I believe that the current Document Shepherds don't do half of what's in there.
That's maybe part of the problem to be fixed, before asking them to do more.

[Ballot comment]
I would like to see this document go forward
as a process experiment, perhaps preceded by
some review as to the actual demand for the
process improvements.

[Ballot comment]
Given the quality of the conversations resulting from the drafts initial
submission, reviews, and last call, I don't see value in publishing the
document in its current form as an RFC.

The discussion has focused mostly on whether and how to capture things _like_
this, rather than what's actually being said. That's natural, given how the draft and the last call were formulated.
That said, the discussion didn'tclearly produce good ways for us to capture an individual's opinion, and there
have been good arguments made that this particular way could be harmful.
The proposals to reformulate this as a process experiment seem to point to a better
path (but I'm still skeptical it is the best path).

I'm glad we tried this approach. I don't think we should try it again. I think
we would be better served as a community to push towards community agreement on
the _substance_ of this draft, and continue to look for ways to make it easy to
make such a large bite of one person's insights accessible for that discussion.

I agree with much of the content of the draft. There are a few places where I
would have said things differently (particularly to avoid giving the impression
that "we" are encouraging all working groups to do things exactly the same way
rather than doing what's right for the situation the working group is in.

So, with respect to the effort that's gone into this so far, and hope that we
continue to work to improve the shepherding system, incorporating many of these
ideas. I will abstain.

[Ballot comment]
I very strongly agree with Stephen's and Adrian's discuss positions.

I know these are your thoughts I figured I'd sprinkle some of mine in and some edits:

I have a feeling (with no numbers to back it up) that there is only a small number of drafts for which shepherding right from the beginning would be reasonable.

a/s1: r/Area Director's/person's
s1: r/been the Responsible Chair/shepherded

s1, para 2: From my experience, things languish in WGs most often based on lack of energy either from the author or the WG.  People were gung-ho to adopt it and then they get distracted or loose interest.  I can't recall a time where the WG consciously said let's work on X first and then get on to Y - but maybe that's just me.

s1, para 3: r/We/I

s1, para 3: If drafts are actually stuck then I can see it, but energized authors can get through this, I think, more effectively than a shepherd.  Because of that I don't know that we need to assign somebody.  The authors need to know to throw a flag and say I think we're stuck here - and that's going to the chairs and if they're non-responsive the ADs.  What I often see though is that people say hey my draft is stuck because nobody is commenting on it.  Not sure how to make more people comment on drafts - usually that means nobody is interested.

s1, para 4: If we're doing this as a process experiment this needs to be fixed.

s3: add "0. Submit individual draft"  Few drafts start straight out in the WG and this would be a good place to point out the replaced by information the secretariat and we like to know.

s3.1: Responsible Chair for a draft?  I never did and I just can't see the WG chairs I have actually doing that.  Is there a tool change that allows this that I don't know about? :)

s3.2: It's hard to keep discussion going when there's often little energy or interest to get it done.  Not every WG draft need be published - I think that point needs to be made.  Some judgement needs to injected in to keeping it going or in to letting it die.

s3.2: I think you mean to say when the Shepherd is the chair they issue the WGLC or is this a request for a WGLC?:

  The Shepherd can take
  the responsibility of either asking for a WGLC (when the Shepherd
  isn't the chair) or issuing a WGLC (when the Shepherd is a chair)
  and of analyzing comments
  to determine whether things are ready to go ahead.

s3.3: Are you asking for early reviews of every draft from every directorate? If we're going to run this as a process experiment, I think we ought to let everybody know a little more explicitly - i.e., send 'em a message that says hey we're about to flood you with early reviews.

s3.3: I just can't see the Shepherd starting the write-up until right after the chair decides that they might send it to the AD.

s3.3: r/  1.  Issue an official "Working Group Last Call" message on the list,
      with a reasonable deadline given./
  / 1.  Chair: Issue an official "Working Group Last Call" message on the list,
      with a reasonable deadline given.

s3.4: I disagree that the y/n response provide "responses are of little or no use" - many of the y/n questions related to discuss criteria.  Regardless of how detailed the write-up is, I'm sure the IESG will revisit any point it wants to.

s3.4: r/IESG Secretary/IESG Secretary (iesg-secretary@ietf.org).

s3.4: should you say the document state changes to "Publication Requested"

s3.12: r/We're/You're

s5: There are DoS attacks based on the size of Shepherd write-up ;)

[Ballot discuss]
I wonder if we need to discuss any process experiment before we even have discussed if such a document is needed at all.  Why should we introduce a new process if we do not see any urgent need for this in the community?

The draft describes a single person's opinion. The abstract and the intro is confusing, as it says it is an AD's view of the process. However, this is rather a personal opinion of an IETF community member, who is also AD.

I could see this draft turned into a slide set for the EDU teams for Sunday, explaining the document run through the whole process.

Further:
Section 1., paragraph 4:

>    This document suggests specific tasks a Working Group Chair should be
>    doing or delegating in order to maintain forward progress,
>    accountability, and quality control on a working group document.  It
>    adds to what's in RFC 4858, intending to extend it, not replace it.
>    Major extensions involve assigning a Shepherd and defining specific
>    tasks earlier in a document's life, and possibly delegating Document
>    Shepherd tasks to a Shepherd who is neither a Chair nor the Working
>    Group Secretary (consistent with the IESG Statement on Document
>    Shepherds [Stmt]).

  I assume that a WG is badly screwed if we need already a document
  shepherd right in the beginning. We have the WG chairs who are
  responsible for WG as whole and the WG on its own.

  If the chairs are overloaded, they can ask for a WG secretary
  (Section 6.2 in RFC 2418).

[Ballot comment]
I tend to agree with the DISCUSSes; I think this would be better done as a process experiment rather than just being posted as the thoughts of a single AD on IETF process.

[Ballot discuss]
Updating my DISCUSS, having realized that this document is an individual submission, not on the independent stream.....

The 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." Insomuch as its scope is limited to "one Area Director's view", its value is somewhat limited.

Also, I wonder what it means to have IETF consensus on "one area director's view". Does it mean that the community agrees with that view? Or that the community believes that the AD actually holds that view?

[Ballot discuss]


(1) I don't know where we are on treating this as a process
experiment, but the document doesn't describe any process
experiment and is still written as a set of personal
reflections. I think it really must be revised before being
approved so that it does describe a process experiment.  In
fact, I think the text changes required will be significant
enough that this ought not be on a telechat agenda until
those are done. I agree with Adrian that if presented as
something that is not a process experiment, this would be
equally or more problematic.

(2) abstract: "It seems reasonable and helpful to begin
shepherding when there's a call for adoption as a working
group document..." I disagree. To me that seems like more
process. We have more than enough process already. Adding
more process, as is done here, seems neither reasonable nor
helpful. I would therefore prefer this not be published.  I
accept that the goal is process improvement, but am of the
opinion that the result would be more process stagnation. I
believe my opinion is as grounded in fact as the document
itself. Which leads to the discuss: where are the facts upon
which this (suggested) process addition is based?  If there
are none, why are we adding more process with no evidence to
back up the suggested added process burden?

(3) s3.1, there is no need for chairs to decide who is
responsible for a document unless or until they want to - why
create this new "Responsible Chair" role as a seemingly
IETF-wide consruct when its not? If there is no need then the
rest of the document seems broken as it depends on this role.
I'm also not sure we ought assume chairs divide resposibility
in that way.

(4) Allowing a shepherd to issue and decide a call for
adoption is a mistake IMO and one that would damage our
current processes by confusing participants as to who makes
consensus calls and changing who serves at whose pleasure.
Saying this "needs" to be done is just a bad plan IMO. (I
note that 3.1, step 4 is also recursive as 3.1 is also termed
"call for adoption" so this doesn't even seem sufficiently
worked out.) This continues in later sections, where chair
roles during WG processing are assigned to shepherds. I think
all of that is a bad plan.

[Ballot comment]


- s1, 2nd para: do we have any evidence that documents
"often" languish unintentionally?

- s1, 3rd para: our goal is not to move forward in the
process, but to have a process that allows improvement of the
Internet. Equating the former with the latter is an error.

- s1, 5th para: providing summaries can make it more likely
people try to slavishly follow those and impose process where
none is needed, and then repeat that a few times before a
document is done. Is that really a good approach?

- s2, last para: this seems to call for a chair to re-do all
the work a non-chair shepherd has done, i.e. it encourages
more pointless process.

- s3, codifying 12 steps seems undesirable to me, sometimes a
nice tidy document might do steps 1-5 when along comes an
upstart way better solution.

- s3.1, the chairs can well forget to record the shepherd's
name and nobody will lose out - in almost all cases the
shepherd is not needed until *much* later. This "should not"
is a good example of the kind of process-creep evident
throughout and demonstrated via the use of imperatives.

- I stopped with the detailed comments at this point. I think
my detailed comments thereafter are predictable other than
those below. In the main, imperatives need to be avoided.

- 3.6, IETF LC isn't mandatory for all documents is it? I
know we do it almost always nowadays, but I don't think you
can assume that that practice will remain for ever.

[Ballot comment]
After publication, errata may collect and go unprocessed for quite some time (years in many cases) ... should the shepherd be encouraged to help make sure this doesn't happen, somehow?

I tend to agree with Adrian's DISCUSS comments.

[Ballot discuss]
I am updating my Discuss having debated the draft with the author and some other folk around the IETF.

I do not believe there is value to the IETF in publishing RFCs that document individual people's opinions or thoughts about process. I think this would be the thin edge of a very long wedge.

I understand that publishing documents about the IETF process on the Independent Stream is not a good idea.

I understand that the author is expressing his opinions and so is not interested in IETF consensus (although obviously interested in discussion).

I can see that issuing an IETF last call effectively worked as a "call for comments".

However, I understand that the ideas in this document may well prove to be practical and useful. Therefore, I think that this I-D should be turned into a process experiment per RFC 3933. This would not require a significant change to the document, and would make it possible for ADs/WGs to make use of the ideas in this document. Furthermore, it would give the I-D a hook to hang on, make IETF last call and consensus meaningful, and make publishing an RFC relevant.

[Ballot discuss]
This is a preliminary Discuss to try to establish how we are going to progress this document.

I understand that publishing documents about the IETF process on the Independent Stream is not a good idea.

I understand that the author is expressing his opinions and so is not interested in IETF consensus (although obviously interested in discussion).

I can see that issuing an IETF last call effectively worked as a "call for comments".

I do not undesrtand why it is necessary to publish an RFC to record the thoughts and opinions of one person about IETF process. I am quite worried about what happens when another hundred people want to record their opinions about stuff.

IANA has reviewed draft-leiba-extended-doc-shepherd-00, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Document Shepherding Throughout a Document's Lifecycle) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Document Shepherding Throughout a Document's Lifecycle'
  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@ietf.org mailing lists by 2012-10-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  RFC 4858 talks about "Document Shepherding from Working Group Last
  Call to Publication".  There's a significant part of a document's
  life that happens before working group last call, starting, really,
  at the time a working group begins discussing a version of the idea
  that's been posted as an individual draft.  It seems reasonable and
  helpful to begin shepherding when 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.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/ballot/

No IPR declarations have been submitted directly on this I-D.

PROTO Shepherd Write-Up for draft-leiba-extended-doc-shepherd-00 (using the experimental template)

1. Summary

The document shepherd is Murray Kucherawy. The responsible Area Director is Russ Housley.

This document is the author's opinion of how the document shepherding function described in RFC 4858 can be extended through the full life of a document, providing a single person (a working group chair or someone who works under the delegation and supervision of a chair) who is responsible for keeping discussion and development of the document moving, and avoiding deadlocks and stalling.  The document proposes no formal change and, as one person's opinion, is presented as an Informational document.

2. Review and Consensus

The author posted a note about the draft to the IETF discussion list and asked for comments.  None were posted to the list, but there was one private comment suggesting that the name of the function be changed from "document shepherd", to avoid confusion with the function presented in RFC 4858, which has been formally adopted.  The author disagrees with this change; he explicitly wants to view this as a broadening of the document shepherd function, and using the same name is quite intentional.

Because the author is documenting his own opinion and presenting it to the community for consideration, and is not proposing any formal change, he is interested in community comments but is asking that changes based on those comments be at his discretion.  It is expected that the finished document will say that the IETF is publishing this, but not imply that the content reflects community consensus.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

None.