2

Sometimes, on an IT helpdesk, you have tickets with a few shared characteristics.

  1. They're low priority--just minor annoyances to user
  2. They're extremely hard to reproduce for testing
  3. You've exhausted all troubleshooting possibilities you have at your disposal
  4. You've spent hours on the ticket

This is fortunately a small percentage of tickets, but they do happen. My approach has been to leave these tickets open indefinitely, eventually to languish in forgotten land. Are there better ways? What are your processes for closing unsolvable tickets?

Improve this question
6
  • Do you not have the option to close as "won't fix"? Commented Jun 24, 2019 at 20:48
  • Not officially, though we could create a label if we wanted to. If you're going to do that, how would you express that to the user? Commented Jun 24, 2019 at 20:50
  • You express that to the user as "won't fix." Commented Jun 24, 2019 at 21:57
  • You should rephrase your last two sentences, because right now, this is more of an opinion/anecdote poll than an actual question. E.g. "What are ways to deal with these issues that: * make them disappear from my todo list, * clearly communicate to the user that their issue is not being addressed" Commented Jun 25, 2019 at 10:43
  • 3
    I think "won't fix" is too glib to be useful. Commented Jun 25, 2019 at 12:18

3 Answers 3

Reset to default
3

There's a fundamental difference between an issue that is unsolvable due to lack of information and an issue that is low priority.

For issues that are unsolvable because they don't contain appropriate steps to reproduce or known debugging and troubleshooting techniques have not turned up anything, the closest you may come to a resolution is the addition of additional instrumentation for future reports. These should be closed, stating as much. Future reports should include references to the additional instrumentation or better reproduction instructions.

For issues that are reproduceable and solvable, these should not be closed just because they are low priority. From a customer service perspective, it's much better to know that something is a known and understood issue that has been deprioritized than it is to have customers finding issues for the first time. Plus, it improves traceability to all of the instances of the problem for communication and discussion.

Deprioritized issues shouldn't become a "black hole" or a state of "perpetual limbo". They should be regularly triaged. If there's sufficient information, tests should be written and linked to these issues and run from time to time (but not as part of a regular build, since they would be failing tests) - if the test errors or passes, then the situation has changed and perhaps the issue should be revisited to see if it's still relevant. You can also link the issue to various features or functions of your system teams working in relevant areas can find open issues and see if some can't be resolved in their ongoing efforts.

"Won't fix" is, in my opinion, an invalid response to a bug report. It's either not a bug or defect and the system is behaving as intended (although perhaps documentation, training, or something else needs to change so users don't think it's an issue), cannot be reproduced with current knowledge and can be closed if the people experiencing it cannot provide sufficient detail or once some instrumentation is in place, or is a known issue that is just deprioritized.

Improve this answer
4
  • I'm not sure leaving something in perpetual limbo is the best idea, though. Commented Jun 24, 2019 at 22:01
  • @RobertHarvey This state of "perpetual limbo" does help if your client comes an wants a summary of known issues. However, this set of issues should be triaged on a regular basis. I should add that to my answer. Commented Jun 24, 2019 at 22:06
  • What if you have an issue that is reproduceable but unsolvable, at least, it's unsolvable by the resources you have. For example, I have a ticket for a weird issue that prevents a user from changing a specific dropdown on a specific OS in IE (user was fine with switching to Chrome). I can reproduce it, but I think I've exhausted my resources for solving it. Or am I giving up too soon? Commented Jun 25, 2019 at 12:22
  • @user11633140 That sounds like a low priority issue that would remain open until resolved. Until there's a user that, for some reason, is unable to implement the workaround or until you end support for the browser(s) with the issue, it's not something that you need to focus on. However, what "too soon" is up to the organization to determine - there's no definition of exactly how much time to spend before moving on or determining that it's not worth spending more time on. Commented Jun 25, 2019 at 12:44
1

We have a bunch of statuses and resolutions that can be used when a bug is closed without being fixed, or when it is left open without being actively worked:

  • abandoned
  • aged out
  • cancelled
  • cannot reproduce
  • expired
  • monitor
  • on hold
  • postponed
  • waiting on info
  • won't fix

I don't know if we actually use all of these, but they can be filtered in or out as appropriate from searches and reports. Typically in your situation, we put it into either monitor or waiting on info, depending on if we are waiting for more info from the user, or just monitoring and hoping for some sort of corroborating report or reproduction instructions or log entry from somewhere else. Then after a few months, we close as cannot reproduce.

Improve this answer
0

So, some controversial statements to reflect on.

  1. "The help desk isn't really there to fix or report bugs. It's there to make users of the product happy."

  2. "Developers aren't there to fix bugs, they are there to write version 2 with new sellable features"

  3. "Ticket KPIs aren't there to make customers happy, they are there so you can give bonuses to managers"

It's good to know about bugs, even the hard to reproduce ones. You can't fix the bug you don't know about! But telling customers a problem is bug, wont make them happy. Nor will leaving tickets open make your manager happy and bugs with no steps to repeat will cause developers to explode!

Improve this answer
1
  • It sounds like you've pointed out some conflicting interests there between a manager and a user :) Commented Jun 25, 2019 at 12:42

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.