New experience for sending us your feedback

Mads Kristensen

We’ve been working to improve the Developer Community for providing feedback about Visual Studio. Last summer, we updated to a more flexible browser-based mechanism for sending feedback. Now we’re upgrading the rest of the Developer Community website. We’ve listened to your feedback and addressed almost half of all feature requests for Developer Community made over the years. The result makes it easier to browse existing tickets, gives you more transparency into the states and processes, improves interactions with the engineering teams, significant performance improvements, and a lot more.

Let’s take a tour of the new website!

Report a problem and feature request

The new browser-based feedback tool takes error reporting to the next level with new features and improved performance. The one-page flow makes it easy to provide the relevant information for the engineering team to take swift action.

Report a problem on Developer Community

You’re automatically logged in to the website with the same Microsoft Account used inside Visual Studio.

The editor allows GitHub-flavored markdown and insertion of images by either direct paste from clipboard or drag and drop from the desktop. This makes it easier to give detailed explanations and for the engineering teams to propose new feature designs and request community feedback. This addresses feature requests #973744, #402573, and #833889.

You can easily take and retake screenshots, upload additional log files, and even record a full trace of the error as it happens. And if you need extra time to finish the reporting, a draft is automatically created so you don’t lose any data if you navigate away.

Front page

On the front page when you are signed in, you can see the status of the current tickets in the system. At a glance, you can see all your fixed issues and suggestions implemented in the latest update to Visual Studio. From there you can drill down for more details and look at previous versions too.

The front page of the Developer Community

When you are signed in, the front page is also where you can see the problems and feature requests you follow. If the Visual Studio engineering team has requested more information from you, those requests will feature here as well.

Explore existing feedback

Another highly requested feature is to make it easy to explore and browse existing feedback tickets. From the Explore Feedback page you can now see the top tickets and filter on many different properties. Want to see the highest voted for feature requests for the debugger? No problem. A few clicks and you are exploring the tickets most interesting to you. This addresses feature requests #774869, and #533842, with #362457 moved to the roadmap.

Search exiting Visual Studio feedback

Details page

When you click a ticket, you can now clearly see the history of which states it’s been in and where it is in the process to completion. Any ticket that is implemented now clearly shows which release of Visual Studio included it. This addresses feature request #439404 and #637301, with #362522 on the roadmap.

Updated details page on Developer Community

We also updated the commenting system with full markdown support for richer comments. Want to add a picture? No problem, either paste it from the clipboard or drag and drop it from the desktop.

Showing full GitHub markdown flavor support

We also added other improvements such as anchors to easily deep link to a specific comment, @mentions, and more customizable avatar pictures. This addresses feature requests #570754, #486817, and #594491.

For problem reports, it is now easy to distinguish regular comments from proposed solutions, which makes it much easier to see the right solution.

Activity timeline view showing both solutions and comments

The road ahead

There are lots of other improvements we are planning for, such as better search and deeper Visual Studio integration. However, there are some limits in our current backend infrastructure that we need to resolve before we tackle search and other features. Stay tuned for more information as we continue this journey and please keep the feedback coming.

A special thanks goes out to Mike DePouw, Yann Duran, and many other members of the community who’s input and feedback have been invaluable.


