How to report a bug

[seanw]

I'm going to be using the forums for bug-tracking, which is somewhat more informal than most of the on-line bug-tracking systems. This means, however, that if you've found a bug, there are certain rules you should follow in reporting it so that the problem can be tracked down effectively.

When you report a bug, please provide this information at a minimum:

• Which version/release/beta of SpaceMonger are you using (1.4, 2.1 beta 1, etc.)?
• What OS are you using it on (win98, winXP, etc.)?
• What mode was SM in (normal, roving, emergency)?
• Where in SM did you see the bug (scanner, treemaps, setup, charts, help, etc.)?
• How serious was the bug (crash, freeze, bad results generated, minor glitch, annoyance, etc.)?
• What were you attempting to do when you saw the bug (just sitting there, clicked a file, clicked a button, started a rescan, etc.)?
• Is there anything else you can tell me about how the bug occurred that might be helpful to know (such as: only happens on a network drive, or only happens to a specific file type, or seems to happen when this sequence of buttons is clicked, etc.)?

In general, the more information you provide, the better chance I have of being able to track down the bug and fix it.

And last, but not least, before you post a bug here, please use the forum's "Search" capabilities to make sure that nobody else posted the same bug already.

Note that if I do fully resolve a bug, I will lock the thread in question; this doesn't imply anything about your postings there, merely that it's a done issue, or should be. If the bug rears its ugly head again, you may start another thread based on it. I'm only locking the threads here as a convenient way to keep track of what work I have yet to do.

Each thread in this forum is tagged with a simple keyword to classify it according to the severity and kind of bug. Please try to classify your bug postings according to this system as well:

• [freeze] - The program refuses to respond to your input, and you can do nothing (or very little) to get it to talk to you again.
• [crash] - The program crashes, explodes, bursts into flames, and/or Windows displays its "This program has performed an illegal operation" message.
• [bad] - The program exhibits generally bad behavior, such as telling you things that are obviously very wrong, or fails to save your settings, or forgets important things.
• [glitch] - The program exihibits incorrect but forgivable behavior, like text that's cut off or there's a spelling error or something just looks awry.
• [annoy] - The program exhibits correct but highly annoying behavior. This may not be a bug, but it interrupts your workflow.
• [confu] - The program exhibits correct behavior, but behavior that's hard to understand why it is the way it is. A fix probably involves rethinking part of the design.
• [miss] - Some feature that's supposed to be there and functional is genuinely missing from the program, such as missing help documentation, buttons that do nothing, and keystrokes that don't work.