Question

I've struggled with the best way to track refactoring cases in FogBugz and am interested in input from other FogBugz users on what is working/not working for them.

The key issue is that they definitely aren't features, but the word "Bug" has certain negative connotations attached to it that start arguments (no matter how much you explain that it is just a label).

Using the category "Schedule Items" alleviates the stigma associated with bugs, but the standard status codes don't fit development items very cleanly.

Another option would be to create a new "Refactoring" category, but it seems a bit like overkill.

Our current approach is to flag the case as a "Bugs" and add a "Refactoring" tag to it.

Anyone have any advice to offer on other options or opinions on which of the above is best suited for cases related to refactoring?

Answer 1

To me "Refactoring" is an exercise in globally renaming or restructuring a chunk of the codebase, so I wouldn't use that particular term.

My interpretation of your problem is that people recognize that a change is required in the code, but its not a new feature and they don't feel comfortable identifying it as a Bug, because that implies that somebody made a mistake somewhere. If that's the case, you could use the Workflow plugin to rename the Bug category, rather than create a new one. I would use a "blame-neutral" label like Maintenance Change. May be a bug, may not be, but nobody should argue that you're maintaining the code, making a change to existing behavior and that it's not related to a new feature.