The first bug tracking system I used had some Microsoft Window only client. I think it was called Track. Its database got corrupted too often. The next one I used was Bugzilla, which was a huge improvement. Plus, I didn't have to use Microsoft Windows in order to use it. The next one was Rational ClearQuest. It had a web interface, but it, rather pointlessly, I thought, used Java applets. It got replaced by Jira, another huge improvement, and is still being used.

When I get assigned a bug, it's sometimes clear from the report what code needs to be fixed. Most of the time, it's not.

Sometimes, logs are attached to the bug, and those are sometimes enough to determine what the fix should be. Sometimes there aren't logs attached, or the logs attached aren't. If the bug was filed by QA, then I go to the QA system and look at the logs there. The logs on the QA systems usually go back a week or two, and the bugs are usually assigned to me three or four days after they were filed. I can usually go back and see more context if the logs were attached, or try to guess at what logs from the time not too long before when the bug was filed was is applicable.

Most of the developers where I work will wipe out the logs when reproducing bugs, probably because they consider old logs clutter. But, it does mean losing some context, and sometimes when they come to me for help, the logs they've wiped out would have been helpful. I've never wiped out the logs on my systems, and have logs going back for years.

Finally, once all else fails, I'll try to reproduce the bug on my system.