[2191] in Release_Engineering
Re: Severity levels of bug reports
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sat Feb 24 19:51:44 1990
This is part of the way Multics development ranked problem reports. For more
look at /mit/jon/MAB/mab??? ...
-- Jon
Problem reports are further divided into Priority groups,
according to the significance of the problem.
1. Problem Reports
A. Critical Priority, a problem which:
- interferes with system operation to an extent
that usefulness of the system is significantly
limited for most users of the system. (1)
- irreparably compromises the security or integrity
of data stored in the system. Data storage
problems at system priority must affect many
system files, or files which are difficult to
retrieve or recreate.
B. High Priority, a problem which:
- causes installed system programs to fail to
operate correctly in limited circumstances, with
no known bypass for the problem. Such problems
can be tolerated for short periods of time.
- compromises data security or integrity for a
small number of files in a way which can be
repaired without significant loss of data. Such
problems can be tolerated for short periods of
time.
C. Normal Priority, a problem which:
- causes installed system programs to fail in a
minor way which can be bypassed, or ignored.
- results from incorrect documentation.
_________________________________________________________________
(1) This includes, but is not limited to, situations in which a
site is totally down, or is running in a highly crippled state.
The goal for TR processing performance states that 75% of
all TR processing operations will be completed within a specified
amount of time, where times are measured from submission of the
TR into the TR system to completion of the TR processing
operation.
The procedures for TR processing state the order in which
TRs are to be processed, and the expected amount of time needed
to perform each TR processing operation.
. . .
The expected amount of time required to perform each TR
processing operation is shown in the table below. Times are
expressed as the number of calendar weeks which should elapse
from time of submission to the time of operation completion,
averaged over all TRs whose operations have completed during the
reporting period. Because the times are averages, they do not
state the processing performance expected for a particular TR.
They instead address our overall TR processing performance.
Table 1: Average Calendar Weeks from Submission
to Completion of TR Processing Operation
OPERATION \ Problem Problem
COMPLETED \ Critical High Query Normal Suggestion
______________\__________________________________________________
| |
Verification | 0.2 1 1 2 4 |
| |
Response | 1 2 4 13 -- |
| |
Resolution | 4 13 4 52 -- |
_|_________________________________________________|
Verification and routing operations are performed as a
single processing operation, and are therefore shown as a single
processing goal in the table above.
Also, as the table indicates, no response is required for
questions. No response or resolution is required for suggestion
reports since current management policies state that response and
resolution of suggestions is optional.
_____ _____
\ \ # ops completed
total_ops = > > since 07/01/80
/____ /____
for problems (critical, for verification,
high & normal) and response and
questions resolution ops
_____ _____
\ \ # ops %_on_time
%_on_time = > > completed * for op
/____ /____ since 07/01/80
for problems (critical, for verification,
high & normal) and response and
questions resolution ops
%_performance = %_on_time / total_ops
Our goal is: %_performance >= 75%
O__r_d_e_r _o_f P__r_o_c_e_s_s_i_n_g T_R__s
TRs should be processed in the following order of
importance:
1. Problem Reports, Critical Priority
2. Problem Reports, High Priority
3. Questions
4. Problem Reports, Normal Priority
5. Suggestions
Type of report and priority of problem reports are initially
specified by the submitter of the report, but can be adjusted by
investigators, TR Administrator (who routes TRs) and developers
as the report becomes better understood.
