Status on Visual Studio feature suggestions

Mads Kristensen


Visual Studio receives over 500 feature suggestions from customers every month on the Developer Community website. Handling that amount is a huge effort and we’d like to share with you how we handle this volume and the steps that we take to respond to them all. What happens to suggestion tickets after they’re opened, how many make it into Visual Studio, and what happens to the rest? Let’s find out.

Let’s start with the breakdown of incoming suggestion tickets in the past 6 months and what state they are in today. We find that around 15% of the suggestions are challenging to act on, and they typically fall into the following buckets.

11% – Closed as duplicate
3% – Closed due to missing info from customer
1% – Closed because they were not suggestions for Visual Studio

We do our best to follow up with customers to get more information where we can and move them into the next stage. For example, when making a suggestion to add a command to a context menu, it is important for us to know which context menu you meant.

That leave us with 85% left which are currently moving their way through the system. Here is the status of those tickets currently in our system:

40% – Closed for a number of reasons (more info below)
20% – New, not yet processed or triaged
28% – Under review and gathering votes and comments
3% – Awaiting more info from customer
3% – On roadmap (under development)
6% – Completed and released

Now let’s dig in and see what’s behind those numbers.

From New to Under Review

We have a filtering system that automatically routes incoming suggestions to the appropriate team within the Visual Studio organization. Within my team, we have established a weekly process to triage these routed suggestions and review status. The process we follow looks like this:

  1. Does this bug belong to my team?
    • If not, move it to the right team
  2. Is the suggestion a duplicate of an existing suggestion?
    • If so, close it and transfers all votes to the original ticket (happens automatically)
  3. Does the suggestion contain all needed information?
    • If not, ask customer for more information
  4. Was this suggestion already completed or in active development?
    • If so, close it as either Completed or On Roadmap
  5. If it made it this far, mark it Under Review to gather votes and comments for 90 days

By following these steps, most suggestions end up Under Review as we gather more data, refine any repos or requirements. These make up over a quarter of all suggestions.

Every time someone adds a new comment to an existing ticket, we receive an email, so we know what’s going on with each ticket along the way, and can respond if needed.

Moving on from Under Review

Within 90 days, we attempt to address items that are still marked Under Review. Our options are:

  1. Mark it as Completed because we implemented the suggestion
  2. Mark it as On Roadmap because it’s in active development or will be very soon
  3. Close it because it didn’t get any votes and/or we’re not able to prioritize it

When we implement a suggestion, we mark it Completed or On Roadmap. Currently, approximately ~10% of the incoming suggestions go on to be implemented or added to the roadmap.

But what about the ones that don’t?

Reasons for closing suggestions

Most suggestions are good suggestions and it’s always painful to close them. Especially because a lot of them are some that we personally would like to see implemented. As developers, you know that time and resources are finite, which means we can’t implement all suggestions.

The reason we close suggestions is a mix of multiple factors, such as:

  1. It didn’t receive any votes after 90 days as Under Review
  2. It got a few votes, but an implementation will not fit within our available resources
  3. It involves areas in Visual Studio that see little usage by our customers
  4. It has negative side-effects such as degraded performance, accessibility etc.

Over a third of all suggestions end up closed due to one or more of the above reasons.

On the positive side, even for some suggestions that we close, we do move the capability into an experimental extension for Visual Studio. This allows us to lower the cost of delivering a quality product investment, and where we can draw more interest from the community.

Suggestion completed

6% of all actionable suggestion tickets end up marked as Completed. It may not sound like much, but it is about 1 suggestion per weekday. Let that sink in. Every single weekday, the Visual Studio engineering team implements a community submitted suggestion.

Before we implement a suggestion, we first write a spec for it if needed. Then we schedule the work item in a sprint for engineering to pick up. The implementation sometimes require work by multiple teams to coordinate, so they can each do their piece of the feature.

After automated test and compliance runs have finished, it’s time for code review before the code starts its journey toward the Visual Studio master branch. More automated testing runs and finally manually testing follows. After fixing all identified bugs, the completed suggestion makes its way to a Visual Studio Preview release for user testing and stabilization.

