HET
Problem Report Management System (PRMS) is built on Gnats Bug Tracking
System, an
email based problem tracking system originally developed by Free Software Foundation, along with
Karl Berry's enhancements to wwwgnats web
front end.
It provides a semi-formal mechanism for users, staff, and managers
to report and solve problems in the system or at the site. Three
types of users are expected to utilize the features of this system.
Submitters send problem reports, maintainers are
responsible for solving these problems, and managers are
responsible for allocating our limited resources in the ongoing effort
to solve these problems. With the small group we have at HET, staff members
may assume any or all of these roles.
Submitting a Problem Report
A Problem Report (PR) consists of a number of attributes. Each
problem report is characterized by its category, class,
severity, priority, state, and responsible
party.
The category is simply which system has the
problem. At HET the following categories are used:
- CCAS -- the Center of Curvature Alignment System
- Doc -- general documentation problems
- ECS -- Environmental Control System
- Enclosure -- the dome, shutter or building
- General -- anything not covered by the other categories
- HRS -- High Resolution Spectrograph
- LRS -- Low Resolution Spectrograph
- MCS -- Master Computer System
- MRS -- Medium Resolution Spectrograph
- PFIP -- Prime Focus Instrument Platform
- PMC -- Primary Mirror Control system
- Site -- general site issues
- SPS -- Segment Positioning System
- Structure -- Telescope structure
- TCS -- Telescope Control System
- Tracker -- the Tracker and its control system
- UFOE -- Upgraded Fiber Optic Echelle
The class of a problem report concerns which subsystem
of the category that this problem report refers too. The following
classes are used at HET.
- sw-bug -- a problem with software or hardware. No category called hw-bug
exists in this system so use this for hardware problems as well.
- doc-bug -- a problem in the documentation
- change-request -- request for new feature or change in behavior
of existing features
- support -- general user support questions
The severity of a problem is a measure of how serious
the submitter thinks the problem is. Severity level may be changed by management
or maintainers. Currently, the HET PRMS system supports the following
severity levels.
- critical -- the system is non-operational or some essential
functionality is missing. No workaround is known.
- serious -- the system is not working properly or some essential
functionality is missing. Problems that would otherwise be rated
critical would be rated serious if a workaround is available.
- non-critical -- the system is working but lacks some essential
feature, has irritating behavior or does something incorrectly.
Performance of system is not severely affected.
The priority of a problem is a measure of how important fixing
the problem is to the submitter. There is some overlap here with the
severity of a problem, however, severity defines how bad a problem is in
relation to the system involved, i.e. how the system is affected,
while the priority defines the relation of the problem to the users. The
HET currently supports the following priorities:
- high -- a solution is needed right away
- medium -- a solution should be available in the next release
- low -- a solution should be available in a future release
The state of a Problem Report is a measure of where it is
within the PRMS system. Current state values are:
- Open -- problem report has been filed and the responsible
maintainer has been notified.
- Analyzed -- maintainer has looked at the problem and has
an idea about where it is or how difficult it may be to fix.
- Feedback -- maintainer has integrated changes into the
system and is awaiting to hear if these changes correct the submitters
problem.
- Closed -- changes have been incorporated, tested, and documented.
No further work is planned on this report.
- Suspended -- work on this problem has been postponed due to high cost,
lack of time, or lack of available resources.
The responsible party or maintainer is the person assigned
the responsibility of fixing the particular problem. Currently the entire
HET staff at McDonald as well as the programmers in Austin are listed
as available maintainers. However, we may choose to have only the HET
mountain staff and Niall Gaffney be responsible parties. These
people may actually farm the work out to others but they are the ones
ultimately responsible for finding a solution to the problem.
When submitting a problem report you should provide your email
address, a one line synopsis of the problem, and a detailed
description of the problem and how to repeat it. The following
paragraphs about submitting problem reports, taken from the Gnats
manual, should provide some hints about submitting descriptions.
There is no standard for submitting effective problem reports,
though you might do well to consult the section on submitting problems for
GNU gcc,
by Richard Stallman. This section contains instructions on what kinds
of information to include and what kinds of mistakes to avoid.
In general, common sense (assuming such an animal exists) dictates
the kind of information that would be most helpful in tracking down and
resolving problems in software or hardware.
- Include anything you would want to know if you were looking at
the report from the other end. There's no need to include every
minute detail about your environment, although anything that might
be different from someone else's environment should be included
(your path, for instance).
- Narratives are often useful, given a certain degree of restraint.
If a person responsible for a problem can see that A was executed, and
Then B and then C, knowing that sequence of events might trigger
the realization of an intermediate step that was missing, or an
extra step that might have changed the environment enough to cause
a visible problem. Again, restraint is always in order ("I set
the build running, went to get a cup of coffee (Columbian, cream
but no sugar), talked to Sheila on the phone, and then THIS
happened...") but be sure to include anything relevant.
- Richard Stallman writes, "The fundamental principle of reporting
bugs usefully is this: report all the facts. If you are not
sure whether to state a fact or leave it out, state it!" This holds
true across all problem reporting systems, for computer software or
social injustice or motorcycle maintenance. It is especially
important in the software field due to the major differences seemingly
insignificant changes can make (a changed variable, a missing
semicolon, etc.).
- Submit only one problem with each Problem Report. If you have
multiple problems, use multiple PRs. This aids in tracking each
problem and also in analyzing the problems associated with a given
program.
- It never hurts to do a little research to find out if the problem
you've found has already been reported. Most software releases
contain lists of known problems in the Release Notes which come with
the software; see your system administrator if you don't have a
copy of these.
- The more closely a PR adheres to the standard format, the less
interaction is required by a database administrator to route the
information to the proper place. Keep in mind that anything that
requires human interaction also requires time that might be better
spent in actually fixing the problem. It is therefore in
everyone's best interest that the information contained in a PR be
as correct as possible (in both format and content) at the time of
submission.
After the PR is submitted
Once a PR is submitted it will be emailed to
bugs@het.as.utexas.edu. The system processes the mail queue
every ten minutes or so. An email response will be sent once the PR
has been accepted by the system. This email will contain the ID
number assigned to the PR. Save this number. You will need it to look
up the status of your PR. If there is a formatting problem with the
PR, it will be forwarded to the administrator for handling. Anytime a
change is made to a PR the submitter is notified by email about the
change and reason for it.
The system is capable of assigning a responsible party based on the
category. However at this time all PRs are sent to Mark Adams and Jim
Fowler. Mark is responsible for assigning resources and responsible
parties. Jim wants to make sure there are no problems in the problem
reporting system.
Once the responsible party or maintainer has been assigned, a copy
of the email will be forwarded to them. They should review the
problem, attempt to determine the cause, or make an estimate of how
difficult the problem will be to solve. Maintainers should edit the
description of the problem report as well as change the status from
open to analyzed once they have done this.
Managers, maintainers, and users may generate status reports about
PRs based on category, status, responsible party, and age of the PR.
These status reports may be used to study how the maintainers are
doing in solving problems, to study which systems seem to be having
the most problems, and to insure that the proper resources have
been assigned to solve problems.
Top of page
Return to main PRMS page