TrueNAS users,
We’ve created a new Forums Category today, Feature Requests
This category will be leveraged in the future to replace our old Jira Suggestion tickets. It includes the ability for you, the community to suggest features, as well as provide voting on which features you think are most desirable to land in a future update to TrueNAS.
For more details on how voting and the suggestions work, please take a look at the Readme.
I already have a few in the queue, but I’ll need to rewrite them so they work for this forum.
Yes, I know. SCALE only. That’s fine. I’m an altruist.
As a note to myself and others, so that I don’t forget:
exposing and leveraging the ZFS “checkpoint” feature in the GUI / middleware
exposing and leveraging the ZFS “bookmark” feature in the GUI / middleware
seamless “staggered snapshots” under a single periodic snapshot task
simple “one-click” manual backups, using ZFS replications under the hood, which can be used for quick plug-and-go USB drives, a la Syncoid (often people don’t use ZFS to backup their data due to the extra complexities and costs involved; not everyone has a remote server or the wallet to build another NAS server)
“Linux sandboxes” integrated into the GUI (but you don’t need me to tell you that)
It would also be good if you could select a list of datasets like you can in the replication tasks. Would mean not having to choose from a snapshot task per dataset (or more) OR a single snapshot task per pool and excluding datasets manually.
Yes, but with a GUI, of course. 
Those are all good ideas, but posting them here in a reply does us no good. Please put them in the Feature Requests category so they can be fleshed out and voted on for official consideration.
Those weren’t the fully written feature requests. Just a “scratch pad reminder” to myself and others.
Others can feel free to steal those ideas too, if they’re willing to write up a fleshed out feature request(s) in the subforum.
I was going to ask for CORE based on FreeBSD 15 
FreeBSD 15 hasn’t even reached STABLE, let alone RELEASE.
Lol, don’t be starting that nonsense. I said realistic Feature Requests 
You lost my attention at that point.
Is there a way to track which features you voted for?
Yes. If you go to the category, you can view “My Votes”
I think there might exist another underlying problem with “limited votes”.
Older feature requests will favor more “votes” because a user has more votes to offer. This means that feature requests which are posted later will naturally see fewer votes, since people would be reluctant to remove their votes from previous requests.
Perhaps there can be a way that a vote’s “usage” is reclaimed after a period of time has passed?
Here’s an example:
This will also prevent someone’s votes being “held up” by a feature request that has accumulated votes, but hasn’t been “accepted” yet. Therefor, the user doesn’t need to play this “back-and-forth” triage game with their votes.
iX just needs to elaborate the existing feature requests, either accepting them or rejecting them, freeing votes in the process.
@Davvo: Let’s take this example: Make forum posts wider
I voted for it.
It currently has 7 votes.
After more time passes, I might have to consider “removing” my vote, so that I can vote for a different feature request that someone posts later. This will bring “Make forum posts wider” back down to 6 votes, further hurting its chances of acceptance. It’s a self-fulfilling sabotage.
But in reality, I’d rather keep my vote with “Make forum posts wider”, and let it accumulate more votes over time. But this is also a problem, because I lose “voting power” for feature requests that people create later.
So we end up having to play this game on gambling: “Do I take my chances and leave my vote here, and soon it will be clear whether the request will be accepted or rejected? Or do I just go ahead and remove my vote so that I can vote for this other issue?”
This is expected behavior. Every user has just one bucket of votes. Some items may take a long while to build critical mass, so you have to be strategic on your voting activity.
You may have 5 votes cast on 5 items, but then somebody proposes something way more interesting. You need to decide which item you will remove a vote from to reallocate to the new hot proposal to show your preference in the exact moment. If any of your 5 items is accepted or closed, your vote will be released and you can re-allocate it back to that lower priority item.
Its a way to make sure that hot things bubble to the surface, no matter when they are proposed. We can have something interesting come in at any time, and users should feel free to re-evaluate if they want to move votes around to bubble the new thing to the top.
We formally review proposals every 6 months in our scoping phase for new TrueNAS SCALE releases. However we have a team here internally that also will keep an eye on things and might accept / reject items out of cycle based on merit and urgency as well.
Speaking of votes…
When feature I voted for is accepted, should I remove my vote and use it elsewhere?
Asking just to be sure. I wouldnt want it to be “unaccepted” 
I might not have been clear. I meant that this affects voting and creating feature requests. Those who create requests are affected by this just the same, if not more heavily, than those who vote.
Those who create feature requests later (even if they are valued more than older feature requests) are at an unfair disadvantage because of the system itself.
It might not be as obvious now, but with time it will become more and more so.
EDIT:
I don’t believe it will work that way. There’s an “inertia” involved in votes that were already cast.
I’ll try to illustrate an example:
December 2024:
Bob posts a feature request and a bunch of people find it to be “pretty good” and vote for it.
March 2025:
Sally posts a feature request that most of the same people (who voted before) find it to be “REALLY AWESOME!” But what is the “conversion”? How many of them will go out of there way to find older votes to “triage” and decide to remove, so that they can now vote for this instead?
It’s this unfortunate inertia that “pre-bleeds” votes from later feature requests that don’t have the same momentum as earlier feature requests… even if the later one is more favored in general.
We might not notice it now, but I suspect with time it will become more evident.
EDIT:
TL;DR version:
It’s easier and more convenient to click “Vote” for something you like when you have many votes to spend.
It’s less convenient and requires more steps to review your older votes, weigh them, and decide to remove a vote just so you can vote for a newer issue (even if the newer issue is just as favored or even slightly favored more.)
Hence, over time, feature requests made later have a natural disadvantage, all things being equal.
Nope, you gain the vote back.
