Defect? Feature request? Who decides?

Scott Westfall has a post about defects vs. features. He notes:

I like the generic term, “change request” for all changes in a system. But it’s very important to know whether it is a defect or a feature request. In my lexicon, a “defect” is something that doesn’t work as spec’ed; a feature request is a request to alter the intended behavior.

He goes on to point out that customers generally don’t care which it is, they just want things changed. Programmers often care about the definition because if it’s a defect, it might mean their code is flawed. Yes, programmers can have egos, often huge ones.

But what he doesn’t answer seem to answer is: who, ultimately, decides whether a submitted “change request” is a defect or a feature request? And does unexpected behavior, even if it specified as such, or simply undefined, qualify as a bug?

I’ve run in to this exact issue on a “change request” for a product I use: the Adept package updater in Kubuntu. On May 10, 2006, I reported that Adept doesn’t behave properly when the network is down, but simply says the transaction failed. I finally discovered that it didn’t properly determine if the network was up before it attempted to start the upgrade process.

After submitting this change request as a bug, it was changed to a “wishlist” priority. After it was changed, I wrote:

I don’t agree with this bug being a “wishlist” bug. If a user does not know their network is not up, and they try to update, they are immediately going to write for help saying “Updates aren’t working,” or they are simply going to give up on Ubuntu because it “doesn’t work right.” I know I would have given up if I hadn’t known to go to the prompt and type “apt-get upgrade,” which is how I found out my network was down.

The change back to whishlist was accompanied by this comment:

You don’t have to agree. It is wishlist though. You are asking for a totally new feature. And missing features != bugs in my world. Please leave it on wishlist, there is absolutely no point in bloating the severity. Thanks.

Now, I’m not sure if, or where, the specification is for Adept, but if a network-aware program I was using didn’t tell me the network was down, but simply failed with no explanation, I would qualify that as a bug. I think that view is justified, considering that 1) another user agreed with me, and 2) my original report now has three other reports attached to it as “duplicates.”

So, I agree fully with Scott that not all change requests are defects. However, when a program violates expected (and/or reasonable) behavior, the programmers/project managers/whoever really need to take a hard look at either the specification (if the program is in fact following the specification), or they need to define the behavior for the given case, and possibly bring it in to alignment with users’ expectation[1].

[1] Yes, I know user expectations can vary wildly. Maybe a usability study is in order, but that’s a topic for another post entirely.

Update: Good additional discussion of the problem. With a good example of something that should be classified as a bug in Visual Studio 2008, but still has not been fixed; and some discussion of how the bug/feature request dichotomy is bad for software projects as a whole since it can create friction between users and developers.