Description

One of the questions we often get is "how can I know whether or not Microsoft is listening to my Visual Studio 2005 bug reports?"

Thanks to MSDN's new Product Feedback Center
you can search through existing bug reports, report new bugs, and also track what Microsoft does with those bug reports. By the way, the team's code-name for this center was "Ladybug."

This is what happens when Microsoft spends $7 Billion on R & D per year, hires legends in the industry into R & D, and still has crappy products. What is even funnier is the fact your R & D could not invent a browser from scratch, you had to steal one from
a University and you do not understand it's code. It's like you took the first person you saw for a spouse, have relations with them, but still can't figure out why the sex isn't great? It is because you do not get to REALLY know them. You just use and abuse.

Somehow I have a feeling this feedback center may have trouble scaling up and stay useful if there is going to be a lot of people using it.

Some ideas which could be used in future bug feedback.

Have the client run a some "watcher" app which records changes to memory state and can playback visually the session of (using VS express for example). Then when something (bug) occurs, you just press some key, it takes a screenshot, shows a list of bugs reported
which had same actions occuring before the bug occured - if its a new bug, it asks details etc and then sends the memory/action trace and screenshot with your report.. Like taking Watson to the 2nd level. Oh well, I guess this might make the non-dual/HT machines
crawl.. Pity AMD 64/Athlon users.

One part of your demo seemed a little fishy to me: when you first searched for problems with code behind in ASP.Net, it turned up nothing. But then you were immediately prompted to search for a duplicate bug (seems like you're forcing the user to repeat
a search he may have already done) -- only to find that a bug DID show up. Why did it come up the second time and not the first?

We are particularly interested in how the UI will work when we have a bigger data set. for example, right now, searching for a bug before you submit doesn't seem onerous because the result set is pretty small and easy to scan through. What happens when
the result set has 50 issues, or more?

I do like your suggestion for a watcher/crawler app. We've talked about doing something similar to pre-populate the version and config fields,but it didn't make the list for v1. but your comment goes beyond what we were thinking. you should submit it.

Hi KSwartz, you noticed a bug! We have a search bug that we'll be deploying a fix for, real soon now. The submission UI forces you through a search, so it's not really necessary to search first if you're planning on submitting a bug or suggestion because
as you noticed, you'll have to search in the process. Thanks for your feedback!