Refreshing Our Feature Request Process: What You Need to Know

Feature Requests
1

Refreshing Our Feature Request Process: What You Need to Know

We’ve heard your feedback, and we’re taking action. Since launching our feature request forum, we’ve received over 400 requests. This is a testament to your engagement. However, many requests have been pending for a long time, and we’re cleaning up the forum to make it more effective.

What’s Happening Now

We’re actively reviewing and cleaning up feature requests. We appreciate your patience as we work through this. During this process, we’re:

  • Closing requests that won’t be implemented or don’t align with our vision
  • Closing posts older than 3 months with low engagement to free up votes for active priorities
  • Consolidating duplicate requests to give popular features proper visibility
  • Updating statuses on requests we’re considering or have already implemented
  • Those closed will be archived shortly after to clean up the list and allow community members to see the open items available for voting

Setting Clear Expectations

Roadmap inclusion doesn’t guarantee implementation. Technical constraints, shifts in priority, or unforeseen challenges may prevent implementation.

Not all requests align with our vision. TrueNAS is designed as an appliance, not a general-purpose OS. Requests that fundamentally change this identity won’t be accepted. Security is also a top priority; requests that could compromise TrueNAS security won’t be implemented.

Some feedback belongs elsewhere. For tweaks to existing features, usability improvements, or UI refinements, use the UI Feedback link within the product for faster implementation.

How You Can Help

  1. Be patient with us during this cleanup—we’re evaluating hundreds of requests
  2. Review your voted requests and reallocate votes as items are closed
  3. Search before posting to avoid duplicates
  4. Be specific and clear about the problem you’re solving, not just your preferred solution
  5. If a request didn’t get enough votes the first time, reposting it exactly the same way probably won’t lead to a different result. Consider reframing it with a fresh perspective to help it resonate better with the community.

Our Commitment

Once complete, you’ll have a clearer, more focused forum where your votes carry more weight on current priorities. We’re committed to transparency and ensuring every request gets evaluated fairly.

Thank you for being part of the TrueNAS community and for your patience during this process.

Questions? Drop them in the comments below.

3 Likes
3

I already see the problem with this. Allow me to explain.

You have a round of new feature requests. Users have votes (now “freed up”) to use. If a user passionately wants a new feature they will vote for it. If a user supports a new feature (maybe less passionately than other features), they are still likely to vote for it.

This means that feature requests which were created early into the “new 3-month session” can receive an early batch of votes.

If someone makes a feature request shortly after this, they will not receive as many votes, since users have already spent their free votes. This unlucky feature request is more likely to be closed by the end of its 3-month cycle, since users who might have voted for it couldn’t.

Here’s the game: The same feature request would have better chances of collecting votes if the person just waits for the current batch (approx. 3-month) to all expire, and then time their request at the perfect moment to maximize votes, when the bulk of votes are “freed up” again.

From the user’s perspective, this feels more like game theory than actually improving a product.

EDIT: I am planning to write a detailed feature request for incorporating checkpoints with the middleware and GUI, but I am nervous about “timing it just right”, or else no one can vote for it because their votes are “tied up” for about 3 months. If I don’t time it right, mine will also die on the vine because not enough votes will be freed up for 3 months.

If I submit it too soon, I’ll hurt my chances.

3 Likes
4

@winnielinnie I understand that, as I am sure you can appreciate, we need to get down to a much smaller number of requests so that community votes can mean something. We’ve accepted that the lack of review of these has created this situation, and we need to get to a better state. The aim is to clean it up and then actively maintain review of items. The 3-month piece is more of a short-term necessity. Over 300 open items are not doing anyone any favors. If someone feels their request was overlooked in this cleanup process, they can resubmit.

Going forward, items that lack traction may be closed more quickly, while those that do will receive a review and a decision on whether they will be moved to the roadmap or not.

3 Likes
5

Also to highlight, if you want to see a cleaner list of just items open use the following: Feature Requests - TrueNAS Community Forums

1 Like
6

Business improvement processes exist in enterprises mostly to prevent investment in non-priorities while creating the impression of engagement with staff or customers for the relatively small group of people who are vocal.

Keep in mind how many customers TrueNAS has total vs. how many are paying for the development work vs. how many votes a high-engagement feature request gets here… Brilliant ideas aligned with the product direction are not going to wait for the 3 month timeout. And as for the rest…

So Winnie, I think you are overthinking and should just post your idea. Checkpoints are a differentiating feature of ZFS that TrueNAS should leverage. You might find your idea is considered brilliant and aligned. Getting it on the board 3 months earlier may mean it’s in a product 3 months earlier. And if it isn’t aligned it isn’t going to be implemented even if it gets votes.

Having said all that I appreciate the effort made by TrueNAS to engage us and also to give faster feedback on ideas.

2 Likes
7

@ABain - I like the canned responses. You might make them more formal on your end, so that another person can take over later, yet use the same canned responses.

Of course, this does not imply that canned responses never get updated. Nor new canned responses never added. Both should be done as needed.

(Gee, these double or triple negatives give me a headache!)

1 Like
8

Done.

1 Like