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