How a feature request gets built

The path from posting an idea to it shipping, what each status means, and how votes are used.

Posting a request

Post on the Feature Requests board. Before you do, search for an existing request. If one already exists, vote on it instead. One request with fifty votes carries far more weight than the same idea posted five times.

If you post a feature request on GitHub instead, nothing is lost. A maintainer labels it enhancement, moves it here, adds a comment with the direct link, and closes the GitHub issue. Follow it here from that point on.

A request is not a commitment

Posting a request does not mean we will build it. Every request starts in a review queue and is reviewed in batches.

The statuses

New / Open / Unreviewed. Just posted. Not yet reviewed.
Under Review. In the current review batch.
Accepted. We are going to build it. No date attached.
Planned. Queued to be built. A GitHub issue exists for it and is linked from the request.
In Progress. Actively being worked on.
Completed. Shipped in a release.
Declined. We are not building it. Always with a reason.
Deferred. Not now. We will revisit it.

Only Accepted and later appear on the public roadmap. Everything else is still visible and votable on the Feedback board.

Timing

Requests are reviewed in batches rather than one at a time, so a new request sits for a while before it gets a status. That is deliberate. It gives the request time to gather votes, and a request with few votes after three days is young rather than unpopular.
Accepted carries no date. It means we have agreed to build it, not that it is scheduled.
Planned is the status that means a GitHub issue exists and the work is queued.

How votes are used

Votes tell us what matters and they order our thinking. They do not decide on their own.

A request with fewer votes may be built first if it unblocks something larger.
A popular request may be declined if it takes PatchMon somewhere we are not going.

Either way you get a reason.

What happens after Accepted

A maintainer opens a GitHub issue for it and comments the link on this request. That is a person doing it by hand, not an integration.
The request moves to Planned.
When work starts, it moves to In Progress.
The pull request merges and closes the GitHub issue. The request here stays In Progress, because merged is not released.
When the release ships, the request moves to Completed with a link to its changelog entry.

If you voted on a request or subscribed to it, you are notified at each of these steps.

Why Completed waits for the release. Completed sends people looking for the feature in the version they are running. Flipping it at merge would be true for the source code and false for anyone who installs releases, so it waits until you can actually have the thing.

Following progress

Comments do not sync between here and GitHub. The linked GitHub issue is where the engineering discussion happens, and it is public, so you can read it without a GitHub account. You need an account only to comment there.

Comments left here are read by the team, but they do not appear on the GitHub issue.

Duplicates

If two requests describe the same thing, we merge them. Votes and comments are combined onto the surviving request, so nothing is lost by merging and no one has to re-vote.

If you want to build it yourself

Please wait until the request reaches Accepted before writing code. A feature pull request opened without an accepted request is labelled needs-accepted-request and is not merged until the request is accepted. It will not be closed.

See Contributing code for the full process, including the AI disclosure requirement.