Timeline for How to deal with the trail of bugs?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 16, 2012 at 22:33 | vote | accept | Asad Iqbal | ||
| Jan 20, 2012 at 0:08 | comment | added | mattnz | My point is refusal to close defects where the developer has nether the resources , desire or intention of fixing is common and ultimately expensive. Every time you have a review meeting, it must be revisited (or you are only doing half the job), each meeting takes longer than the last and the reports get polluted with historic data. Reports on "Closed + Will Not Fix" can then be used where required, and an issue can always be reopened if you change your mind about it. | |
| Jan 19, 2012 at 23:28 | comment | added | iteratingself | The problem is business is fluid, not static. The overall strategy and goals may change causing changes in priorities. Defects that were low priority may become higher priority. However, if they are all closed you won't know if they were actually fixed or not. I don't want to confuse fixed defects with defects that were closed and not fixed. | |
| Jan 19, 2012 at 2:55 | history | answered | mattnz | CC BY-SA 3.0 |