During the summer, we refreshed the experience for sending feedback on Visual Studio. It marks the first in a long row of changes coming to the Visual Studio feedback system. The result will be a more engaging experience that is also faster and more user friendly.

The feedback tool helps us fix more than five hundred customer-reported bugs and feature suggestions in each update of Visual Studio. It’s an important part of our development process, and now it’s time for an overhaul.
Over the years, we’ve collected feedback on the feedback system from both Visual Studio customers and from our engineers who investigate the customer feedback. This has given us a great starting point with a good understanding of what worked well and what didn’t work so well.
For practical reasons, we started by moving the reporting tool to a browser-based implementation. You still send us feedback using the same commands under the Help top-level menu inside Visual Studio. Clicking Report a Problem… or Suggest a Feature… will now open your default browser to the feedback tool.

Moving the feedback tool out from being a modal dialog inside Visual Studio to be browser based has some benefits. Since it’s in your default browser, your normal browser workflow of copy/pasting, searching, using extensions, keyboard shortcuts etc. stays intact when filling out the bug report.
Also, the modal could sometimes cause problems when recording traces and taking screenshots as part of reporting a bug. With the modal dialog now gone, this is no longer an issue. Finally, the browser experience will allow us to innovate more rapidly without dependencies on the Visual Studio release schedule.
Streamlined flow
The previous feedback flow consisted of multiple wizard steps. That made it challenging to know exactly what information to give and how long it would take to finish the bug report. The new tool keeps it all on a single page, making it clear what to fill in.

When writing the description, you can take full advantage of markdown to make it as clear as possible. A new impact selection dropdown helps the Visual Studio engineering team better understand the nature of a bug, which will help them fix it.
Async recording
Recording traces is one of the most helpful things in a bug report, because it gives the engineering team a much clearer picture of where the issue occurs in the code. We updated the process of recording to happen completely asynchronous so that you don’t have to wait for the recorded traces to finish before you can submit the bug report. It will automatically upload those traces in the background after you submit – even if you close the browser.
This feature is almost complete and ships very soon.
My Feedback
To follow up on your problem reports and feature suggestion, go to the new My Feedback page. Access it from within Visual Studio from Help -> Send Feedback -> My Feedback… or from the browser after you reported a problem or suggested a feature.

From My Feedback you can quickly check the status of your tickets or, if we have sent the issue back to you, provide extra diagnostics information to help us investigate the issue.
First of many updates
We started by updating the reporting flow, but we have many more updates to come in a wave of new features, tweaks, and redesigns. Customer suggestions drove many design decisions and we’ve been able to complete a high number of them with this first change. In the months to come, we’ll be able to complete a lot more as we start rolling out more updates. In the end, you’ll experience a faster and more user-friendly system that is more engaging to use.
If you have any ideas for improvements, please let us know in the comments below or on Developer Community.
Hi,
I strongly agree to the other comments:
It's not the feedback system itself that needs overhauling - it's the attitude of certain teams and the way how they are misusing the feedback system to keep their statistics looking good. I had made pretty mixed experiences. In rare cases even high quality responses in a timely manner.
What's not acceptable IMO is that
- Sometimes, employees are hiding themselves by letting status decisions appear as being made by the "Feedback Bot", even though, it's obviously a human's decision
- Reported issues are marked as "duplicate" of issues that are already closed
-...
Please give lots of love to the Developer Commuity. It's a very disappointing experience.
- Ctrl-Z undos more than one would expect, sometimes full paragraphs
- Ctrl-Y doesn't always redo
- Ctrl-K doesn't add a link, like in most editors
- The service reps aren't as educated or helpful as they need to be
- Search isn't great
- There are often multiple threads reporting the same issue, but they are all marked as "Not enough information" or "Low priority"
- Issues are closed as stale, while the users were waiting for the reps to respond
- Issues can be closed...
I agree with Dan
Hey @Mads Kristensen do you have seen how many comments about the real USABILITY of the site?
It’s years that someone puts comments like these in DevCommunity (I surely) but no one have followed they.
I hope that the comments in this page can stimulate per boss of the DevCommunity to wake-up him to listen people that works every day dvelopping code for the real-world and have a great real-world ideas.
Someone known who’s the BOSS of Developer Community?
Thanks for your comment, Dan. We’ll make sure to give the Developer Community a lot of love.
The issues about closing as stale or low priority, no voting on closed tickets, and duplicates that doesn’t consolidate votes are all issues we’re looking into addressing. We’ve already taken several measures with more to come soon. I’ll write more about what we’re doing in these areas in a different blog post.
Have you taken into account that the developers using your product have an actual job, other than providing you with free QA services, and don’t have time to browse various tickets looking for related issues to upvote. Just dealing with the issues themselves takes more of our time than we actually have.
I like the new browser-based Feedback with a hook into Visual Studio. Very nice, thanks! Is there also an official word on the policies governing these “ideas?” For example, it used to be that you closed them when they didn’t make it onto the Roadmap for a given release, even if they were quite popular. I believe I saw you mention somewhere that this policy has changed? I totally agree with this BTW. Good ideas are good ideas. Can we resurrect some of the previously closed “good ideas” above a certain threshold of upvotes perhaps?
Thanks for the kind words on the new browser-based tool. While it is true that we used to close ideas that we couldn’t get to in the short term, we no longer have such a policy. We’re even making it possible to request re-activation of closed feedback tickets and that you can continue voting on closed tickets. Recently, we published guidelines that includes how we handle incoming feedback.
so many genuine feedbacks and suggestions are still hanging without any sort of proper attention/response. In VS2019 so many new useless features are being added in every release and at the same time, some core burning issues are being overlooked. Such ignorance is demotivating us to report prob or give feedback/suggestions. one such example is the VS2019 new project dialog box. How long will it take to provide an option to switch to the old or new dialog and use VS telemetry to know how many developers are really using the new dialog? Why forcing something which the majority dislike...