When does a bug become a feature request?

Question

When does a non-critical bug become a feature or should a bug always remain as a bug?

For example. Should there be a statute of limitations in place.

For example, if you have a defined statute of 1 year. The bug was introduced over 18 months ago, but only noticed today. Should that bug be defined as "this is now how the system works" and to change it, it should be placed on the backlog for prioritisation.

Answer 1

When you change the specification in response to it.

Answer 2

Are your developers giving you the "That ain't a bug, it's a feature!" line?

Seriously, a "bug" would be something in the applications that behaved counter to the specifications of the project. Unless the specifications change, I would not expect a bug to ever expire.

Answer 3

I believe that the bug is still a bug no matter when it is discovered in the project lifecycle, and should be defined and documented as such. Remember, documenting a bug does not make it a feature :D

Answer 4

A "bug" is normally seen as an impediment to some execution, generally by creating a unworkable situation. Outside of that, a different way of successfully executing can only be labelled a bug when it does not conform to a given specification. If it becomes acceptable, then the specification changed and therefore the bug does not exist anymore.

Answer 5

Your question seems to imply that bugs fixes don't get prioritized. I believe that prioritizing should happen somewhat frequently, and that features and bugs should both be treated equally as "issues". Bugs will often be higher-priority than a new feature, but that shouldn't be an automatic decision.