We’re upgrading Visual Studio’s feedback!
Visual Studio is a customer driven tool, our team is dedicated to exploring and learning what challenges you may be facing so we can help. To provide the highest quality of feedback we are upgrading our system, which means older versions of Visual Studio will no longer be compatible to provide feedback. If you want to continue to submit feedback, please upgrade to 16.7 or any LTSC service release after April 2021.
We strive to have a transparent and collaborative relationship with our users to offer the best developer experience inside and out of Visual Studio. We encourage users to provide feedback on our primary tool Developer Community, where we receive 3000 feedback items every month. This is the best way to directly reach our engineering teams and ensure that your feedback item will be seen, read, and taken action on. In addition, we receive hundreds of feedback items from Twitter, YouTube, the Visual Studio Blog, various conferences and online events, Facebook, LinkedIn and more so feel free to get involved there too!
We want to offer the best customer experience when giving feedback and make sure that your voice can be heard. For this reason, we are choosing to upgrade our Send Feedback options available in the help menu and feedback center:
This new system will make it much easier for our engineering teams to track, organize and transfer tickets. Our main goal is to have the best communication between our users and the Visual Studio engineering teams as we head into the future. We are expecting this will increase our responsiveness to issues and in turn give the user a much better experience.
This new system does come with a cost. Moving to this new system has made these versions unable to submit feedback for the Send Feedback options:
- 15.9.0 – 15.9.34
- 16.4.0 – 16.4.20
- 16.5.0 – 16.6.X
It is hard for us to make the decision not to support certain versions of Visual Studio, however, with the increase in productivity and scalability that this new system offers we feel it is the right decision for our product.
If you would like to continue to provide feedback and see Visual Studio grow, please upgrade to 16.7 or any LTSC service release after April 2021.
So, what is the actual upgrade?
The upgrade mainly takes place behind the scenes. This upgrade drastically improves our scalability and communication between engineering teams. It makes transferring and organizing tickets much easier for the engineering teams as well. From a user perspective we hope that you will notice the increase in responsiveness to tickets and increase in communication between engineering teams and our users. I hope this answers your question. If you were looking for the more technical response basically, we are restructuring how our backend is stored and moving onto a new hosting system, a better one!
Enough information for me.
It just seemed odd, to me, that not a single word talked about what the upgrade actually is, so nothing positiv came from the post.
eg. Hey, we are doing this and that cool stuff, but sadly to do this we have to drop support for…
Instead it only says
eg. We are dropping support, because of an upgrade.
Which only highlights the negative part of dropping the support.
The only remote thing that could be interpreted as the “upgrade” where the menu items, but also that just had a very odd vibe.
Because I asked my self, really you are dropping support because of new menu items?
Which I simply refused to believe, and that is why I asked what is actually the upgrade.
Are you planning on improving the actual feedback recording system? I have reported dozens and dozens of bugs whereby I am literally recording what is occurring on my machine and each one of them has resulted in a response like this one:
Why are you allowing us to literally record what is occurring on our machine only to result in asking for more information because you cannot reproduce it?!
It is even more frustating when they acknowledge it is indeed a problem and then either close the ticket with whatever reason they came up with, or let it die with a comment telling that someone is looking into integrating it into future roadmap items and a couple of years later just close it eventually.
Sometimes I wonder why I still bother.
I don’t bother anymore. I’ve been submitting bugs for more than 15 years, the oldest ones all disappeared at a certain point.
The newer ones never ever get fixed.
In every survey about Visual Studio I’ve been asked to participate in I’ve mentioned that they need to fix their bugs.
Every so often we get an article like this that says that now they are planning to really do something about it, but results never materialize. It’s frustrating. And I just don’t believe it anymore.
this comment has been deleted.
Hi, this thread has been very insightful for me, thank you for expressing your opinions in a constructive manner. I am a new PM at Microsoft, and this general area is becoming my focus. Things like contextual help in product, feedback (Developer Community), and other areas that relate. I really want to make this experience better for all our users and hope that we can work together to improve Visual Studio. As I said I am new, so it may take some time for me to onboard and truly crack down on the problems in this area. Improving your feedback experience and making sure that you can find solutions to your issues are some of my highest priorities. Please feel free to reach out to me personally on twitter if you have suggestions and ideas. (Please be constructive I know this area can get frustrating at times)
Hey @Jason thank YOU for taking the time to learn the layout of the land here. I have a penchant for getting a little animated on here at times, myself. So, thank you for your patience as I do so. 🙂 The other frustration is that these comments and pain points have already been voiced here many times on this blog over the course of many months and it does not seem like they have gotten to anyone in particular who can (or want to)
do anything about it.
From my perspective, the Visual Studio Feedback workflow is really nice and there are a lot of great things going for it. The greatest of which is being able to record exactly what is occurring on the user’s machine and report it. This, of course, is the source of my grief and everlasting confusion, as those recordings do not seem to be enough to track down the root cause of the issues that I (and others) are reporting. Does it mean more ETL/diagnostics? It feels like this is the case. At the very least it seems like more effort has to be made in providing more diagnostics and/or ETL when a recording is made.
If you want a starting point, you can simply go by my username and see all the issues lamenting in `Need More Info` status. FWIW, I even have an outstanding issue with my name and that has been stalled for whatever reason:
Another one for your review:
It is interesting to note that the reproduction was attempted in a Sql Server Project? Do the SLN/csproj types not make it over to you? Again, I am recording exactly what is occurring on my machine so at the very least the type of project being used (Blazor server-side) should at least make it over to you.
Thank you for any continued assistance/consideration.
Well as your new, start with easy things like making copy paste work normally. In Vs 2008 a bug was introduced, that copies the entire line if nothing is selected ( read when hitting ctrl-c by mistake), fast forward to 2022 and still not fixed.
@jasonchlus , Glad you’re getting involved, and wish you the best! 🙂
I think here’s a good example of some of the current frustrations that users have when filing VS bugs: https://developercommunity.visualstudio.com/t/vs2022-advertises-update-1705-yet-no-release-notes/1637734?from=email&viewtype=all#T-ND1640366 🙂 In this case, a new version of VS was released, but the VS team didn’t post release notes for it, so someone filed a bug saying that the release notes are missing.
This seems like a critical bug (at least to me! 🙂), but after 5 days and 66 upvotes, there hasn’t been any feedback from Microsoft.
Anyway, not sure if that helps, but maybe it’ll help you get connected with some of the right people and have a chance to dig into the processes behind how these types of bug reports are handled! 😀
I’ve taken you up on that Twitter offer, @Jason but it is not exactly doing well:
In the applications I work on, the goal is not to need a reporting application like that.
If I had to receive 3000 bugs a month, it would mean that something is not right. I would not bother improving the system to report the problems, I would ensure that everything is properly tested and not received more bugs.
Microsoft strategy looks like outsourcing the testing of VS to the developers that pay for the license.
Then they request for logs, dumps, screen recording, sample solutions to reproduce the problem.
Then if you don’t provide the full details as expected, they just close the bug, instead of spending the time to find a solution.
It’s normal MS doesn’t have the resources to find the solution, they spend all the time creating a new reporting system to allow more issues to be submitted.
Hi Roberto, I love the thinking here. We share the same goals. We would also love to release a product that has 0 bugs, and everyone is happy with, that is of course the goal. You see a lot of our feedback items actually come from new improvements that we are making to the product. Due to us having so many potential projects to work on and areas to add exciting new features to we often start with small experiments. Some of these projects really take off and users love them, so we try to improve and expand upon them more. Unfortunately, these things do take time and we have to go through extensive testing just to make sure it can work with all the areas across Visual Studio. Visual Studio is an old product (20+ years) it’s quite difficult to make sure that all the clean new code we are writing still connects and works with all the old code that is still used in some areas. We strive to do the best we can and deliver a product that all our users enjoy using, and if we continuously tested and made sure there was 0 problems in every feature of every area, I fear we would fall behind in terms of releasing new features and making improvements that effect millions. It’s a delicate balance we try to play, I hope you can see and understand that it is hard to make a product that millions of people use differently, perfect.
Yes, many of us can understand and sympathize with how difficult it is to design, develop and maintain a large, multi decade, product with many department/users who expect something just a little different than the person next to them. But that sympathy tends to fade when Microsoft appears to care little about how the constant changes in direction, limited testing and frustrating feedback system affects its customers.
Unfortunately on our end the management does not extend sympathy when we tell them that we need to go back and rework existing code because Microsoft made changes, introduced bugs or is no longer supporting their previous ‘it’ technology. Technical debt = developer incompetence in many executive eyes. So when you add in dismissive support channels… customer loyalty tends to fade and hostility begins to grow.
At present, various developed UI controls of visual studio are difficult to save and manage, so it is often necessary to find and copy some controls once written everywhere, which makes developers spend a lot of time on a lot of repetitive work
The problem here isn’t the feedback tools. It’s that so much feedback is simply ignored.
Take the “new project dialog” issue for example. There are 8 pages of negative feedback on the original blog post about it, and three years of detailed discussion on the the corresponding Developer Community feedback suggestion. The dev teams at MS had personal meetings with people about this and they promised to make improvements. But those improvements never happened. Instead the MS people were reassigned to something else. And we’re still suffering with the result.
At this point, I’m with Jens Samson – I’ve lost faith in the entire process.
Soooo….. what is the improvement?
The entry point is now in Help instead of a separate icon? Wooptidoo
Guess we can conclude that the different entry point allows for deeper integration into VS in collecting the information Msft wants but fewer and fewer users will voluntarily hand over. I am expecting more heavy handedness from Msft, to which I will respond by no longer submitting feedback. But that is too early to tell.
The problem with feedback is not accessibility.
The problems I see are:
Msft is asking its users to invest more time in the discovery of issues, this further increases the cost of ownership (hours, days lost due to VS issues). Even if I use the community version, there is stil a cost of ownership. The burden of discovery should be mostly with Msft.
Msft keeps fiddling with stuff that works only to replace it with something that is a clear regression (not only VS, but pretty much all their products). Windows 11 is a case in point.
Takes too long to go from feedback to a solution, in my experience at least a month, sometimes several
My expectations of finding a solution to my problem with VS through feedback is close to zero.
I do submit feeback still, however, I have stopped answering “we need more information” requests.
And I have stopped looking at my posts once I have submitted.
this comment has been deleted.
As of today I can’t send feedback. I am using Visual Studio for macOS, version 8.10.16. There is no later version. I am on the latest version. Therefore all ability to upload feedback has been removed.
I’m tempted to suggest this is because VS for macOS is so full of holes! But if this is an error, can this please be turned back on?