You can 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 than "repro-ed on X".
- Provide arguments in favor of fixing the bug or why the bug report should receive higher priority over other requests.
If the bug being reported has greater implications that aren't mentioned in the report (e.g. it reads like a minor bug but has bigger effects), you can post an answer explaining those issues, or arguments as to why the bug should be fixed rather than an alternate solution implemented.
- Sometimes bugs exist 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.
- Explain that the bug is not a bug but a feature and/or a misunderstanding of how a feature works. A similar thing also applies when an apparent bug is in fact caused by something on the author's end (e.g., a browser extension). Consider retagging to support for these cases.
- Announce that you fixed the bug
This is most likely to happen if you are a 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).
- State that the bug was fixed or is no longer an issue
If a bug was fixed but no employee actually updated the post in any manner to state so, or if later changes made the bug report obsolete, you can post an answer explaining that the bug has been fixed or that it's no longer an issue due to other later changes.
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, though especially in the first four cases are generally better served as edits to your report. Bug reports that you have written but that cannot be reproduced anymore should be close voted, not answered.
For reference: I have written answers to 50+ 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.