Request for discussion: lowering the backlog of old Trac tickets.

[Perry E. Metzger]

So I started looking over the Trac tickets a few days ago. There was a
really scary number open, over 2400. A couple of days of looking got
it down without much trouble to 2393.

I suspect lowering the number by about 100-200 a month should be
doable with a very small but very steady effort from a few people.
That would result in the number getting down, over a year or two, to a
couple hundred open that represent real long-term issues that need to
be tracked and are too important to close, with new tickets generally
being acted on within a few days.

(I also got the "haspatch maintainer" backlog down to 11, there were a
few recent ones that were really easy to handle.)

Along these lines, we probably need some discussion about what the
general policies about tickets should be.

This came up in a discussion on a ticket today. I noticed on Trac
enhancement ticket that had been waiting for someone to answer a
question for a couple of years, I suggested that the ticket might be
something to close.

Ryan, quite reasonably, asked "Why".

I'm going to copy the answer I gave there, because it seems like a
reasonable thing to answer and discuss. People might disagree
strongly with my answer, and it would be good to have a consensus on
this well before we figure out how to clean out the ticket backlog:

....

[So why close an old ticket waiting on input when the issue hasn't
been resolved.]

First, because the submitter and the owner haven't replied in years,
and thus are unlikely to every reply again without someone actively
soliciting input from them.

But, more generally: because if you make your tracking system into a
graveyard of dead requests that will never be acted on, you end up
with it being very difficult for someone to look through it and find
things that actively need fixing.

The function of a ticket system is to allow people to keep track of
open issues and to direct their work so that those issues get
resolved. This requires that most tickets contain actionable
information, so that someone looking through the tickets can easily
find tasks that they can quickly perform.

(There is a second category of things that can validly be left open
indefinitely: tickets can be used to record projects that are
important but might not be acted on for quite some time. This allows
for tracking of projects that are of interest. But, generally, there
are fairly few such things that one tracks compared to the number of
defects and issues reported by users, so they don't generally get in
the way of using the ticket system to track problems because the
nature of such tickets is obvious in the description.)

If a ticket system gets overly clogged up with things that cannot be
acted on and likely never will be acted on, the things that do need
attention get lost in the fog. You end up with people waiting years
on things that could be acted on because no one can see that they're
in need of attention. Then people get depressed that the problem
keeping them from getting their work done has been ignored, and
wander off, never to return.

New people looking at the tickets system also get immensely depressed
when they see that it is not uncommon for people to report an issue
and have it sit for many years without action. It is, of course,
vastly easier to clear out actionable requests when you can find
them. (And thus, again, it is best not to have a lot of things in the
system that cannot be acted on, because otherwise you need a lot of
effort to find the actionable items amidst the unactionable ones,
with most effort going not to fixing problems but to finding the
problems that can be fixed.)

...

Anyway, that was what I wrote. I'd be interested in hearing other
people's thoughts.


Perry
-- 
Perry E. Metzger		pmetzger at macports.org