most recent 30 from http://fogbugz.stackexchange.com 2013-05-18T20:20:06Z http://fogbugz.stackexchange.com/feeds/question/8247 http://www.creativecommons.org/licenses/by-nc/2.5/rdf http://fogbugz.stackexchange.com/questions/8247/feature-request-ability-to-enter-release-notes-in-an-active-case Derek 2011-05-18T16:05:47Z 2012-08-02T17:16:35Z

<p>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.</p> <p>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.</p> <blockquote> <p><img src="http://www.gravatar.com/avatar/baf927dcc0b0c5d0f41dece1e575aa0f?s=32&amp;d=identicon&amp;r=PG" alt="Fog Creek"> <a href="http://fogbugz.stackexchange.com/questions/1023/whats-that-kiwi-logo-and-case-number-at-the-bottom-of-my-feature-request" rel="nofollow">Case FC2073740</a></p> </blockquote>

http://fogbugz.stackexchange.com/questions/8247/feature-request-ability-to-enter-release-notes-in-an-active-case/8796#8796 Rich Armstrong 2011-07-19T16:22:47Z 2011-07-19T16:22:47Z

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

http://fogbugz.stackexchange.com/questions/8247/feature-request-ability-to-enter-release-notes-in-an-active-case/9466#9466 Stephen C. Steel 2011-11-02T15:24:39Z 2011-11-02T15:24:39Z

<p>There are two aspects to this non-feature that make it particulary irritating:</p> <ol> <li><p>The strong suspicion that code was <strong>added</strong> 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.</p></li> <li><p>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.</p></li> </ol> <p>See my answer to <a href="http://fogbugz.stackexchange.com/questions/3868/how-are-you-creating-maintaining-release-notes-with-fogbugz/4867#4867" rel="nofollow">this related question</a> for some examples of why the current behaviour gets in the way.</p> <p>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:</p> <ul> <li>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.</li> <li>A development manager might consider the case resolved when the changes have been reviewed and merged to the trunk in the version control system.</li> <li>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.</li> <li>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.</li> </ul> <p>Obviously, this gets even less clear when you consider the use of FogBugz for things other than software projects.</p>