You answer a bug report when you can either:
- Explain where the bug in the code is and add a possible solution.
That is easier if you have code access, but I've answered a few bug reports based on some reverse engineering and inspection of what I found / tracked in the browser.
- Have a good reproduction (screenshots / steps / given input / expected output / observed output) of the bug on a different device / browser. Use this option with great care and only use a comment if you have nothing more to add then "repro-ed on X".
- Explain that the bug is not a bug but a feature and/or a misunderstanding of how a feature works. Consider retagging to support for these cases.
- Sometimes bugs exists but have a workaround.
Documenting the alternatives is useful, for those who experience the bug and for prioritizing bug-fixing and/or resolution negotiation. Bugs with a reasonable workaround can go beyond the 6 to 8 weeks estimate.
- Announce that you fixed the bug
This is most likely to happen if you are an Stack Exchange Employee. In your answer you include some juicy details, pictures and/or twitter feeds. Mention after which build number the fix will be live (meta and main).
A good answer should make it easier for visitors to verify if they experience the same bug and for a Stack Exchange Developer to quickly get to the root cause with a reasonable test-case so they can verify they fixed the bug.
An answer to your own bug report could follow any of the above options. Bug reports that you have written but are no longer reproducible should be close voted, not answered.
For reference: I have written answers to 35 bug reports and I'm not an SE employee, although some of my answers are for bugs reported for the Stack Exchange Data Explorer, which is open-source.