GitHub Projects: project boards from issue to release

A milestone tells you how many items are closed. It can't answer the CEO's other question: “Who is doing what this week, and are we on track?” A spreadsheet next to GitHub could, for about two days, until it falls out of date.

GitHub Projects is GitHub's planning space on top of issues and pull requests. Three facts make it different from a spreadsheet:

• A project belongs to an organisation or a person, not to one repository, so it can hold issues and pull requests from several repositories at once.
• Every item is the real issue or pull request, not a copy. When #159 was closed, every project holding it showed that at once.
• Nothing moves out of the repository. The issues stay where they are; the project only arranges them.

So CatChow creates a project called “Loyalty launch” in the catchow organisation and adds the milestone's items. From then on, the plan and the work can't drift apart, because they are the same objects seen from two places.

A project fills up in three ways.

• Existing issues and pull requests. Paste a link or type # in the project and search by number or title. Items can come from any repository the project's owner can see.
• Draft items. A quick note that lives only in the project: a title, a description, and the same fields as any card, so it can sit in a column and carry a priority. It has no number and no repository, and the repository's issue list doesn't show it. When the idea is ready, choose Convert to issue, pick a repository, and it becomes a real issue with a number.
• Workflows can add items for you, for example every new issue with a certain label. You'll meet them in a moment.

Draft items suit half-formed thoughts in a planning session: “Ask support for a loyalty FAQ”. They are not a place to keep real work, because nobody outside the project can find or reference them. And removing an issue from a project only takes the card off the plan; the issue itself stays open in its repository.

A project has views, saved as tabs along the top. Each view uses one of three layouts, as of 2026.

• Table is a spreadsheet: a row per item, fields as columns, editing right in the cell. It's the fastest way to set the priority of twenty new issues in one sitting.
• Board is a kanban board: cards in columns, one column per value of a field, usually Status. Dragging a card to another column changes that field. Developers live here: In progress when they start, In review when the pull request is ready.
• Roadmap lays items on a timeline by a date or iteration field, with markers such as a milestone's due date. It answers “when?”, which makes it the natural view for a CEO.

Filters, sorting and grouping are not a layout of their own: every view has them and saves them. A filter like label:bug is:open works in a table, a board or a roadmap.

All views show the same items. Change a field in one, and every other view shows the change.

Board columns come from fields. Status is built in, with Todo, In Progress and Done to start with. Add a fourth option, In review, between the last two, and the board gets a fourth column at once.

Issues bring their own fields into the project: assignees, labels, milestone, linked pull requests, even sub-issue progress such as “1 of 4”. These are the issue's fields, so they look the same in every project and on the issue page.

On top of that, a project can have custom fields of its own. For the loyalty launch, three are enough:

• Priority, a single select with P1, P2 and P3;
• Target date, a date that feeds the roadmap layout;
• Iteration, one-week slots from Monday to Friday, so “what's in this week?” becomes a filter instead of a meeting.

Custom fields belong to the project, not to the issue. #163 can be P1 in “Loyalty launch” and have no priority in another project. On the issue's own page they appear in the Projects part of the sidebar, one block per project.

By Wednesday the “Loyalty launch” board has four columns of real work. #164, the launch switch, waits in Todo. The parent #147 sits in In progress with “1 of 4” sub-issues closed, next to #163, spending points at checkout (Daniel, P1, target 5 November), and the draft programme page #157 by Emma, the content marketer. #162, the balance, is in In review with its linked pull request #166. #159 is in Done, closed by #165.

Read a board from right to left: what's finished, what's waiting for a reviewer, what's being built, what hasn't started. The right-hand columns are closest to customers, so they matter most this week.

The review column is where a PM can help most. Work in it is built and waits for people: an approval, an answer to a comment, a merge. A nudge to the right reviewer often moves a card further than any amount of new work.

Keep two things apart while reading. Priority says what matters most, not what is closest to done. And the parent's column says little about progress; its sub-issues tell the real story.

Nobody wants to spend Fridays chasing people to drag cards. A project has built-in workflows under its Workflows menu, as of 2026, and they keep part of the board current by themselves.

Two are on in every new project:

• Item closed: when an issue or pull request is closed, its Status becomes Done.
• Pull request merged: when a pull request is merged, its Status becomes Done.

Daniel switches on two more. Item added to project sets Status to Todo, and Auto-add to project pulls in every new catchow/website issue with the label loyalty. Now a new loyalty issue lands in Todo on its own, and a pull request with Fixes #162 closes #162 on the merge, which moves the card to Done. The middle columns people still move by hand, or with a GitHub Actions script.

This is why the closing keyword now matters twice. If the description says Part of #162 instead, #162 stays open, its card stays in In review, and the board is wrong until someone notices. Publishing a release, by contrast, moves no cards at all.

On Thursday the team publishes v1.5.0: #156, #160, #165 and #166 since v1.4.1. Two loyalty cards sit in Done, the release notes list their pull requests, and customers still see nothing.

On this board Done means merged or closed. At CatChow that also means deployed within minutes. But the whole programme is behind the feature flag loyalty-points, on for staff only, and the board can't see the flag.

Each question has its own source of truth:

• The project board: the work, its owners and whether it's on schedule.
• The pull request page: the review, the approvals and the checks.
• Deployments → production: which commit is running on the live site right now.
• The release page: which version first included a change.
• The flag panel: what customers can actually use.

So when someone asks “is it live?”, don't read them the board. Read production under Deployments and the flag, and say which of the two answers you're giving.

The CEO opens the board and writes: “2 of 4 sub-issues Done, so we're halfway launched?” It's a fair reading of a board that wasn't built for him, and it's wrong: both finished pieces are hidden behind the flag, so customers have nothing yet.

Teams handle this in two ways. Some add a Released column and move cards into it on release day. CatChow keeps Done meaning “merged or closed” and makes the launch a card of its own: #164, “Switch on loyalty points for all customers”, owned by Sofia, waits in Todo until 10 November. The moment customers get the feature is then visible on the board, with an owner and a date.

A good reply to the CEO separates three things in two or three sentences:

• what's built: the bug fix and the balance are merged and live for staff;
• what customers see: nothing yet, because the flag is on for staff only;
• what's next: spending at checkout (target 5 November), then the switch on 10 November.

Mentioning the flag also reassures: the launch is a switch the team controls, not a gamble.

Follow one piece of the loyalty programme, #163 “Spend points at checkout”, along the whole path:

1. Issue #163 is opened with the label loyalty.
2. The auto-add workflow puts it on the board in Todo.
3. Daniel moves the card to In progress and starts pull request #167 with Fixes #163.
4. The card moves to In review; Oscar and Sofia review #167.
5. #167 is merged and deployed; #163 closes and the workflow moves its card to Done.
6. Next Thursday's release, v1.6.0, lists #167 in its notes.
7. On 10 November the flag loyalty-points goes on for all customers.

Only step 7 changes what customers can do. Everything before it is the team's work, which the board tracks.

The same split shapes the weekly update for the CEO: what changed this week, what's at risk and what happens next, in his words rather than the board's. Give him a view of his own, a Roadmap filtered to the loyalty issues by target date with the milestone marker, and leave out drafts and the column-by-column detail.