Feedback Policy

Why are we doing this?

We get many feature requests and suggestions from our users.  We are using the Feedback Project, and its voting system, to manage this. We do this for two reasons.

Firstly, the voting system allows us to make informed decisions about which items we should work on. This allows us to use our resources most effectively. For example, if a user proposes a small change, the feedback project and the voting system allows other users to engage with each other and vote. This, in turn, allows us to easily gauge user interest in particular features. The voting system gives us a sense of which issues would satisfy the most users, and we can direct our development efforts accordingly.

Secondly, and perhaps more importantly, the voting system gives more transparency into the process for our users. Previous to this, requests were hidden from other users. If a user found that their suggestion was not implemented, they had no window into our decision making process. The open nature of the feedback project changes this in that users can see requested suggestions and can see the process through which their ideas can be brought to fruition. They can also actively engage with each other and build up support for particular items for users that share common needs.

This is common practice in other software markets, see Atlassian for example.

HOW DO SUGGESTIONS BECOME FEEDBACK ITEMS?

The Support team reviews your suggestions and feature requests along with the Product Manager and comes to a decision.

One of three things can happen:

  • "That's an interesting idea and it's super easy to implement, let's do this right away!"
  • "That's an interesting idea, let's put it in the Feedback project to see if other users are interested."
  • "That's an interesting idea but it's not currently in line with our product roadmap.  We may reconsider this in the future but for now, we will not implement this."

HOW DO WE CHOOSE?

Each product manager will choose highly voted issues that are in line with the thematic elements of a particular release. The decision for choosing a particular issue is based on the number of votes and the number of different clients that express interest.

So, how do we choose? Here are a few examples of guidelines we will be using.

  • More votes is good, this is obvious, the high number of votes raises an item naturally to our attention.
  • Having a good spread of votes across a range of clients and industries/sectors is also good. For example, having seven votes from seven different clients is better than having seven votes from seven different employees of a single organization.
  • If an issue is of interest for a particular theme then this may be implemented even if the number of votes is low.

Of course, there is some nuance in the final decision making process. The ideas explored above give a sense of the general guidelines that we will be striving to follow. If we decide to change our guidelines, we will update this document and will inform users of this immediately.

This leaves the issues that do not have a high number of votes and that are not tied to any of the themes from our roadmaps. For these issues it is less likely that they will be addressed. If the issue is of a high interest for you then please contact QPS to discuss alternative solutions.

IMPLEMENTATION

The top votes issues are regularly reviewed and we strive to resolve a target number for a particular release. For example, at least 3 out of the top 10. As QPS and our clients gain more experience with the Feedback project and process, we will likely adjust our targets. We will always strive to make our targets transparent to users. If issues are in the top and will not be done in a reasonable time then this will be updated/commented in the issue.