At one point about two years ago I also suggested closing all tickets more than about six months old, for the exact same reasons. So I'm on board.
There _is_ a vast storehouse of practical information in MacPorts trac. Whenever I get a build error I go there first, often before Google. But ancient tickets are dusty cobwebs, IMHO, and have all the effects you mentioned. Ken On 2018-04-30, at 9:16 AM, Perry E. Metzger wrote: > 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]
