One of the hardest things to do when you receive a bug report is outright rejecting it. As keepers of the system, we want everything to be perfect under every circumstance. However, wanting to please users to this degree can actually hurt your reputation rather than help it.

There are few good reasons to reject a bug report on its face:

• The bug report involves running the system in a totally untested and out-of-scope configuration. For example, if a user reported a bug where the server wouldn't run inside the Windows emulator on a Mac, I might briefly investigate as an intellectual exercise, but I'm not going to treat this a bug.
• The bug report expresses a preference, and other users might have different preferences. If every user expresses the same sentiment, then I might accept it as a bug. If users differ, then it starts to fall into the realm of customizability, which generally involves new feature development.
• The bug cannot be replicated and is not severe. In this case, it's just not worth spending time on. If it can be replicated, it's probably relatively easy to fix. If it's severe (i.e. results in data loss or unusuable system), then it's probably worth spending some time looking in to.

Problems that can arise from accepting any bug report as a command to fix include:

• Your reputation can suffer because it appears that you can't fix some of these "unfixable" bugs, especially the unreplicable ones.
• Your reputation can suffer because you are spending too much time developing new features under the guise of bug fixing, and so you are perceived as having a buggy system rather than a full-featured one.
• Your bug tracking system gets cluttered with lots of unreplicable bugs, which never get fixed since they can't be replicated.

Saying No is not that hard if you start doing it from the outset, and you communicate clearly with the reporter your reasons for rejecting the bug. Most users will accept an explanation that says, "I'm sure that was very annoying when it happened, but it hasn't happened again, and no one seems to be able to make it happen again. If it happens again, let me know", or "We've never tried running it that way before, so I'm not surprised that it didn't work. I'll make a note of it, and if you want to do this in the future, make sure it gets into the list of requirements". You can't just start rejecting bugs 3 years into a project though, it will just make users frustrated. You must implement this strategy from the beginning.

Tomorrow: Clarifying the Bug Report