HET banner
Home Problem Reports Operations Schedule Weather Data Archive

PRMS Overview

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


Created:   11-Dec-1998
Last updated: 01-Oct-2003

Send comments to: webmaster@het.as.utexas.edu
Copyright ©1998, 1999, 2000, 2001, 2002, 2003  The University of Texas at Austin, McDonald Observatory