MS Connect Feedback Part 2

Thanks for the great comments. Great in that you took the time to provide them. Not great in what they say about Connect. I was surprised by the feedback - but maybe I shouldn't have been.

This prompted me take a very quick look at some SQL2K5 SP2 data. I'm reporting on the areas I own (Agent, DBMail, SQLCMD, SMO, part of Maintenance Plans, and part of Management Studio).

~9% of the bugs we fixed in SP2 were reported by customers through Connect (or the old MSDN site).

I'm satisfied with the 9% number. It could be higher but it's not bad. If we didn't have the Connect site this number would probably be less than 1%. I'd be happier with something closer to 15%. Why 15%? I don't have a good answer other than it "feels" like a better number than 9% and it feels reasonable.

Of all of the customer bugs closed but not fixed during SP2, 31% were closed as no repro. Other reasons for closure are by design, duplicate, external (meaning another team owns the issue), and won't fix.

The 31% number is an interesting number. I don't know if this is too high or too low. It would require more analysis to understand the details behind the number. I do know, based on the bugs I've triaged, many issues don't contain enough information to do a repro.  When this happens we do one of two things: 1) leave the issue open for a period of time and request more information from the person who filed it. We then close it if we don't get a response or 2) Close it but ask the person to reopen it if they have more information. Our goal is to give people a chance to respond with more information.

I can't speak to the rest of SQL Server and the way their teams handle customer submitted bugs (in general I think SQL Server is very customer focused). For my team, we take everyone of them seriously and strive to have a meaningful dialog with the submitter. But you'd be amazed at the poor quality of some of the bugs submitted (you can probably do a search on Connect and find some of these). My advice is, if it's important to you and your going to spend the time to enter it, provide as much information and detail as you can. The more information and detail you provide the greater the probability we'll "get it" the first time we read the bug. The Repro steps are the most important. Make sure you can consistently repro the problem. If you can't then provide some data on how often you see it, is there a correlation to something else (e.g. It only happens when I have offline databases), etc.

Remember, if we can't repro it in house, we can't fix it.