We use Mylyn and think that this is a great tool to support the work on the tasks entered in the issue management system.
If we encounter a bug or have an idea for a new feature we use the Mylyn editor to gather the required information. To use our release report only two extra steps are to be made:
We also select some keywords so that we can search for particular bugs more efficiently (and eventually will generate some useful reports on certain views on the issue management).
We use the context management of Mylyn and the focusing mechanism that moves currently not relevant information out of view. But using the context that opens the editor used prior to postponing the task for another task is the killer feature of this great tool.
We often provide the context as an attachment for later use. The code reviewer or controller responsible for closing the bug may find the compilation of of affected files useful.
Checking in the changes into the SVN will also generate a comment that links to the issue currently worked on. Adding further information is sometimes useful, though.
We sometimes add breakpoint files to the bug. This will show the important pieces and it will be easy to debug the code in case there is another bug in the same area. But the breakpoints are only useful for a short period of time. The code usually changes too quickly to have the breakpoints at the right spots.
A comment on the bug details what has actually been done and why it was done this way. Sometimes of is helpful to provide a screenshot on the new feature. This screenshot may be used later if, e.g. this is a new and noteworthy feature...