This post was written by Rich Lander, a Program Manager on the .NET Framework team. He’s also the one posting as @DotNet on Twitter.
Late last month, we released the .NET Framework 4.5.1 Preview. We’re in a spot in our release cycle where we’d appreciate feedback on the pre-release version that we just made available, but we’re also starting to think about .NET vNext. A few of us were talking about that, and we thought it would be a good idea to share our approach to feedback.
There are two major axes of feedback: time and place. On the time side, we split feedback into real-time and forward-looking. If you report an issue with .NET Framework 4.5.1 Preview, that’s real-time feedback. If you request a new feature, that’s forward-looking. On the place-side, we generally try to go to the places you choose; however, there are some feedback places that we look at and respond to first.
While I was writing this post, I saw the following comment come in on a recent blog post on HttpClient, about not finding an official support channel. This serves as a good example of why we should be clearer on how to report feedback and requests for support.
We always seem to have a preview release out, now that we are releasing .NET Framework libraries on NuGet. It also happens that the .NET Framework 4.5.1 is out in preview at the moment, too. While releases are in preview, we do our best to collect as much feedback as possible. There is always something that we should fix or change (some that we know about, and some that we don’t) with preview releases. We rely on your feedback to determine what those changes should be.
We use the .NET blog to tell you about our releases, and we tweet those blog post URLs on Twitter. The best place to report product issues or ask questions about preview releases is in the blog post comments or on Twitter (include “@dotnet” in the tweet). That’s what @SebM chose to do, above. We do our best to keep on top of those comments. Feel free to send your comments about products that have shipped (that are no longer in preview) this way, too.
For NuGet packages, you can also use the “contact owners” link in the NuGet Gallery to give feedback on a specific package. For HttpClient, for example, you will see the contact owners link on the left side of our HttpClient package page, just below our gravatar.
We know that many of you use forums such as StackOverflow or MSDN. In fact, forums probably represent the place we get the vast majority of feedback and support requests from our users. They tend to ask a lot of “how do I” type questions that are just as easy for the broad community to answer, and that’s indeed what we see happening. There are some really great answers that we’ve seen on StackOverflow, for example. Thanks for sharing your expertise! Seriously. We also participate there, and some of us have StackOverflow tag subscriptions; however, we tend to target particular issues that we are concerned about due to large volumes of activity that we see in forums.
Visual Studio and .NET Framework Connect is another good way to report issues. It has the benefit of being fully integrated into our TFS bug system, so your issue show up in our bug queries. We have heard that a high volume of issues have started coming in via the Visual Studio Send-a-Smile program. Connect is a better way to send issue feedback, since it is integrated into our bug reporting system, however, I’d rather see the feedback come in through any system than not at all.
You may have seen in our .NET Framework 4.5.1 Preview post that in addition to describing new features, we reported progress on UserVoice requests. There are a lot of good requests on UserVoice, and we hope to see new ideas continue to show up there. We’re looking at that list as a sort of agile backlog that we consider as we plan for a new release.
I mentioned earlier that we try to meet you where you’re at. We look out for feature requests wherever we can find them. That said, we use UserVoice as our primary home for forward-looking feedback. It has a nice feature set and a lot of activity, which means that a lot of you are already there.
Here’s a recent discussion on Twitter. Alexander asked for a particular update for WPF. I asked him to crowdsource the need for it on UserVoice, with the promise that I’d broadcast the UserVoice entry.
About 24 hours later, I saw this from Alexander:
You might be thinking that Alexander lucked out with this particular interaction. Not true. Tweet @DotNet a new UserVoice entry that you’ve created about .NET and I’ll retweet it. Also, if you have a favorite existing UserVoice entry (again, about .NET) but you don’t think it’s getting enough attention, tweet that to me (@DotNet) as well. The goal is to get a lot of people voting on the .NET UserVoice requests so that we feel confident about the relative priorities, as set by a large set of .NET developers.
Here are the primary forums to report feature requests about .NET:
These three tweets, both the feature requests and the general idea of broadcasting them this way, got a positive reaction from the UserVoice community. That’s great. Just so everyone is on the same page, I’m offering to retweet these feature requests to raise visibility and increase voting on UserVoice features. This isn’t a commitment to do the feature work. We also may choose to ship releases with features that came exclusively from other places. That said, we do think that UserVoice is a great source for a crowdsourced, prioritized feature list. We felt really good about checking off some important requests that came in from UserVoice in the .NET Framework 4.5.1 Preview, and we hope to repeat that.
Thanks again to Alexander for being a great advisor to the .NET team. Thanks to everyone else who has been advising us as well, particularly our MVPs. Be the next Alexander and share your ideas with us!
We’re, in effect, lending you our ears. Do tell us, Robin, what should we do?