Discussion is closed. Login to edit/delete existing comments.

  • MgSam 0

    This is great, Mads. Thanks.

    Though I do feel like you guys should just migrate the entire thing to Github anyway. I assume by now your internal work items are Github issues in a private repo? Why not just make a corresponding public repo for bugs/issues like Microsoft’s other stuff.

    • Vaclav Elias 0

      I think it will happen eventually once GitHub UI is changed so it could accomodate similar UI from this new experience?

    • Mads KristensenMicrosoft employee 0

      There are several reasons why we use a custom front-end for Developer Community. One is that is allows for private sharing of log files and bug reports. The new front-end is designed to be flexible and somewhat agnostic as to what backend stores each ticket, so it could work on top of a GitHub repo in the future if that becomes beneficial.

  • Dean Jackson 0

    The last comment/activity date is missing when showing the list of tickets. I use this a lot to avoid navigating into the detail of that ticket, when I can see there’s no new activity since I last looked at it.

    • Mads KristensenMicrosoft employee 0

      That’s great feedback. Thank you for sharing.

      I’ve opened a feature request for it, so please go ahead and vote for it.

  • Vaclav Elias 0

    I like it but in my opinion

    1) the top up/down vote buttons are small/tiny 12×22 on the Details page.
    – the finger up/down are better 16×22

    2) I would reorder or have an option to see the most recent entries on the top

    3) I have to scrooooooooooooooooooooooool to the bottom to Add comment :), like in UserVote it is more user friendly to have it on the top?

    • Mads KristensenMicrosoft employee 0

      1) We’ll take a look, thanks for the heads up!

      2) Me too! Please go vote for the feature request here

      3) If you don’t read the comments then you might miss some important context. I understand it’s easier to comment when it’s at the top, but do you think it adds value to the conversation on each ticket if people don’t read the timeline before commenting?

      • Vaclav Elias 0

        1) Thank you 🙂

        2) Done

        3) If it is a conversation then it should be read, I do agree. If it is just your opinion/feedback/reasoning then not necessarily? Anyway, I am up to whatever works 🙂

  • Neil MacMullen 0

    This looks very nice. From my perspective though the biggest problem with the previous feedback system was that the triage process too often seemed to take the approach of closing an issue unless it either came with a slam-dunk repro case and/or picked up 100 votes from other users within the requisite 30 days. Perhaps the new tool will help with the vote-count issue by improving discoverability for other users? I think we all understand that the VS team has limited bandwidth and most of it is pre-booked for shiny new features (I like them too!) but it would be nice if the tooling change also went along with a slight change of culture to emphasise that sometimes “observations” by users can be worth looking into.

    • Mike Diack 0

      I totally agree, Neil. I’ve emailed various members of Microsoft’s management about this, including Mads. The problem with the feedback system, is largely NOT a technical one, it’s been an attitude problem amongst the staff:

      – Not making even the simplest attempt to repro the problem (even when sample code is attached).
      – Not understanding that fixing bugs in earlier (but still supported) releases is important – we can’t all move to the latest compiler at the drop of a hat, bugfixes need to be backported more often than the MS team seem to appreciate, for real world usage.
      – Keenness to close problems before the fix has been verified by users.
      – Simple laziness (“try the latest release” or “the fix is in the latest release” – a moving target), rather than documenting exactly which version/build introduced the fix.
      – The voting system is ridiculous. If a bug is a bug (e.g. causes a crash or a hang), it should be prioritised irrespective of any voting.

      • Kirsan 0


        • Mike-E 0

          *2. 😁

          My beef is that the team there will immediately look to see if ReSharper is used and completely dismiss the ticket saying it’s JetBrains fault, without actually looking at the issue. Great example of this here:

          • Mike-E 0

            I ended up having to post this issue 3 full times to get it resolved. Turns out it was a legitimate issue with the Razor tooling which is now slated to be fixed in 16.9 preview 4:


            It’s frustrating enough to run into constant churn with your product, but exponentially so when you don’t even bother to look into issues reported by your users and/or flippantly dismiss them “because JetBrains.”

      • Vaclav Elias 0

        I think the amout of the reported problems is much higher then people who can make an attempt to repro the problem and fix it, also with such high amount of specific problems which might occur to a very few users vs. problems which might occur to majority users is nice to vote so Visual Studio Team can see the strenght of the community voice where they should direct their effort and prioritise. Visual Studio is super complex.

        I believe, if they could fix all the bugs before each release they would do it right away 😉.

        • Neil MacMullen 0

          These are fair points – VS certainly is an extremely complex product and *any* development team needs to make hard choices about where they focus limited effort. Many users will simple drop random observations without actionable information or follow-up.

          Nevertheless, I still maintain that Microsoft’s feedback process here is not as effective as it could be in gathering useful information and can actively *disengage* users who are trying to help to improve the product. And without getting crass, it’s worth remembering that many users pay a not-insignificant amount of money (I’m not sure many organisations are crazy enough to fork out for Enterprise licensing but most will pay for Professional subscriptions @$45pcm); VS is not some open-source project that MS provide out of charity – it’s a commercial product that also has a significant strategic role in keeping developers engaged with the Microsoft eco-system.

          It’s therefore not unreasonable, even for those of us who are Microsoft supporters, to point out where the VS team could improve ! 🙂

      • Mads KristensenMicrosoft employee 0

        Thanks for posting the list of issues. I’ll do my best to answer them:

        > Not making even the simplest attempt to repro the problem (even when sample code is attached).

        The engineering teams spend a lot of time trying to repro bugs, but there are cases where they can’t or make some mistakes. Do you have a particular bug report we can look at?

        > Not understanding that fixing bugs in earlier (but still supported) releases is important – we can’t all move to the latest compiler at the drop of a hat, bugfixes need to be backported more often than the MS team seem to appreciate, for real world usage.

        I understand the pain on this one. We do port security, and some C++ platform fixes to earlier supported baseline versions of Visual Studio today. Did you experience issues with the C++ or C# compiler, or…?

        > Keenness to close problems before the fix has been verified by users.

        We heard this loud and clear and have now introduced a way to easily state that a fix didn’t work. After a bug report was closed, you can now click a button on the feedback ticket to have it reopened.

        > Simple laziness (“try the latest release” or “the fix is in the latest release” – a moving target), rather than documenting exactly which version/build introduced the fix.

        Each fixed bug or feature request now has the exact version clearly listed in which they were fixed.

        > The voting system is ridiculous. If a bug is a bug (e.g. causes a crash or a hang), it should be prioritized irrespective of any voting.

        The votes alone don’t set the priority for a bug fix. They do provide signal in to how many people are impacted by the issue. Along with other factors, this helps engineering teams prioritize fixes, but in no means does vote count stand alone in that – not even close.

        • Mike Diack 0

          Mads: I don’t have particular problems at present (most of the killer issues I’ve had have been fix), but I have had problems that cover all of my bullet points in the past with the VS support staff.
          I’ve emailed you privately and John Montgomery and other programme managers about this in the past, to discuss this issue at some length – it’s a generic problem (an attitude problem), not a single specific technical problem/bug.

          The very fact that someone made a +100500 comment under my post tells you I am far from the only one feeling this.

          The “fix is in the latest release” and inexactness practice is still going on – I can’t remember – but after seeing this blog I went and had a look at some open bugs (I didn’t book mark any sadly), but it’s still going on right now today, this week! Also there was a bug in the VS Update 9 Preview 2 release that has been “fixed” for months, but isn’t fixed but yet despite protestations it’s closed. I don’t have time at present to cite concrete examples (but I will do later), go and have a look. The problems are still there.

          • Neil MacMullen 0

            So, I dug out an old issue which I think illustrates some problems ..

            – Reported May 1
            – Ignored until Jun 5 (despite being related to another issue – it’s worth looking at history for that as well!) before being summarily closed.
            – Reopened Nov 2 (thank you!) but with a generic “not able to reproduce – please provide a solution repro”. I mean, I gave you a load of info in the original report. Was it even looked at? Maybe it was and you tried a few things but still couldn’t repro it. If you told me what you had _tried_ maybe I could figure out what I forgot to tell you but at this stage I’m not going to go away an invest another day trying to frame the issue in a way that *might* cause it to be looked at seriously.
            – To be fair, the lack of activity on the rest of the thread can be blamed on me. It would have been polite at least to say I wasn’t going to spend any more time on this, but I was frustrated and just assumed that I wasn’t going to get anything changed at this point.

            The related issue is also interesting. Pretty clear and reproducible error. Actually very good and quick engagement for first week (which prompted me to provide more useful information). An apparent acknowledgement that the problem is real and being looked at and then…. tumbleweed before the automated closure.

  • Rogier van der Hee 0

    This is great! Voting gives an error for me when I log in with my Microsoft account though.

    • Mads KristensenMicrosoft employee 0

      I’m sorry the voting is broken for you. Could you please send me (madsk at microsoft com) a fiddler trace or network response from your browser from when the error occurs?

    • Martin Liversage 0

      I often experience problems with signing in to Microsoft systems with one of my multiple accounts. However, trying again in a private browser session almost always fixes the problem.

      • Kirsan 0

        Yes, multiple accounts is the pain…

  • Petr Houška 0

    Amazing improvement! love the new feedback <3.

    One small issue (might've already been solved): when I used it in recent weeks (internal preview?) whenever I did some action (submitted a new comment, unfollowed an issue, …) it took minutes until it propagated and showed up. Due to it, I've submitted multiple comments multiple times (the UI tells you it might take a while… but I expected seconds not minutes) & then had similar issues deleting them.

    • Mads KristensenMicrosoft employee 0

      I’m glad you enjoy the new Developer Community 🙂

      The issue you’re describing is one that we’re will be looking into shortly. The fix is part of the (big) task of replacing the backend system. It will eventually be instant once we’re done.

  • André Ziegler 0

    Who cares about those “improvements” if you ignore the content of the feedback. One of the most voted feedback is to bring back the tree based “new project” dialog and Microsoft ignores it since first VS2019 preview.

    • Mads KristensenMicrosoft employee 0

      Each update to Visual Studio has an average of over 600 fixed customer reported bugs and feature requests

      • vernmeans 0

        The lead new feature of a major Visual Studio release, or any large software product, should not be UX / UI color or tooling improvements.

        Those are not business features.

        My CIO asks when a new Visual Studio version comes out, “Is it worth upgrading or waiting until the next major version?” for each of our large systems. If the dev team’s best answer is “Visual Studio version X has better tooling and different UI colors.” we do not get budget, nor time nor staff to do the upgrade.

        This puts our dev department into a constant firefight of upgrading legacy system X which is on a Visual Studio version 2+ versions back and will take months to build, deploy, retest and get UAT business owner sign-off. That is instead of actually adding new business features to the applications.

        They are financial solutions falling under SoX regulations in the 500,000 lines of C# or more size connected to other large C# .NET systems.

        Far too often, the dev tools team of MS comes over as if most all software solutions are toy disposable applications with limited functionality that can be retested, redeployed and UAT validated in just a day or two.

        • Mike Diack 0

          vernmeans – Exactly, hence my comment:
          “– Not understanding that fixing bugs in earlier (but still supported) releases is important – we can’t all move to the latest compiler at the drop of a hat, bugfixes need to be backported more often than the MS team seem to appreciate, for real world usage.”

          Microsoft need to get this. Many business critical apps are developed using VS, and switching versions in such cases is never done lightly, and sometimes not done at all…

  • Mike Diack 0

    As I promised, an example of how messed up, unhelpful, ambiguous and confusing the feedback staff and process can be, Mads.

    Take a look at the progress of how this bug was dealt with very recently in VS 2019 – it’s a model example of EVERYTHING thats wrong with the feedback process – not the technology – the teams driving it.

  • Mike Diack 0

    I know I sound like a broken record but I will say this again. You are NOT taking on the feedback we are giving.
    You tell us there will be no more “try the latest release” feedback etc.
    Here we are. Todays release (Feb 9) of VS 2019 16.8.5. It’s still going on.


    Feedback bot says:
    “A fix for this issue has been released! Install the most recent release from Thank you for providing valuable feedback which has helped improve the product.”

    Question: WHY OH WHY is it soooooo impossibly difficult (sarcasm for emphasis) for that reply to say what version(s) the fix is in? So that users can skim the bugs history and read the answer?

    • Mads KristensenMicrosoft employee 0

      We’re trying to integrate Developer Community deeper into our engineering systems to better be able to answer what version of VS a fix goes in at the time it was committed. Today, it takes a little time before we know exactly what release it ends up in, but as you can see in the green top header, it now has a release (16.8.5) associated with it.

  • Mike Diack 0

    Again, my comment about the need to backport fixes rather than assuming people can change compilers at the drop of a hat:
    Another of today’s bugfixes:

    Feedback bot tells the frustrated user to install the preview build not the regular build.

    The users response:
    “A performance degradation as bad as this one requires a hot fix release, because people literally cannot work on this release! You cannot assume that people will install another (preview) version of Visual Studio side by side, which might even have more serious bugs.

  • Rocco Balzamà 0

    Good morning,
    we are very interested in new developments in VisualStudio 2019,
    but before making a purchase, it would be possible to know when and if the new version “VisualStudio 2021” will be released

Feedback usabilla icon