JIRA Resolved vs Closed

[Kirk Lund <kl...@pivotal.io>]

Is there a standard that ASF follows for when a JIRA ticket changes status
to Resolved vs Closed?

If not, then I'd like recommend that we follow the process that Spring uses:

Ticket changes to Resolved when the fix/implementation is committed or
merged (to develop in our case). It then moves to Closed when that fix or
implementation ships in a release. The two different states then have
meaning and purpose as well as having a clear definition of when a ticket
should be Resolved vs Closed.

If a bug actually originates on a branch and is then Resolved on that same
branch before merging anywhere, we could then specify that the ticket
should be Closed before merging to develop.

Thoughts or feedback?

-Kirk

Re: JIRA Resolved vs Closed

[Ashvin A <aa...@gmail.com>]

+1

Using Closed state for change log makes sense. Will the release manager
make the transition from Resolved to Closed state after a release?

Thanks,
Ashvin

On Mon, Nov 2, 2015 at 2:19 PM, Anthony Baker <ab...@pivotal.io> wrote:

> Echoing the logic:
>
> http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200605.mbox/%3C447D2230.5020304@apache.org%3E
>
> Anthony
>
> > On Nov 2, 2015, at 12:43 PM, John Blum <jb...@pivotal.io> wrote:
> >
> > +1
> >
> > To add a bit of clarification on the Resolved vs. Closed status, you can
> > also think of Closed as the moment the customer/user considers the
> > issue/enhancement identified in the JIRA as complete and "accepted".
> Since
> > most OSS projects do not have a specific user/customer, then a ticket is
> > considered closed once released to indicate there were no additional
> follow
> > up on the ticket keeping it in an "in-progress" status and holding up the
> > release.  This is not to say that a ticket cannot be "re-opened" at a
> later
> > time if another related problem is found.  However, it usually up to
> > individual projects to decide whether to re-open the existing ticket or
> > just file a new one (and link back to the original).
> >
> > -j
> >
> >
> > On Mon, Nov 2, 2015 at 12:10 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >
> >> Is there a standard that ASF follows for when a JIRA ticket changes
> status
> >> to Resolved vs Closed?
> >>
> >> If not, then I'd like recommend that we follow the process that Spring
> >> uses:
> >>
> >> Ticket changes to Resolved when the fix/implementation is committed or
> >> merged (to develop in our case). It then moves to Closed when that fix
> or
> >> implementation ships in a release. The two different states then have
> >> meaning and purpose as well as having a clear definition of when a
> ticket
> >> should be Resolved vs Closed.
> >>
> >> If a bug actually originates on a branch and is then Resolved on that
> same
> >> branch before merging anywhere, we could then specify that the ticket
> >> should be Closed before merging to develop.
> >>
> >> Thoughts or feedback?
> >>
> >> -Kirk
> >>
> >
> >
> >
> > --
> > -John
> > 503-504-8657
> > john.blum10101 (skype)
>
>

Re: JIRA Resolved vs Closed

[Anthony Baker <ab...@pivotal.io>]

Echoing the logic:
http://mail-archives.apache.org/mod_mbox/db-jdo-dev/200605.mbox/%3C447D2230.5020304@apache.org%3E

Anthony

> On Nov 2, 2015, at 12:43 PM, John Blum <jb...@pivotal.io> wrote:
> 
> +1
> 
> To add a bit of clarification on the Resolved vs. Closed status, you can
> also think of Closed as the moment the customer/user considers the
> issue/enhancement identified in the JIRA as complete and "accepted".  Since
> most OSS projects do not have a specific user/customer, then a ticket is
> considered closed once released to indicate there were no additional follow
> up on the ticket keeping it in an "in-progress" status and holding up the
> release.  This is not to say that a ticket cannot be "re-opened" at a later
> time if another related problem is found.  However, it usually up to
> individual projects to decide whether to re-open the existing ticket or
> just file a new one (and link back to the original).
> 
> -j
> 
> 
> On Mon, Nov 2, 2015 at 12:10 PM, Kirk Lund <kl...@pivotal.io> wrote:
> 
>> Is there a standard that ASF follows for when a JIRA ticket changes status
>> to Resolved vs Closed?
>> 
>> If not, then I'd like recommend that we follow the process that Spring
>> uses:
>> 
>> Ticket changes to Resolved when the fix/implementation is committed or
>> merged (to develop in our case). It then moves to Closed when that fix or
>> implementation ships in a release. The two different states then have
>> meaning and purpose as well as having a clear definition of when a ticket
>> should be Resolved vs Closed.
>> 
>> If a bug actually originates on a branch and is then Resolved on that same
>> branch before merging anywhere, we could then specify that the ticket
>> should be Closed before merging to develop.
>> 
>> Thoughts or feedback?
>> 
>> -Kirk
>> 
> 
> 
> 
> --
> -John
> 503-504-8657
> john.blum10101 (skype)

Re: JIRA Resolved vs Closed

[John Blum <jb...@pivotal.io>]

+1

To add a bit of clarification on the Resolved vs. Closed status, you can
also think of Closed as the moment the customer/user considers the
issue/enhancement identified in the JIRA as complete and "accepted".  Since
most OSS projects do not have a specific user/customer, then a ticket is
considered closed once released to indicate there were no additional follow
up on the ticket keeping it in an "in-progress" status and holding up the
release.  This is not to say that a ticket cannot be "re-opened" at a later
time if another related problem is found.  However, it usually up to
individual projects to decide whether to re-open the existing ticket or
just file a new one (and link back to the original).

-j


On Mon, Nov 2, 2015 at 12:10 PM, Kirk Lund <kl...@pivotal.io> wrote:

> Is there a standard that ASF follows for when a JIRA ticket changes status
> to Resolved vs Closed?
>
> If not, then I'd like recommend that we follow the process that Spring
> uses:
>
> Ticket changes to Resolved when the fix/implementation is committed or
> merged (to develop in our case). It then moves to Closed when that fix or
> implementation ships in a release. The two different states then have
> meaning and purpose as well as having a clear definition of when a ticket
> should be Resolved vs Closed.
>
> If a bug actually originates on a branch and is then Resolved on that same
> branch before merging anywhere, we could then specify that the ticket
> should be Closed before merging to develop.
>
> Thoughts or feedback?
>
> -Kirk
>



-- 
-John
503-504-8657
john.blum10101 (skype)