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

[Ken Cunningham]

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		pmetzger at macports.org