What happens to your feedback request
The statuses a request moves through, what Deferred and Upstream mean, and the pipeline it clears before shipping.
This is the feedback side of How work gets planned and shipped, and the counterpart to What happens when you open a bug. For how to write the post in the first place, see Where to post feedback.
The statuses
Every post — feedback or bug — moves through the same set:
Status | Roadmap | Meaning |
|---|---|---|
Open | No | Posted, gathering votes, not yet reviewed |
Needs Info | No | Waiting on you — it cannot move until a question is answered |
Under Review | No | Being evaluated for effort, risk and priority |
Planned | Yes | Accepted and queued — no date attached |
In Progress | Yes | Actively being built |
Upstream | Yes | Accepted, but the change belongs to the upstream project |
Deferred | No | Accepted in principle, but not in this phase |
Complete | Yes | Released |
Closed | No | Closed without action, with a reason |
Duplicate | No | Merged into an existing post, which keeps the votes |
Out of Scope | No | Not something Think will take on |
1. Votes gather
One vote per person per post; they cannot be stacked, and totals are public. A comment describing your use case makes a request concrete, and concrete requests get built.
2. Triage
An administrator reviews it and picks one of the statuses above. Three are worth explaining, because they are easy to misread:
- Deferred is not a rejection. The idea is good, but the platform is in a phase focused elsewhere — see How versioning works. It will be revisited.
- Upstream means we agree and cannot do it alone. The feature belongs to the open-source application we deploy, so it is requested there and your post tracks it here.
- Out of Scope means Think will not take it on — it belongs to a different service, a different channel, or is outside what the platform does. Always with a reason.
3. It gets built
In Progress means work has started. For a Think service that almost always means changing a git repository rather than editing a live system — the deployment is defined in git, and the cluster is reconciled to match it.
4. It gets tested and scanned automatically
Nothing deploys on the strength of "it worked on my machine":
Stage | What runs |
|---|---|
Lint | YAML, container and Helm chart linting |
Validate | Schema validation against Kubernetes, plus a full Helm template render |
Security | Static analysis, infrastructure-as-code scanning, and policy checks |
Secrets | Secret detection, including a historic scan of past commits |
Hygiene | Formatting and pre-commit checks, auto-fixed where possible |
A change failing these does not ship. The Helm render matters more than it sounds: it catches a broken chart before the cluster ever sees it.
5. It gets published and deployed
The chart is packaged and published, then handed to ArgoCD, which applies it and reconciles the running state to match git. Rollouts are gradual — containers are replaced progressively, and a version failing its health checks stops the rollout instead of taking the service down.
NeuVector covers what scanning cannot: runtime container security inside the cluster, watching what containers actually do once running, rather than what the code looked like beforehand.
6. It ships
Status becomes Complete and it appears in the Changelog with a version number. If you voted or commented, you are told.
Whether it lands as a subphase or a patch depends on what it was — see How versioning works.
How votes are actually used
Votes are a major input, not an automatic queue. Effort, risk, and whether something unblocks other work all count. A three-vote request taking an hour often ships before a thirty-vote one needing a rewrite — and the reverse happens when enough people want something badly enough to justify the work.
Voting on something already Planned still helps: it ranks that item against everything else queued.
Was this helpful?
Your feedback shapes what we write next.