Understanding the PowerShell UserVoice
The PowerShell Team been using UserVoice to take in requests, feedback and bug reports for a few months now. It’s been really great seeing feedback come in directly from the PowerShell community. I wanted to give some details around how your feedback gets used and what happens to something after it gets posted to UserVoice.
We recently added some status definitions to our UserVoice forum. I’m going to walk through UserVoice to show how we do things, and give more detail on what those definitions actually mean in practice.
Suppose I want to share my deepest desire – an open source version of the Archive module. I just type this into the “enter your idea” prompt on UserVoice to post this as a new idea.
UserVoice will automatically search previous suggestions for matches. This is great, because if you didn’t know Microsoft.PowerShell.Archive was already open-sourced, now you know! Or if someone else has already put in a similar request, you can just press the “vote” button to the left of the title to express your support for the idea. In general, this is always preferable to creating a new item. We’ll get to how “votes” fit into our process in a second, but for now let’s pretend I just created a new suggestion for my second most-desired feature: an improvement to the PowerShell Gallery. Anyone else can come by and vote on my suggestion, or make a comment about it.
That’s what creating a new UserVoice issue looks like from your perspective. Now let’s go through and see what’s happening behind the scenes. First, a disclaimer: this is a process we are still working through and actively improving.
The PowerShell PM team sits down to look at our UserVoice on a regular basis. The first step in our triage is to mark the item as “Survey”. At the top of our UserVoice, we define “survey” as: “We saw this and we are considering it. Please if it’s important to you”.
Once we’ve marked the item as “survey”, we have some work to do. First, we need to make sure we understand the suggestion. That means understanding what the people who have voted for the suggestion are trying to do and why they want to do it. It also means understanding what is preventing our customers from accomplishing their goal, what environment they are running in, and whether we can reproduce the issue ourselves. If we don’t have enough information to understand the suggestion, we will mark it as “needs more information”, and an email will get sent to the supporters of the issue. We try to be specific about what we need when we do this. Once we have enough information, we judge the number of votes to understand how aggressively we should peruse the suggestion. We get a lot of suggestions on our UserVoice, so we try and focus on the top-voted items.
The PowerShell PM team also walks through the when we meet to ensure nothing is catching us off-guard. We also make sure everything on the first page of “Top” is on our radar. If a top suggestion doesn’t have a reply yet, we want to make sure it has one by the next meeting.
The final step is to review all of the existing items and make sure they get updated appropriately. If an item meets a set of criteria including (but not limited to) number of votes and consensus that it is a good suggestion, we will walk through those items and update their status as follows:
If we understand what the suggestion is asking for, and we feel it has enough votes, we will go back and mark the suggestion as “investigate”. Essentially, this means we have handed it off to our teammates in engineering to help us understand what it would take to fix this issue. At this stage, the number of votes a suggestion has received is still important as it signals how many people have this exact problem. However, it’s never the only consideration.
If we are confident the suggestion is a good one and we can deliver on it eventually, we will mark the item as “in queue”. This does not mean we are actively working on an item and we will ship it in the next release. Instead, it means we have created a work item for it in our backlog. Our backlog is constantly shifting according to customer and business priorities, so we can’t promise an exact delivery date. This is where votes become extremely important. The number of votes translates directly into the number of customers we can satisfy by completing this work. Therefore, a highly-voted item is more likely to be completed before an item with a small number of votes.
Finally, we report on our UserVoice regularly at team meetings. I use PowerBI’s UserVoice integration to generate graphs showing us how we’re doing at triaging data, and how big our backlog is:
This chart shows the number of votes per category, as well as the number of triaged (“approved” or “closed” on this chart) vs untriaged (“published”) items by vote count. You can see we have a huge backlog in PowerShell engine – largely a consequence of our move from Connect. However, you can also see that we are doing an awesome job staying on top of the ISE and Tooling and DSC !
This chart shows the number of suggestions per day over the past two months. This happens to encompass two PowerShell Summit sessions, so it’s a little higher than normal.
We love taking in customer feedback via UserVoice. It’s really valuable to us, and we are so happy to be able to respond directly to your feedback. That said, it’s not without its challenges. The number of creative, important things people do with PowerShell is literally impossible to calculate. As a result, we have ended up with a lot of feedback spanning a huge number of areas. We’re doing our best, but your votes are what make it all count. So please, go to UserVoice and give us your suggestions and votes today. We’re listening!
Light
Dark
0 comments