GitHub public roadmap for a repo: 4 ways

GitHub has no roadmap page for a repository, so a roadmap for your repo is something you assemble: milestones, a ROADMAP.md, a Project or labels, compared below with a template you can copy. 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, except the milestone facts, read on 2026-11-07.

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 add a roadmap to your own repository?

Pick the lightest option that matches how you plan, because each one trades effort for how much it shows. All four work on a public repository, and none needs more than write access.

Milestones are built into every repository. GitHub's documentation says a milestone page shows a description, a due date, a completion percentage and the open and closed Issues and pull requests in it (read 2026-11-07). A milestone answers "what is in 1.4?" well and "what comes after 1.4?" badly, because it is one goal at a time.

A ROADMAP.md costs nothing, and a link from the README gets visitors to it. It goes stale the day nobody edits it, and it does not link to the Issues behind each line unless you add the links.

A Project roadmap and lane labels are covered below. The first needs a Project beside your Issues; the second lives on the Issues themselves.

Is there a GitHub roadmap template?

GitHub does not ship one, so here are two you can paste. The first is a ROADMAP.md for the root of the repository. Replace the bracketed parts and link each line to its Issue.

# Roadmap

Last updated: YYYY-MM-DD. This is a plan, not a promise.

## Now
- [Short title of the work in progress](https://github.com/OWNER/REPO/issues/NUMBER)

## Next
- [Short title of what we plan to start next](https://github.com/OWNER/REPO/issues/NUMBER)

## Later
- [An idea we want but have not scheduled](https://github.com/OWNER/REPO/issues/NUMBER)

## Shipped
- [What shipped, newest first](https://github.com/OWNER/REPO/releases/tag/vX.Y.Z)

## How to ask for something
Open a Discussion or an Issue. We read both.

The second is the label set Gitback reads. With the GitHub CLI, run this inside your repository:

gh label create "roadmap: planned" --description "On the roadmap" --color 0E8A16
gh label create "roadmap: in progress" --description "Being worked on" --color FBCA04
gh label create "roadmap: complete" --description "Shipped" --color 5319E7

gh label create takes a name, a description and a six-character hex colour, and you need write access to the repository. Keep the names exactly as shown, including the space after the colon, because Gitback matches the label text.

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.
• 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.

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.
• 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.