GitHub public roadmap: Projects view or labels

GitHub has no roadmap page for a repository. You can get close with a public GitHub Project in the roadmap layout, which works well for a team planning against dates, but it asks you to maintain a Project beside your Issues and it shows outside visitors only what their repository permissions allow. This guide sets that up first, using GitHub alone, then shows how Gitback builds a public roadmap from the Issues and labels you already have.

The GitHub facts below come from GitHub's documentation, read on 2026-09-24.

Does GitHub have a public roadmap page for a repository?

No. GitHub's documentation describes no dedicated public roadmap or changelog page for a repository. Two documented features come closest:

• A public GitHub Project with a roadmap layout. A Project can be listed on the repository it belongs with, and for a public Project, "everyone on the internet can view the project."
• Releases. Releases are based on Git tags, anyone with read access to the repository can view them, and generated release notes list the merged pull requests and contributors. Releases record what shipped; they say nothing about what is planned.

When people search for a "GitHub public roadmap", they usually want the first of these, or a page that looks like a product roadmap and is fed by GitHub. (Search suggestions for the phrase also include GitHub's own product roadmap, which is a different thing: the plans GitHub publishes for Copilot and Actions.)

How do you make a roadmap with GitHub Projects' roadmap view?

You add your Issues to a GitHub Project, give the Project date or iteration fields, and switch a view to the roadmap layout. GitHub describes a Project as "an adaptable table, board, and roadmap", and any view can use one of those three layouts.

1. Create a Project for the repository's work and add the Issues you want on the roadmap.
2. Add the fields the roadmap positions items by. The roadmap uses "your custom date and iteration fields to position your issues", so you need either a start and target date or an iteration field.
3. Open a view and change its layout to roadmap. The roadmap is "a high-level visualization of your project across a configurable timespan."
4. Set the zoom. GitHub offers three levels: month, quarter or year.
5. Plan by dragging. Dragging an item changes its start and target dates or its iteration, and the timeline draws markers for iterations, item dates and milestones.
6. Make it public. Project admins and organization owners control a Project's visibility; set it to public.
7. List the Project on the repository, so visitors reach it from the repository page.

That gives you a timeline your team edits in GitHub and the internet can read.

What does a public roadmap need that a Projects view does not give outside visitors?

A public roadmap needs to show every item to everyone, and a Project does that only when the permissions line up. GitHub is explicit that the Project and its items are separate questions: a public Project is visible to anyone, but to view an item in it, "someone must have the required permissions for the repository." Issues from a public repository are fine. Issues from a private repository stay hidden from outside visitors, even on a public Project.

The rest is upkeep. A roadmap view is built from Project fields, so every Issue has to be added to the Project and given dates or an iteration before it appears where you want it. That is a second place to keep current beside the Issue itself, and a timeline suits a team planning to dates better than a project announcing "planned, in progress, done" to its users.

A Projects roadmap does several things better, and they are worth keeping if you rely on them: dates, iterations, milestones on a timeline, and drag-to-reschedule planning. Gitback's roadmap has none of those.

How does Gitback build a public roadmap from Issues?

Gitback reads the repository's open Issues and sorts them into four lanes by their labels, so the labels are the roadmap and there is nothing else to sync. Every Gitback Board carries a Roadmap Module (one of five, beside Feedback, Changelog, FAQs and Issues, and reached with the r key), and it works like this:

• Three labels make three lanes. roadmap: planned, roadmap: in progress and roadmap: complete put an Issue in Planned, In progress or Complete. The roadmap: prefix keeps them apart from labels the repository already uses.
• Open is the absence of a label. An open Issue carrying none of the three sits in the Open lane, so nothing on the repository is left off the roadmap. Gitback fills that lane with a GitHub search for open Issues that excludes each lane label by name and leaves pull requests out.
• One lane per Issue. An Issue carrying two lane labels appears once, in the earlier lane: Planned beats In progress, which beats Complete.
• Your own labels can count. A Client can map labels the repository already has onto the lanes, for example enhancement onto Planned, in the repository's .gitback/config.yml. Both the mapped label and the roadmap: label then put an Issue in that lane.
• Moving a card is a label change. A Client (a GitHub account with write access to the repository) can drag a card between lanes. The drag removes the old lane label and adds the new one on the Issue, through GitHub's API and under the Client's own GitHub account. Anyone else sees the board read-only.
• A card shows its 👍 count. Each card carries the number of 👍 reactions on the Issue, read from GitHub.
• Each lane loads 25 cards at a time and pages further on request, one lane at a time.

Because the lanes are labels, the roadmap is visible on github.com too: filter Issues by roadmap: planned and you get the Planned lane. Gitback caches the read for minutes, not hours, because a Client may also relabel Issues in GitHub's own interface, where nothing tells Gitback a change happened.

How do you set up a Gitback roadmap for your repository?

You open a Board for the repository, claim it, and label Issues. The getting-started guide covers the first two steps in detail.

1. Open the repository's Board from Open a Board by pasting its URL.
2. Claim the Board by signing in with a GitHub account that has write access.
3. Put roadmap: planned, roadmap: in progress or roadmap: complete on the Issues you want in those lanes, on GitHub or by dragging cards on the Board. Leave the rest unlabelled; they appear under Open.
4. If you already track status with your own labels, map them onto the lanes in .gitback/config.yml instead.

Public repositories have unlimited Boards on every plan; private repositories and custom domains depend on the plan, listed on the pricing page. The other Modules are on the features page, and more guides are in Guides.

What does Gitback's roadmap not do?

It has no timeline and no dates. These are the limits, taken from the code:

• No GitHub Projects. Gitback neither reads nor creates a GitHub Project. An earlier design provisioned a Projects board and a separate roadmap repository; both were dropped, and the roadmap is labels on the repository's own Issues.
• No dates, iterations or milestones. A card carries its title, number, labels, assignee, sub-issue progress, 👍 count and timestamps. There is no timeline view.
• No priority. A repository has no standard place to hold priority, so every card's priority is left empty.
• Only open Issues. Every lane reads open Issues. Closing an Issue takes it off the roadmap, including one labelled roadmap: complete, so shipped work stays on the board only while its Issue is open. Releases and the Changelog Module cover what shipped after that.
• Four fixed lanes. You cannot rename them or add a fifth. Mapping your own labels onto them is the only customisation.
• Voting on a roadmap card is not saved yet. The count on each card is the Issue's 👍 total from GitHub, but pressing the vote button on a Roadmap card lasts only until the page reloads; nothing is written to GitHub.

If you need a dated plan for your own team, keep the Projects roadmap view. If you want a public "what's planned, what's in progress, what's done" page that updates when you change a label, that is the job Gitback's roadmap does.