Adding "upstream issue" to ticket resolutions

[Ryan Schmidt]

On Jun 12, 2014, at 2:25 PM, Mojca Miklavec wrote:

> Sometimes the open tickets are really upstream issues that the
> maintainer isn't able to fix until the upstream solves a particular
> problem. I would like to clearly distinguish these tickets from the
> rest.
> 
> Such tickets can either stay open for years (and give a bad impression
> that tickets in the tracker are too often ignored [which is actually
> true to some extent]) or they can be closed with "wontfix" and go
> completely out of radar (if upstream actually fixes the problem,
> backporting the fix might still be desired) + maybe even discouraged
> anyone to submit a patch.
> 
> It would be nice to introduce a special state, meaning that while this
> is still an issue, it will only be fixed if the upstream fixes the
> problem (or if someone is willing to invest time to fix this). Like
> here:
>    https://github.com/Homebrew/homebrew/issues?labels=upstream+issue&page=1&state=open

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.

If we really wanted to indicate that a ticket wasn't fixed because it's an upstream issue, we could use a new keyword... We could then make it independent of whether we close the ticket or not. i.e. if it's a problem affecting many users and the developers are active, we could add an "upstreamissue" keyword while leaving the ticket open so that others can easily find the issue, then backport the fix when it's available. Or if the ticket was just a wishful feature request, we can close it as "wontfix" while adding the "upstreamissue" keyword.


> There might be other useful states like "infoneeded" when users report
> something and then disappear without feedback.

Mantis bug tracker has this "feedback needed" state; once the user provides feedback, the state automatically changes back. I don't know if Trac has anything like that. We could use a new "infoneeded" keyword, but would have to remember to add and remove it manually. We could look if there are Trac plugins to help with such a workflow.

I think it's pretty easy to see if info is needed, just by looking at the last comment in a ticket. 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.


> Truth to be told, I
> also find the "accept" option weird and almost never used (I'm unable
> to assign the ticket to someone else and if someone else assigns it to
> me, there's no point it explicitly marking it as "accepted"). A
> "confirmed" state would be more useful than accepted.

I personally "accept" a ticket once I've confirmed the issue and have decided to fix it. I don't know if other developers are using "accepted" the same way.