During the investigation
The best place to keep track of progress and any discoveries would be through the comments.
The goal is, after all, to:
Make sure you remember yourself what you did yesterday when you continue to work on the bug the next morning,
Ensure your colleagues can take over if, for some reason, you should interrupt your work on the bug.
If in the first case, the location doesn't matter, in the second one, bug discussion thread is the natural place where developers would go to get the latest info.
Once the bug is solved
The obvious place to use to document the resolution of a bug would be the commit which solves the bug, and sometimes the commit message.
In most cases, this is all you need for other persons to be able to understand later what caused the bug. If the code is not straightforward and doesn't make the bug cause clear through to a person looking at the diff, chances are you had to either refactor your code to make it more explicit, or add a comment.
One of the reasons is that (1) if the bug existed in the first place and (2) if the difference between the old and the new code doesn't make it clear why the bug existed previously, then there is a risk for someone to reintroduce the bug later.
Sometimes, however, the bug is so weird that no code comments can make it clear. In this case, discussion fields are indeed a good place for those details. The original ticket describes the expected and the observed behavior; the comments explain what happens under the hood.
Many bug reports on GitHub are a good illustration:
- The ticket itself describes the problem.
- The comments explain the discoveries, add the details (edge cases, possible regressions somewhere else when attempting to solve a bug, etc.), and often the resolution itself, before the bug is actually solved. What happens, sometimes, is that someone knows how to resolve a bug, but doesn't necessarily have time to do the actual coding.
- The revision number of the commit which resolved the issue.