[RFC] Issue Tracker Cleanup

[Paul Burba <pt...@gmail.com>]

Whenever we approach a release we always face the question: Which of
our open issues are blockers for the upcoming release?  Obviously as
we approach 1.8, anything with a target milestone of 1.8.0 is
(supposedly) a blocker.  But what about all the issues with the '---'
target milestone?  Very old issues (e.g. something filed in say 2007)
are almost certainly not blockers, whereas more recently filed issues
may be.

Unfortunately we currently have 131 issues with a target milestone of
'---', though given the age of many of these I'm fairly confident they
are *not* blockers for 1.8 as they have already seen one or more
releases pass by.

Recall how we claim to use the target milestone:

[[[
When an issue is first filed, it automatically goes in the "---"
target milestone, which indicates that the issue has not yet been
processed. A developer will examine it and maybe talk to other
developers, then estimate the bug's severity, the effort required to
fix it, and schedule it in a numbered milestone, for example 1.1. (Or
they may put it the unscheduled or nonblocking milestone, if they
consider it tolerable for all currently planned releases.)

An issue filed in unscheduled might still get fixed soon, if some
committer decides they want it done. Putting it in unscheduled merely
means it hasn't been scheduled for any particular release yet. The
nonblocking milestone, on the other hand, means that we do not
anticipate ever scheduling the issue for a particular release. This
also does not mean the issue will never be fixed; it merely means that
we don't plan to block any release on it.
]]]

In the interests of sanity I propose we bulk assign all issues filed
before some arbitrary point in time to the 'unscheduled' milestone.  I
suggest using the date 1.7.0 was tagged as that point, under the
assumption that any issues filed prior were not considered 1.7.0
blockers, so shouldn't be considered 1.8.0 blockers either.  That
would leave 24 "newer" issues which I'm happy to review and assign an
initial milestone to.

Thoughts?

-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

Re: [RFC] Issue Tracker Cleanup

["C. Michael Pilato" <cm...@collab.net>]

On 03/14/2013 04:50 PM, Paul Burba wrote:
> In the interests of sanity I propose we bulk assign all issues filed
> before some arbitrary point in time to the 'unscheduled' milestone.  I
> suggest using the date 1.7.0 was tagged as that point, under the
> assumption that any issues filed prior were not considered 1.7.0
> blockers, so shouldn't be considered 1.8.0 blockers either.  That
> would leave 24 "newer" issues which I'm happy to review and assign an
> initial milestone to.
> 
> Thoughts?

I was thinking along similar lines yesterday (though with '1.8-consider'
stuff in mind, not '---').  So, yeah, +1.

As an aside, we as devs need to get into the habit of ensuring that we never
comment on any issue without also giving it a real milestone assignment.
It's really not that hard when you think about it, even if it means querying
on IRC for second opinions.  '---' is our "needs triage indicator.  As it
is, I see 17 issues that are targeted at '---' and on which I made a
comment, so I am clearly part of the problem here.  Sorry about that, and
I'll try to be better citizen in the future.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Re: [RFC] Issue Tracker Cleanup

[Julian Foad <ju...@btopenworld.com>]

Paul Burba wrote:
> Whenever we approach a release we always face the question: Which of
> our open issues are blockers for the upcoming release?  Obviously as
> we approach 1.8, anything with a target milestone of 1.8.0 is
> (supposedly) a blocker.  But what about all the issues with the '---'
> target milestone?  Very old issues (e.g. something filed in say 2007)
> are almost certainly not blockers, whereas more recently filed issues
> may be.
> 
> Unfortunately we currently have 131 issues with a target milestone of
> '---', though given the age of many of these I'm fairly confident they
> are *not* blockers for 1.8 as they have already seen one or more
> releases pass by.
> 
> Recall how we claim to use the target milestone:
[...]
> In the interests of sanity I propose we bulk assign all issues filed
> before some arbitrary point in time to the 'unscheduled' milestone.  I
> suggest using the date 1.7.0 was tagged as that point, under the
> assumption that any issues filed prior were not considered 1.7.0
> blockers, so shouldn't be considered 1.8.0 blockers either.  That
> would leave 24 "newer" issues which I'm happy to review and assign an
> initial milestone to.
> 
> Thoughts?

+1, and I can't think of any date better that your suggestion of 1.7.0 tag date.

- Julian

Re: [RFC] Issue Tracker Cleanup

[Paul Burba <pt...@gmail.com>]

On Thu, Mar 14, 2013 at 4:50 PM, Paul Burba <pt...@gmail.com> wrote:
> Whenever we approach a release we always face the question: Which of
> our open issues are blockers for the upcoming release?  Obviously as
> we approach 1.8, anything with a target milestone of 1.8.0 is
> (supposedly) a blocker.  But what about all the issues with the '---'
> target milestone?  Very old issues (e.g. something filed in say 2007)
> are almost certainly not blockers, whereas more recently filed issues
> may be.
>
> Unfortunately we currently have 131 issues with a target milestone of
> '---', though given the age of many of these I'm fairly confident they
> are *not* blockers for 1.8 as they have already seen one or more
> releases pass by.
>
> Recall how we claim to use the target milestone:
>
> [[[
> When an issue is first filed, it automatically goes in the "---"
> target milestone, which indicates that the issue has not yet been
> processed. A developer will examine it and maybe talk to other
> developers, then estimate the bug's severity, the effort required to
> fix it, and schedule it in a numbered milestone, for example 1.1. (Or
> they may put it the unscheduled or nonblocking milestone, if they
> consider it tolerable for all currently planned releases.)
>
> An issue filed in unscheduled might still get fixed soon, if some
> committer decides they want it done. Putting it in unscheduled merely
> means it hasn't been scheduled for any particular release yet. The
> nonblocking milestone, on the other hand, means that we do not
> anticipate ever scheduling the issue for a particular release. This
> also does not mean the issue will never be fixed; it merely means that
> we don't plan to block any release on it.
> ]]]
>
> In the interests of sanity I propose we bulk assign all issues filed
> before some arbitrary point in time to the 'unscheduled' milestone.  I
> suggest using the date 1.7.0 was tagged as that point, under the
> assumption that any issues filed prior were not considered 1.7.0
> blockers, so shouldn't be considered 1.8.0 blockers either.

Done.

-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba