This document describes how to file a good bug report, what a bug report should contain, and provides some examples of good and bad bug reports. For some people, reading this will result in a "Thank you, Captain Obvious!" moment. =) Many people already file good, solid bug reports. Many do not, and not because they're not capable, but because they just aren't aware of what a good bug report is and why. This guide attempts to address some of that.
BUG REPORTS
Bugs. We've all seen them, had them affect us in various ways. Some are funny, some are annoying, some are weird, and some are "game-breaking".
According to the Jargon File, a bug is defined as follows:
bug: n. An unwanted and unintended property of a program or piece of hardware, esp. one that causes it to malfunction. Antonym of feature. Examples: "There's a bug in the editor: it writes things out backwards." "The system crashed because of a hardware bug." "Fred is a winner, but he has a few bugs" (i.e., Fred is a good guy, but he has a few personality problems).
As a software developer, I've dealt with my share of bugs. I've created more than a few, and fixed more than I can possibly count. When users report bugs, developers often get frustrated because the user doesn't always realize what the developer needs in order to find and fix the bug, and so the bug report is incomplete or not useful. This means the bug probably won't get fixed or won't get fixed to the user's satisfaction.
Then the user is left wondering why the developer didn't fix the problem. After all, he reported it- why didn't it get fixed? Bugs are going to exist in any software; that's a given. The more complicated the software, the more bugs are going to be in it, in general. The biggest problem with diagnosing/fixing bugs is that quite often fixing one bug can create others- this is called the "law of unintended consequences" and is the bane of software developers.
In a game like SWG, there are probably dozens, if not more, developers. They also have a very large test team, if reading the back of my game manual is any indication. Your bug reports go to some group inside SOE; it is *highly* unlikely that they go straight to a given developer, who has a large list of things on his or her "to-do" list. What is more likely is that they go
to a tester for checking and reproducing, then entered/updated in SOE's internal bug-tracking system.
What does this mean and why am I explaining this? Because it means that when you file a bug report, you're not talking to the developer who wrote the code with the bug in it. You're talking to a tester, most likely, who knows as much about the actual code as you do- that is, not a thing. Testers aren't developers; it's important to communicate as much as possible about a
given flaw in the system to them as is humanly possible so that they can find a way to reproduce the issue and get it sent on to the dev team for fixes.
THE BUG REPORT INTERFACE
In the game, if you run across a bug, you can start the bug report interface in one of two ways: Press CTRL-H and click the appropriate button, or just type /bug. Do not confuse bug reports with CSR tickets! A CSR ticket is a request for a CSR (Customer Service Representative) to assist you with something in the game. If you report a bug using the CSR ticket request, it probably won't get filed properly and you'll waste the CSR's time. If you file a request for assistance using the bug reporting interface, you probably won't ever get any assistance and your issue will remain unresolved.
CSR tickets are to correct things like being stuck in a wall or in the air, or when you have immediate problems that may be caused by a bug, but require an administrator's assistance to correct. CSR tickets are not for reporting bugs! If you run into a bug that also causes you to need a CSR, file a ticket to get help and file a bug report while you're waiting for the CSR to get back to you.
The bug reporting window has a number of options, like how severe the bug is, whether or not you can reproduce it, what game system it affects, and so on. Set these options as best you can; I've quite often found that many situations aren't covered by the items available on the menu, so do your best when that occurs. The most important part of a bug report is the description you provide, not the menu items you select.
Note: I'm not getting into the specifics of the /bug interface. It's confusing, and much of the information you can provide is either redundant or not always applicable. My recommendation is to fill out the form as best as you can, then put all the details you can provide in the actual text description of the bug, which is far and away the most important part of the bug report.