Subject: Re: WG Charter Milestones

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 01 Jul 2011 17:10:09 -0400

On Thu, 2011-06-30 at 16:42 -0500, Robert Sparks wrote:
> 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.

I still think we're confusing policy and implementation.

The _IETF's_ policy is that changes to milestones (other than marking
something done) must be approved by the appropriate area director.

The implementation of that policy, today, is that a chair who wishes to
change a milestone asks the secretariat to make the change, and the
secretariat's _internal_ policy is to confirm with the AD before making
the change.  This is appropriate, because chairs know when they send
email to ietf-action that they are asking to start the process to have
something happen, rather than actually doing the thing.

The change we're discussing is to get the human secretariat staff out of
the loop, on the grounds that they already have too much to do and that
latency on these sorts of operations will be lower if they don't have to
wait to reach the top of someone's work queue.

There are (at least) two ways to go about this.
One allows the AD to make the change directly.
The other allows the AD or the chair to make the change directly.
In either case, we are talking about altering the implementation, so
that milestone changes are effected by a different person.  We are not
talking about changing the policy, which is that milestone changes are
not effected until approved by an area director.

Working with computers too much tends to blind us to the difference
between the ability to do a thing and the authority to do it, because
we're so used to using software to insure that no one ever had the
ability to do a thing unless he also has the authority.  This is
particularly problematic when the authority he lacks is not to _do_ the
thing, but to approve it being done.

Just because we have a policy does not mean that the only way to be sure
the policy is followed is to write software that enforces a more
restrictive policy.  The policy we want is "milestones are not changed
unless approved by the AD".  The policy some have proposed to implement
is "milestones are not changed unless the change is done by the AD".

-- Jeff

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jul 2011 15:24:10 -0700

> wait to reach the top of someone's work queue.

That is not, in fact, the grounds on which we are making the change. I apologize if the introduction to draft-ietf-genarea-milestones-tool didn't make that clearer. What it currently says is:

   Today, the tasks associated with creating and updating WG milestones
   are performed manually.  Normally, WG chairs send email to their Area
   Director (AD) requesting that milestones be created or updated, or
   saying that one or more milestone has been met.  These messages
   sometimes come as part of charter creation or updating, but are often
   separate (such as if a current milestone is met but there is no
   reason to update the charter itself).  WG chairs sometimes send mail
   directly to the IETF Secretariat to make a change to the database of
   milestones, such as to change the dates for milestones or to say that
   they are completed.

   In early 2011, the IETF approved a set of requirements for a tool
   that helps ADs with the WG chartering and rechartering process
   [CHARTER-TOOL].  During the IESG discussion of that document, it
   became clear that everyone wanted more automation to the milestones
   process.  This document, and the discussion it will hopefully
   engender, is intended to bring that discussion to a general consensus
   among WG chairs and ADs for the requirements for the eventual tool.

   The IAOC would like to create a better tool for the tasks of WG
   milestone creation and updating, and this document lists the
   requirements for such a tool.

That is, this is not about "too much to do" or "latency"; it is simply about more automation. With the model as it is currently described, an AD gets to decide how much to maximize the automation. He or (historically) she can set it to 10 for a WG by allowing the chairs to do all the steps without AD approval, or set it to 8 by requiring AD approval. (Having this all be done in the web pushes it well past the "hopefully the email gets read" automation of today.)

> The other allows the AD or the chair to make the change directly.

There is the third way, which is described in the draft that this thread is about.

> not effected until approved by an area director.

In fact, the draft is mostly silent on this. The draft says "Any AD can add or update any milestone for any WG", and the unstated intention is that if a WG chair makes a change that an AD disagrees with, the AD can reverse the change. That is quite different than "not effected until approved by an area director".

--Paul Hoffman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 03 Jul 2011 23:42:08 -0400

On Fri, 2011-07-01 at 15:24 -0700, Paul Hoffman wrote:
> That is not, in fact, the grounds on which we are making the change. I
>  apologize if the introduction to draft-ietf-genarea-milestones-tool
>  didn't make that clearer. What it currently says is:

> That is, this is not about "too much to do" or "latency"; it is simply
>  about more automation.

You're right; I made an inference.  "More automation" is generally not
an end-goal; it's usually a means to some other end like saving labor,
improving performance or reliability, etc.

> With the model as it is currently described, an
>  AD gets to decide how much to maximize the automation. He or
>  (historically) she can set it to 10 for a WG by allowing the chairs to
>  do all the steps without AD approval, or set it to 8 by requiring AD
>  approval. (Having this all be done in the web pushes it well past the
>  "hopefully the email gets read" automation of today.)

That's fine.  I was simply trying to reject the notion that this is a
policy change.  Just because the tool is configured to allow a chair to
make a change without the AD going in and telling the tool it has been
approved, does not mean that it is appropriate for the chair to make a
change that has not in fact been approved.

> In fact, the draft is mostly silent on this. The draft says "Any AD can
>  add or update any milestone for any WG", and the unstated intention is
>  that if a WG chair makes a change that an AD disagrees with, the AD
>  can reverse the change. That is quite different than "not effected
>  until approved by an area director".

Yes, it is.  But, if the policy is that milestone changes must be
approved by an AD, then the "change" that chair made wasn't a change to
the milestones; it was a change to the records, with the effect of
creating an incorrect record (or, alternately, a correct record of an
incorrect assertion).  Of course, as Russ already pointed out, it is
this very property, plus the ease of reversing changes, that makes it
reasonably safe to give the chair the ability to enter that change in
the first place.

That, and the fact that we expect WG chairs to behave reasonably most of
the time.  Well, I do, anyway.  Perhaps the rest of the IETF has less
confidence in the fitness of its WG chairs for their positions.

Again, I'm merely rejecting the notion that the tool is the policy, and
that therefore deploying a tool which could make it _possible_ for a
chair to do something counter to the present policy is equivalent to a
policy change which gives him the _authority_ to do so.

-- Jeff