Unfortunately, the distinction between bug and feature request is very important when it comes to if work on the issue in question is billable to the client or not. In a lot of cases fixing bugs is not billable after release.
There is a difference between a bug and a feature.
A feature is when a user wants something different; a bug is when he wants what you claim to provide, but donât.
There usually is a business need to distinguish between them, because you have to fix bugs from free in many cases, while you can make users pay for (or wait for) features.
Anyone who thinks otherwise is not working on software used by companies.
I love how people cling to requirements as their defining line between bugs and feature requests. Lets face it folks, requirements are hardly worth the electrons it takes to display them on your screen. I donât care if the requirement covers every possible interpretation and the customer signed off in blood - as soon as the app is realized and in front of my face, if I donât like it, you should fix it. Prioritize, complain and moan, ask for more money, whatever. The job of software is to make the userâs life easier. If itâs making it harder, the software needs to be fixed. Itâs all semantics, the software doesnât live up to the userâs expectations - call it a disenchantment if that makes it gets the darn thing addressed.
I like James McKay: if in doubt, itâs a bug. Much easier.
VB6 - FontWiz: The Missing Piece in Styling Your Programs
http://www.vbforums.com/showthread.php?t=543037
Adapt to the system font at runtime with minimal program changes.
Note the lack of interest: only 20 downloads in 5 weeks as I write this.
What youâre saying makes sense if youâre working for the company that youâre designing software for. If youâre a custom software development shop, then itâs a different situation, and gets back to do you charge for fixing bugs?
Microsoftâs DevDiv has a real problem with dealing with bugs that are actual bugs, so a feature request going uncommented for four years is hardly surprising.
Iâd say that not disposing of non-graphical controls dragged onto a form was a bug, wouldnât you? Apparently Microsoft donât think so: still no feedback from MS on my bug at http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=305534.
@SteveJ: requirements are hardly worth the electrons it takes to display them on your screen - Great!
Requirements in a formal sense are conspicuously and characteristically absent from nearly all open source projects, so the distinction isnât really so well-defined in that environment.
Robert Lefkowitz has some interesting things to say about that: http://oscon.blip.tv/file/1108217/
P.S. â That behavior in Apple Mail is also present in Claws where simply highlighting a section of a message before hitting reply serves to automatically trim the quote to just the higlighted portion.
Maybe Apple added that feature to apologize for the default behavior of setting the user up to compose a top-posted reply, which I personally file under bug, not feature 
The application shouldnât choose a typeface. it should get itâs typeface from the window manager. This is one of the things I HATE about windows. Applications donât let you tell them what typefaces to use, they use what they use, and to hell with what the user thinks looks good.
So this is a feature request, because to fix it requires fixing the window manager in windows, and fixing every single app in windows, because they are ALL broken in this way.
To me, the distinction between bug and enhancement is easy. Of course, I am a developer, so I know how these things work. A bug is something that works contrary to the design of the system (crash, 2 + 2 = shoe).
I agree that general users often arenât of the same mindset. There are multiple reasons for this. One reason is that users are often not even aware of specs, so they go by what theyâre used to.
Basically, to many users, a bug is when the system works contrary to how they expect it to work.
In some cases, though, it really does make sense to strictly classify these. Company X pays you to create a program for them. They give you specs, and you give them the finished program. You are still liable to fix bugs (not working as designed). Enhancements or new features would likely be grounds for a new contract, though.
I think there is a faulty assumption that removing the bug/feature attribute of a request would have made the Visual studio doesnât use the correct font when building Windows applications issue get addressed any faster.
If the vendor doesnât want to address it, they arenât going to address it. Period.
sorry to say, Da Bob, VB6 isnât exactly state of the art at this point.
i havenât read all the comments so iâm sure itâs been said before. the problem you have is if you have a deadline and you want to ship a bug free program. you will have to prioritize and i guess the bug vs feature request is used as a way to do that sometimes.
on the other hand, i completely agree. there should be no distinction, there should only be a way to put a priority on anything that is requested. and you should definitely not tell your users that theyâre wrong for entering a bug by reclassifying it as a feature request. theyâre essentially doing your job.
LOL. We used to call bugs random features.
Seriously, agree with Charles. If the vendor doesnât want to address it, they wonât. And they might not want to if (a) it isnât a security risk and (b) enough high profile customers arenât complaining about it.
So, weâre assuming here that Visual Studio should default to the system font for whatever OS you are running it on?
Would that really be a good default? One of the features of Visual Studio is that you can build applications that target different versions of Windows, mobile devices, etcâŚ
Perhaps it should default to a setting that says - use the default font based on the OS context. Still - most people probably want to have a little more control than that.
I think a lot of bug / feature requests donât get implemented because it is unclear how something should work. If you do it one way, youâre going to annoy 25% of your customers â if you do it the other way, youâre going to alienate another 25%.
I disagree that bugs and feature requests are the same thing though. If you take that point too broadly, you could say that there is a bug in Microsoft Word because it canât edit your home movies.
Software has to have a point â a focus. It canât be all things to all people. Otherwise, we would just have a single program that did everything.
If it violates your specs, itâs a bug. Otherwise itâs a feature request.
You do have specs, right?
This is how IBM did it back when I was a customer of theirs. Worked pretty well.
Who cares which it is? I have a different system. We log everything to a central place, with no distinction between the two. I then let the users choose the priority of their requests (in relation to each other) and the top ones get fixed first. No need to care. Even if it is a bug, but the feature request is more important to them, we do that first.
Software has to have a point â a focus. It canât be all things to all people. Otherwise, we would just have a single program that did everything.
Emacs!
If it was in the requirements/specification and not implemented (correctly) in the software, then it can be defined as a bug.
If it wasnât in the original requirements/specification, then it is a feature request.
You are just punting on the problem. You are assuming there werenât bugs/missing features in the requirements/specification to begin with. Maybe the bug was that it should have been in the requirements doc but someone missed it so now you are categorizing what should be a bug as a feature request (and probably treating it differently).
I agree with Jeffâs general point that the distinction between a bug and a feature doesnât really add a lot of value to the development process. I think more about the impact that the issue has: does it keep the user from doing something that the program should do? Which comes back to Timothy Lee Russellâs point that a program should have a focus.
the distinction is clear⌠bugs I fix for free, features I charge for
One of my favourite games! Feature or creatureâŚ
http://nomagichere.blogspot.com/2007/09/feature-or-creature.html
http://nomagichere.blogspot.com/2008/02/time-keeps-on-slippin-slippin-slippin.html