A first hand look from the .NET engineering teams
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.
Can you talk a bit about why it took 4 years to fix the SerialPort issue you mentioned? I noticed that it was filed on 6/19/2006. Can we conclude from your discussion that issues with a high number of votes (32 in this case) will be fixed in approximately 4 years?
oh and one more
Allow to unload assemblies
140 votes, 18 Aug 2004, Active, Last action by MS 23 Aug 2004
But according to the Connect web site you didn't fixed the SerialPort bug, it says closed (by design)!
favourite connect bugs (most from Ayende)
TypeConverter for value types (such as int, bool, short, etc.) return true to IsValid, even if the value is not valid
152 votes, Feb 2005, "active"
Allowing Expression<T> in attributes parameters.
31 votes, Jan 2007, "closed as wont fix"
Cannot create/shadow copy 'VariousFileName' when that file already exists.
60 votes, 55 users can reproduce, oct 2006, "Resolved as Won't Fix"
Getting a ObjectDisposedException in a TransactionCompleted when TransactionScope
8 votes, Aug 2008, "Resolved as External" with no explaination
Give .NET Windows Forms the MFC 7 look with the Tahoma font as default
82 votes, Jul 2004, "Closed as Postponed"
Deleting a LINQ to SQL EntitySet Member in a Bound DataGridView Orphans Table Records
7 votes, closed as by design after 7 months
Change to LINQ to SQL EntitySet Member Doesn't Mark Root Object Dirty
3 votes, Sep 2007, "closed as by design"
LINQ to SQL's GetOriginalEntityState Doesn't Include EntitySet or Entity Ref Data for Related Entities
2 votes, Oct 2007, "Closed as by design" after 13 months
Debugger crash VS when method called to runtimed generated type (RefLection Emit) that has generics
6 month later "sable to reproduce and then responded with
"Very sorry for not getting back to you on your last comment till now. Unfortauntely the Connect system just tracks fixes for our next product releases."
You're bound to cop a bit of flak when you mention the 'C' word, but I'm afraid I'm going to have to chime in.
If Microsoft really valued customer feedback, they'd damn Connect to an eternal hell full of demons and Simon Cowells, and replace it with something that doesn't induce suicidal urges in its users. The few times I've used it have been so incredibly frustrating that I never want to go near it again. It is an abomination.
Sorry but the SerialPort issue seem still Closed by design and not resolved as of today (after months of .Net 4 beta/RC releases)
If 4 years to solve an issue and no comment or informations about solving it is considered a "focus" of your "attention" well i don't really want to have an issue that isn't a focus it will never ever be solved.
And yes i'm one of the 32 that voted on it !
Firstly, SerialPort. It took longer for us to notice that issue despite the high number of votes because it was resolved early on as By Design, before getting so many comments and votes. Once an issue is resolved, we generally don't track it unless someone has registered for update notifications. As for the current status, it is fixed in .NET 4. There were several bugs tracking that issue (or similar issues), and we didn't go back to re-resolve duplicate issues. I'm sorry I didn't check the public status on that one before linking it. I was just querying for the one with the high vote count.
Now for specific issues mentioned.
93559: This isn't actually a CLR bug, but it looks like it's been fixed (see the comments).
254057: The comments say it's a special case of 425856. Please use that issue to track this. You can add comments detailing your specific scenario.
The other ones mentioned aren't CLR issues (remember this was scoped to the CLR's Connect process), so I can't comment on why they were resolved the way they were.
For some CLR issues resolved as External, we used to use this resolution when we moved something reported as a bug to our feature tracking database, and weren't always good at commenting on the bug.
Kent, I'm sorry it's so frustrating for you. I don't know if there are any specific things we could try to improve, but feel free to mention them if there are. We don't control the whole Connect infrastructure, but we can pass suggestions along.