In our bug database, when resolving a bug, you have to select a “Resolution”.  Obviously you can resolve as “Fixed”.  Other options include:

        By Design   - this isn’t a bug, we meant it to work this way.

        Not Repro  - you were mistaken, this bug doesn’t exist.

        Postponed  - this is a bug, but we won’t fix it this time.  Will reconsider next version.

        Won’t Fix    - this is a bug, but we won’t fix it, not even in the next version.


There’s an interesting tension between Postponed and Won’t Fix.  A Won’t Fix bug gets “lost” into history.  (Actually, the bug database is always around & available to be queried, for all of eternity.)  If you see a bug resolved Won’t Fix, you might worry that we’re dooming ourselves to shipping the next product in a broken state, too.


Near the end of each product cycle, we sit down to review all the Postponed bugs.  It involves several of the leads from the team, and can take days.  We’re looking for two things:

  1. Bugs that we should fix next version / features that we should plan to do
  2. Bugs that we should fix right now in the current version.  Last chance!  Pretty rare.


Then, shortly after the start of the next product cycle, we sit down to review all the bugs again.  With a rough feature list & schedule in hand, we make sure that the bugs are assigned to the right person, that our feature plans take these bugs in to account, and that we have enough time set aside to fix the bugs we want to fix.


It’s a tedious & expensive process.  And it’s often not very worthwhile.  There’s a set of issues that we keep postponing every time.  (Not many in C# IDE because it’s still pretty new, but on my old team this was pretty bad.)  I think this is because these bugs really aren’t important enough to spend time on.  We should put our time somewhere else.


When selecting between Won't Fix and Postponed, here's what I look at:


- If there's important information in the bug, like design decisions or the results of detailed analysis, then Postpone so we keep that information.


- If it's a real bug, but in a corner case that most people may not care about, I'll resolve it Won't Fix. 


If we made the wrong choice (should have fixed it), we'll hear about it, from customers, partners, and dogfooders.   Having the bug won't be an important part of our decision to fix it next time. 


If we made the right choice (users don't really care), then we never have to think about it again.


- If it's a bug we know we want to fix next time, and there's a chance that we might forget to fix it otherwise, then Postponed.


- If the bug is something we won't fix without re-architecting the system, but is something we'll probably think about during the re-write work, then I resolve Won't Fix.


- If the bug came from ladybug, it nearly always gets Postponed.  That because a customer has actually said they want the bug fixed.  And because the sample set (beta users) is pretty small, the feedback should be taken seriously.


As you can see, I’m pretty hard core about marking as much Won’t Fix as possible.