We've changed how bug reports and feature requests work in the NetBird GitHub repository, and this article walks you through the new flow so you know exactly where to post and what to include.
The short version: new bug reports and feature requests start as GitHub Discussions, not Issues. The DevRel team validates them, and confirmed problems get promoted to Issues that engineering can pick up and work on.
NetBird had over 1,400 open issues. A lot of them were duplicates, stale, or things we couldn't reproduce. Real bugs that affect a lot of people were getting buried, and the team was spending more time triaging than fixing. Not sustainable.
So we restructured. The Issues tab is now a curated list of validated work the team is actively committed to. Everything else starts in Discussions, where the community can weigh in and DevRel can confirm before it turns into engineering work.
This isn't an experimental pattern. Projects like Ghostty and Renovate run this way and it works.
When you go to open something in the repo, you'll see three categories in Discussions. Pick the one that matches what you're posting.
For reproducible bugs, regressions, and unexpected behavior . If something is broken, this is where it goes first.
If you're not 100% sure whether it's a bug or a config problem, post it here anyway, or start in Q&A / Support and we'll move it over once we've confirmed it's a product issue. Same goes for intermittent issues. Include the trigger, frequency, timing, and any logs you have, and we'll work from there.
For new features, enhancements, integrations , and product ideas. Search first and add your use case to an existing thread when one already exists, that's more useful than ten separate discussions on the same idea.
Community traction matters here. Upvotes, replies, and detailed use cases feed into what gets prioritized. A clear problem statement ("here's what I'm trying to do and why it's hard today") is more valuable than a solution-only request.
For setup, configuration, self-hosting, and general usage questions . This is community support, no SLA. If you're on NetBird Cloud and need official support, use the Cloud support channel from the docs instead.
DevRel triages discussions on a regular basis. For bug reports, that means trying to replicate your issue with the info you provided. If we can reproduce it, the discussion gets promoted to a validated Issue in whatever repo the fix belongs to (core, dashboard, operator, docs, and so on). If we can't reproduce it, we'll comment in the discussion asking for more detail.
For feature requests, we look at community signal alongside roadmap fit. The ones with traction get evaluated for the roadmap.
Issues opened directly without a validated discussion will be closed and redirected to Discussions. Maintainers can still open issues directly when they spot something internally, that's the only exception.
The faster we can replicate your bug, the faster it becomes an Issue and gets fixed. The Issue Triage template walks you through everything, but the essentials are:
Do note: don't paste secrets, tokens, private keys, internal hostnames, or public IPs into a public discussion. Anonymize before posting.
The Ideas & Feature Requests template prompts you for the right things, but the high-value pieces are:
You can also flag whether you're willing to submit a PR or help test, that helps us route faster.
Don't report security vulnerabilities in public discussions or issues. Use the security policy on the repo instead. We'll take it from there privately.
One repo for all discussions. Everything goes in regardless of which component is affected. You don't need to figure out whether your problem belongs in core, dashboard, operator, or docs, that's our job during triage. When the discussion gets promoted to an Issue, it'll land in the right repo.
Search before posting. A few minutes searching existing discussions and closed issues saves everyone time. If you find an existing thread, add your use case or there, that signal is more useful than a separate post.
The forum is still around. forum.netbird.io hasn't gone anywhere. GitHub Discussions is the primary path going forward, but the forum is still listed as a community option.
**Slack is still good for chatting with the community. For anything that needs to be tracked or that other people might hit later, GitHub Discussions is better because it's searchable and persistent.
Not getting mass-closed. Now that we're not drowning in new unvalidated reports, we can actually work through the backlog properly. Some will be moved to Discussions for re-validation, some will get assigned to a maintainer, and some will be closed. This happens gradually, no fire drill.
That's the whole thing. The goal is simple: less noise, more action on the bugs and features that actually matter to you. If you have questions or feedback about the process itself, drop a comment in Discussions and we'll get back to you.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。