What happens when you open a bug
Triage, why bugs skip the vote queue, and the pipeline a fix goes through.
This is the bug side of How work gets planned and shipped. Bugs are triaged differently to ideas, and the difference matters.
The moment you post
Your post lands on the Bug Reports board with status Open, and you are subscribed automatically. You need do nothing else to stay informed.
Triage
An administrator works out three things: can it be reproduced, how many people does it hit, and how bad is it when it hits.
Outcome | What it means |
|---|---|
Planned | Reproduced and accepted; appears on the Roadmap |
Under Review | Real, but needs investigation before it can be sized |
Needs Info | Could not be reproduced from what was written |
Duplicate | Merged into an existing post, which keeps the votes |
Upstream | Real, but the fix belongs to the application we deploy |
Out of Scope | Not ours — wrong channel, or outside what Think does |
Closed | Closed without action, always with a reason |
Bugs skip the vote queue. One person reporting a service is down outranks twenty people wanting a new button. Votes are how features are prioritised; severity and reach are how bugs are.
"Cannot reproduce" is not a rejection
It is the most common reason a bug stalls, and it almost always means a missing detail: browser, exact steps, whether you were signed in, which service, what time.
If you are asked for more, supplying it is the single fastest way to unstick your post. If a bug has gone quiet in Open, check whether someone asked you a question.
While it is being fixed
In Progress means someone is on it. The fix is a change to a git repository, not an edit to a live system — so it goes through the same pipeline as everything else:
Stage | What runs |
|---|---|
Lint | YAML, container and Helm chart linting |
Validate |
|
Security | SAST, IaC scanning, |
Deploy | ArgoCD reconciles the cluster to match git; rollout is gradual |
Runtime | NeuVector watches container behaviour once it is actually running |
A failing health check stops the rollout rather than taking the service down with it. This is also why a "one-line fix" is rarely one line of work — the fix is small, the verification around it is not.
The post's timeline records every status change and who made it, so nothing happens invisibly.
Urgent bugs
A bug that takes a service down does not wait for the next triage pass. If something is genuinely broken for everyone, say so plainly in the post, and use Discord or ThinkComplaints if it needs escalating rather than queueing.
When it is fixed
Status becomes Complete and you are notified. Fixes anyone would notice also appear in the Changelog, carrying a patch version — see How versioning works.
If it is still broken for you after it is marked Complete, say so on the same post rather than opening a new one. That keeps the history in one place.
Was this helpful?
Your feedback shapes what we write next.