How the roadmap works
A filtered view of the boards, the three tracks, and how phases decide what gets accepted.
The Roadmap shows what has been accepted and what is being worked on. It is not a separate list maintained by hand — it is a filtered view of the same posts you see on the boards.
What puts a post on the roadmap
Every post has one of six statuses. Three of them appear on the roadmap:
Status | On the roadmap? | Meaning |
|---|---|---|
Open | No | Posted, awaiting triage |
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 worked on |
Upstream | Yes | Accepted, but the fix belongs to the upstream project |
Deferred | Yes | 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 |
Because of this, acceptance and publication are the same act. Moving a post to Planned puts it on the roadmap immediately — there is no separate announcement to forget, and no roadmap that quietly drifts out of date.
The four tracks
Roadmap items fall into four tracks. A track says what kind of work an item is, and it decides which part of the version that item moves when it ships:
Track | Covers | Moves |
|---|---|---|
Services | New applications, migrations, retirements, new content |
|
Stability | Fixes, reliability, performance, upgrades, retrofits |
|
Documentation | Wiki pages and Help Center articles |
|
Phases | The deliberate platform shifts themselves |
|
The tracks are not a priority order. A Stability item frequently ships ahead of a Services one, because it is smaller and lower risk — see How work gets planned and shipped.
A single release almost always mixes tracks: one release can carry a new service, a dozen fixes and a documentation rewrite together. That is why each changelog entry names the tracks it touched, rather than being labelled with just one.
Phases shape what gets accepted
The platform moves in phases, and the current phase decides what is being worked on. During a stability or consolidation phase, a perfectly good request may sit in Under Review for a while — that is a scheduling decision about the phase, not a judgement on the request.
The phase is the first number in every version. See How versioning works for the full mapping.
Planned does not mean scheduled
There are no dates on the roadmap. Planned means accepted and queued; it does not mean a release date exists, and asking for one will not produce one.
Why your post might not be there
- It is still Open or Under Review — not yet accepted
- It was Closed — check the comments for the reason
Either way the post's timeline shows every status change and who made it. Nothing happens invisibly.
You can still vote on roadmap items
Voting on something already Planned is not wasted. Planned items are ranked against each other, and votes are part of deciding that order.
Roadmap versus changelog
The roadmap is what is coming. The Changelog is what has landed, with a version number attached. A post typically appears on the roadmap when accepted, moves across it as work progresses, and then shows up in the changelog when it ships.
Was this helpful?
Your feedback shapes what we write next.