what is a problem

[Harald Tveit Alvestrand]

--On s=F8ndag, november 24, 2002 15:39:18 -0500 Pete Resnick=20
<presnick@qualcomm.com> wrote:

> The *only* way to figure out what the problem above was is first to look
> at what the IESG can and cannot do in its current procedures. This isn't
> about figuring out solutions; this is about figuring out what problems
> actually exist.

actually knowing what the IESG can and cannot do doesn't help you in the=20
slightest when analyzing this particular case.....

you already know that the IESG is able to raise objections. you also=20
observe that the information in these objections can take a lot of time

you can also safely assume that this waste of time is not due to bad=20
intentions on anyone's parts (as soon as you assume bad intentions,=20
essentially all bets are off, and you need to polish recall procedures, not =

charters).

so the internal IESG process as currently instantiated is:

1 - an AD raises a point in mail or on the telechat ("raise a DISCUSS")
2 - that point gets discussed by the IESG on the list and/or in a telechat
3 - if the point-raising AD thinks the point is important enough, he keeps=20
the DISCUSS; otherwise he drops it ("no-obj with comments").
4 - the point-raising AD writes up the point, if still valid
    (may also happen in step 1, usually does if emailed)
5 - the shepherding AD tries to understand the objection, and then takes=20
the point back to the authors and/or working group chairs.

It's obvious now that in your case, one of these points failed/stalled, and =

unless the points' transition times get documented (which we try to do in=20
the tracker), it isn't possible to tell which step failed.

But a high level description of the IESG process, such as what I think is=20
appropriate for a charter ("the IESG is able to raise objections to=20
documents, and will attempt to get those comments back to the authors in a=20
timely manner") will STILL not tell you what failed.

                     Harald