GitHub has no single roadmap feature. A roadmap is a Projects board set to its roadmap layout, feature requests arrive as issues shaped by a form, and ranking them is a sort by reactions. Each piece is free, and each needs its own setup. A public project can be read by anyone, but every request, reaction and comment on it needs a GitHub account.
Building a roadmap in GitHub Projects, step by step
A GitHub Project is a table or board of issues, pull requests and draft items with custom fields attached. The roadmap layout turns one of those fields into a timeline. Steps below are from GitHub's own help pages, read 3 October 2026.
- Open a Project and add or switch to a view, then set that view's layout to Roadmap.
- Click the calendar icon labeled Date fields in the top right. GitHub tries to reuse date or iteration fields already on the project; create a new one with the plus icon if none fits.
- Choose which field is the Start date and which is the Target date. An iteration field can stand in for either one, and iterations can run any length, including a break.
- Click the gear icon next to the search bar, choose Group by, and pick a custom field to group rows on. Title, labels, reviewers and linked pull requests cannot be the group.
- Click the marker icon labeled Markers to show vertical lines for iterations, item dates, or milestone dates on the timeline. A milestone is not a grouping option on the roadmap, only a marker.
- Pick a zoom level, Month, Quarter or Year, from the search icon, to control how much of the timeline shows at once.
- Drag an item's bar to move its dates, or drag either end to resize it, the same way a Jira Timeline bar works.
Nothing here needs a paid plan. Projects, including the roadmap layout, custom fields and views, is the same feature set on GitHub Free, Team and Enterprise Cloud, read on GitHub's pricing page 3 October 2026.
Making the project public
A Project's visibility is set independently of any repository it draws from. GitHub's own documentation states it plainly: for a public project, everyone on the internet can view the project; for a private one, only people granted at least read access can see it.
That visibility covers the board itself, not every item on it. To view a specific issue or pull request inside the project, a visitor also needs read access to the repository that item belongs to, so a public project built from a private repository's issues still hides those issues from an outsider even though the board loads. A visitor with no GitHub account at all can open a fully public project, read every card, filter and sort the view. They cannot create a view of their own, drag a card, change a field, or comment, because every write action on github.com needs a signed in account, the same account GitHub also requires to react to an issue.
The public roadmap repository pattern
Some companies skip Projects for the public facing piece and run the roadmap as a plain repository instead, often named roadmap, holding nothing but issues that stand for planned work. GitHub does exactly this for its own roadmap: the github/roadmap repository's README states it is for communicating GitHub's roadmap, where visitors learn what features are coming, what stage they are in, and when to expect them, and that its issues are read only with conversations locked.
The pattern trades a Projects board for something anyone already searching GitHub can find and link to directly: one issue per planned feature, each carrying its own URL, discoverable the same way any other repository is. What it gives up is everything a board's fields provide: no date, no custom status field, no roadmap timeline inside the repository itself, just a list of issues a maintainer updates by hand.
Feature requests through issue forms and labels
A plain issue has a single free text box. An issue form adds a structured intake for feature requests. GitHub's documentation puts the file at /.github/ISSUE_TEMPLATE/, as a YAML file ending in .yml.
Every issue form file needs name, description and body at the top. The body is a list of fields, each one of a documented type: markdown for static text, input for a single line, textarea for a longer one, dropdown for a fixed list of choices, and checkboxes for a list a reporter can tick more than one of. A top level labels key attaches one or more existing labels to every issue the form creates, but GitHub's docs are specific that a label named in the form and missing from the repository is not created automatically, so the label has to exist first. A top level projects key, formatted as OWNER/NUMBER, adds the new issue straight onto a Project, provided the reporter has write access to that project or the project's auto add workflow is turned on.
Voting with reactions, and sorting by them
GitHub's vote is the reaction bar under an issue, the same eight emoji available on any comment. There is no vote count field separate from it, so ranking requests by popularity means ranking issues by their thumbs up reaction.
GitHub's search documents the qualifier for that directly: sort:reactions-+1-desc sorts a search's results by the count of 👍 reactions, most to fewest, which also means it only counts that one reaction, not the other seven. A search like is:issue is:open label:feature-request sort:reactions-+1-desc in a repository's issue search box produces the ranked list. Reacting needs a signed in GitHub account, the same requirement that applies to opening an issue in the first place, so a reaction count only ever reflects people who already have one.
Visual Studio Code ranks its requests this way and puts a threshold on top. A request the team does not plan to build has 60 days to reach 20 thumbs up, or a bot closes it. Of 28,886 VS Code feature requests, 6,376 were closed that way, with a median of one upvote each, and of those filed since July 2020 that did pass twenty, 53.0 percent are still open in the Backlog. Across the 1,000 most starred repositories, 72.1 percent of feature requests have no thumbs up at all.
What each plan costs
| Plan | Price a user a month, read 3 October 2026 | GitHub Projects | Private repositories |
|---|---|---|---|
| Free | $0 | Tables, boards and the roadmap layout, custom fields and views, unlimited projects | Unlimited, unlimited collaborators at no charge |
| Team | $4 | Same feature set as Free | Unlimited, unlimited collaborators included |
| Enterprise Cloud | $21 | Same feature set as Free | Unlimited, collaborators billed per seat |
Projects itself carries no separate price on any plan. What a paid plan buys is seats on private repositories and the governance features layered on top, not a bigger roadmap.
What none of this gives you
Every piece above assumes the person looking at the request already has, or is willing to make, a GitHub account. A reaction, a comment, an issue form submission, all need one. 634 public feedback boards measured in October 2026 found a median request carrying 2 votes, the poster's own included, on boards built for customers to vote on. A public GitHub project is visible without an account, but reacting to shape its order is not.
The other gap is what happens once something ships. Closing a GitHub issue notifies the people subscribed to it: whoever opened it, commented on it, was assigned or mentioned, or clicked Subscribe. A thumbs up is not on GitHub's list of actions that subscribe someone, so most of the people who voted with a reaction hear nothing when it ships, and nobody who only read the roadmap does either.
A public roadmap or feedback board built next to GitHub issues is the pattern for closing both gaps without replacing the tracker. It covers GitHub issues and reactions as a feedback channel in full, including when a separate board does and does not earn its place.
VoteFirst beside GitHub
VoteFirst is a public board and roadmap a visitor votes on without an account; a cookie identifies them instead of a login. When a request ships, every voter who was signed in when they voted gets one email, and an anonymous vote gets none because there is no address to send to. Lite is $9 a month for one project, Pro is $39 for unlimited projects, a custom domain, the API and a team.
VoteFirst has no GitHub integration of any kind: no issue import, no sync either direction, no GitHub login. What it does have is the API and a CSV export, so moving a request between the board and an issue tracker is a script or a person, not a built in sync.
14 days, a card at signup, then $9 or $39 a month.