allow tagging tickets as wontfix without closing them

[Chealer]

Tickets can be marked as "wontfix" when setting their resolution to closed:

Ticket Fields A ticket contains the following information attributes: […]

• Resolution - Reason for why a ticket was closed. One of fixed, invalid, wontfix, duplicate, worksforme.
• Status - What is the current status? One of new, assigned, closed, reopened.

However, deciding that an issue won't be solved doesn't solve the issue, it should keep open Status. Most BTS engines, for example debbugs, allow this ( ​http://www.debian.org/Bugs/server-control.en.html#tag ).

It could be argued that this is not a bug. Traditionally BTS-s were used internally in organizations where developers may decide a bug report is no longer interesting when it was decided it won't be fixed. As there is no definition of the status options, "closed" could be understood as "we won't address this issue".

Nowadays BTS-s are increasingly used directly by software end users who want to see problems, whether they'll be solved or not. Even closed development teams may want to see wontfix ticket open for example to merge duplicates more quickly.

Considering the 2 scenarios above, closing a report when it's tagged wontfix could remain as an option.

BTW, the documentation doesn't mention the Status open. Clearing up Status could help.

[Remy Blank]

How about one of the following:

• Use a "wontfix" keyword in the keywords field. This corresponds to the "tags" in the Debian link you provided.
• Add a "Future resolution" custom field, where one can select from a list of values.

I don't really see the need to complicate the workflow for most users. Voting "wontfix" (yeah, I do see the irony in this).

[Christian Boos]

Replying to Chealer:

Tickets can be marked as "wontfix" when setting their resolution to closed:

Ticket Fields A ticket contains the following information attributes: […]

• Resolution - Reason for why a ticket was closed. One of fixed, invalid, wontfix, duplicate, worksforme.
• Status - What is the current status? One of new, assigned, closed, reopened.

However, deciding that an issue won't be solved doesn't solve the issue, it should keep open Status.

No, "open" should be understood here as: "open for discussion". The status is not about the issue itself, it's about the ticket describing the issue.

"closed" is a resting state, which doesn't imply the issue has been solved. That nuance is provided by the resolution field.

One could argue that once a resolution has been decided upon, this could corresponds to a pre-closed state that could be called "resolved". That's what Mantis does, and can be seen more consistent (resolved with resolution xyz). In practice, I find that it is overkill and "closed" is enough, at least in our practice. Furthermore, I believe the TracWorkflow would allow you to configure this quite easily, with the set_resolution key.

But if you do this, or follow the suggestion from Remy above, think about the implications in the context of the timeline: deciding that a ticket won't be fixed is an important decision in the lifecycle of a ticket but if you don't change its state to closed at this occasion, then this won't even appear by default in the timeline, as the "ticket updates" is not selected by default. I think the Announcer plugins also has options to only notify on closed (not 100% sure).

It could be argued that this is not a bug. Traditionally BTS-s were used internally in organizations where developers may decide a bug report is no longer interesting when it was decided it won't be fixed. As there is no definition of the status options, "closed" could be understood as "we won't address this issue".

Right.

Nowadays BTS-s are increasingly used directly by software end users who want to see problems, whether they'll be solved or not. Even closed development teams may want to see wontfix ticket open for example to merge duplicates more quickly.

But a wontfix ticket doesn't mean it's an uninteresting one! Furthermore, if you're looking for an existing problem, you would usually also look into the closed tickets, as if it's a recent problem chances are that the issue was fixed and the ticket closed, but the corresponding version of the software is not yet available…

Note that we can select the non-closed tickets and the "interesting" closed tickets using a query link:

e.g. issues with MySQL: query:?keywords=mysql&resolution=wontfix&resolution=

Unfortunately, it is not easily doable in the Custom Query view, as the empty option could not be selected. I think it would make sense to be able to select there the "empty" resolution (showing None as the label?), for easily selecting the tickets with no resolution set. Btw. Mantis associates a resolution value of open to the not yet resolved tickets. I wonder if one can't do the same in a new setup: add an open resolution value, and set it as the default_resolution (not tested).

[Christian Boos]

Furthermore, I believe the TracWorkflow would allow you to configure this quite easily, with the set_resolution key.