GitHub Projects for Lightweight Issue Tracking

For a single repository or a team of five, a dedicated issue tracker is usually overkill with extra logins and a synchronization problem bolted on. GitHub Projects is the alternative that needs no new account: it is a set of views — board, table, roadmap — over the issues and pull requests you already have. The trick that saves people is understanding that a project is a lens, not a second source of truth.

Projects are views, not another database

An item in a project is a reference to an issue or pull request, or a draft with no issue behind it. The issue remains the source of truth: its state, assignee, and comments live there, and the project simply arranges references. That single fact prevents the classic two-track failure where your tracker and your board disagree and nobody knows which one the operations people read. When you change status on a project board you are changing a custom field on the item, not the underlying issue.

Views and fields

A project is built from fields and views. Fields are typed columns — a single-select Status, a date, a number you can use for estimates or points, an iteration. Views are just groupings of the same items: a board grouped by Status, a table sorted by Priority, a roadmap laid out by Start date or Iteration. Since all views render the same items, you get the Jira-style dashboard without the Jira-style state explosion.

The status field is really the contract you agree with yourself: three to five values, ruthlessly clear. Nothing kills a board faster than twelve statuses nobody can map to actions. Decide the status vocabulary once and freeze it, because renaming a value later rewrites every automation rule that references it. And because fields are typed, a Date field drives the roadmap while an Estimate number field drives the table sort — both are just columns over the same items, which is the whole trick: one store, many arrangements.

Automation keeps it honest

Projects ship built-in workflow rules that react to issue and pull request events: new issues land in Backlog, merged PRs move to Done, closed issues leave the active board. Those rules are configured in the UI rather than checked into the repo, but they are fully addressable from the CLI — which matters when your release process wants to read the board as data:

# find a project and dump its metadata
gh project list --owner netbay --format json --jq '.projects[] | {title, id}'
gh project view 13 --owner netbay --format json --jq '.status, .fields[]'

Adding an item to the board from a script is then one GraphQL call:

# add an issue to the board
gh api graphql -f query='
  mutation {
    addProjectV2ItemById(
      input: { projectId: "PVT_kwADO_ABCD", contentId: "I_1234" }
    ) { item { id } }
  }'

The GraphQL mutation is the same call the button makes, which means your build can mint triage tickets straight onto the board and nothing in the UI staff needs to know. That is the point at which "lightweight tracking" becomes "tracking that does not ask anything of anyone."

Milestones versus projects

People routinely conflate the two. A milestone groups issues against a date-anchored goal — "ship 1.4" — and shows a progress bar. A project arranges items across any axis you like, independent of a fixed end date. They compose cleanly: milestone for the release target, project for the working board, and the roadmap view when the release dates matter.

Keeping it light

The discipline that makes Projects stay lightweight is exactly three habits: the status field is the only state machine, automation rules do the moving, and nothing real is tracked in a spreadsheet next door. The moment a second board reproduces half of the first, cut it — duplication is where lightweight tracking turns into a second tracker with its own rot. The same instinct, one honest store read many ways, is what keeps small-team operations fast as the repository grows.

Takeaway: GitHub Projects gives a real board and roadmap without a new canonical store, and its graph API lets scripts and builds feed the board directly. Run those scripts somewhere dependable — a Lucknow DC01 VPS from Netbay deploys in under 60 seconds at netbayhosts.in.