On Tue, 1 May 2018 00:51:27 +0200 Rainer Müller <[email protected]> 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 [email protected]
