Resolving/Closing JIRA issues

[Antonio Petrelli <an...@gmail.com>]

Hi all!
Just a (maybe stupid) question: what is the policy about
resolving/closing issues?
At Tiles, we resolve issues when we finish committing, and close them
once a vote has been positive for a release.

Thoughts?

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Paul Benedict <pb...@apache.org>]

The problem is that there is no real way for the reporter to evaluate it.
Yeah, you can go build the snapshot, but that would be a very dedicated
reporter. If we setup nightly snapshots of Struts, I think perhaps, you
could have a purpose between Resolved vs. Closed.

Paul

On 8/9/07, Antonio Petrelli <an...@gmail.com> wrote:
>
> 2007/8/9, Dale Newfield <Da...@newfield.org>:
> > Does JIRA send email to the reporter when the issue is marked resolved?
>
> Yes
>
> >   If we could just alter that email to encourage them to re-evaluate and
> > close...
> >
> > ...but I agree there's not a huge up side to that.
>
> This kind of collaboration is very rare, IMHO (though, when we find
> it, it is pretty pleasant for the developer :-) )
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Resolving/Closing JIRA issues

[Antonio Petrelli <an...@gmail.com>]

2007/8/9, Dale Newfield <Da...@newfield.org>:
> Does JIRA send email to the reporter when the issue is marked resolved?

Yes

>   If we could just alter that email to encourage them to re-evaluate and
> close...
>
> ...but I agree there's not a huge up side to that.

This kind of collaboration is very rare, IMHO (though, when we find
it, it is pretty pleasant for the developer :-) )

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Antonio Petrelli <an...@gmail.com>]

2007/8/9, Paul Benedict <pb...@apache.org>:
>
> Would anyone find it valuable to remove either Resolved or Closed? Is that
> even possible? I don't object to getting rid of one. What do you think Don
> and Antonio?



I don't know...
The concept of "close when it's released" it's useful: if you see a closed
issue, you are sure that you can fix your problem by upgrading (at least, if
there is no regression :-) ). I suppose that in Tiles we will stick with
this way of doing things, but I am happy to change in Struts if others do
not find it so useful.

Antonio

Re: Resolving/Closing JIRA issues

[Dale Newfield <Da...@Newfield.org>]

Ted Husted wrote:
> As Don mentioned, a closed status is useful when there are two
> distinct groups handling the same ticket, since ti tells us that the
> second group signed-off. But, since we don't have that kind of
> workflow, I don't see any practical reason for us to use closed.

Well, we could encourage issue reporters to verify that the issues were 
addressed, and if so close them.

Does JIRA send email to the reporter when the issue is marked resolved? 
  If we could just alter that email to encourage them to re-evaluate and 
close...

...but I agree there's not a huge up side to that.

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Ted Husted <hu...@apache.org>]

Speaking as a RM, unless there is a clear technical advantage that
saves us work in some way, I don't see the point in adding yet-another
step to the process. As Don mentioned, a closed status is useful when
there are two distinct groups handling the same ticket, since ti tells
us that the second group signed-off. But, since we don't have that
kind of workflow, I don't see any practical reason for us to use
closed. Not offering the status, if that were possible, might
eliminate some confusion,

On 8/9/07, Paul Benedict <pb...@apache.org> wrote:
> Would anyone find it valuable to remove either Resolved or Closed? Is that
> even possible? I don't object to getting rid of one. What do you think Don
> and Antonio?
>
> On 8/9/07, Jeff Turner <je...@apache.org> wrot
> >
> > On Thu, Aug 09, 2007 at 03:32:43PM +1000, Don Brown wrote:
> > > 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.
> >
> > I've rejigged JIRA to allow Closed issues to be edited, since that's been
> > confusing/annoying a few people:
> >
> > https://issues.apache.org/jira/browse/INFRA-1303
> >
> > (at least they will be on the next JIRA restart)
> >
> > Let me know if the Struts devs prefer to keep Closed issues uneditable.
> >
> >
> > --Jeff
> >
> > > Don

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Paul Benedict <pb...@apache.org>]

Would anyone find it valuable to remove either Resolved or Closed? Is that
even possible? I don't object to getting rid of one. What do you think Don
and Antonio?

