Subject: Re: WG Charter Milestones

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Jun 2011 09:19:09 -0700

On Apr 14, 2011, at 9:43 , Russ Housley wrote:

> IETF WG Chairs:
> 
> During the IESG evaluation of draft-ietf-genarea-charter-tool, the IESG talked about the best way to handle WG charter milestones.  One suggestion is that the IESG completely delegate milestone management to WG chairs.  Is this an idea that WG Chairs would embrace?

Updating dates of milestones or which wg drafts are associated with a milestone seems like a great thing for the chairs to do. 

However, I am not in favor of chairs adding new milestones, or changing the text of existing ones, without AD approval. The WG will make the chair do whatever they hum on, most WGs will hum yes to close every milestone proposed - the net effect with be a loss of any sense of focus in the WG and a peanut butter effect to spreading the energy so thin that each WG milestone takes longer than it currently takes. My view of one of the largest problems at the IETF is that things take too long - adding more milestones will not help.

One of the jobs of the AD is to help prioritize work in an area and get stuff moving. Adding milestones are one of one of the few tools they have to do it. Trying to delegate this to the chairs won't work because the chairs will end up directly or indirectly bound to the hums. If the area disagrees with the ADs prioritization, it's time for a new AD. 

Not to mention the issue of things like the codecs wg chairs might go and add a milestone for a video codec which I 'm sure would create a lot of excitement for the IESG :-)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Jun 2011 10:00:49 -0700

> Not to mention the issue of things like the codecs wg chairs might go and add a milestone for a video codec which I 'm sure would create a lot of excitement for the IESG :-) 

FWIW, the wording from draft-ietf-genarea-milestones-tool-01 is:

   The responsible AD for a WG can specify whether any of the following
   actions can be made without the AD approval for milestones associated
   with the WG:

   o  create new milestones

   o  delete milestones

   o  change milestone descriptions

   o  change milestone due dates

   o  change which Internet-Drafts are associated with a milestone

   o  assert that a milestone is completed

   The default settings at the time that this feature is launched will
   be that all actions other than changing due dates and asserting
   completion require AD approval.  These settings apply both to
   additions and changes made by WG chairs and by other ADs.

That means that the default settings match your proposal above, but allow the AD to let the WG chairs to create peanut butter on a WG-by-WG basis. Note that the AD will be informed of each change, regardless of whether or not the WG chair needed AD approval.

Discussion of this proposed text is heartily welcomed.

--Paul Hoffman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 28 Jun 2011 17:59:52 -0400

On Tue, 2011-06-21 at 09:19 -0700, Cullen Jennings wrote:
> Updating dates of milestones or which wg drafts are associated with a
>  milestone seems like a great thing for the chairs to do. 
> 
> However, I am not in favor of chairs adding new milestones, or changing
>  the text of existing ones, without AD approval. The WG will make the
>  chair do whatever they hum on, most WGs will hum yes to close every
>  milestone proposed - the net effect with be a loss of any sense of
>  focus in the WG and a peanut butter effect to spreading the energy so
>  thin that each WG milestone takes longer than it currently takes. My
>  view of one of the largest problems at the IETF is that things take
>  too long - adding more milestones will not help.
> 
> One of the jobs of the AD is to help prioritize work in an area and get
>  stuff moving. Adding milestones are one of one of the few tools they
>  have to do it. Trying to delegate this to the chairs won't work
>  because the chairs will end up directly or indirectly bound to the
>  hums. If the area disagrees with the ADs prioritization, it's time for
>  a new AD. 
> 
> Not to mention the issue of things like the codecs wg chairs might go
>  and add a milestone for a video codec which I 'm sure would create a
>  lot of excitement for the IESG :-) 

It seems to me that we are thinking about this wrong, and particularly,
confusing the ability to do something with the authority to do so.  WG
chairs are not children; presumably they can be expected to work within
our current process, whatever that is.  It should not be necessary to
encode current policy into the software.  Instead, the tools should
allow chairs and ADs the maximum flexibility to get work done.

WG chairs are not dumb automatons, either.  If the rules say that adding
a milestone requires AD approval, then a WG can't just stand up and hum
a few bars of "we want to add this milestone" and have the chair dance
over to the computer and start clicking things!

I also think there's an assumption here that adding or removing
milestones is the mechanism that gates what a WG does or does not work
on, and that somehow if the software allows chairs to add milestones
then WGs will run amok adopting all sorts of work that is not in their
charter or otherwise doing bad things.  That may well be the case, in
WGs that work on things "informally" and don't adopt a document until it
is done (a model I have never understood).  It's certainly not the case
in WGs I've been part of.  It's also worth noting that we don't require,
in software or in our defined process, that an AD approve adopting work.
Again, perhaps some people think you can only adopt work if there is
already a milestone, but the WGs I've been in don't work that way --
milestones appear as a result of the WG starting to work on something,
not as a cause.

Really, it's not necessary to write and test a lot of unnecessary code
to tie our hands and make sure everyone follows some person's idea of
how a working group ought to operate.  We're perfectly capable of
negotiating with our ADs as to what milestones should be, and I'd really
be kind of annoyed if the current model (negotiation, followed by me
sending mail to the secretariat and copying the AD) were replaced by a
model with more bottlenecks (negotiation, followed by repeatedly nagging
the AD to log in to the tool and make each change we discussed).

-- Jeff

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Jun 2011 15:50:24 -0700

> the AD to log in to the tool and make each change we discussed).

In case it wasn't obvious, the request to give the AD discretion on which of his or her chairs could automatically do what came from ADs, not from WG chairs. Maybe those ADs do not share the view of "perfectly capable of negotiating". If the tool is deployed as it is currently described, individual WG chairs can see how much their ADs trust them by asking their ADs to allow all actions to happen without needing approval from the AD.

--Paul Hoffman

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 30 Jun 2011 21:59:37 +0100

> In case it wasn't obvious, the request to give the AD discretion on which of
his or
> her chairs could automatically do what came from ADs, not from WG chairs.
> Maybe those ADs do not share the view of "perfectly capable of negotiating".
If
> the tool is deployed as it is currently described, individual WG chairs can
see how
> much their ADs trust them by asking their ADs to allow all actions to happen
> without needing approval from the AD.

Not all ADs are the same.
Not all ADs think that WG chairs should be on a short leash. There is no need
when we can shoot them!

Adrian

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Jun 2011 17:04:22 -0400

> Not all ADs think that WG chairs should be on a short leash. There is no need

I believe that the history of the actions taken is a powerful tool.  There is no need for fine grained access control when the actions are easily undone and the public ca see who did and undid them.

Russ

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Jun 2011 16:42:12 -0500

I've lost track of why we're having the conversation we appear to be having.

I _think_ we're talking about an official change to policy. As I was reminded recently
by the secretariat, the policy that is followed today is that any changes to the milestones
other than marking a milestone "Done" requires AD approval before it appears on the 
charter page.

If we want to change that policy, we should so explicitly. It's a mistake to make
that kind of change as a side-effect of what we code one tool to allow or not allow. 

As I said when reviewing the tool requirements, I'm ok if the tool allows for policies
other than what the current policy is, but it needs to allow the current policy, and that
should be the default (and arguably, the only valid) configuration until we reach
consensus to make a change.

To be clear, I am not arguing for or against the current policy with this message.
I'm saying tool needs to follow whatever the current policy is, not set it.

RjS