Skip to main content

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

Discuss


Yes

(Russ Housley)

No Objection


Abstain


Recuse

(Barry Leiba)

No Record

Andrew Alston
Erik Kline
Francesca Palombini
Jim Guichard
John Scudder
Lars Eggert
Martin Duke
Murray Kucherawy
Paul Wouters
Robert Wilton
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES.

Andrew Alston
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Jim Guichard
No Record
John Scudder
No Record
Lars Eggert
No Record
Martin Duke
No Record
Murray Kucherawy
No Record
Paul Wouters
No Record
Robert Wilton
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Adrian Farrel Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-11-05 for -00) Unknown
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.
Gonzalo Camarillo Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-11-15 for -01) Unknown
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.
Martin Stiemerling Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-11-14 for -01) Unknown
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).
Ron Bonica Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-11-13 for -01) Unknown
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?
Stephen Farrell Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-11-12 for -01) Unknown

(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.
Russ Housley Former IESG member
Yes
Yes (for -00) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2012-11-15 for -01) Unknown
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.
Pete Resnick Former IESG member
No Objection
No Objection (2012-11-13 for -01) Unknown
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.
Ralph Droms Former IESG member
No Objection
No Objection (2012-11-14 for -01) Unknown
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.
Sean Turner Former IESG member
No Objection
No Objection (2012-11-14 for -01) Unknown
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 ;)
Wesley Eddy Former IESG member
No Objection
No Objection (2012-11-12 for -01) Unknown
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.
Robert Sparks Former IESG member
Abstain
Abstain (2012-11-14 for -01) Unknown
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.
Stewart Bryant Former IESG member
Abstain
Abstain (2012-11-15 for -01) Unknown
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.
Barry Leiba Former IESG member
Recuse
Recuse (for -00) Unknown