Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been involved in several projects either as tester or developer. In many of projects there were following statuses for defects:

  1. WON'T FIX
  2. Cancelled

Do you use such statuses and how do you differ them? I ask, because most people can't explain the difference. My understanding is:

WON'T FIX - developer will not fix the defect, due to it's not a defect;
Cancelled - defect should not be fixed, because of lowest priority

share|improve this question

migrated from Mar 17 '11 at 11:01

This question came from our site for professional and enthusiast programmers.

up vote 10 down vote accepted

As others have noted, these status names aren't very clear. I would prefer more precise and detailed status names:

  • Won't Fix (the cost of fixing this is not justified)
  • Workaround Provided (and it is enough to make users happy)
  • Not a Bug (but a feature)
  • Not Reproducible
  • Duplicate
share|improve this answer
Workaround Provided,it's something new,other statuses are known – sergionni Mar 17 '11 at 11:46
"Fix in Later Version" can be another useful status. Typically we use it near the end of the development period, because we don't have the time or resources to fix it (although we would like to). Until it is fixed, customers are notified of it via an SVA (software vulnerability assessment). Getting rid of that SVA, gives us extra incentive to fix it in the next release. – Sparky Mar 17 '11 at 12:17
you may just change version of task in Jira instead of using "Fix in Later Version" status – sergionni Mar 18 '11 at 12:50

I think you've got the answers backwards

Won't fix - would apply to a minor bug that is not impacting or may be in an older version therefore not worth the cost of the developers time to fix it but they acknowledge that is it s bug.

Cancelled - This could a bad bug report were it is not reproducible or may be it is not a bug at all.

share|improve this answer
yah. I'd considered "cancelled" to be applied when the "fix" was under development but not completed because on second screening it was found to not be needed (either because the entire section of code was replaced with something else or because it was found not to be a problem). "Won't fix" can either mean decided it's not a problem or it's so minor it's not worth the investment needed to fix it. – jwenting Mar 17 '11 at 11:34

Taking your 2 descriptions:

WON'T FIX - developer will not fix the defect, due to it's not a defect;

Cancelled - defect should not be fixed, because of lowest priority

It is obvious that the intended difference is:

WON'T FIX - It's not broken, we purposely intended for this behaviour (E.g., feature not a bug);

Cancelled - We agree it is broken, but it is so trivial/inconsequentally we will never be bothered to fix it.

share|improve this answer
actually,there is status "Not a bug" also,that is closed to your "Won't fix" behaviour – sergionni Mar 17 '11 at 11:48
These descriptions make just as much sense if you reverse them: "The ticket is Cancelled because it's not a bug", "We Won't Fix it because it's trivial" – Kevin Laity Mar 17 '11 at 14:38
@Kevin, I completely agree. I'd argue they actually make more sense when reversed. I answered based purely on based on the information in the question. – Dan McGrath Mar 17 '11 at 20:01

At my company we do not use such statuses and I think them to not be a good choice of labeling for the states you described.

Our states consist of

In Progress
Ready To Test

And the states should be this simple. Anything more detailed as if it were a bug or if it is too low of a priority should be put in a note.

share|improve this answer

Cancelled seems to imply that either a fix was started but then stopped, perhaps because it turned out to need more resources than originally thought and more than the defect justifies or that the person who entered the defect ticket changed their mind about it being a defect. Won't fix seems like there is an agreement that a defect does exist but that there is a reason for not wanting to fix it at this time (cost vs benefit, potential impact on other functionality, etc.).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.