How work gets planned and shipped
The three work streams, what triage actually weighs, and what 'done' requires.
Work on Think comes from three places. Feedback is the one you control, and it is the only one with a public queue.
The three work streams
Stream | Where it comes from | Visible to you? |
|---|---|---|
Feedback | Posts on the boards here, ranked partly by votes | Yes — boards, roadmap, changelog |
Maintenance | Updates, certificates, storage, backups, security patching | Rarely — only when something breaks |
Platform | Migrations, consolidations, replacing abandoned upstream projects | On the platform roadmap |
Nothing moves between these automatically. A person reads the boards and decides what becomes work — there is no integration that turns a post into a task.
The feature path
Status | What it means | Where it shows |
|---|---|---|
Open | Posted, gathering votes, not yet reviewed | Board only |
Under Review | Being evaluated for effort, risk and priority | Board only |
Planned | Accepted — no date attached | Board + Roadmap |
In Progress | Work has started in a repository | Board + Roadmap |
Complete | Released | Board + Roadmap + Changelog |
Closed | Declined, duplicate, or no longer relevant | Board only, with reason |
Planned means accepted, not scheduled. There is no date, and asking for one will not produce one.
The bug path
Bugs follow the same six statuses but are triaged on different criteria — see What happens when you open a bug. The short version: a reproducible bug that breaks something important skips the vote queue entirely. Votes matter far less for bugs than for features.
What triage actually weighs
Factor | Question asked |
|---|---|
Reach | How many people hit this? Votes are the proxy |
Severity | Is it broken, degraded, or merely imperfect? |
Effort | Hours, days, or a rewrite? |
Risk | Could this break something that currently works? |
Unblocking | Does something else depend on it? |
This is why a three-vote request sometimes ships before a thirty-vote one. The votes were not ignored — one took an hour and the other needs a migration.
What "done" requires
Before a change reaches you it has to clear the pipeline described in How a feature request gets built:
- Linting passes — YAML, containers, Helm charts
- The chart renders and validates against the Kubernetes schema
- Security scanning passes — SAST, IaC, and
checkov - Secret detection passes, including a historic scan of past commits
- Documentation is updated when behaviour changes
- The rollout succeeds and health checks pass
Documentation is not optional. A behaviour change without a wiki update is unfinished work, which is why documentation and retrofits get their own patch releases.
Phases
Think moves in phases, and the phase shapes what gets accepted. During a consolidation or stability phase, a perfectly good feature request may sit in Under Review for a while — that is a scheduling decision about the current phase, not a judgement on the request.
The phase is the major number in the version — see How versioning works.
What you can do to make something happen
- Write it clearly. A vague request cannot be estimated, so it stays in Under Review.
- Describe the problem, not just the fix. It allows a cheaper solution to be found.
- Get the affected people to vote. Five votes from people hitting the same thing is a strong signal.
- Add your use case in a comment. Concrete beats abstract every time.
- Accept that timing is not yours. The queue is real, and the phase is real.
Tracking it
Once accepted it is on the Roadmap. When it ships it is in the Changelog with a version number. You are subscribed to anything you posted or commented on, so you do not need to watch.
Was this helpful?
Your feedback shapes what we write next.