Posting this publicly based on internal conversation with @nickdb
First off, I really like the new community setup — it’s a great space for general discussion, DIY sharing, troubleshooting, and collaboration. That said, I think there’s room for improvement when it comes to handling bug reports and feature requests.
Right now, these posts often get mixed in with general threads, which makes it hard for both users and developers to track what’s important or gaining traction. I’d like to suggest a small structural improvement within the existing forum:
Create separate categories for bugs and feature requests
Allow sorting by upvotes by default so the most popular feature requests and most pressing bugs rise to the top
Keep things simple, without needing a whole new system—just clearer organization
Of course, the dev team would still decide what gets prioritized. But this way, community feedback is more visible, easier to follow, and more actionable. I think it would really strengthen the feedback loop between users and the team.
There is the tag bug report and the tag feature request, i usully just filter using those.
The problem with the bug reports usually is a fair portion of them are not exactly bugs.
People who do things like get involved in beta testing, mods, wider ranging use of the Victron ecosystem (the keen members) will post in the appropriate category and check first to see if there is a bug report or feature request already there to upvote, but there will be a large number of posts that will continue to end up in Q&A regardless.
guystewart
(Guy Stewart (Victron Community Manager))
6
It’s not the first time this suggestion has been made, and rebuked previously as well.
I will follow up with a bit more of the reasons why after others have had a chance.
Create two sub-categories under Development: “Bug Reports” and “Feature Requests.”
Enable Discourse Voting in each, with the default sort set to Votes so the hottest items float to the top.
Run a 3-month pilot, measure the results, and keep or revert based on data.
1 Why Categories Beat Tags for This Use-Case
Current Situation
With Dedicated Categories
Tags (bug_report, feature_request) exist but are scattered across every category. Newcomers rarely notice them.
A newcomer sees one obvious place to post, reducing duplicates and mis-tags.
Tagging is optional → high chance of missing / mistyping.
Choosing a category is mandatory. Worst-case mis-category = 1 click for a mod to move the entire thread.
Dev triage requires hunting for tagged posts across the forum.
Devs can bookmark one URL and get an automatically ranked backlog.
2 Why Voting ≠ “Popularity Contest”
Rapid triage: Devs land on the first page and instantly see which bugs are biting hardest or which features users are willing to champion.
Self-curation: Instead of 15 identical “+1” replies, folks up-vote, keeping threads tidy and searchable.
Focus for power users: Beta testers can spend energy reproducing top-voted bugs instead of guessing what matters most.
Note: Votes are advisory, not binding. The core team still decides priorities by effort, security impact, roadmap fit, etc.
3 Addressing Concerns Raised So Far
Concern
Response
“People mis-file non-bugs as bugs.”
True — but a Bug category quarantines the noise. Mods (or OPs) can move a thread back to Q&A with one click, and the rest of the forum stays uncluttered.
“Many posts will still land in Q&A.”
That will happen, but now mods have two obvious landing pads to relocate threads. Over time, users learn by example.
“We tried this before and it was rejected.”
I’d love to know what blocked it then.
4 Pilot Plan (Low-Risk, Reversible)
Create sub-categories under Development:
Development › Bug Reports
Development › Feature Requests
Each with a pinned “Read First” template (see below).
Install & enable Discourse Voting (takes ~5 min). Set category default sort to Votes.
Run for one quarter (June 15 → Sept 15 2025).
Measure success:
Average time to first dev/mod reply
Duplicate rate (% threads closed as dupes)
Net new votes vs. total threads (~signal-to-noise)
Decision point: If metrics show no benefit, merge categories back into the parent with two clicks and disable Voting. Zero tech debt.
5 Suggested “Read First” Templates
Bug Report Template
## Summary
_A one-sentence description of the problem._
## Expected vs. Actual
*What you thought would happen, and what actually did.*
## Hardware / Firmware / App Versions
- Inverter model & firmware:
- GX device & firmware:
- VRM portal version (if relevant):
## Steps to Reproduce
1. …
2. …
## Logs / Screenshots
_Please attach if possible._
Feature Request Template
## What problem are you trying to solve?
_A clear description of the pain point._
## Proposed solution
_Be as specific as possible (UI, settings, API call…)._
## Alternatives you’ve considered
1. Doing it manually
2. Third-party integration
3. …
## Links to related threads or docs
Templates make it dead-simple for first-timers to give devs the info they actually need.
6 What Success Looks Like
Cleaner main categories: fewer “Is this a bug?” drive-bys in Q&A.
Actionable backlog: top-voted items bubble up without constant moderator gardening.
Faster fixes/features: devs spend less time sifting and more time building.
Data-driven retros: after 90 days we’ll have hard numbers on duplicates, up-votes, and average response times — something we’ve never had before.
Thanks for reading this wall of text!
I’m keen to hear objections, improvements, or a flat-out “no” if that’s where we land. But given the low setup cost and easy rollback, I think a short pilot is worth a shot.
There are already a few special categories for EVCS, Venus OS, VictronConnect and VRM.
So the responsible devs have a place to look for bug reports.
If there is only one category for all bug reports it’s harder for the devs to find the reports they need to see.
May new users don’t use the search function or the already existing categories, so it’s more work for the mods to move that topics (and that is more than just one click).