On 8/9/07, Jeff Turner <je...@apache.org> wrote:
>
> On Thu, Aug 09, 2007 at 03:32:43PM +1000, Don Brown wrote:
> > 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.
>
> I've rejigged JIRA to allow Closed issues to be edited, since that's been
> confusing/annoying a few people:
>
> https://issues.apache.org/jira/browse/INFRA-1303
>
> (at least they will be on the next JIRA restart)
>
> Let me know if the Struts devs prefer to keep Closed issues uneditable.
>
>
> --Jeff
>
> > Don
> ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Resolving/Closing JIRA issues

[James Mitchell <jm...@gmail.com>]

+1 from me


--
James Mitchell



On Aug 9, 2007, at 10:18 AM, Ted Husted wrote:

> On 8/9/07, Jeff Turner <je...@apache.org> wrote:
>> Let me know if the Struts devs prefer to keep Closed issues  
>> uneditable.
>
> +1 for editing.
>
> Thanks Jeff!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Ted Husted <hu...@apache.org>]

On 8/9/07, Jeff Turner <je...@apache.org> wrote:
> Let me know if the Struts devs prefer to keep Closed issues uneditable.

+1 for editing.

Thanks Jeff!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Jeff Turner <je...@apache.org>]

On Thu, Aug 09, 2007 at 03:32:43PM +1000, Don Brown wrote:
> 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.

I've rejigged JIRA to allow Closed issues to be edited, since that's been
confusing/annoying a few people:

https://issues.apache.org/jira/browse/INFRA-1303

(at least they will be on the next JIRA restart)

Let me know if the Struts devs prefer to keep Closed issues uneditable.


--Jeff

> Don
...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Ted Husted <hu...@apache.org>]

I don't know if it makes any practical difference, but I wonder if we
should decide to use either "Resolved" or "Closed", but not both.
Right now, we seem to be using either/or, willy-nilly.

Following up on Don's observations, my preferences would be to keep it
simple and just use Resolved and forget about Closed. (Or vice-versa,
since we can edit Closed tickets too.)

-Ted.

On Aug 9, 2007 12:32 AM, Don Brown <mr...@twdata.org> wrote:
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Don Brown <mr...@twdata.org>]

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 <pb...@apache.org> 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 <hu...@apache.org> wrote:
> >
> > Is there any practical advantage to closing a resolved issue after a
> > release?
> >
> > On 8/7/07, Paul Benedict <pb...@apache.org> wrote:
> > > Don, the PITA truth is the only reason why I use Resolved up to a
> > release.
> > > :-)
> > >
> > > On 8/7/07, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Paul Benedict <pb...@apache.org>]

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 <hu...@apache.org> wrote:
>
> Is there any practical advantage to closing a resolved issue after a
> release?
>
> On 8/7/07, Paul Benedict <pb...@apache.org> wrote:
> > Don, the PITA truth is the only reason why I use Resolved up to a
> release.
> > :-)
> >
> > On 8/7/07, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Resolving/Closing JIRA issues

[Ted Husted <hu...@apache.org>]

Is there any practical advantage to closing a resolved issue after a release?

On 8/7/07, Paul Benedict <pb...@apache.org> wrote:
> Don, the PITA truth is the only reason why I use Resolved up to a release.
> :-)
>
> On 8/7/07, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Paul Benedict <pb...@apache.org>]

Don, the PITA truth is the only reason why I use Resolved up to a release.
:-)

On 8/7/07, Don Brown <mr...@twdata.org> 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
>
> On 8/8/07, Paul Benedict <pb...@apache.org> wrote:
> > I have been doing the same: resolving when finishing the issue and then
> > closing once the release is finished.
> >
> > On 8/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> > >
> > > On 8/7/07, Antonio Petrelli <an...@gmail.com> wrote:
> > > > 2007/8/7, James Mitchell <jm...@gmail.com>:
> > > > >
> > > > > That makes sense to me.  I don't remember what the decision was on
> > > > > that.  I think this has more to do with making the release
> managers
> > > > > life easier than policy per se.
> > > > >
> > > > > I can reopen and resolve if needed.
> > > >
> > > >
> > > > It wasn't an "accusation" for your particular issue. I've seen
> people
> > > > closing issues directly (probably at Commons) so maybe this is the
> > > correct
> > > > behaviour for Struts.
> > > > I think that a document should be prepared to inform all developers
> on
> > > the
> > > > correct steps to follow (whatever it is).
> > >
> > > The only comment I have is that closing issues before a release is a
> > > PITA if you use Jira for release notes - and want to make any changes
> > > (correct version number, change title etc) because if they're closed
> > > you first have to re-open before you can then edit.
> > >
> > > Niall
> > >
> > >
> > > > Ciao
> > > > Antonio
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Resolving/Closing JIRA issues

