Today I asked the following question:
"What is the outcome you're looking for with this bug?"
Let's parse this for a bit.
How the Question Was Asked
Notice that the question wasn't about what needed to change. It wasn't about what the fix was. It was about the customer's expectations.
Ask the question in such a way that the user gets to choose from a variety of answers. Sometimes an explanation or a document can solve the issue as well or better than code. Other times, the user really does want a fix.
I specifically asked what the outcome will be. Occasionally, a resolution (aka a stop to the bug) is something that will be really hard to figure out. Sometimes the customer just wants to complain. Venting and complaining are fine, but a bug is not a good place to do that. There needs to eventually be some resolution, even if it's just, "I hear you. We're not going to do anything about it right now, but I understand that it bothers you." (This is typically the resolution type "won't fix").
You're Looking For
It doesn't matter what the recipient of the bug wants or needs. It matters what the customer wants or needs. It sounds straightforward, but often a bug will trigger the memory or idea of another bug or a feature request. A customer may log a bug that they can't download files of certain names and you discover on the way to looking at it that all files over size X fail to download; those are two different bugs. This is just a quick reminder that you're talking about your customer's request, not your request.
With this bug
It's easier to call it a bug or an issue. Don't get hung up on parsing whether it's a bug or not; that's just a rat hole. It's something that you're working on. Call it "fred" if it makes you feel better!
Asking the question is great, but how you ask the question can have an effect on the response you get. So think first, then ask.