News

Microsoft Tackles Visual Studio Feature Request 'Black Box' Problems

Microsoft is seeking to open up the "black box" of its Visual Studio feature request mechanism that can anger and frustrate developers who provide tooling feedback.

Providing more transparency in the feature request process is the first step of an overall improvement program that handles more than 500 feature suggestions every month, managed on the Developer Community site.

That first transparency step began last week with a post by Mads Kristensen, senior program manager, Visual Studio Extensibility. He explained how 15 percent of those 500-plus suggestions are soon closed for various reasons (duplicate suggestion, missing info and so on) and how the team handles the remainder.

"We've gotten feedback that this process feels like a black box," Kristensen said. "Customers feel like they don't get a response and they don't know the status of their suggestions," he continued, offering up the following anonymous comment as evidence:

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

Along with improved transparency into the processes, began with last week's blog post, Kristensen said two other ideas being considered include:

  • Faster responses to new suggestions: "That means triaging them within the first week, so we can bring down the 20 percent 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."
  • Providing better information about closed 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."

The post obviously addresses a sore point among developers, many of whom chimed in with suggestions in comments section, ranging from how the Developer Community site works to the aforementioned handling of closed tickets.

"Agreed -- the closure process is terrible," reads one comment. "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."

To address that issue, the company is soliciting more feedback on the above ideas.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube