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]

Reply via email to