Hannes Preishuber

# re: Whidbey Development process from outside: no changes accepted

Well, sad enough something like this form ever made it through quality control. I mean, you are totally right in your assessment that this functionality is core.

If this is true (have to check): "the changed entrys in the list are not sorted", then we could actually say the current design is retarded at best. I mean, showing a change list, unable to sort and not having it sorted means it is only usefull in toy scenarios. Once you ahve 300 items on the list, how the heck are you supposed to easily fine a particular one. AT LEAST the list should be sorted.

::I think a list without this function is bug
::and i would never give a customer a project
::with a missing function like that.

I agree here. I tend to put these in as major bugs, simply because they are SO fundamental. The application looks bad and like done by a non-pro with this.

# re: Whidbey Development process from outside: no changes accepted

I agree. Ridiculous unless we're mssing something. If we are, just as big a problem.

# re: Whidbey Development process from outside: no changes accepted

Hannes, having done UI features myself a few years ago, I thought I'd respond with a few thoughts on why a bug like this was postponed. Not knowing what the requirements were when copy web wizard was first spec'd and written, I won't argue with your rationale about implementing sort with the file list.

I do want to help you see why what seems like a 'quick' UI change would be postponed. We're not experiencing any unusual schedule problems as you speculate but rather, we take a disciplined approach toward any new functionality as we prepare for the RC and RTM milestones. As such, the bar is very high for new features and feature changes so we only take a handful of them (aka DCRs). The priority is to fix bugs that will block deployments or will cause pain/frustration to customers. This 'bar' will keep rising as we approach the end of this milestone. Even now, we need to hold down changes so we can build a product that will hold up to extensive testing we'll do. So, looking at the priority for this bug, I'd agree that it would be very useful to know which files changed but the lack of that information/presentation wouldn't negatively affect my work.

Another consideration is the impact of a UI change. UI tends to lock down very early. I always used to get asked - why can we just add a check box for X? UI is problematic because any such change means we have to make corresponding changes or additions to the test harnesses. We also may need to consider localization impact (e.g., how to implement/test sort order for different cultures). Also, docs are already in final stages so do we need to update the docs and screenshots, etc.? So all of these things can mean a high cost of a UI change.

Finally, is the change in a core feature of the product or is it on the periphery? How often is it used and how many people use it? This isn't in the core of VS but I'd say that copying is a fairly widely used feature so it's a tossup - the feature team might have more to say about it.

From now on, we're very very selective about the bugs we'll take. The kind of bugs we'd really like to see coming from the MSDN Product Feedback center right now are ones with solid, clearly written repros that we can follow and reproduce ourselves, bugs that are significant usage blockers or broken features, and 'fit and finish' bugs that help to create a better overall experience that can also be done within the project constraints. We'll still take suggestions for improvements to a feature or new features you'd like to see but the majority of those will be considered in the next major release.

I hope this gives you a better idea of the processes we follow to develop the product and why we make the decisions we do. I'm also hoping that we can post more information to customers on the front page of the Product Feedback Center about where we currently are in the product cycle and what that means in terms of decisions we make and how to help us with your bug submissions.

# re: Whidbey Development process from outside: no changes accepted

Hi Hannes, I wanted to explain further on the the "postponed" resolution for the issue you mention in this post.

Unfortunately, the ability to sort on different columns wasn't part of the design of the copy web window. I completely agree with your suggestion that this would be a very useful feature to add to the tool.

However, given where we are with Whidbey, our schedule does not permit the ability to add this new feature to the product without impacting our schedule negatively.

As Richard mentions, we are being very particular in the issues we fix and are focusing mostly on bugs at this stage.

Hope this helps provide some more context on the reasoning behind the postponement.

Omar Khan
Web Platform and Tools Team
Microsoft

# re: Whidbey Development process from outside: no changes accepted

Thanks to the Omar and Richard to give feedback.
I understand how to handle changes in late period (drop it)
Remark: i have seen this issue in very early builds and dont expected that this will be till final. So i didnt reported it in prodcut feedback center.