So, how do we decide to implement suggestions and how can you optimize the chances of your suggestion making it? We look at several things:

  1. Suggestions with many votes and continuous votes over time
  2. Suggestions in areas that see lots of usage by our customers
  3. Suggestions that are easier to implement
  4. Suggestions that would improve Visual Studio’s competitive advantage
  5. Well written suggestion with all relevant information in the description

A different way to think about it is to turn it around. Imagine someone wanted you to implement a feature in your product. It’s in the best interest of our product and customers to complete as many suggestions as possible, and we strive to do so.

The best times are when we get to make a lot of people happy with a feature implementation based on a suggestion.

We can must do better

We’ve gotten feedback that this process feels like a black box. Customers feel like they don’t get a response and they don’t know the status of their suggestions.

After submitting a suggestion, there is no transparency into the process, and it ends up closed without any good reason 6 months later. I end up feeling frustrated and angry. I don’t want to submit another suggestion just to be ignored. – Anonymous Visual Studio user

This is not acceptable. We must do better.

Some ideas that we are working on within the team are as follows. And, we welcome your feedback on what we might do more of to help you understand the process better.

First up, we want to be much more transparent about the process. That’s exactly what this blog post aims to achieve.

Secondly, we must be faster at responding to new suggestions. That means triaging them within the first week, so we can bring down the 20% of new untriaged suggestions to a minimum. It also means not leaving any suggestions to linger for months. This will add visibility into what is going on with the suggestions much earlier and throughout its various phases. We’ve made great progress with this in the past 6 months, but still have a bunch of open tickets to go.

Thirdly, we need to be better at giving reasons for closing tickets. Individually written by the program manager that closed them and not an automated response. As we’re getting better at handling the vast amount of incoming suggestions, this is where we’ll focus next.


I hope this blog post helps shed light on the way we handle suggestion and how we plan to improve. Completing a suggestion every single weekday will hopefully encourage you to continue opening suggestion tickets.

In closing, we’d really like to hear your thoughts or questions. What could we do better and what do we do well? Let us know in the comments below.

Mads Kristensen
Mads Kristensen

Senior Program Manager, Visual Studio Extensibility

Follow Mads   

