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

[Perry E. Metzger]

On Tue, 1 May 2018 00:51:27 +0200 Rainer Müller <raimue at macports.org>
wrote:
> On 2018-04-30 18:16, Perry E. Metzger wrote:
> > 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.  
> 
> I highly doubt anyone is going to look through open tickets unless
> they are looking for tickets filed against a specific port...

I do. I've been doing it for a while now. I've been closing a few
tickets a day this way. If more people joined me, I think with a few
minutes a day of work on the part of a bunch of people, we could
probably close 100 to 200 more tickets than come in a month, and in a
year or two, we'd be down to the few hundred real issues that can't be
dispatched with and need to be left open.

The job is much harder than it needs to be because one often has to
read a long thread only to find something like the submitter saying
"this can be closed" only no one noticed several years ago, or one
discovers a problem was actually fixed but someone wanted the report
left open as a reminder to fix something unrelated which they forgot
about three years ago instead of closing that report and opening a
new ticket about the distinct issue, or it takes a while to
ascertain the issue was really about a port that got upgraded or
removed a long time ago.

For every ticket, it should be obvious whether:

1. There is an action someone could concretely take that it is
awaiting, and if so, who the person being waited on is and what the
action would be.
2. There is no action anyone can take, but it is hoped that after
some future event (the release of a new version of macOS, the fix of
a general MacPorts feature deficiency, etc.) the ticket can be acted
on.
3. The ticket is permanently or semi-permanently "stuck", say a
persistent bug several people are experiencing which no one knows how
to fix and no one can act on until some unknown future time.
4. The ticket represents a reminder about a needed future feature.

Mostly tickets aren't in the form of (3) or (4). Mostly they're
potentially (1), but no one has articulated who is responsible and
what they need to do. Sometimes, less often, they seem to be (2)
(there's an open ticket about FUSE of that form because of something
Apple broke).

The goal for someone going through the tickets DB is to quickly
identify if a ticket is of form (1) and to figure out exactly who
should be doing something and what that something is. It often takes
a great deal of reading just to figure that out. The more tickets
that are outstanding, the harder it is to peer through the fog.

> A ticket documenting a bug can still be valid after years, even if
> nobody commented on the ticket anymore.

Oh, sure. But if someone was in pain for years and no one fixed the
problem, they probably moved on to use something else. The goal is
to fix bugs quickly and not to leave them lying around for long
periods.

A ticket for a truly persistent bug that cannot be fixed should of
course be left open. However, most of our tickets are not of that
form.

> Note: these comments only apply to bug reports. I fully support
> closing open port submissions that have not been worked on for
> years.

My goal at this point is to try to get new port submissions and patch
submissions worked on quickly. We should try to slowly go through and
either incorporate patches from the past or close out those reports.

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