Re: WG Charter Milestones

[Jeffrey Hutzelman <[e-mail]>]

On Tue, 2011-06-21 at 09:19 -0700, Cullen Jennings wrote:
> 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 :-) 

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