MgSam 2019-07-31 09:34:36
I think you're missing a big reason the current process is suboptimal. The feature suggestion system sucks! o The search function is terrible. o Tickets do not have public ids, so sharing existing tickets, and having the community assist in duplicate identifcation, is impossible. o The controls for writing up features uses a 3rd-rate rich text control which doesn't support Markdown (why does Microsoft refuse to use Markdown controls? You guys have owned Github for nearly 2 years, just take the controls from there.) o There's no way to subscribe to existing tickets. o Even getting to the feature suggestion hub is confusing mess. Navigate to Wait for the page to slowly load all its content. They'll be 3 quick links on the bottom which are only for bug reporting (Setup, IDE, All). Click any of them. Now you're on Click the Features tab. Literally the only way to view the existing feature suggestions. No wonder its so hard for them to get votes! In short, you need to move feature suggestions to a Github project.  And this isn't related to VS- but the formatting of this post will likely be destroyed. Because the MS blog system is less functional than something from 1996. 
Chuck Ryan 2019-07-31 09:46:11
@Mads Kristensen I am sorry but we have heard all this before, or some variation of it, and we simply do not beleive it. Sure that might be your process and it might sometimes actually be followed but in the end we are right back here with someone like you writing a blog post explaining how things are going to get better. This simple fact is that since the whole Visual Studio 2012 debacle, combined with the accellerated release schedule, Visual Studio has been on a downward spiral and is often described as buggy, bloated and slow. Each new release brings more incomplete features, many poorly designed and with plentiful bugs, which further bloats and slows down the product even more... It does not make for an enjoyable day in the office.
Jack Bond 2019-07-31 10:32:48
You failed to mention another reason Microsoft closes a suggestion... Microsoft is strapped for cash. Yep, that's the only logical explanation for closing this suggestion.  And now that it's closed, it probably can't be upvoted. BTW, stating, it's a "very valid suggestion" simply throws salt in the wound. Bottom line, if you're receiving very valid suggestions, and you don't have time to work on them in the immediate future, HIRE MORE PEOPLE. Or is it like I said, strapped for cash? Finally, what is it about Microsoft programmers that EVERYWHERE you have a textbox for providing input, that's easily going to run multiple lines, the genius responsible sets the height of the textbox to 8 pixels and not resizeable?
Kevin Woronuk 2019-07-31 10:34:37
One thing that I would find helpful is the ability to find an item that has the "On Roadmap" tag on the actual roadmap.  For example, this is a feature that has the "On Roadmap" tag, but I can't find it on the roadmap and I'd really like to know where it is.  The roadmap has linkable items to the item on the developer community page, but the reverse does not appear to be true.
Derek Foulk 2019-07-31 11:55:03
"Close it because it didn’t get any votes and/or we’re not able to prioritize it" This is one my biggest issues with the way our reports are handled. It feels like too many good reports go unaddressed because they don't get enough votes. Especially when we're talking about stuff that only a minority of users are going notice. I'm guessing a small fraction of users are going to take the time to provide feedback. Even less are going to vote on issues that they didn't try to report themselves. Heck, I forget to vote on issues I go to report, but somebody else has already done so. "Most suggestions are good suggestions and it’s always painful to close them. Especially because a lot of them are some that we personally would like to see implemented. As developers, you know that time and resources are finite, which means we can’t implement all suggestions." I don't believe anybody expects all reports to be acted on- just more of them. This is a Microsoft product that we pay good money for. Too many good reports are closed. If it's a good suggestion, idea, but report- backlog that puppy! Groom that backlog, of course, but get it in!
Derek Foulk 2019-07-31 12:00:30
"Your suggestion has been queued up for prioritization. Feature suggestions are prioritized based on the value to our broader developer community and the product roadmap. We may not be able to pursue this one immediately, but we will continue to monitor it up to 90 days for community input" To add to my other comment... This has killed many good reports I've found. I feel like a lot of us give up trying to provide feedback after seeing this a few times. Especially with reports that only affect a minority of VS users (Xamarin, etc.).
Daniel Smith 2019-07-31 15:09:24
Oh boy what a can of worms to open!  One thing I see a lot, is people getting frustrated that sometimes bizarre changes are made to Visual Studio, or much loved screens or features are ripped out without any requests from the community, and yet some of the highest rated user requests go ignored. Obviously you guys need to have the freedom to innovate, but it feels like you could make better use of the blogs to get early feedback on potential changes from a wide range of your real world users, as opposed to using private focus groups.  There’s certainly an abundance of people on here who are more than willing to provide feedback :-)
Alexandr Golikov 2019-07-31 23:42:48
Agreed with all above. What can you say about many times requested 64 bit VS suggestion that bein closed every time? 
Robert Gale 2019-08-01 00:05:59
Every single weekday, the Visual Studio engineering team implements a community submitted suggestion. I wasn't quite sure if this is meant to be good or shockingly slow?
Federico Navarrete 2019-08-01 01:40:12
I'd rather focus on the bugs since the current iteration of VS2019 is quite tricky, I have experienced multiple bugs in macOS and Windows every release reaching a point that the question mark is: What is going to the new broken section? Is UWP going to work? Is Xamarin still supported? I'd rather focus on improving this part because I'm quite surprised that Microsoft is allowing the release of so many bugs per release, I have been using VS since the v6 to 2019 and I have never experienced so many bugs in one release in 13 years.
David Roff 2019-08-01 05:31:20
I realise that the default tone for all comments is sarcastic, negative and often rude, but I would like to offer an exception. I think that Visual Studio is still far and away the best tool for my C++ developement needs. I've tried and discarded many others. Better still, it seems to be improving steadily, with stability and responsiveness leading the way. The newer C++ compiler and CMake support get a big thumps up from me. Sure, I have my gripes, but I can empathise with your team and I realise not all changes will be approved. Surely anyone can understand that not all suggestions can be implemented and there perhaps isn't time, or resource, to explain why some suggestions don't make the cut.  Keep up the good work. P.S. I don't, and never have, worked for Microsoft
Mike Diack 2019-08-01 05:36:48
There is too little transparency and accuracy from Microsoft:1) Many regressions in the recent 15.8+ builds of VS 2017 have been flagged. The response has almost always been "it's fixed in VS 2019, use that". This has angered MANY people, because the answer is inexact and TOTALLY misses the point - the customers need the fix in VS 2017, which was working but has become broken (these are genuine regressions, not things that never worked to begin with). I have raised this with Nick. ATL wizards broken, #import wrong, wizards creating unbuildable code etc. You as a group need to fix this as well. 2017 Update 9 is intended as a long term support version of VS 2017, but has significant problems.2) When problems are resolved, the details of a fix becoming available are vague (they rarely refer to a build or version number exactly), instead saying "it's now fixed". This is hopeless for anyone outside of Microsoft. Why can't we know exact builds etc that the fixes have gone into?
Mike Diack 2019-08-01 05:39:24
Agreed - the closure process is terrible. The lack of response beyond "Closed" - is why so many people are so angry with the VS team - because it feels like the much heralded community are having all their feedback tipped in the bin. Frankly it feels like we're ignored. Many many many people want the start/new project work "fixed". Many more people said - please don't mess around with the VS IDE UI (the menu bar etc), but that feedback too, was mostly ignored. Much as with Windows 10. It feels like you are fiddling around with the periphery rather than getting the basics right.
Sam Jost 2019-08-01 07:04:25
What about translation bugs? Should I post wrong translations as "feature suggestion" or is there a bug forum for these? For example the new testing dialogue in VS2019 has 'state' in german as 'bundesstaat', which would be, like, Texas, New York, ... which of course is plain wrong.
James Foye 2019-08-01 10:36:00
Lost cause. I myself, after decades of using Visual Studio, switched to Rider. I come here now to the VS blogs because I find comments entertaining. (I have a dark sense of humor). Despite all the protestations of "We are listening", you continue down the road of changing things for the sake of change, then springing them on the community, then dealing with the negative feedback after the fact, when it's too late to do anything. Plus at some point you fired too many QA folks, as the bugginess of the product seems to get worse and worse.
Scott Ward
Scott Ward 2019-08-01 19:17:55
I have a suggestion on there that seems to be totally ignored apart from the (I'm guessing) automated first response from Jane Wu I submitted a suggestion on 01 May 2019 and its now August so 3 months and no feedback what so ever, apart from non microsoft people with suggestion of how to get a response (those ideas went un-noticed as well). It would be nice to have some dedicated people to triage these and have some more status, eg, I can reproduce this issue, any known workarounds or state there is none, Has been added to a wish list that is actually looked at by the developers, under development, etc   my post: I also aggree with the last commenter about the "controls for writing up features" they are terrible, it mucked up all my enter marks and could not be fixed while editing it. (On that note this page gives me a non-adjustable 4 line control for commenting (using Firefox)) I love visual studio and use it on a daily basis for work and fun, it would be nice to be heard when there are feasible ideas that would make my and other users experience better and more productive
Ladislav Burkovsky 2019-08-01 22:34:00
I´m working daily with VS. I can tell you over the years we don't got have significant improvements. Refactorings are at best basic (MS doesn't use it internaly ?). Other area are mem/speed profilers. Why can you not integrate(buy) a serious tool. What happend with all the UML Tools (not integrated with class diagram). You are jumping from one theme to another. Take time and money and finish things so you can be PROUD of them. Laci
Ondřej Linhart 2019-08-02 00:18:32
Instead of fixing some functionality from VS2017, you just remove it in VS2019... Who wants to work in latest VS with less functionality than previous? How exactly you measure "little usage by our customers"?
Matt Lavallee 2019-08-03 20:36:15
As a long, long time user of VS, what I see affecting my day-to-day has been an apparent fracturing due to trying to satisfy so many personas. I think part of VSCode's overwhelming success is simply that it doesn't have that burden.  When you're an architect working with dozens of repos, dozens of branches, and hundreds of apps, feature changes like the new Start Page -- which is probably perfectly fine for 50%+ of VS users who rarely context-switch -- cause meaningful loss of productivity every single day.  It'd be fascinating (and helpful) to understand if the program managers are trying to weight the personas equally or if it's just a question of pure vote volume that represents the community feedback.
Jan Heckman 2019-08-04 02:40:45
Mads, thanks for the good intentions and I understand limited resources and an overwhelming workload. Besides, I like improvements in VS2019, so I'm in a positive mood, so to say. Anyhow, given the subject, this cannot be anything else than an intro to some complaining. Sorry. It appears to me that your guys can ot upscale properly when a bigger issue is involved. I miss the triage proces. See which eventually works out to the (m)idl legacy code using type(def)s which need change because of C++17. This is in the bug department, but I feel the issues are similar. The issue is almost exactly 2 years old (under investigation), there's plenty of comment and urgency, but all I see is some inane work-arounds and a question whether the issue can be closed, which I downvoted. The issue can imo be resolved fairly easily but requires work by MS. Here, the conductivity from problem to solution is not exactly very high and communcation is virtually absent. Better exampes do exist. I'm not happy about using this channel to go into details, but found this really frustrating, after feeling frustrated by (imo) a quite silly bug.These reports are often not made in the best mood and that shows.
Ondřej Linhart 2019-08-05 01:43:57
Looks like deleting replies is as effective as closing VS issues... Deleted...
Roland Harrison 2019-08-05 06:36:16 Can someone please action these 7 issues here. The issue has 200+ comments saying the problem is worse and not solved.  Some of the worst QA I've ever experienced in my life. 
Steven Rasmussen 2019-08-05 09:07:43
Hi @Mads Kristensen - I'm curious to hear your thoughts on why one of the most voted suggestions (94 votes) with a lengthy discussion was closed.  It wasn't even asking for new functionality, it was asking for the "old" functionality to be returned: Looks like another reason why issues might be closed is due to CYA - In this instance it seems like the MS UX devs don't want to admit that perhaps their "new" UI design is less than optimal.  All we're asking for in many instances is the ability to toggle new features on/off instead of things being shoved down our throats.  There's absolutely NO reason this couldn't be a toggle on the options page.
Steve Parker 2019-08-06 14:51:47
You failed to mention another way that suggestions are handled. In the case of anything which criticized the new modal Start Window,  the discussions were completely hidden from view once they started racking up the highest vote counts of any topic.  At first, an attempt was made to dilute the discussion by closing the main thread and scattering people off to different topics.  It didn't work, so when those topics started gaining votes, they were removed from visibility (some by being moved to an irrelevant thread or re-tagged). Even now, the topic "Make the Visual Studio 2019 start window non-modal" is not visible despite it having 53 votes. Of course, removing these topics from visibility ensures that they get no more votes. I find the level of censorship disturbing and the level of disrespect disgusting.
Fawad Raza 2019-08-07 00:04:03
So many comments should tell one and only one thing to Microsoft. Your feeback system is severely broken and yes this "Pratik" guy is bit immature in dealing with an issue, it underlines a deeper problem of lack of training in Microsoft about the way things are handled. Don't just say stuff, act upon it too, please. Regards.
Magnus Mikkelsen
Magnus Mikkelsen 2019-08-07 01:23:25
How about adding a pane to the Visual Studio Installer, with links to new suggestions? Pick 5 - 7 new suggestions at random, and ask the user: "Which of these suggestions do you like the most?"  Or have reaction buttons along with the links. For example: "I need this!", "But why?", "Unclear: I don't get it!" I think the data produced by this poll, might help your team to process and rank new suggestions. And it might also make users more aware of the suggestion process.
Eleven Admin 2019-08-07 04:34:28
Consider this highly-voted ticket which is a hugely-annoying bug.  Fixed pending release for two years?!?  Then re-opened through desperation by someone, which was closed but actually triggered no progress on the matter. Then this ticket - it's Closed - Fixed.  But it isn't fixed.  The "fix" hasn't worked for everyone.  So that's the end of the story?  These are examples of why we get fed up with the feedback system.  Through goodwill and community spirit we try to help you to make VS better.  But often we're just ignored once you're done listening.
Andrew Truckle 2019-08-07 05:56:24
Another problem is that you are wanting to test issues with "laboratory conditions". Many times we can't do this. Like the MFC Class Wizard issues. The only way to resolve those it to include more debegging log info or to remove it to our particular projects. So many of my problems are closed because I can't help you reproduce the issue. You need to try my particular projects (which are GBs is size etc.) and provide advanced error logging to produce sensible errors so that you can hone in to the real problems. Whilst i appreciate that VS 2019 is provided free, it is not really my responsibility to beta test the application. It should have already been tested with real life programs that started out in VS 6 and have migrated through VS2005, VS2015, VS2017, VS2019 to there they are now. Andrew
Andrew Truckle 2019-08-07 05:57:36
People also often add "replies" as "answers" which is wrong. And using your site on a mobile is very difficult. I have to use a PC for it to be a easy user experience.
DragonSpark 2019-08-07 21:50:54
You all put something "Under Consideration" and then mark it for closure 60 days later? whut? Also, do you all actually enjoy making counter-intuitive user interfaces now or are you there just to collect a paycheck these days and chalk it up to something Google would do?  All of the above?
Jon McGuire 2019-08-08 02:24:43
As many others have covered, the feedback and bug-reporting UI/UX is terrible, using the lack of votes to close good suggestions and valid bugs is ridiculous (who has time to wander that terrible site tossing around votes?), but the reason I've stopped using the site is when a valid bug is closed either because nobody got around to working on it, or worse, somebody arbitrarily decides it isn't a bug. A prime example is this bug I reported where simply running VS continuously generates a ton of errors in the event log. Somebody (probably an intern or contractor judging from the inept answer) pops in to post irrelevant junk he randomly Googled (he literally writes "I looked up these error codes on the internet") then closes it, probably one ticket closer to his daily quota. Guess what? It still happens in VS2019. This was the straw that broke the camel's back for me. I haven't reached the point of giving up on VS yet, but I'm done helping you debug your product.
Mike Diack 2019-08-08 04:09:33
I've said it elsewhere, but having looked at how this thread is expanding I went and looked at some of the bugs people raise. A few trends are very clear.1) Versions that a fix is in are rarely clear - the answer is often "fixed in latest release". For the love of God, please put the version number in - surely it can't be difficult for support staff (or the bot that does it), to put the version number of the fix in?2) Too often, the replies are just verbatim that could be written by a robot, and are more like a press release/lawyer - "your feedback is important" etc. and convey no useful information. 3) As others have mentioned there have been important bugs floating around for 2-3 years, in a weird state of limbo (open, but not closed, fixes working for some people not others, lots of "me too" or "still broken in version ......" . Surely you can do better than this. Its just a mess. But my main bugbear is 1 and 2.
Mike Diack 2019-08-08 04:11:44
One practical piece of advice for others posting here - email John Montgomery and/or Nick Uhlenhuth with your issues - once I started bugging them directly via email with examples of the mess that VS 2017 and the bug reporting/follow up/tech support process is, things started to happen.
John B
John B 2019-08-08 11:30:27
The biggest frustration is that first responses are from people who jump straight to "need more info" even for simple reports. It gives the impression they're not versed in the technology, aren't taking time to read, or lack communication skills.
Neil MacMullen 2019-08-09 04:30:45
Well, I've just had yet another issue-report closed with the standard "lack of activity" template reply.  I really do appreciate the necessity to prioritize and the reality of finite development resource but I've now reported several genuine bugs (at the the very least, undesirable behaviours) that have been ignored this way.  In the development teams I've run, we always treated customer reports as an important feedback mechanism to uncover bugs that had escaped internal testing and actively chased these up rather than just waiting to see if more than one customer would notice.  (On more than a few occasions a 'minor' behavioural oddity turned   out to be an indicator or something potentially far more serious.)  I don't know whether the issue is just that the people doing the triaging are primed to try and 'protect' core development but I'd echo a few of the other comments here that the impression I generally get is that the triage process seems to be heavily biased towards rejection - both of false reports and genuine ones.  Often there is a request to provide infeasible amounts of supporting evidence (yes - we all want a local repro case - I understand!).  I can't just hand over my entire solution (or PC!) but in the past I've offered to run test builds to capture problems and never been taken up on it.  Anway, I really do hope things improve.  Visual Studio is still actually a great product and I have very few gripes with it  but the feedback process is an exercise in frustration and I'm inclined to stop providing feedback since the vast majority is rejected.
Mike Diack 2019-08-16 01:00:53
Continuing my comments about the terrible feedback loop on bug reports (specifically identifying which "latest release" has the fix, by absolute number, rather than just saying "Fixed in latest release" (at the moment that the Microsoft staff member wrote the bug report update!)Perfect example:The following bug was fixed in this week's Visual Studio Update 9.15 patch: Release notes here: on that bug report, does it make ANY mention of a fix being in the 15.9.15 update? Nowhere!