Stringency (RE: 12 problems)

[Natale, Robert C (Bob)]

Hi,

jak said:
> Whoops! Cancel that analysis. If the number is "months per RFC",
> then it actually showed an *improvement* between 1995 and 2000.

Yeah, I had a hard time following your analysis in several respects.
In any case, what I think these numbers show is that we are almost
surely placing too big a workload on our "system" (by which I mostly
mean the *people* involved in quality assurance):

Year  RFCs Average  'C/B'  % Change  % Change  % Change
            Delay          RFC Count AvgDelay  'Productivity'
----  ---- -------  -----  --------- --------  --------------
1993  31    5.5     0.177  baseline  baseline   baseline
1994  80    8.4     0.105   158.06    52.73      -40.82
1995  61    10.5    0.172   96.77     90.91      -2.98
1996  96    12.4    0.129   209.68    125.45     -27.20
1997  103   14.4    0.140   232.26    161.82     -21.20
1998  147   19.6    0.133   374.19    256.36     -24.85
1999  157   19.8    0.126   406.45    260.00     -28.92
2000  158   24.2    0.153   409.68    340.00     -13.67

The "% Change" figures are relative to the 1993 "baseline" numbers.
So, while the "workload" has increased by over 400% and the delay by
well over 300%, the "productivity" index has remained relatively constant.

Of course, we all know there are factors missing from this analysis.
For one, we'd need to know whether the resources available to the
IESG, IAB, RFC Editor, Secretariat, etc., have increased proportionally
to the workload.  I'll assume the answer is "no" here.  Also, the
definition of "Productivity" here is very gross -- without factoring
in some meaning of "output quality", I don't consider it a very
meaningful measure.

I am sure all of that (and much more) can be debated in a variety of ways.
I am not one to shy from qualitative positions:  What I see in these
numbers so far is (1) a system that is probably generating more work than
it has resources (especially qualified people) to handle well and (2) a
relatively constant number of qualified people working very hard to keep
the system afloat.

The numbers do suggest that workload growth may have topped off, but
I would say they are at a level that is significantly too high.  Trying
to solve this problem by adding more resources *might* help, but the
root (I believe) is in reducing the workload on the front-end.

Cheers,

BobN