>>>>> "RJ" == RJ Atkinson <rja@extremenetworks.com> writes:
RJ> On Sunday, Nov 24, 2002, at 14:50 America/Montreal, Sam
RJ> Hartman wrote:
>> Personally I'm much more interested in achieving engineering
>> correctness--in finding a process that tends to work in
>> practice--than in spending significant time handling potential
>> corner cases allowed for by a charter when those corner cases
>> do not happen in practice.
RJ> Absent clear and complete documentation on the scope
RJ> of IESG responsibility, it is inevitably unclear which
RJ> problems are real and which are not.
I don't really understand what meaningful distinction you're trying to
draw between real problems and non-real problems. You seem to be
implying that when the process is followed and that when the IESG acts
within its scoped responsibility, perceived problems with the results
are not real. I believe this in not correct for many reasons,
including the possibility that the scope of the IESG is defined
incorrectly.
Remember we're not here to fix the IESG, we're here to find a
statement of problems with the entire IETF process.
Let's consider a potential problem: People believe that documents stay
in IESG wait too long.
We can determine whether this problem exists by analysis of data about
the process; we can compare how long people expect documents to stay
before the IESG with how long they actually did take before the IESG.
This comparison requires little information about the procedures of
the IESG; it does depend on some basic procedural elements like what
it means for a document to be before the IESG. However, I suspect the
procedures are well enough understood to make this determination.
If it turns out to be a problem that people believe that documents
take too long before the IESG then we still have a lot of work to do
to get from a problem to a solution. We have to answer questions like
whether the documents actually do take too long, why they take too
long if they do in fact take too long, etc. Potential solutions to
this problem might include:
* Educating people about why documents take a long time so that
perception matches reality.
* Working to make sure reality matches the ideal procedure.
* Implementing new procedures.
* Realize that while documents are not taking too long, we're never
going to convince people of the truth of this and give up.
Naturally actually answering these questions will involve information
like the current IESG procedures, scope of responsibility, etc.
Thinking more about my first message, what I'm proposing is that we
list the perceived problems rather than trying to work to a root cause
of the problem at this early point. This is consistent with Harald's
slides. I certainly believe it is necessary to consider all perceived
problems. Even if a perceived problem does not have a root cause
other than an incorrect perception, it is worth our time to try and
fix that perception because even an incorrect perception can drive
people we want involved away from the IETF. I suspect that listing
perceived problems is also sufficient; I cannot think of classes of
problems that we need to solve that aren't actually bothering anyone
in the process.
I believe that enumerating and clearly documenting the perceived
problems will actually be a fair chunk of work. I actually think it
can be handled in a fairly objective manner--certainly more objective
than determining whether problems are real or not or determining
whether the scope of the IESG is correct.
I also believe that an enumeration of the perceived problems would be
a useful input into a working group that considered solutions to these
problems.
--Sam