Does the software not do something that the programmer intended? Is there a place to do it and the consequences of doing it all worked out? Ask these questions before debating if it is really a bug or a feature request.
James Bach suggests that a bug is something that "bugs" the user. He arrived at this definition working on photoshop. Does the blur command blur? What is right? Hard to say.
Ron Jeffries suggests keeping the bug count at zero. If a bug shows up just fix it or discard it. Don't save them up because you like them.
James serves the product manager and defends the end user in this relationship. Ron serves the developers and wants them working in a safe and productive environment.
Surprise
Clean code consists of mechanisms for dealing with situations that are known to occur or at least possible. When real circumstances elicit unwanted behavior we can ask, was the real within the limits of the anticipated? If so, then we can expect the solution to be a small increment on code already written.
It may be that the real situation can't be easily determined or easily understood.
It may be that the mechanisms designed don't actually work as anticipated even in anticipated situations.
It may be that the encoding process allowed simple errors, typos for example, to pass without detection.
See Encoding Checks
Explain swarming ...
Explain bailout ...
Performance
A team should be scheduled based on estimates grounded in their ability to anticipate.
The zero bugs strategy accepts that decisions made programming defines the boundary between what surprise work will be done now or handled some other way.
An organization should be prepared to adjust for disappointment when software ships. There are many alternatives. But heaping grief or wallowing in details don't stack up well.