In some circles I'm known as "the Connect guy" because I've filed a heck of a lot of suggestions and bugs that I've envisioned or encountered, and I'm often willing to file an issue on someone else's behalf. In other circles, for very much the same reasons, I'm probably known as "that annoying Connect guy." On and off over the past few years, I've assembled what I've called "Connect Digests" here on this blog, calling out some of the issues that have been filed that I've deemed as deserving attention. At some points these digests have been more regular than others, and that is totally driven by travel, schedule and workload.

Today I thought I would share a little bit of wisdom with my fellow (and potential) bug-filers. I do see a lot of bugs that get closed as Not Reproducible ("no-repro") or Won't Fix, and I don't think that they all had to be closed that way. Part of the problem can often be pointed back to the quality of the bug itself. I'm not going to name names or call out any specific "bad" bugs, but just wanted to give some hints about what they are looking for. Note that for bugs you should be able to re-open them even if they get closed, but only do so if you have new information to add, not just because you didn't like the decision.
 

If your bug comes back as Not Reproducible

Try to ensure that you have included complete information about the repro. If there is a crash, capture the detailed stack trace information from the event log or the application's dialog (e.g. SSMS has these details). If screen shots help with the repro, include them. If there are certain "non-standard" aspects of your environment, such as a non-default collation, different compatibility mode, database name that is a keyword, different operating system language, etc., it is possible that those differences are influential in manifesting the bug and, without that information, it might not be possible for Microsoft to repro (because they aren't going to walk through your steps using a full matrix of every possible test combination). Without full, consistent and reproducible steps to exhibit the problem, it is also impossible to know whether you've fixed the problem, and can also be difficult to determine how effective the fix is and whether or not it caused regression elsewhere.
 

If your bug/suggestion comes back as Won't Fix

Hopefully there is a comment that goes along with it, and the comment will explain why the issue won't be fixed. Sometimes it is just not practical to fix a bug or implement a suggestion, or to do so in the current development cycle. The following factors are all used to guide where a bug or suggestion ends up on the pipeline:

• how to reproduce the problem
• the frequency the problem occurs
• the likelihood of the problem occurring (number of customers potentially affected)
• the actual impact on users
• the root cause
• the cost and risk of fixing it (e.g. backward compatibility)
• available work-arounds

Yes, they certainly understand that an issue might be important to you; however, there are many other factors to consider. Depending on the reason(s) stated in the comment(s) by Microsoft, you might want to come back armed with more compelling information, or more people stating their business case qualitatively (see below).

If you haven't filed your bug/suggestion yet (or it's not yours)

Please keep the above in mind. Also note that the qualitative information is at least as important, and often more so, than the quantitative information. In other words, if you just state that x is broken, needs to be fixed, and look at all these votes that support it, that is not necessarily enough to convince Microsoft that it needs to be fixed. In the description of your bug, or in a comment on someone else's, state *why* it needs to be fixed. A real business case that demonstrates significant impact on a customer goes a heck of a lot further than a few extra votes. If your arguments involve standards compliance or keeping up with a competitive RDBMS product, it certainly can't hurt to include that information as well. If you have additional information that explains why the issue hurts, or how the workaround is painful, this can be factored into the decision (unlike an extra up-vote, which to Microsoft is just an <aol>me too</aol>). Including this data can only make it more likely that the item will be seriously considered.
 

Summary

Connect can be an invaluable tool in getting feedback back to Microsoft and affecting change in SQL Server. It can also be quite frustrating if the flow of information – in either direction – is not the highest in quality. I hope I've given you some things to think about to at least improve one direction of that flow.