Subject: RE: WG Quality Processes WG

From: <[email-masked]>
Date: Mon, 2 Jun 2003 16:29:25 +0300

Hi Harald,

> the mechanical things can be done, with just a Small Matter of 
> Programming... the trick is to figure out which ones actually help....

Of course, however, I am definately a proponent of the 'more info is better'
school.

> > It would be great, for example, if
> >
> >  a) WGs that were more than 6 months late on one of their deliverables
> > where      sent montly reminders of the fact until either the deliverable
> > was completed      or charter was updated.
> 
> currently we're going for bimonthly reminders to chairs on all overdue 
> milestones... I'm not sure how much that helps in the long run, but it's a start...

A gentle reminder is not a bad thing, speaking as a chair ...

> >  b) If the Draft-tracker had a time out, so that any document sitting in
> > a certain state for too long (say 4 months) generated a mail to the
> > mailing list, document     editor(s)/author(s), sheparding AD about the
> > status.
> 
> well.... state "RFC Published" and "dead" are quite OK for a document to 
> stay in, of course; "AD is watching" is doubtful (could change if/when the 
> system is extended to do WG tracking) - otherwise, it would seem to make 
> sense.

OK, OK, I guess I should have added 'relevant' state ...

> >  c) if the draft-tracker would send mail to a WG, author(s)/editor(s)
> > everytime a     document changed state
> 
> Already on the wishlist. I don't think the whole WG wants *all* the state 
> changes, so the WG chairs could act as a filter.....

That is fine, as long as it is mentioned that the chair SHOULD forward
relevant info to the WG.

John

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 02 Jun 2003 09:34:38 -0400

>That is fine, as long as it is mentioned that the chair SHOULD forward

I respectfully disagree...

One of the problems with the IETF, IMO, is how little communication
we have, and how much of it has to flow through certain bottlenecks
(including IESG members and WG chairs).  Also, why would we want to
introduce the human error of a WG chair into what should be a fully
automated process?

There may be a bunch of "noise" transition that the WG doesn't
need to know about, but the transitions between meaningful states
should just be sent, automatically, directly to the WG.  It's
not as though state changes happen _all_ that often, and we
could include some well-known tag in the subject or from field,
so that folks who are irritated by them can filter them...

I'd even be happy (not now, but in the lull between Vienna and
Minneapolis, perhaps) to help write-up a meaningful description
of each state change to include at the bottom of each e-mail
message, so that newcomers and lightly engaged participants
wouldn't be confused by the messages...

Margaret

---

From: <[email-masked]>
Date: Tue, 3 Jun 2003 06:12:18 +0300

Scott,

> I'm just reluctant to make it a WG without an immutable time-to-live,
> less than a year.  I want them to take on just one or two possible
> changes at a time.  A change which is so major that it takes longer
> should be shepherded by the IESG (at this group's 
> instigation?).  It can
> be recreated (not just rechartered) every time.  We have a precedent,
> the NomCom.  I don't want the group to get stuck in its ways.

So, putting it in different terms, if we go forward with such
a WG, are you suggesting it should have an extremely tight charter
that requires re-chartering to continue?

John

> On Sat, May 31, 2003 10:05:24PM -0400, Margaret Wasserman 
> allegedly wrote:
> >     A working group should be formed in the General Area of 
> the IETF to
> >     oversee improvements to the quality processes used in 
> IETF WGs, and
> >     to increase the effectiveness of IETF reviews at all 
> levels.  This
> >     group should take an experimental, iterative approach to these
> >     improvements:
> > 
> >          - Identify and prioritize a set of promising proposals for
> >            improvement.
> >          - Figure out what each proposal is trying to improve (in
> >            measurable terms) and define a metric to measure 
> performance
> >            in that area.
> >          - Determine the current level of performance against the
> >            defined metric.
> >          - Institute each change in a few representative WGs (on a
> >            volunteer basis).
> >          - Measure the results to determine if each change was
> >            successful.
> >          - Make successful changes available IETF-wide, by 
> publishing
> >            them in BCP RFCs.
> >          - As necessary, train WG chairs and other 
> participants on the
> >            how to implement the successful improvements in 
> their WGs.
> >          - Repeat as necessary.
>