Question

Currently the creation of "Release Notes" only happens after the case has been marked as "Resolved". This is way too late in the process for us. As source files are checked into source control, a Release Note explaining what was changed should be able to be generated. If you wait till the case has been tested and resolved then those changes that were made are not fresh in the mind of the people making the changes.

Obviously FogBugz chose its current implementation for some reason, thus making this configurable by the FogBugz admin would be a very helpful option. Let us choose when items are enabled during the process. You have great tools to allow us to work with "our" process just don't force us to use "a" process chossen by others.

Case FC2073740

Answer 1

I've marked this a papercut in our system (small but hugely annoying) and promoted it to our highest priority . I'd really like to get this done.

Answer 2

There are two aspects to this non-feature that make it particulary irritating:

1. The strong suspicion that code was added to prevent one from editing the release notes field except when a case is resolved, and that fixing this will simply mean removing this code to restore the default behavour of most other fields.

2. The fact that this behavour flies in the face of FogBugz's expressed philosophy of not getting in the way of the users entering useful information by enforcing arbitrary restrictions.

See my answer to this related question for some examples of why the current behaviour gets in the way.

I think there is a conceptual error in the FogBugz model: the idea that resolved is a well defined boolean state of a FogBugz case. A case frequently moves through several stages in workflow. The proper question is not "Is this case resolved?" but "Is this case resolved from my point of view?" The answer to the latter, of course, depends on who is asking the question. For example, with a software product:

• If you're the developer coding the fix, the problem is resolved when you've commeted the changes to fix it the version control system.
• A development manager might consider the case resolved when the changes have been reviewed and merged to the trunk in the version control system.
• The people in the company who deal with end users might not consider the case resolved until the fix has been included in a release shipped to customers.
• Finally, a customer probably doesn't consider the case resolved until they've installed a release with the fix and confirmed that the fix works.

Obviously, this gets even less clear when you consider the use of FogBugz for things other than software projects.