GitHub Projects: plan and track work

GitHub Projects is a planning layer connected to issues and pull requests. It is not a second Git history. You can present the same work as a table, a Kanban board or a roadmap and customize which information matters. A personal project can organize your own repositories; an organization project can coordinate work across several team repositories.

Create a project

1. On GitHub, open your profile or organization and select Projects → New project.
2. Start from a blank Table, Board or Roadmap, or pick a suitable template.
3. Name it for the product or team, for example Frontier Dispatch development, not just Tasks.
4. Add existing repository issues and pull requests, or create a draft item when the idea is not yet ready to be an issue.
5. Add a project README explaining purpose, triage rules, ownership and the definition of Done.

Projects can contain items from multiple repositories. Moving a card to Done changes planning metadata; it does not itself merge code or prove a deployment succeeded.

Design fields with purpose

Field	Example	Why it is useful
Status	Backlog, Ready, In Progress, Review, Done	Make handoff and bottlenecks visible
Priority	Critical, High, Normal, Low	Help order the backlog, not guarantee deadlines
Iteration	Sprint 8	Coordinate short planning windows
Target date	November 20	Expose a deadline where one really exists
Team / area	Gameplay, Tools, Infrastructure	Group cross-repository work

Some metadata comes from the issue itself, such as assignees or labels; other fields belong to the project. Use consistent definitions rather than accumulating a dozen nearly synonymous status and priority fields.

Build multiple views of the same work

A Table is useful for bulk triage and comparing fields. A Board shows work grouped by status. A Roadmap emphasizes time and date fields. Create additional filtered views for team:gameplay, high-priority bugs or the current iteration. Views change presentation, not the underlying issue identity.

Invite collaborators safely

Open project Settings → Manage access and grant the minimum required level (for example read or write). Project access is distinct from repository access: inviting someone to a project does not automatically grant permission to a private repository referenced by its cards. Review the project’s visibility and actual repository permissions before sharing sensitive work.

A practical first exercise

Create a private test project with statuses Backlog, Ready, In Progress, Review and Done. Add a draft item, convert it to an issue in a test repository, assign it, and view it in both Table and Board. Finally, check whether another collaborator can see the intended information, and whether they have the correct access.

References: GitHub Projects overview, creating a project, managing access.