[Python-Dev] 'languishing' status for the tracker

[R. David Murray]

I believe Brett mentioned the 'languishing' status for the tracker in
passing in his notes from the language summit.

To expand on this: the desire for this arises from the observation
that we have a lot of bugs in the tracker that we don't want to close,
because they are real bugs or non-crazy enhancement requests, but for
one reason or another (lack of an interested party, lack of a good,
non-controversial solution, lack of a test platform on which to test the
bug fix, the fix is hard but the bug is not of a commensurate priority,
etc) the issue just isn't getting dealt with, and won't get dealt with
until the blocking factor changes.

The motivation for introducing a new status, rather than continuing
to leave these bugs in 'open' state, is to make it clear which bugs
are the *active* bugs, the ones we should be focusing on and working
to fix first.  This would allow the count of open bugs to be a more
meaningful metric than it is currently, and might even allow us to get
to a point where the open bug count stops increasing.  More importantly,
however, it would act as a first level partition of the non-closed bugs,
such that the ones for which it is most likely that effective action can
be taken will be what appear first.  This is especially important for new
people coming in to help.  How many people have looked at the tracker,
and decided to start from the oldest bugs and see what they can fix?
I know I started out that way.  Looking through those oldest bugs can
be quite discouraging, since many of them are old because they are hard,
or blocked for one reason or another.

We would in addition propose that a 'languishing' search be added to
the standard searches.  I would also propose that the default search
be changed to search all bugs, and group them by status, not priority.
This will make it more likely that bug *reporters* will find existing
bugs that relate to the problem they are experiencing or the feature
they want to propose.  The other searches (except open) should probably
return languishing issues as well as open, since they sort in reverse
chronological order the more active bugs will be at the top, and that
way the languishing bugs won't be forgotten.  (Note: languishing bugs
should probably never have the 'needs review' keyword, since bugs should
not be allowd to languish simply for need of a review.)

To move a bug to state languishing, the procedure should be to post
a comment saying why you are moving the bug to that status, that by
implication or explicitly lays out the conditions required for it to
move back to open.  Doing so may wake someone up who wants to and can
deal with the issue, in which case it can be moved back to open.

--David

PS: I believe that the other change that would be required in addition
to adding the new status and search is to alter the bug summary email
script to handle the languishing state.  If I've missed anything else
please let me know.