The sordid life of software bugs, exposed! is a very interesting look into the software bug process within Microsoft. While this is about another MS product my impression is that this a very common approach within Microsoft. If you are going to report a bug to Microsoft it helps to have an exact repro scenario including an example file if appropriate and why you think it’s important to a lot of people that Microsoft should fix it ASAP versus in the next Service Pack versus never.
I do something similar but vastly simplified in my shrink wrap program the Granite Fleet Manager. With a few minor exceptions. Every time I come across a bug or problem that I can’t fix and test in five minutes it usually gets entered into an Access database. Now if the bug or problem in a feature that I’m working on and I’m going to get to it in a day or two then I’ll enter it in my active OneNote page I use as a notepad for that particular feature. Then I cross it off once I’ve done using the strikethrough font capability. (I’ve added the strikethrough button to my OneNote Toolbar.)
I frequently find that as I go through my list of outstanding bugs that I’ve already done several but had forgotten they were in my list.