MSDN Feedback Bug Prioritization

MSDN Feedback Bug Prioritization

  • Comments 14

During the past few months, the Visual C++ team allocated many of its development resources towards addressing bugs submitted through the MSDN Feedback Center.  In fact, almost 90% of these bugs were fixed and will ship as part of Visual Studio 2005 Service Pack 1 (also known as SP1).  Our goal is to be the best provider of development tools and your use of the MSDN Feedback Center has been instrumental to that end. 

 

The MSDN Feedback Center has also been beneficial in driving product strategy.  In analyzing bug submissions, we realized that a significant number of these issues resulted from architectural limitations in some of our older pieces of technology.  Historically, our approach has been to apply point fixes to these fragile subsystems.  After careful review, however, we have decided to take on the task of updating these systems with a modern architecture.  The result should be not only better quality, but faster performance and higher productivity as well.  

 

Since this approach addresses entire categories of bugs, we have chosen to limit some of the fixes we make to these subsystems.  Instead of continuing to patch old code, we will dedicate resources towards implementing the new architecture.  We believe this represents an investment that will yield significant benefits for customers in the long term.   Understand that this does not mean we will ignore MSDN Feedback Center submissions nor that you should stop reporting bugs.  In fact, we have recently created a team focused on resolving serious customer issues.  It does mean, however, that we will establish a clear set of guidelines for approving both customer and internally reported issues.  By adopting this approach, we can make progress on a modern design while addressing the most severe problems.  

 

To help you understand this process, and optimize your MSDN Feedback Center submissions, we are providing a set of submission guidelines.  These guidelines are designed to help the dedicated servicing staff quickly prioritize issues and generate fixes that benefit the largest number of customers.  Of course, you can always use the MSDN forums to collaborate with Microsoft developers, MVPs and beta testers to identify problems and workarounds.

 

Bug Submission Guidelines

    You can view the bug submission guidelines here. 

Again, thank you for the valuable feedback.  Through the MSDN Feedback Center, you have provided us with a better understanding of the issues faced when using Visual C++.  More importantly, your feedback has helped highlight key feature areas where we need to modernize.  By providing insight into our development plans we hope to continue the dialog established through the MSDN Feedback Center and build a great future for Visual C++.

 

Sincerely,

The Visual C++ Team

 

  • The VC++ team blog has a message regarding how MSDN Product Feedback Center bug reports will be addressed...
  • As long as intellisense drops cpu usage after loading a solution...and I don't have a huge C++ solution.

    When is sp1 due?
  • See http://msdn.microsoft.com/vstudio/support/servicing/sp1_vs05/default.aspx for details on SP1.

    Thanks,
    VC++ Team
  • We issued related fixes (QFEs) for similar issues. These fixes are available for immediate download and deployment by calling product support. Of course, they will be included in SP1 as well.
    There are two QFEs to mention. One is VS QFE 4082 (KB 916769) and VS QFE 3991 (KB 913377). The first one lowers the Intellisense thread priority and the second fixes a common case of infinite parsing.

    Thanks,
    Tarek Madkour & Boris Jabes
  • How are you going to tell whether some code is real-world code?  My submissions have been carefully crafted to isolate the problem and not to leak any project-relevant information.
  • Hi yecril,

    When evaluating a bug in a triage process, we typically look at the scenario that will reproduce a bug. It's rare that we actually have a repro case that matches the original source code, nor would we want the original code. Simplified test cases are far easier at targeting the real issue and avoid hours of configuring a machine and environment.

    The scenario description is the most relevant thing to the triage team. Through that, we can determine what the developer is trying to accomplish. If there are clear architectural alterntatives, we may choose to not fix the bug. If the test case is designed to exercise a corner case, or simply goes beyond the supported expectations of the compiler, we will not fix the issue.

    In the absence of a scenario description, we do our best to compare the issue to other code that we have seen via bug reports, public libraries, and other source bases.

    I hope that makes sense,
    Brandon Bray
  • Reader Norm vents some frustration about the VC++ bug fixing policy expressed on the VC++ team blog:...
  • Hi folks,

    I'm very disappointed the way you resolve issues at ProductFeedback.

    At this page there are at least 6 categories why you will not consider a fix. Users have no idea on thich category their report fail into.

    I can understand that you have limited resources and unable to address all bugs in code.
    But can you spend more time giving answer on EACH report on how to workaround issues they see, alternative aproachhes or detailed reasons why it's not possible to address it.

    If you will not do this - I will be not be interested to report any new issues as this will give me no value (only link to this posting).

    Thanks in advance
  • Hi TAG,

    As written in the guidelines, we described issues that we are capable of fixing. Issues reported that fall outside of the guidelines are the ones that are not fixed.

    Going forward, you should expect to see more detail in the report. The guidelines here were crafted after review of the many bugs we are managing to closure, so they should represent active bugs that we are working towards fixing. Our forums are much better equipped at providing the necessary work arounds.

    If you find that our triage guidelines are not providing useful evaluation of bugs you filed, I encourage you to help us create a good set of triage guidelines. Rather than simply providing detail in every bug report, it will be far more valuable to develop these guidelines with more detail. It is rare that a bug falls into an ambiguous area of a triage guideline, so when that does happen, please let us know how the triage guideline can be improved.

    Thanks!
    Brandon Bray
  • Hi Brandon,

    Just take a look on how it must NOT be done:
    Classical - so long reply with no usefull information
    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=FDBK50493
    FDBK50388
    FDBK50330
    FDBK50222
    FDBK50207
    FDBK49628
    or here little bit shorter FDBK50806
    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=FDBK50258
    FDBK50779
    FDBK50744
    FDBK50663
    FDBK50453
    FDBK50391
    FDBK50390
    FDBK50375
    FDBK50188
    FDBK50031
    FDBK49978
    FDBK49965
    FDBK49944
    FDBK49638

    You can provide at least some comments like here
    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=FDBK50615
    FDBK50526
    FDBK50431

    Regarding triage guidelines - I'm not Microsoft Product Manager (yet) - and I believe that Microsoft capable to address my complain using internal resources.

    Thanks in advance7
  • Hi TAG,

    The lack of feedback in many of the recently resolved bugs is an unfortunate result of the fact that we were forced to "bulk" resolve a large backlog of bugs that didn't meet the requirements we detailed in this blog entry.  To reply thoughtfully and individually to each bug report would have taken at least a couple of person-months of effort.  While it would have been a much more friendly way to do things, such a use of resources would have impacted our ability to deliver on Orcas.  We therefore had to make the tough, but IMO correct call, to bulk resolve the bugs.

    Going forward, you should expect to see more detail in the bug reports.

    Thanks,

    Steve Teixeira
    Group Program Manager
    Visual C++
  • VS2005 New Project wizard does not work with IE7.  I get a script error and the browser window never opens when trying to create a Smart Device MFC Application.  I will go back to IE6, but thought you should know about this.
  • about the IE7 bug, maybe you should report it via the feedback center?

  • hi guys...

    i m newbie in vc++ world...

    plz help me...

    how can i learn vc++ asap..

    i hav sound knwldge of c/c++...

Page 1 of 1 (14 items)