I'm a developer, and I do add additional information in our bug/feature tracking system on completing an item whenever I think it might be useful. I target this mainly to testers, but much of the same information might also be useful to another developer who comes across some code I touched and wants to know more (after reading source comments) about why it is that way.
For some simple fixes, there really is not much more to say. (Problem description: "The foobar icon is green, but per requirements it should be cyan." Resolution: "Changed the default color for the foobar icon to cyan.") But for maybe around half of all Defect fixes, something from my analysis and/or fixes is worth noting. After all, I'm the one who invested the most time in understanding the original issue, deciding exactly how to fix it, and analyzing whether my changes might potentially affect anything else.
I don't expect a tester to be able to understand code, but even for someone who does read code, a brief English explanation of the bug and fix can be quite helpful. Sometimes in complex code, the sequence of events involved could run through many different functions and stored data, and yet have a single line fix. Looking at that single line (and any added comment), you might be able to see why the change is "correct", but it wouldn't always be obvious how that relates to the observed bug.
So here are some questions you might try posing, to be more exact about what you need than just asking for "more information":
What conditions cause the bug?
This is slightly different than "How can the bug be reproduced?". A bug report will normally include at least one way to reproduce a bug, and possibly a few scenarios that seem to cause the same problem. But quite often when I discover the cause of a problem, I'll realize it's actually more general than the reported scenario(s), and/or would only happen depending on something else not described in the report. For example, a bug report might note the issue is reproduced when you "Do actions
A and then
B to widget
C", but there's actually a problem whenever you "Do any particular-class-of-action
A' and then action
B to any widget with property
D, while at least one
E is active".
Or even better, I might start with an issue that seemed to happen frequently but not reliably, and come up with a way to reproduce it consistently.
This is critical information for a tester to properly test the breadth of the change. For example, if I described the original bug as above, a tester might want to also verify that the problem is fixed for a sampling of actions
A' and widgets with property
D, and that the system continues to work correctly in the same scenarios except where no
E is active.
You might rephrase this question, "Are there other ways of reproducing the bug?". A subcategory question is, "Were there any existing configuration settings that would have affected the bug?"
Was anything besides the observed bug fixed?
Of course entirely unrelated changes should not be attached to the same ticket. But maybe two different features were using a common function that had an error that manifested in different ways in each feature. Or maybe the fix involved refactoring some code in a way that solved more than one issue identified during the work.
The test team should definitely be made aware if any positive "side effect" like that was noted, so they can test that out as well.
Which features exercise any of the changed, added, or removed code?
This is the flip side of the previous question. Sometimes a code change has happy side effects, but there's almost always a risk any code change might break something else. Developers should make reasonable efforts at analyzing changes to try to determine what else might be incorrectly impacted, but might miss something, or simply conclude that the remaining risk is acceptable.
When a few other features specifically use some of the same changed code, it may be worth keeping an eye on any automated tests for those features, and/or running a few simple regression tests for those features.
At one extreme, the answer may be "modified a core library function, so effects could be seen anywhere". (And maybe the modification is "obviously" correct, but some other code accidentally relied on the old incorrect behavior...) It's probably not feasible to run all the manual regression tests you have documented and/or can think of when this sort of thing happens, but at least you'll be aware of it as a possible issue.
Are there any non-user tools relevant to the bug or fix?
We developers like to create or find ways to get all sorts of information about what the software is doing that are not meant to be visible to the end user. This includes things like log output, execution traces, and means of inspecting internal data live.
Many of these things would need to be configured or otherwise activated, or might even require an external program. But they're often relatively easy to learn to use, just because the main purpose is to make things easier for us.
Only user-visible behavior truly defines whether software works or not, but sometimes peeking at the software internals in these ways can help verify more exactly that a fix or feature is working as intended. In particular, maybe in a certain scenario you would expect some variation in the output, but there seems to be an undesired pattern in that output. Since it may be impossible to tell from one try if anything's wrong, it may be more useful to investigate the steps in computing the output.
As a bonus, knowing a few of these sorts of tools for your software system can come in handy when writing a new bug report or failing a fix or feature. If you include some data from such a tool that appears, in your best estimation, to be highly relevant to the actual observed bug, the developer assigned to investigating it might appreciate it.
Hopefully explaining exactly what sort of information would be useful to you and why will convince developers to start attempting to provide it.
If developers still resist changing, you might want to discuss these same reasons for wanting more information with a manager, so expectations on the process can be established. This might be more or less formal, depending on your team's size and style.