Subject: Re: advice on role of a WG Chair

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Jul 2006 17:35:02 +0200

Since Juergen re-raised and eveyone including myself seems to be having
a cow about process,  let's not go overboard in either direction.  For
instance...

Juergen Schoenwaelder wrote:
> I am waiting for a proof that the stringent documentation and process
> rules the IETF has put in place over the last few years actually help
> producing better documents and more running code and ultimately widely
> deployed technology.
>   
Seems to me a lot of the new process has been focused as much on
improving throughput as quality.  My understanding of the PROTO process
was that it was an effort to protect against a DDOS by working group
chairs who were either overzealous or hadn't bothered to read their own
drafts, thus requiring numerous rounds.  Part of that process, for
instance, requires a draft to pass idnits, something that it has to do
in order for the RFC Editor to take over.  A reasonable question is
whether we believe that process has helped.  Judging by the numbers it
seems to have, but I can't claim I understand the causal issues.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Jul 2006 11:21:21 +0200

> seems to have, but I can't claim I understand the causal issues.

These are hard things to measure in terms of cause and effect, because
it takes several years for changes such as PROTO to fully take effect,
but I think you are correct. Similarly I believe that the availability
to the community of the IESG's DISCUSS criteria will also have such an
effect -partly by making it hard for the IESG to have ill-defined
objections to a draft, and partly by making it clearer to WGs what sort
of thing the IESG gets worried about.

I'd like to underline that these things are procedural - we haven't
made substantial changes to our process rules for year.
(Hence the question asked in draft-carpenter-newtrk-questions-00.txt,
which will be asked again in plenary next week.)

     Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 10 Jul 2006 03:42:21 +0100

Andy Bierman wrote:

> Alexey Melnikov wrote:
>
>> Andy Bierman wrote:
>>
>>> IMO, WGs should be nuked if they don't finish on time.
>>
>> How many WG will be around after that?
>> (Most WGs I participate in are late, but making progress)
>
> What I am suggesting is that WGs take a more project-oriented
> view of their work.  The charter milestones seem almost irrelevant
> to many WGs -- because the Chairs know they can keep getting
> extension after extension.
>
> If you know you have a 12 - 18 months to get done -- or else --
> there would be more incentive to focus, keep it simple,
> and get work done in useful increments.

Right.

I am not saying that making WG accountable for milestones is a bad idea, 
but I would hate to make this a strict rule. There are so many reasons 
why people miss milestones, starting from authors/chairs being busy 
doing their day jobs, to unexpected issues that weren't anticipated when 
milestones were suggested.

One idea that came to my mind is to have 2 sets of milestones. One set 
is what I call "motivational" (or aggressive) milestones. They are used 
to motivate WG members to make forward progress on documents. The other 
set is a more realistic set of milestones agreed with the responsible 
AD, and generally it should not be known to the WG. The latter set 
should try to account for unexpected delays, etc. There should be some 
kind of a penalty for missing the realistic milestones.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Jul 2006 17:28:25 +0200

Alexey Melnikov wrote:
...
> kind of a penalty for missing the realistic milestones.

Secret milestones? Is that really how we want to manage the IETF?

    Brian

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Jul 2006 08:50:07 -0700

Brian E Carpenter wrote:
>> is what I call "motivational" (or aggressive) milestones. They are 
>> used to motivate WG members to make forward progress on documents. The 
>> other set is a more realistic set of milestones agreed with the 
>> responsible AD, and generally it should not be known to the WG. The 
>> latter set should try to account for unexpected delays, etc. There 
>> should be some kind of a penalty for missing the realistic milestones.
> 

No -- IMO we need to do 3 things:

1) finish the boilerplate, because the unstable documentation rules
    are the root problem to many 2nd order problems currently
    distracting and upsetting many people.

2) Transition to a meeting structure that allows for more technical
    meetings, especially inter-area and intra-area meetings:
      - project planning
      - functional requirements review
      - design review
      - final review

3) Stick to the well-crafted charters and milestones that the IESG approves.
    If WGs are going to depend on each other for delivering protocol features
    as components in an overall architecture, then the milestones have to matter.
    (I know WG Chairs should already manage the WG focus/scope effectively such
     that the WG always meets its milestones.  Yet in practice, IETF milestones
     are hardly ever met, so something is broken.)

>    Brian

Andy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jul 2006 11:44:59 +0200

Andy Bierman wrote:
> Brian E Carpenter wrote:
> 
>> Alexey Melnikov wrote:
>> ...
>>
>>> One idea that came to my mind is to have 2 sets of milestones. One 
>>> set is what I call "motivational" (or aggressive) milestones. They 
>>> are used to motivate WG members to make forward progress on 
>>> documents. The other set is a more realistic set of milestones agreed 
>>> with the responsible AD, and generally it should not be known to the 
>>> WG. The latter set should try to account for unexpected delays, etc. 
>>> There should be some kind of a penalty for missing the realistic 
>>> milestones.
>>
>>

I think the sad fact is that this may never end, so we need to find
a way to make it easy to embed the current boilerplate. That is certainly
a goal in the IPR WG, but as long as people want to use a variety
of tools to generate drafts, it isn't a sure thing.

