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 [email protected]
