I believe the traditional purpose of the "closed" state is for a QA department, so they can mark the issues they have verified to be fixed. In Struts, I don't think we really do that, and while we do informal code reviews (commit emails), we certainly don't require formal test documents that verify the ticket resolution is correct. If a release manager wants to take that role upon themselves, that's great, but it should be purely optional.
Don On 8/9/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > According to JIRA: > > *Resolved = *A resolution has been taken, and it is awaiting verification by > reporter. From here issues are either reopened, or are closed. > ***Closed = *The issue is considered finished, the resolution is correct. > Issues which are not closed can be reopened. > That seems pretty practical to me. Just because the issue is resolved > doesn't mean it's correct or has been verified by other > committers/reporters. I was never given any guidance on the issue, but it > seems Anotonio and I figured to close issues after a successful vote. To me, > a release implies "the resolution is correct" for the ticket list and thus > closing them. Because closed issues must be reopened to work on them, a > Resolved state implies not the termination of the workflow. > > Paul > > On 8/8/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > Is there any practical advantage to closing a resolved issue after a > > release? > > > > On 8/7/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > > > Don, the PITA truth is the only reason why I use Resolved up to a > > release. > > > :-) > > > > > > On 8/7/07, Don Brown <[EMAIL PROTECTED]> wrote: > > > > > > > > My 2c is I don't see any practical value in resolved/closed. They are > > > > functionally the same thing, only closed is a PITA because to change > > > > it, you have to reopen it. I know many orgs have workflows where the > > > > two states mean very different things, but for Struts, I think it > > > > would be overkill. > > > > > > > > Still, if you want to do something like Paul, that's fine, but I > > > > probably won't for my tickets. > > > > > > > > Don > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]