One of the most valuable contributions to any piece of software is user feedback. We love the extremely open communication in our community, and we work hard to utilize the feedback it provides. We receive over 500 comments, emails, and forum posts every week- and many of them contain feedback on the calendar. There are even more votes each week on feature requests in our UserVoice tracker.
If you are one of the countless folks who has provided feedback, we first of all want to say: Thank you!! We also want to use this article to explain what we do with your feedback, how we measure it, and how we act on it.
There are two major categories of user feedback: bug reports and feature requests. We are going to dive further into both of these.
Once a bug is reported and confirmed, we then log it in our internal issue tracker. Each bug is given a priority based on how much it impacts the average site.
However, the priority that we first give those bugs is subject to change; and that’s where you come in. Each comment we receive that describes a similar issue is noted and logged. We use these logs to reprioritize things as needed. The more users who chime in, the higher we prioritize something. Some comments detail use-cases and scenarios in which the bug might be more severe than usual, and we factor that in as well.
Quantifying feature requests is surprisingly difficult. We read every comment we get via email, forum threads, or UserVoice. But describing a feature you want is challenging to do clearly, particularly if you don’t know technical terms or are less experienced with the nuts and bolts of WordPress. Sometimes feature request can be difficult to interpret correctly.
Furthermore, it’s hard for anyone (on either side of the conversation) to visualize all of the details that a certain feature entails. Often times small changes in those details can fundamentally alter a feature, determining its usefulness to the user. For that reason, our support staff takes the time to fully understand the issues, discuss them with the user, and then log the detailed comments in our feature tracker.
We tally up our list of comment feature requests alongside the UserVoice vote count, and use this as our metric for measuring user demand. However, it does not always make sense to build the most requested features first. We also have to weigh this against how long the feature takes to build. You might have 500 users request one feature, yet in the time it takes to build it you can build 10 other feature requests which thousands have collectively requested. We have to deliberate and decide the best way to spend our development resources.
Planning Releases Based on Feedback
Now that you know how we collect and quantify feedback, you are probably wondering how we act on it.
We plan our releases many months in advance; sometimes nearly a year out. We leave a little room in every release, for as long as we can, to slip in last minute priorities that might arise. Bugs are a priority category of their own, and can easily fill up the space allotted. They are typically addressed within 1-2 releases. Sometimes they are addressed even sooner in a hotfix.
New features, on the other hand, are often on our roadmap for many months before we have time to build them. We have often said we would love having infinite resources to plan, build, test, and polish all of these features immediately. But of course such a thing is not possible. Instead, we build a careful roadmap detailing when we will plan, develop, and test a new feature. This means that when we shift priorities on a feature request, such as moving it to an earlier release date, often times another feature request must be bumped back to a later date.
The closer we get to a release, the harder it gets to shuffle around which new features get included. Often we have begun laying the groundwork for a feature 1-2 releases prior. So adding new features to an upcoming release becomes exceedingly problematic. This is why when someone requests a new feature and asks if it can be implemented next week to meet their client deadline, or perhaps requests that it be implemented in the next release, we almost always have to say: It’s simply not possible. But that doesn’t mean we aren’t listening. We’re always processing feedback and working it back into our feature planning.
We hope this article helped shed some light on how much we value your input, and how it shapes the future of our plugins. From all of us at Modern Tribe: Thank you very much for using our plugins. And here’s to the next release!