In our project we work in a zero-bug (a.k.a zero-defect) methodology. The basic idea is that bugs are always higher in priority than features. If you're working on a story and it has a bug it must be resolved in order for the story to get accepted. If a bug is found during the sprint for an older story we need to put it next on our backlog and resolve it - top priority.
The reason I'm saying resolve is that we not always fix the bug. Sometime we just declare it "won't fix" as it's not that important. All-in-all it sounds great. We're shipping high-quality products and don't carry "a hump" in the form of a huge bug backlog.
But i'm not sure this approach is correct. I do tend to agree that we always need to fix serious bugs ASAP and we need to throw-away non-interesting bugs. But what about bugs that are important but not as important as new features? I tend to think they should be filed in the backlog with a suitable priority.
I'll give an example in order for it to be clearer - in my project we work with a UI written in flex. We have a wizard screen that opens at the same size for every screen resolution. It turns out that when we extend the wizard window, one of the pages does not look good (there is a vertical scroll bar that does not disappear although the wizard can now present everything and does not require the scrollbar). I think this bug is ugly. I'm sure it MUST be fixed. But we're on a tight schedule and we have a lot of features that we're afraid won't make the cut and enter the release. I feel that we can live with such bug. It does need to be fixed but on lower priority than other features (so, in case we won't be able to complete it, at least we didn't leave out more important features). But, we work in a 0-bug policy and it must be fixed now (even though we spent more than a day trying to resolve it and we'll need at lease another one).
I would love to hear opinions about how to manage with bugs that I don't want to mark as "won't fix" but also are not of highest importance.