[Don Brown <mr...@twdata.org>]

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

On 8/8/07, Paul Benedict <pb...@apache.org> wrote:
> I have been doing the same: resolving when finishing the issue and then
> closing once the release is finished.
>
> On 8/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> >
> > On 8/7/07, Antonio Petrelli <an...@gmail.com> wrote:
> > > 2007/8/7, James Mitchell <jm...@gmail.com>:
> > > >
> > > > That makes sense to me.  I don't remember what the decision was on
> > > > that.  I think this has more to do with making the release managers
> > > > life easier than policy per se.
> > > >
> > > > I can reopen and resolve if needed.
> > >
> > >
> > > It wasn't an "accusation" for your particular issue. I've seen people
> > > closing issues directly (probably at Commons) so maybe this is the
> > correct
> > > behaviour for Struts.
> > > I think that a document should be prepared to inform all developers on
> > the
> > > correct steps to follow (whatever it is).
> >
> > The only comment I have is that closing issues before a release is a
> > PITA if you use Jira for release notes - and want to make any changes
> > (correct version number, change title etc) because if they're closed
> > you first have to re-open before you can then edit.
> >
> > Niall
> >
> >
> > > Ciao
> > > Antonio
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Paul Benedict <pb...@apache.org>]

I have been doing the same: resolving when finishing the issue and then
closing once the release is finished.

On 8/7/07, Niall Pemberton <ni...@gmail.com> wrote:
>
> On 8/7/07, Antonio Petrelli <an...@gmail.com> wrote:
> > 2007/8/7, James Mitchell <jm...@gmail.com>:
> > >
> > > That makes sense to me.  I don't remember what the decision was on
> > > that.  I think this has more to do with making the release managers
> > > life easier than policy per se.
> > >
> > > I can reopen and resolve if needed.
> >
> >
> > It wasn't an "accusation" for your particular issue. I've seen people
> > closing issues directly (probably at Commons) so maybe this is the
> correct
> > behaviour for Struts.
> > I think that a document should be prepared to inform all developers on
> the
> > correct steps to follow (whatever it is).
>
> The only comment I have is that closing issues before a release is a
> PITA if you use Jira for release notes - and want to make any changes
> (correct version number, change title etc) because if they're closed
> you first have to re-open before you can then edit.
>
> Niall
>
>
> > Ciao
> > Antonio
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Resolving/Closing JIRA issues

[Niall Pemberton <ni...@gmail.com>]

On 8/7/07, Antonio Petrelli <an...@gmail.com> wrote:
> 2007/8/7, James Mitchell <jm...@gmail.com>:
> >
> > That makes sense to me.  I don't remember what the decision was on
> > that.  I think this has more to do with making the release managers
> > life easier than policy per se.
> >
> > I can reopen and resolve if needed.
>
>
> It wasn't an "accusation" for your particular issue. I've seen people
> closing issues directly (probably at Commons) so maybe this is the correct
> behaviour for Struts.
> I think that a document should be prepared to inform all developers on the
> correct steps to follow (whatever it is).

The only comment I have is that closing issues before a release is a
PITA if you use Jira for release notes - and want to make any changes
(correct version number, change title etc) because if they're closed
you first have to re-open before you can then edit.

Niall


> Ciao
> Antonio
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Resolving/Closing JIRA issues

[Antonio Petrelli <an...@gmail.com>]

2007/8/7, James Mitchell <jm...@gmail.com>:
>
> That makes sense to me.  I don't remember what the decision was on
> that.  I think this has more to do with making the release managers
> life easier than policy per se.
>
> I can reopen and resolve if needed.


It wasn't an "accusation" for your particular issue. I've seen people
closing issues directly (probably at Commons) so maybe this is the correct
behaviour for Struts.
I think that a document should be prepared to inform all developers on the
correct steps to follow (whatever it is).

Ciao
Antonio

Re: Resolving/Closing JIRA issues

[James Mitchell <jm...@gmail.com>]

That makes sense to me.  I don't remember what the decision was on  
that.  I think this has more to do with making the release managers  
life easier than policy per se.

I can reopen and resolve if needed.


--
James Mitchell



On Aug 7, 2007, at 10:03 AM, Antonio Petrelli wrote:

> Hi all!
> Just a (maybe stupid) question: what is the policy about
> resolving/closing issues?
> At Tiles, we resolve issues when we finish committing, and close them
> once a vote has been positive for a release.
>
> Thoughts?
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org