Since the MSDN Product Feedback Center was launched publicly at the end of June with the Visual Studio 2005 Beta 1 release, we’ve received a lot of great input from customers. So far we’ve fixed 24% of the bugs filed. Here’s some insight into how you can make the most impact through the bugs you report.
To make the most impact on the product you want to spend the most time on the issues that are most likely to be fixed. How does Microsoft decide which bugs get fixed and which don’t?
It would be great to fix every bug in the product, but it’s also great to ship J. In prioritizing which issues to fix, here are the some factors that cause certain bugs to miss the triage bar. Bugs that are least likely to be addressed:
To create the highest quality bug report which will save developers time and increase the likelihood the bug is fixed, a little extra work goes a long way:
Here are some tips on how to create a great bug report that will enable Microsoft to action on it quickly. Often bug reports submitted via the PFC lack key peices of information so triage teams send bugs back to customers to request more information. We don’t want to mistakenly resolve and issue as By Design, Won’t Fixed or Postponed, so providing a complete bug report helps ensure the best response from Microsoft. We want to spend as much time as possible fixing customer bugs – to that end, high quality bug reports help us spend less time deciphering the issue and more time resolving it.
Bug titles should completely and succinctly describe the issue. Internally, we spend a lot of time querying the bug database and looking at lists of bug titles. It saves time when we don’t need to open the whole bug report to know what the problem is. On the PFC site, when other users are searching for bugs, they too don’t want to open every link.
“Search selected text”
“Find and Replace dialog should default to last-searched term”
“Control Tab Files”
“Had to press Ctrl-Tab twice for toolwindow selection dialog to raise”
“Change filename in Solution Explorer”
“Changing case of a filename in Solution Explorer doesn’t take effect”
Steps to reproduct the bug are the most import part of a bug. Investing a little extra time in this area helps developers immensely. When creating repro steps:
Result: White space appears, because the scroll region didn't recalculate after hiding abstracts
Expected: After hiding abstracts, scroll region adjusts to match the search result display region
Descriptions should provide all the other useful information about and issue that is not captured in the repro steps some of which may include:
Attachments are extremely helpful, especially for fit and finish UI bugs.
Sharing workarounds is one of the best features in the PFC. It’s great to see the developer community members help each other be more productive with Visual Studio!