Freigeben über

Visual Web Developer team and the feedback you file at MSDN Feedback center

  • Artikel

What are we doing with the feedback you have been filing on MSDN Feedback site? We have been getting together regularly at triage meetings to look at the feedback and process bug reports and suggestions. Triage meeting typically involves program manager, development lead or development manager (yours truly) and a QA person. It is important to have all three to have balanced view on the subject and correctly estimate impact of the bug, impact of the code change, cost of implementing and testing a feature, complexity of a change, etc.

We just finished first milestone of the Orcas cycle. First milestone is very important as after it we typically know what we can and cannot do in this cycle and. So we are going through bug reports, suggestions, feature requests and you can see reports resolved in one way or another. I’d like to explain a bit what each of the resolution means.

First, we classify the report. Typically report either describes a product bug or is a feature requests. Sometimes you may be perceiving issue as a product bug, but in fact it might be a missing feature. For example, Visual Web Developer Design view only works with single-nested master pages while intelligence in Source view is able to handle arbitrarily nested master pages. This is not a bug, this is result of a design decision which we made back in the Whidbey cycle to tame complexity, lower development cost and keep project on schedule and on track.

We classify issue as a bug when something that is supposed to work does not work. We wanted it to work, but missed the case in testing and ended up shipping product with a bug.  There are bugs reports filed by you, Watson reports submitted on product crashes or hangs, issues filed by internal test teams, internal and external partners, by customer reports through PSS, etc.

Then there are feature requests.  Feature requests typically do not go into service packs with the exception of very high profile issues such as requests filed by multiple customers, problems for which we had to issue patches, or when we completely missed popular user scenarios. Examples of design changes that went into the planned VS 2005 service pack from our team are performance improvements in refactoring and Web Application Projects.  The reason that service packs do not typically include new features is to limit amount of regressions, tame cost of testing and reduce time that it takes to release a service pack.
Therefore we first separate feature requests and suggestions from bug reports. Let’s talk about suggestions and feature requests first.

Feature requests and suggestions

We look at how popular is the request, how expensive would it be to implement the new functionality, if the work fits into improvements we have been planning for Orcas so far and if the work is in line with the overall product vision for the next release. We do not resolve features as postponed anymore. We stick to three resolutions: Won’t Fix, Duplicate and External. Won’t Fix means the suggestion will not go into Orcas. It may go into post Orcas release though. Duplicate means there is already a similar request filed by someone. Our team tends not to use Duplicate resolution for issues filed by customers since you may not be able to see primary item and may not be able to tell whatever happened to it. External means the issue is already included in the development schedule which is being tracked in a different database. Please note that although feature request may be in the development schedule, this does not automatically guarantee that it will be implemented and even if it does get implemented that it will look exactly the way you requested it. Schedule may changes, development cost may become too high, higher priority issues may show up, there may be unforeseen architectural limitations, we may have to change behavior to be consistent with similar existing features, etc. Large projects have very many variables so we hope you understand. We are not keeping issues active until feature is implemented since keeping reports active makes it difficult to track what needs to be looked at, what we have already looked at, what we are going to implement and what we are not going to work on at least this time around.

Bugs

We classify bugs by impact, number of votes, number of related issues, how common is the scenario and if there is a reasonable workaround. Some issues may have low number of votes on MSDN Feedback site, but there are may be other bugs in the same area filed by internal testers and/or there may be other reports in the MSDN Feedback database that may look different at a first glance but really describe the same problem. Bug resolutions are By Design, Won’t Fix, Duplicate, External or Fixed. By Design means that product works as expected, feature exists or there is a slightly different way of achieving the same goal. Won’t Fix means that although the issue may be considered as a defect, it has low impact, there is a reasonable workaround, the issue is cosmetic (such as wording of an error message), etc. Duplicate and External have the same meaning as in suggestions.  Fixed is self explanatory, although there may or may not be note if the fix is included in a service pack. Some fixes do get included and some with lower impact or those that required high risk code change, may not. If bug is fixed, corresponding code change will at least be included in the next product release.

If you are looking at Orcas CTP builds, you may notice that although bug may be resolved as Fixed or External, it may still repro in the CTP. This is because the change may not have been integrated into the product main branch yet. Visual Studio teams are working in private branches and only complete features which pass certain amount of testing and that meet division quality bar are integrated into the mainline. Therefore bug may be resolved as fixed, but the change is still sitting in a private branch. It is expensive to integrate changes one by one, so most teams perform integrations in batches or may decide to fix a bug later when someone will be working on improvements in this area.

Comments