Writing a good bug report

There are some simple guidelines to writing ticket which will make prioritizing, tracking, and resolving problems more efficient.

Justification

Each ticket should relate to a single problem or feature

In order to easily prioritize and track tasks we need to have a state associated with each issue. The problem with "laundry list" tickets is that some tasks get done, some get defered, and some cancelled. It is never clear when the ticket is done and individual fixes can't be approved so even if it nominally is done things are likely to fall through the cracks.

Provide a descriptive subject

We look at summaries of tickets with subjects only and it is much easier to find the relevant ticket with a descriptive subject.

Be as specific as possible about what is wrong

Problem descriptions that are too short or ambiguous are less likely to get fixed than those that can be easily interpreted.

Put the URL to the offending page in the ticket

Having the URL in the problem description will streamline finding, fixing, and verifying the ticket. You do not have to enter it as an HTML href, simply including the full url ( including the http:// and the trailing variables ) is sufficient.

Describe the steps you took to produce the problem

If we cannot reproduce your problem it will be much harder to find. The problem can be related to the page visited proir to the page on which the error occurs or may be related to the specific data you input to a form.

Provide sensible priorities and deadlines

We make an effort to meet deadlines and fix things in priority order but if all tickets are critical with a short deadline we will not necessarily fix them in the order you would really like. Here is an explanation of what the priority and severety codes mean:

Severity

  1. Critical. System crash, security violation, or data loss.
  2. No Workaround. Because of this bug, a function cannot be made to work.
  3. Workaround. The bug interferes with functionality but an alternative
  4. Cosmetic. The bug does not interfere with functionality.

Priority

  1. Must be fixed by next release
  2. Should be fixed by next release
  3. Might be fixed

Jeff Davis
Last modified: Fri Dec 13 06:36:53 EST 2002