Adding "upstream issue" to ticket resolutions

[Mojca Miklavec]

On Fri, Jun 13, 2014 at 1:47 AM, Ryan Schmidt wrote:
>
> I'm loth to add more options. I think we already have far too many options that people need to select, and more than often select incorrectly. I like simpler bug trackers, like FogBugz, which require nothing more than a single sentence to open a ticket.

I just started watching their video from a talk. Yes, they have a
great user interface, simple to use, but the information in the
tickets is anything but simple. It might actually be driven by one of
the most complex databases I've ever seen in a bug tracker (users seem
to be allowed to mark *a lot* of different options).

Plus, "infoneeded", "bug confirmed", "upstreamissue" is really not
something that regular users can edit anyway.

If anything, I would kick "accepted" out. Unless 72 hours are over,
I'm not allowed to accept a bug/feature request for someone else's
port. And even once it's past 72 hours, it feels strange to accept
someone else's ticket.

If a ticket is assigned to me, I need to fix it. I don't feel a
difference if I accept it or just keep it as new and assigned to me.
Or at least that field doesn't let me close the tickets any faster. It
would be a difference if we would look into confirmed bugs vs. random
duplicates or user errors.

The bad GUI designs include:
- automatically setting macports version when there is a bug in the port
- showing "port" field when the bug doesn't involve the ports
- it should allow autocompletion of keywords and ports
- it should automatically assign the owner or CC maintainers of cited ports
- it doesn't handle portgroups in the same way as it handles ports
- it doesn't allow linking tickets (as depending on each
other/blocking another ticket, related to each other, ...)
- the port names in "port" field could be hyperlinks leading to all
tickets for that port
- there should be a trac syntax cheat sheet link next to the main field
- I still believe that all tickets listing port foo should be CC-ed to
something like foo at ports.macports.org and people could subscribe to an
arbitrary number of ports (I could sometimes fix issues reported in
new tickets, but I usually don't know when a ticket for a port I'm
interested in has been opened)
- no graphs with the number of tickets opened/closed over time
- (I could list more)

On top of that I wish there was a way to specify the reason why a
ticket is open (sometimes for years). A lot of time it's because a
non-commiter cannot do anything and no comitter is interested to look
into it. Sometimes it's because the maintainer (or anyone else on CC)
doesn't know how to fix a particular issue and some extra expertise is
needed, either in C++ or in Tcl. Sometimes it's because the ticket is
waiting for maintainer timeout (and other committers think it's
ready). Sometimes there is no Snow Leopard user to fix a problem that
can only be reproduced there.

Overall trac can be very nice, but with several thousand open tickets
and no incentive for anyone (other than a few most devoted ones) to
look into the tickets (committers potentially willing/able to fix
issues are often not aware of the "interesting" tickets) it's hard to
ever hope of minimizing the number of open issues.

> I think it's pretty easy to see if info is needed, just by looking at the last comment in a ticket.

I checked a few other trac setups. The default views don't even show
these tickets.

> Maybe it's hard to do a search for tickets that need info, but I'm not sure if anyone would ever do such a search.

It's more often used to hide those tickets than to show them ;)

But it's also true that having "infoneeded" doesn't feel as important
as the rest.

Mojca