>      - functional requirements review

Opinions certainly vary about this. If we didn't have a situation where
many individuals are each involved in many WGs, it would be much easier
to organize. I look forward to hearing how the post-IETF NETCONF interim
meeting worked out.

>     are hardly ever met, so something is broken.)

What I see is that the rough consensus requirement makes it harder
to meet milestones, since it doesn't offer a definitely terminating way
to make decisions. I don't have an easy fix for that. I think chairs (and
ADs) need to make it very clear to WGs that their milestone dates
are a contract. But if new issues come up, it's not good to ignore them.

     Brian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Jul 2006 06:15:06 -0400

>       - functional requirements review

Moving away from presentations and toward substantive technical discussion 
during meetings is something that individual working groups can and should 
do.  Some are doing it sooner and/or more agressively than others.

"Review" is not something that belongs in a face-to-face meeting session. 
It is something that happens in the comfort of your home or office, with 
the time to go over things in detail, follow references, etc.  Spending 
valuable meeting time going over a document point-by-point with people who 
haven't read it before is not only a poor use of time, it can be actively 
harmful because it tends to mask the problems that would occur if that 
person read the document on their own.

Now, addressing comments resulting from review is an appropriate use of 
meeting time, for comments where there is something to discuss (either to 
figure out how to fix a problem, or to convince a commenter that there 
isn't one).

With the exception of RAI, every area had an area-wide meeting at IETF66, 
and none of these overlapped with each other; this is normally the case. 
These meetings are generally a mixture of review of specific work going on 
within an area and discussions or presentations of relevance to the area as 
a whole.  If you want to know what's going on in other areas, attending 
these meetings is a good way to find out.

> 3) Stick to the well-crafted charters and milestones that the IESG
> approves. If WGs are going to depend on each other for delivering
> protocol  features as components in an overall architecture, then the
> milestones have  to matter. (I know WG Chairs should already manage the
> WG focus/scope  effectively such that the WG always meets its milestones.
> Yet in practice,  IETF milestones are hardly ever met, so something is
> broken.)

What's broken is the misconception that IETF milestones in any way resemble 
a hard deadline, or that the IETF can set such deadlines.  Participants in 
the IETF are volunteers, not employees.  A working group chair coordinates 
and administers his working group, but he does not have the power to set 
tasks, priorities, or deadlines for individual participants.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Jul 2006 07:54:49 -0400

> Participants in the IETF are volunteers, not employees.  A working
> group chair coordinates and administers his working group, but he
> does not have the power to set tasks, priorities, or deadlines for
> individual participants.

No, but the IESG does have the power to disband a working group that
doesn't meet its deadlines, if the IESG should decide to operate that
way.  Then it's up to the participants to decide whether the work is
important enough to them that they should/can set their own tasks,
priorities, and deadlines appropriately.

In practice, the IESG doesn't (and shouldn't) hold working groups
strictly to deadlines, but instead looks (and should) at the progress
the group is making.  Working groups that are making useful progress,
even if it's slower than we'd like, even if they're "behind schedule",
are given latitude and/or are rechartered to update their milestones.
Working groups that have stagnated are sometimes (perhaps not often
enough, but that's quite a subjective decision) shut down.

I don't think that's broken; I think that's as tightly as we ought to
be controlling deadlines.  That is, it all needs to be looked at group
by group, and subjective decisions need to be made.  Fixed rules won't
work well, and we'd wind up [insert cliché here].

Brian correctly points out that some groups sometimes depend upon the
work of another, and that the second group's delays adversely affect
the first.  That's certainly true, and needs to be taken into account
when the IESG makes the subjective decisions.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Jul 2006 15:10:42 -0700

Brian E Carpenter wrote:
>>>> documents. The other set is a more realistic set of milestones 
>>>> agreed with the responsible AD, and generally it should not be known 
>>>> to the WG. The latter set should try to account for unexpected 
>>>> delays, etc. There should be some kind of a penalty for missing the 
>>>> realistic milestones.
>>>
>>>

I will be honest.
I have known all along that this is really a non-issue
because of tools development.  As any gcc guru will tell you,
it doesn't matter how complicated the build environment is,
as long as the user can type "make all" and everything works.
Someday we will be able to do that for RFCs (!)

I just don't like the IETF wasting time on boilerplate.

> to organize. I look forward to hearing how the post-IETF NETCONF interim

Maybe this is only a conceptual process structure,
and the physical meeting structure is free-form ad-hoc,
WG meeting, bar bofs, whatever.

The absurdly over-sized meeting facility may have inadvertently
provided us with the simple answer:  Just provide the right environment
for lots of ad-hoc meetings to take place concurrently with our
regularly scheduled programming.  People doing their job will
take care of the rest.

>> approves.

IMO, it starts with the culture.
It shows up in little ways, like the way the IETF has always
kept charter pages in a way that disallows any meaningful
schedule accountability.  Again, tools (*) can save the day here
as well, by providing automated transparency.  This will help
give the perception that the milestones matter.
(* -- referring to the milestone tracker tool)

If that doesn't work, any WG 1 year late on a critical milestone
self-destructs on the that date, automatically, just the way
a 6 month old I-D is supposed to expire.

Andy