Connect

As hopefully most of you know, Microsoft has a site called Connect where customers can log bugs and suggestions (http://connect.microsoft.com/).  Issues for .NET can be found in the Visual Studio and .NET Framework feedback category (http://connect.microsoft.com/VisualStudio/Feedback) and can be logged from the main Visual Studio Connect page (http://connect.microsoft.com/VisualStudio/). 

One of the complaints we often hear from customers is that they don’t know what happens to a Connect issue after they file it.  So I wanted to take this chance to tell you a little about how the process works on the CLR team. 

Once the issue is opened, there’s a first level of screening just to figure out which team it should be sent to.  It usually ends up assigned to someone in the product within a few days.  If the initial assignment was incorrect, though, it could take a couple more days to get it to the right person.

If the issue is a code defect, we treat it like any other product bug.  We make sure it’s reproducible and not by design and something we can fix for the current release depending on where we are in the product cycle.  We don’t necessarily do this right away, though.  There are times in our product cycle when we’re more focused on bugs than others, and the bar gets higher toward the end of the release when all changes are riskier.  Any change can introduce regressions in compatibility, performance, or behavior, and taking changes toward the end gives us less time for stabilization.  We might not be as good about delivering status updates on Connect as we could be, but we do try to comment on each issue.

When deciding whether to fix a bug, there are several criteria we look at.  One of them is whether anyone might have taken a hard dependency on the existing behavior.  We don’t want to solve one problem but end up with a bunch of customers whose applications no longer work after upgrading to the newest version or applying the latest patch.  There are occasionally security reasons to make breaking changes, but we try to avoid them when we can.  We also look at things like how hard it is to work around the bug and how many votes there are on the issue.  The severity of the issue also affects the priority: Is this a bug that will crash your machine, or is it just a minor annoyance? 

Another thing we look at when deciding to fix a bug is how many people are likely impacted.  If you find a new bug in an older product, like .NET 2.0 that’s been out for 5 years and used by hundreds of thousands of developers, you might be one of only a few people who is impacted by that bug.  But if you file a bug on a newer product, like .NET 4, that’s has just been released, there’s a good chance that hundreds or even thousands of people are impacted.  Because of this, we take bugs on products in Beta, or that have just been released, particularly seriously. 

Once we do decide to fix a bug, we have to decide where to fix it.  Our default answer is generally to fix it in the next major or service pack release (which is usually the one we’re working on at the time).  Only fixes for particularly severe bugs might be included in an update to an existing release.  If you are blocked on a bug for an existing release that’s been out for longer, e.g. .NET 2.0, and you need a fix, Connect is not the place to file a bug.  You should be contacting Microsoft customer support to request a QFE.

We tend to get a high number of suggestions, both from Connect and other sources, and we don’t always get a chance to look at them and respond right away.  But we do look at all the suggestions that come in on Connect.  When suggestions come in, we consider whether it’s something we might do in this release or a future release.  We also check to see if it’s a duplicate of an existing suggestion

Aside: please search before you file.  One suggestion with 20 votes has more impact than 20 suggestions with 1 vote.  You can sort by number of votes on the site, and that helps us focus our attention when it comes to suggestions.  For example, we recently fixed a SerialPort issue and a serialization issue that had a high number of votes.

We try to close issues if there isn’t a chance we’d ever do them, but we leave ones we might consider open so that the community has a chance to vote and comment on them.  Again, these can go for a while without comment, until we get to a point where we can act on them.  However, we do have a mechanism to be alerted when someone comments on an issue.  It’s opt-in, so it may not be universally used, but it may get someone’s attention.  If suggestions come in while we’re working on a release and already have plans, it’s less likely we’ll be able to implement anything large for that release.

One thing that really helps us with suggestions is when the poster or commenter includes details on what problem this would help them solve.  With a lot of suggestions, people jump straight to the suggested solution.  You may think this is a shortcut for us, but it’s not always.  We see those and realize that maybe we could do that, but don’t necessarily know why we should.  What would you be able to do if you had this that you can’t do now?  Often there are several ways to solve a problem (at least).  If we know what you’re trying to accomplish, it helps us measure whether our solution really met the goal.  Or if we see lots of customers with similar problems, we might be able to come up with a slightly different solution that meets lots of needs.  And it’s a lot easier to reason about that from the problem descriptions than from the often-diverse solution descriptions.

If you’re wondering about the kinds of suggestions we’ve acted on, in .NET 4 we took suggestions ranging from new numeric types to adding single APIs or overloads that helped customers out.

For those of you wondering when we’ll get to these suggestions, the answer is now.  With work on .NET Framework 4 coming to an end, we’re starting to look at the open suggestions in more detail.  Through May we’ll be trying to close ones we don’t think we’ll be able to do in our next cycle.  We’ll also be trying to work through any bugs that might still be open.  The fact that a suggestion is still open in June doesn’t mean you’ll necessarily be seeing it any time soon, but only that we’ll take the time to look into it more closely. 

If you’ve been thinking about voting or commenting on a suggestion, or opening a new one, now would be a good time.  If we close one that you feel passionately is more important than some of that other stuff we’ve left open, let us know that, too.