With the restriction of not being able to have release notes for cases that are not marked resolved (FogCreek has a case open: Case FC584149), I'm wondering how people are doing release notes?
I find that we should be able to attach release notes to any case, no matter what their status is, and because of the limitation, we're having to workaround it by creating sub-cases and tags which I feel that there may be easier ways that we haven't thought of.
We've added custom fields for release version and release note, and query them using the version number when a release goes out. There's a little bit of intervention required to make sure all the right stuff goes in there, but it works fine for our small team. Having to wait until the case is closed would not work for us.
I find myself closing the case to make a note, then reopening it, which is a total pain. I can see some work flows not adding a release not until the task was complete, but I think making the link unavailable is just a silly imposition on those who, like me, may want to add a note while I am in the middle of working on something and want to make a note on it before I forget.
Right now, the release notes field is a peculiar variant of a required field: it is required to be blank unless the case is marked as resolved.
Almost everything the FogBugz team has written about required fields being evil applies equally well to this case. The FogBugz staff should re-read some of their arguments against required fields with this in mind and seriously rethink why they feel they need to prohibit users from entering information in the release notes before a case is resolved just because it wouldn't make sense to them.
The current policy vaguely makes sense for software projects, but only if you think that resolving a Fogbugz case corresponds to checking source code changes in to the revision control system. But, even restricting ourselves to using FogBugz with software projects, there are lots of reasons why release notes might be useful before the case gets to be marked as resolved:
We might want to review the source
code changes before a case is marked
We might want to review
the release notes themselves before a case is
We may need to merge the
source code changes into the main
trunk in our version control system
before a case is resolved.
We may need to include the changes in a version
of the software that is released to
customers before a case is resolved.
We may require that the customer that
raised the bug report confirm the new
version does indeed fix the problem
that caused them to raise the bug
before it resolved.