Dan's Blog : Microsoft Connect

Now is the time for Connect!

dtjones — Fri, 22 Aug 2008 17:52:35 GMT

Of course I'm referring to Microsoft Connect. Since we've released SQL2K8 we're now deep in the planning for the next release. I know for some of you (likely a lot of you) you are still learning the new functionality in SQL2K8 but now is the time to get your feature requests submitted. Aaron Bertrand, a SQL Server MVP, has already started submitting his ideas for Management Studio. You can find his list and a pointer to his Connect items on his blog. As Aaron knows, submitting it through Connect isn't a guarantee it makes it into the product but getting it on our radar is the first step. Those items which have a large number of votes with a high rating do get our attention. Intellisense, Object Search, and the T-SQL Debugger are examples of that in SQL2K8. Each of these was a community item that had a lot of votes and a high rating. Trust me when I say that Object Search took a lot of convincing to get it in the product and the main reason it made it was because of the community support. Get'em entered and vote on them! Pretty simple.

Microsoft Connect Resolution Reasons

dtjones — Wed, 20 Aug 2008 17:22:27 GMT

In SQL Server we use Visual Studio Team System to track all of our work. There is a back-end integration between the Microsoft Connect site and our VSTS database. When an item is submitted through the Connect site it eventually flows to our VSTS database. We, the product group, can manage the bug directly from within VSTS and certain data flow back to the item in the Connect database.

One of the properties which goes back is the resolution reason. Here are the resolution reasons along with a brief description. As with many attributes there are exceptions; this simply means that not everyone applies exactly the same precise definition and in some cases the wrong reason maybe selected. In other words, use this as a general guideline but not as a hammer.

Fixed: If the item is a defect (a bug in the system) this resolution means it was fixed. If the item was a feature suggestion it means it was added to the product. It may not have been added to the exact specification in the Connect item but the general spirit was implemented.
Won't Fix: If the item is a defect this generally means we've verified it is a problem but we have no plans of ever addressing it. If the item is a feature suggestion is too means we have no plans of ever addressing it.
By Design: This generally only applies to defects. It means that we've verified the reported behavior but we believe this behavior is expected and therefore is not a defect. For example, cannot install BIDS on IA64.
Not Repro: It means that we are unable to verify (reproduce) the reported behavior. I know this one can be extremely frustrating. The more detailed the defect report the better are the chances we'll be able to verify it. I blogged about this back in January. We cannot fix what we cannot reproduce. Depending on the criticality/severity of the defect we will spend varying degrees of time attempting to verify it. Defects that are more severe will get more attention. Just remember we're under constraints just like you.
Duplicate: This simply means the defect or feature request has already been submitted. Often I'll attempt to keep the one opened through Connect as the master so the community can track it. If multiple come through Connect I'll try paste the URL to the original when I close the duplicate.
External: This means the issue does not belong to SQL Server. It could be a Windows or Visual Studio problem. Unfortunately we don't have a robust system for moving bugs around. We have to close it in one VSTS database and open it another. This results in a broken link to Connect .

I hope this information helps you to decode the resolution of your submitted items. Remember, sometimes the person closing the item selects the wrong reason or doesn't provide a complete description explaining the resolution. We try hard to be thoughtful and communicative but sometimes stuff happens.

Getting Your &amp;amp;quot;Favorite&amp;amp;quot; SQL Server Bug Fixed

dtjones — Sat, 12 Jan 2008 10:01:17 GMT

As a PM in SQL Server I read through just about every bug entered for the components my team owns. Given the surface area of what my team owns this translates into a lot of bugs. I don't characterize it that way to disrespect the team or the quality of the product but rather to make a point there are a lot of things that are vying for attention. Add in the new feature requests and there's a lot to look at. We have limited resources and limited time. We cannot possibly fix every bug. So we have to prioritize what we work on and when we work on it. The first order of business is to determine which bugs are "real".

When we triage bugs we take in account many different factors. For example, how many customers does it impact, how often will a user hit it, is there a workaround, is it a regression, does the bug result in data loss or a crash.

So the question is how do you get your bug fixed? Here are some tips for increasing the odds:

1) Include detailed information about your environment. What OS are you running, what SP, are you up to date with Microsoft Update critical updates, what other interesting software do you have installed (think Visual Studio),

2) Include detailed information about your SQL install. What is the full version number, how many instances do you have on the machine, is it a named instance, what's the collation, what SQL components are installed, etc.

3) Include detailed steps to reproduce the problem. Be as specific and detailed as possible. State if the problem consistently happens or is intermittent.

4) State what you expected to happen vs what actually happened. Include a screen shot if applicable

5) Include all error messages. If you get an exception, include the full exception message.

6) Finally, include the impact the bug has on your "business". Do you have to reboot the machine every time you hit it - meaning you have to take down a server.

Does doing all this guarantee your bug will be fixed? No. But it does increase the odds. Remember, if we don't understand the bug we can't fix it. If we can't repro it, we can't fix it.

Oh, one last thing. Don't be disrespectful in the bug. You'd be amazed some of the comments we get in bugs. Why would I put any effort in to a bug that came from someone who's insulting me, the team, or the product? Think of it this way. Would you hire someone with a sloppy resume and insulting comments? Would you expect to be hired with that resume?

One more last thing. I'm a big fan of Connect. Yes, it has its quirks, but it's an invaluable tool for collecting and responding to customer feedback.

MS Connect Feedback Part 2

dtjones — Fri, 06 Jul 2007 21:45:46 GMT

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.

Microsoft Connect Feedback

dtjones — Thu, 05 Jul 2007 17:48:08 GMT

Does the feedback mechanism on Microsoft Connect really work? By "work" I mean is customer feedback changing the product? From my perspective it's too early to make the call. In SQL2K5 SP2 we tried to address the top issues submitted through connect (based on the voting mechanism). I haven't run the analysis to see how successful we were - I should do that. Now we're in the middle of the dev cycle for SQL2K8 and I can tell you that feedback coming through Connect is playing a role in directing our work. This isn't to say that every item entered in Connect will be addressed, but it does mean your vote does count. After we ship SQL2K8 I'll go back and analyze the data to determine what percentage of all "bugs" fixed came through Connect.

Until then, keep posting your issues and voting active items.

Dan's Blog : Microsoft Connect

Now is the time for Connect!

Microsoft Connect Resolution Reasons

Getting Your &amp;amp;amp;quot;Favorite&amp;amp;amp;quot; SQL Server Bug Fixed

MS Connect Feedback Part 2

Microsoft Connect Feedback

Getting Your &amp;quot;Favorite&amp;quot; SQL Server Bug Fixed