SCHOOL OF ENGINEERING AND COMPUTER SCIENCE

Bug Report Guidelines

The ECS programmers work to help you on each and every problem you submit, but our job becomes harder when we don't have enough information to work with. If you follow these guidelines, we won't need to keep communicating with you, allowing us to resolve many problems in minutes rather than days.

Please report all bugs. Small bugs may hide large ones (but don't be offended if we don't have time to fix the small ones!)

Bugs (system problems) should be submitted to the bugs@ecs.vuw.ac.nz email support address. If instead of a bug report you have a feature request or a query about our system you can use the address jobs@ecs.vuw.ac.nz instead.

Emails sent to these addresses are assigned a "ticket number" and entered into our request tracking database. When an email is first assigned a ticket number, a copy of that email will be sent to all members of the technical support team responsible for dealing with bugs and feature requests on ECS systems. Any followup emails should have the text "[ECS #XXXXX]" in the subject line (where XXXXX is the ticket number) which will cause them to be stored in the database along with the original email.

Support team members can take ownership of a request, in which case they will be the only person to see copies of the followup emails (if there is no owner for a request the entire team will see them). But even when a request has an owner, any member of the support team can still view the history of emails relating to a request and so may be able to assist with a solution, despite not seeing the emails when they arrived.

Because these email addresses cause requests to be created in our tracking database, confusion can occur when emails are sent to them and to other people at the same time (ie: by having multiple addresses in the To: header, or by including addresses in a Cc: header). The support addresses are not intended to be used for general purpose communication between a group of people that includes the school support staff. Hence a bug report/feature request/query should be sent only to the appropriate one of the above support addresses. General communication amongst a number of people including the support team could use the tech-staff@ecs.vuw.ac.nz address instead.

A good bug report has these things:

  1. Steps to reproduce - How can the programmers replicate what happened? If we can't replicate it, we can't fix it.
  2. What you expected to see.
  3. What you saw instead.
  4. How urgent this is - Be honest! If this has a specific deadline, let us know. Tasks are dealt with by urgency.

Be precise, clear and verbose. If you're visiting a URL, don't give us the title of the page, give us the URL. Avoid pronouns, it makes it hard to understand what isn't working correctly.

ALERT! A bad example: "I tried to see the Google in Firefox, but it didn't work. I need this now." What's "it"? Firefox? The web page itself? What element didn't work? What was "it" supposed to do? Do you really need this now?

DONE A good example: "I visited http://www.google.com in Firefox on NetBSD. When I visit the page from my home computer, I am presented with an option to search for web pages; there are two buttons below the text input box. However, I am unable to see either of these buttons on this computer. This prevents me from running a search, which is severely impeding my ability to research today."