Subject: RE: area directors at risk

From: "Dawkins, Spencer" <[email-masked]>
Date: Mon, 26 Nov 2001 10:17:12 -0600

One other minor point on milestones - WG milestones are the only committed dates I've ever seen that don't track original-forecast, current-forecast, and actual dates separately. If we don't like the committed date, we just update it, and if we ever complete something, all is forgiven (date = "DONE")!

Perhaps working groups would be motivated by public humiliation?

Spencer

-----Original Message-----
From: Aaron Falk [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 12:56 PM
To: Matt Holdrege
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: area directors at risk

On Wed, Nov 21, 2001 at 09:36:04AM -0800, Matt Holdrege wrote:
> Perhaps after a group has had it's initial charter created, the WG
> chair(s) can then do the updates on their own as long as they think
> it meets the consensus thinking of the working group. Then the IESG
> can always go back and slap a wrist or two if a chair steps out of
> line.

Matt-

I was thinking along similar lines.  However, in my experience, a well
written charter doesn't need nearly the maintenance as a meaninful set
of working group milestones.  IMHO, the working group milestones
listed on the charter page are usually so outdated as to be useless.

Suppose, rather than updating the working group's charter, wg chairs
invested more time in writing clear and meaningful milestones and kept
them updated.  Past experience on large projects has taught me that
one's ability to create an accurate schedule reduces rapidly the
farther out one plans.  So, naturally, when you create a list of
milestones you'll have many for the next few tasks and a few vague
ones out in the future.  There's nothing wrong with this as long as
you continue to update the schedule.  Where many charters seem to
falter is that a single list containing some deliverables and dates is
created then is only rarely updated.

This has the added benefit of requiring little to no pre-submission
review by the AD, so long as the milestones are consistant with the
charter. 

In fact, one might also make milestone updates a pre-requisite to
getting IETF meeting agenda slots.  Of course, this won't ensure
quality but it will at least cause chairs to give the matter some
thought. 

--aaron

PS. A glance at the PILC charter will show that I am at least as
guilty as the next chair milestone update procrastination. -af

---

From: Randy Bush <[email-masked]>
Date: Mon, 26 Nov 2001 09:46:02 -0800

> Perhaps working groups would be motivated by public humiliation?

how about semi-public?

like it sure would be nice if the wg chairs would actually update
charters and millstones as opposed to spending the time being sooooo
helpful in micro-managing the iesg [0].

how about no wg chair spends time making suggestions here unless
their charter and millstones are in great shape?  glass houses and
all that [1].

was that what you were suggesting?  :-)

randy, channeling frank :-)

---

[0] - actually, your concern, ideas, ... are appreciated.  the iesg's
      poor communication skills deprives you of the perspective to
      always be maximally relevant in this discussion .  in slc, i
      believe we'll do a bit at the plenary to be more revealing of
      the document process.

[1] - yes, i need to work on the dnsext charter.  hey olafur, shall
      we have a go at it before slc?

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Mon, 26 Nov 2001 15:17:36 -0500

>randy, channeling frank :-)

Not even close to channeling me...
I much prefer quite-public, messy, executions...
Look into the history of The Splitting Maul

Frank Grumpenholz

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 27 Nov 2001 00:11:01 -0500

>       we have a go at it before slc?

We submitted revised charters, twice this year but the AD due to overload
kept sending it back after the world has changed thus requiring more
changes.

I promised on June 7'th to get a new version to the AD after I got
back from the trip I was going on, but my (non existent) bug
tracking system never reminded me, and my co-chair never bugged me.

What this fiasco tells me is that IETF MUST adopt a common automated
system that tracks documents, charters, and events. Participants in
the IETF process must be able to quickly identify what open action items
are and more importantly what comments have been made in the past.

I do not want to see each working group going out a picking their
own system, we must pick one so to minimize the learning curve.

I know getting changing the process and getting the new system started
will involve a lot off work for the secretariat (or whoever takes this on),
but this must get done. It would be wonderful if IANA and RFC editor
where part of this system so WG chairs can see when actions are taken
on documents[1].

I'm willing to help in getting this effort of the ground, I hope some
other chairs are also willing to get this rolling.

What are the next steps ?

1. Create requirements (can we steal them from IEEE).
2. Select a system
3. Set up the system
4. Test the system in one area (multiple working groups)
5. Roll out the system and teach WG members to make comments on documents
         via the tracking system.

I think we should be able to accomplish 1 and 2 by the end of SLC,
and even start on 3.
In Minn. we should be able to go to step 5 and rese2rve some time slots
there to teach the use of the system.

One of the hard things is to set the policies and enforcing them.
For example I would like to see all official WG ID submissions go through
the tracking system with a change log entries pointing at comments.
The ID will not be announced before the author and chair sign off
that this is complete.

I say this as someone who co-chairs a WG that
- has run 10+ last calls this year,
         I can not keep track of all the comments,
- has about 30 ID on its platter
         Official working group documents, in various stages,
         some pending RFC publication to brand new items.
         or documents requesting the WG to take a look at them.
- has in 2 years dealt with over 50 ID's
         some pushed out as RFCs
         some killed
         some merged with others [1]
         many still on our platter.
- is struggling with advancing documents along the standards track
         DNSEXT has about 30 RFC as proposed standard,
         we need more templates on how interoperabilty reports are done
         we need information on how to conduct interoperabilty testing
         we need something to motivate people to take on tasks like this
                 and get rewarded/recognized for it[3].

         Olafur

[1] I as a WG chair want to see all communication between RFC editor and
RFC author especially the 48 hour notice.

[2] Once you publicly kill a few documents authors fall in line much faster.

[3] Getting people to author a ID is not that hard, as the carrot is possible
RFC publication. Interoperabilty testing has no such identified reward.
Can we publish Interoperabilty reports as a special RFC series ?

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2001 09:12:39 -0500

At 12:11 AM -0500 11/27/01, Ólafur Guðmundsson wrote:
>system that tracks documents, charters, and events.

Well, since Olafur piped up, so should I. ( ;) )

Not all groups are the same.  DNSEXT is a monster in terms of work items
and load.  PROVREG ("my[0]" group) isn't.  I can see why the larger groups
would need more automated help, but that isn't true across the board.  Just
as there is no one way to write charters, no one way to adopt documents, no
one way to run in-person meetings, etc.

Other than to say that I do believe there is a scaling problem in producing
documents - based upon experience from even before I chaired my current
group - I have no constructive criticism to offer on the original topic.
I've thought about the problem some, but haven't been able to arrive at a
solution that meets the (unknown) needs and costs less than the available
funds (none).

[0] co-chair with Jaap.  But then again does anyone really own a group? ;)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

---

From: Alain Durand <[email-masked]>
Date: Tue, 27 Nov 2001 15:21:35 -0800

> own system, we must pick one so to minimize the learning curve.

As I said earlier, I agree we need tools. However I'm not sure we should make
them
mandatory.  Let's try to make this the IETF "way", through rough consensus,
and let the folks who do not want to use it not using it.

> 1. Create requirements (can we steal them from IEEE).

I think they will have to be discussed a little bit. Not all wg have the same
needs
and what IEEE has required may or may not suit us. Let's have an open
discussion,
but let's not discuss for two years. Few weeks should be enough.
We may even have a late evening BOF with interested WG chairs to set up
the requirement in Salt Lake City.

> 3. Set up the system

There is a question on resources. Who is going to pay for it?

> 4. Test the system in one area (multiple working groups)

I would suggest to test it on the interested WG, not necessarily from the same
area.
Let get this rolling on a voluntarily basis.

    - Alain.