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

[Mojca Miklavec]

Dear Perry,

On 30 April 2018 at 18:16, Perry E. Metzger wrote:
> So I started looking over the Trac tickets a few days ago.

Thanks a lot for taking the initiative for this.

Below are some of my thoughts.

One thing I really dislike about many projects is that one sometimes
spends quite a while trying to submit a reasonable report with
minimum-failing example. It might have started with a long discussion,
but you don't know how to fix the problem (or cannot, in case of bugs
in Apple's frameworks), you keep being stuck with the problem and then
out of the blue upstream or Apple closes the ticket. Just because
nobody commented for a certain amount of time.

They close the ticket, "problem solved and gone". I totally hate
having 3-5k tickets open, but I equally hate the idea of closing them
all just because they are old.

In my opinion what we really need is a clear way to distinguish
between tickets that could really benefit from immediate attention and
tickets that we cannot address, but don't explicitly close either.
Something like a "stale" state?

I would really like to see tickets ending up in a special state that's
neither open nor closed, but something inbetween. Say that gcc keeps
segfaulting which prevents building a particular port A on PPC.
Someone submits a ticket upstream, none of us knows how to fix the
issue. We could label it "upstream" (potentially along with a few
other labels like "if we want to solve this, we need additional help")
and move the ticket to that special state.

When the user searches for tickets related to port A, we could even
show two queries or allow an extended query showing tickets from both
states (open or stale). It would be immediately clear that there is a
known issues for which we lack the expertise to fix, and it would be a
clear sign that none of us is planning to work on it in some near
future, but that we would be super happy to accept patches.

Another example would be most of the "port requests" that have not
seen any activity for N years. If we didn't respond to a request for a
number of years, it's unlikely that the user who requested the port
would still benefit from the addition and there might not even be any
other user interested in that port. To me, seeing a port request
closed as "won't fix" is sending a signal that writing a patch for
such a port, even if I have time and motivation to do it at a later
point, is not even desired.

One question is, if some user opens a ticket saying that a certain
piece of software needs to be updated and nobody does anything for 4
years (fontforge is an example of such a port which was recently
picked up by someone): what would you do with such a ticket? And what
would you do with some real bugs in macports base which nobody knows
how to fix?

Things that can really make a difference is a bunch of small things
like the recent addition of list of personal tickets that
automatically get displayed to logged in users. To remind users and
developers. My bet would be that Chris Jones must have closed some 10+
tickets as a consequence of this change :)


We have various categories of tickets. One example of such a
"category" are tickets like "please add cmake.build_out_of_source
yes", "github projects with different checksums", "upgrade all ports
to perl5.28", "upgrade all ports to python 2.7 and 3.6", "figure out
what to do with google code projects", ... tickets that are completely
straightforward, easy to handle even for newbies, it's just that it
takes forever to solve them because the number of ports that need a
change is relatively large. If we could add more "metadata" to tickets
to filter our difficult challerges and easy tasks for beginners, this
would definitely help.

Mojca