Problem Report Fields

State
This is the current state of the problem report. It can be one of the following:
Open
The problem report has been filed and the person responsible for that category has been informed. They are expected to assign it to someone as soon as they have had a chance to read the report; if appropriate they'll simply assign it to themselves. PRs should not be left in an open state.
Assigned
Responsibility for the PR's been accepted, and it's been assigned to a specific person for solving.
Analyzed
The problem has examined and understood; the difficulty of solution has been estimated and it's somewhere on the Responsible Person's stack
Feedback
The person responsible needs more information before they can proceed with handling the PR.

When a PR is changed to feedback it may be appropriate to change Responsible to the person who filed the PR originally, or to someone else who can provide the desired information. (this may not always be possible -- send mail to sdss-request in case of difficulty).

Needstest
It is not clear if this is (still?) a problem. The original problem is solved (e.g. the deblender failed on such-and-such a galaxy), but the more general question of whether the problem will reoccur needs to be addressed. This is also a common state for change requests.

In simple cases (e.g. `photo dies with a SEGV on frame 12 at line 1234 of file.c') there is no need to change the PR to needstest before closing it.

As for Feedback, you may want to change the person responsible when changing the PR's state to Needstest. It is not clear if this is (still?) a problem. The original problem is solved (e.g. the deblender failed on such-and-such a galaxy), but the more general question of whether the problem will reoccur needs to be addressed. This is also a common state for change requests. As for Feedback, you may want to change the person responsible when changing the PR's state to Needstest.

Suspended
It isn't possible to make further progress on this problem, but it isn't clear that the problem is resolved; for example, an intermittent bug that hasn't been seen for several months, but for which no clean cause was ever found. As for Feedback, you may want to change the person responsible when changing the PR's state to Suspended.
Closed
The problem is resolved. If this proves an over-optimistic assessment, the PR can be transfered back to active status.
Onetime
This problem appeared once, and hasn't been seen since. Onetime problems are assumed never to be going to re-occur, so this counts as a `closed' state.
Class
The class of a problem can be one of the following:
Bug (Software or Hardware)
A general product problem. For hardware PRs, this generally means malfunctions and breakages.
Documentation
A problem with documentation.
Change request
A request for a change in behavior, etc.
Support
A support problem or question.
Duplicate
A duplicate PR; you cannot submit a bug report as being a duplicate.
The default value is "Software Bug".
Severity
The severity of the problem. Possible values are:
critical
The product or component is needed before we can start the spectroscopic survey (this includes reducing spectroscopic data, and getting the right type/redshift)
serious
The product or component is needed in routine operations, but not to start the spectroscopic survey. Critical errors with a known workaround are considered serious
  • A workaround may be an operational change (e.g. "don't type RHL, ever"), or reverting one software product back one level.
non-critical
The product or component is part of an enhanced goal; for delivered products it's a non-critical error if it lacks features, has irritating behavior, does something wrong, or doesn't match its documentation.
The default value is serious.
Priority
How soon the originator requires a solution. Possible values are:
high
A solution is needed as soon as possible; we should cut a new version when the fix is available -- i.e. fix it on the current stable branch, with the risk of breaking production code.
medium
The problem should be solved in the next release. In cvs terms, this means on the next branched version (if branching's being used).
low
The problem should be solved in a future release. I don't expect to see any more critical/low problems; non-critical/low PRs may never be solved.
The default value is medium.
Scheduled
Is this change authorised? New PRs come in as `unknown', if we can't decide whether to approve them now, change them to `manana'.

This field is irrelevant for critical/high PRs which get worked on as soon as possible. For consistency, critical/high PRs should be set to "approved"

As I write this, scheduled is only applicable to observing software (*op etc.) and photo (frames and psp). I encourage other groups to sign on to its use.

unknown
This is a newly arrived PR which no-one in Management has read yet; when they do read it, they'll reclassify it as discuss or notapproved (or approved for high/critical PRs).

For categories that use the scheduled field, no PRs should be left in this state.

discuss
This is a new PR which needs to be discussed in some suitable forum (e.g. the Observing Software 'phone con) and classified. The Member of Management who looked at this PR thinks it should be considered for being classified as approved or longterm, but such action needs to be approved in the appropriate forum.

The difference between discuss and unknown may not be important for some groups.

For categories that use the scheduled field, no PRs should be left in this state after the approval forum has met.

notapproved
The PR has been looked at and a decision has been made NOT to work on it anytime soon. This does not preclude, however, its being bumped up in priority for work at some later date.
approved
This PR is to be worked on and placed in needstest in the current development cycle.
longTerm
This PR has been approved to be worked on, but will take several development cycles to complete. An estimate of the completion date should be included in the PR at this point.
manana
The problem reflected by the PR is considered important, but we aren't prepared to approve work on it just yet. The implication is that we will probably upgrade its status at some point in the not too distant future. Note that permission is explicitly not granted for active development work on this class of PRs.

The default value is unknown.