The Visual Studio 2005 Betas were the first fully public betas with completely public customer feedback at Microsoft. We received roughly 18,000 bug reports and about 8,500 suggestions. We made some tough calls during the Whidbey end-game and had to postpone some customer bugs.

 

Now that teams are starting to plan for the next version of Visual Studio, we’re reconsidering all the postponed issues from the VS 2005 Beta. We’re reopening all the postponed bugs and will be reresolving them over the course of the next few months.

 

While we expect that we will be able to fix many of these bugs, we do not expect to fix all of them.  Bugs that were postponed very late in the release cycle, or shortly before a milestone release (e.g. beta2) stand a greater chance of being fixed.  Bugs that would require a fix that may break applications or run a very significant risk of destabilization will probably not be fixed.  

 

One internal change we are driving is asking people to be honest and decisive in their resolution.  If a bug should ever be fixed, fix it now.  If the bug does not need to be fixed, resolve it as “won’t fix” instead of postponing it.  We sometimes take the easy way out – “I feel bad about not fixing this, so I’ll postpone it and maybe some day we’ll have more time/people and it will get fixed”.  The problem with that approach is that we falsely raise expectations (the “some day” rarely ever comes) and we – and now customers – revisit the bug again and again, wasting time.

 

If we resolve something “won’t fix” and get very strong feedback that it’s the wrong decision, we will revisit it.  We welcome your feedback as we work through this. 

 

Thanks,
Marie Hagman

Program Manager

Visual Studio