[James Ross]

If you happen to be familiar with bug trackers in general, most of this information should be familiar to you. For the rest of you, this should serve as a brief introduction to bug trackers in general, and how the Open Rails teams plan to use the one on Launchpad.

Bug fields

• Summary - this is the title of the bug report and should be a clear 1-line summary of the problem.
  
• Description - this is a full description of the bug with the details necessary to demonstrate it to others.
  
• Status - the current status of the bug, as we'll see below.
  
• Assignee - the current person working on the bug.
  
• Comments/attachments - all bugs have comments and attachments where anyone can provide further details, explanations, suggestions and attach related files such as screenshots.

Bug lifecycle

• New - this is where all bugs start. At this point, the bug has not been looked at by the right people to check whether it is complete, or if more details are needed.
  
  • Incomplete - a member of the Open Rails teams has decided that the bug needs more information before it can be fixed. The person who created the bug report doesn't have to be the one to provide the extra details.
    
  • Opinion - the bug has been identified as an opinion, meaning that it isn't clear whether there is actually a bug or how things should be behaving.
    
  • Invalid - a member of the team believes that the report is not actually a bug report. This may be because Open Rails is working as designed and expected or it could just be spam. The bug may be put back to the new state if further information or clarity is provided in comments.
    
  • Won't Fix - a member of the team has decided that this bug will not be fixed at this time. If the bug report is a "feature request", then they have decided that the feature isn't desired right now. This status does not mean something will never happen but usually a better reason for fixing the bug or adding the feature will be needed first.
• Confirmed - someone outside the team has been able to experience the bug as well, by following the instructions in the bug report.
  
• Triaged - a member of the team has been able to experience the bug as well, or is confident there is enough information in the bug report for it to be fixed. Bugs generally need to get to this state before developers will want to look at them in detail.
  
• In Progress - one or more members of the team are currently planning to or actually working on the bug report. They will be identified by the assignee field.
  
• Fix Committed - the fix for the bug report or feature request has been completed and checked in to our source control system, Subversion. Once here, the fix will usually appear in the next experimental release.
  
• Fix Released - now the fix is in the code, and the code containing it has been released in an official release. Everyone should be easily able to show that the bug is fixed.

Tips

• Don't be offended by bug statuses - they often sound harsher than they really mean, like "Invalid".
  
• Don't be afraid of changing other people's bugs - if you are sure they should be changed.
  
• Don't expect a speedy response in general - issues will get looked at as and when people have the time.
  
• Be prepared to expand upon the initial report - it is remarkably easy to forget some crucial detail that others need to find and fix your bug, so expect to be asked a couple of questions back before work can begin.
  
• Try to avoid comments that add no technical or relevant detail - if you want to record that the bug affects you, Launchpad has a dedicated button at the top: "Does this bug affect you?".
  
• If you wish to follow along with someone else's bug report and get e-mail notifications, you can subscribe to bug mail from the sidebar.