GitHub Projects: From Simple Kanban to Engineering Intelligence

For years, GitHub Issues were seen as a “lite” alternative to Jira. That changed with the launch of the new GitHub Projects (v2). As a senior engineer, I no longer view Projects as just a place to drag cards; I view it as the metadata layer of the entire development lifecycle.

The core philosophy of modern GitHub Projects is integration over isolation. In legacy workflows, developers would update a ticket in Jira and then go to GitHub to write code. This context switching is a productivity killer. By utilizing Projects, the “Ticket” and the “Code” are the same entity. When a Pull Request is linked to an issue, the Project knows. When a CI/CD pipeline fails, the Project can reflect that status.

The Power of Automation

The real “senior-level” move isn’t setting up columns; it’s setting up Workflows. Using built-in automation or GitHub Actions, you can ensure that as soon as a PR is approved, the corresponding card moves to “Ready for Merge.” This eliminates the “status lag” that plagues large teams. If your project board requires manual updates for every status change, you aren’t using GitHub Projects—you’re using a digital whiteboard.

Common Pitfalls to Avoid

Over-Engineering Fields: Don’t try to replicate every Jira field. Start with Status, Priority, and Estimate. Complexity breeds non-compliance.
Ignoring the “View” System: Many teams stay stuck in the Board view. The Table view is superior for bulk editing, and the Roadmap view is essential for stakeholder management.
Decoupling Issues from PRs: Always link your PRs to issues using keywords (e.g., Closes #123). This is the “glue” that makes Project automation work.

Study Guide: GitHub Projects & Automation

GitHub Projects is a customizable, flexible tool for planning and tracking work. It sits at the intersection of Issue tracking and Repository management.

The Analogy: The Smart Warehouse

Imagine a warehouse (your Repository). The items in the warehouse are Issues and Pull Requests. GitHub Projects is the Automated Logistics System. It doesn’t just store the items; it tracks their location, predicts when they’ll leave (Roadmaps), and automatically moves them from the “Receiving” dock to the “Shipping” dock based on their barcode (labels and PR status).

Core Concepts & Terminology

Items: Issues, Pull Requests, or Draft Tasks (simple text notes).
Fields: Custom metadata like Iterations (Sprints), Single Select (Priority), or Numbers (Story Points).
Views: Different visualizations of the same data (Table, Board, Roadmap).
Workflows: Logic-based triggers (e.g., “When PR is merged, set status to Done”).

Typical Workflow

Triage: New issues land in a “Needs Triage” view.
Planning: Assigning issues to a Milestone or Iteration.
Development: Creating a branch from the issue. The Project moves the item to “In Progress” automatically via linked pull requests.
Review: PR is opened. Project moves item to “In Review”.
Completion: PR is merged. Project moves item to “Done” and closes the issue.

Real-World Scenarios

Scenario 1: The High-Velocity Startup Team

Context: A team of 5 engineers needs to move fast without a dedicated Project Manager.

Application: They use a Team-level Project with “Auto-add to project” workflows. Any issue created in their 3 core repos with the label bug or feature is automatically added to the board. They use Iterations to manage 2-week cycles.

Why it works: Zero manual overhead. The board manages itself based on labels and PR activity.

Scenario 2: The Open Source Maintainer

Context: A project with hundreds of contributors and thousands of issues.

Application: Using Draft Tasks to brainstorm features before turning them into official Issues. They use public “Roadmap” views to show the community what is coming in v2.0.

Risk: Spam. They mitigate this by using GitHub Actions to close stale issues that haven’t moved on the project board for 30 days.

Interview Questions & Answers

Question: What is the difference between a Repository-level project and an Organization-level project?
Organization-level projects can track issues and PRs across multiple repositories, making them ideal for cross-functional teams. Repository-level projects are contained within a single repo.
Question: How does GitHub Projects v2 differ from the “Classic” Projects?
v2 is built on a spreadsheet-like engine. It supports custom fields, complex filtering, multiple views (Table/Roadmap), and much more powerful built-in automation compared to the basic Kanban of Classic.
Question: Can you automate a Project using GitHub Actions?
Yes. While Projects has built-in triggers, you can use the github-project-automation action or the GraphQL API to perform complex logic, like moving a card when a specific CI test fails.
Question: How would you track “Story Points” in GitHub?
Create a custom “Number” field named “Estimate” or “Points.” You can then use the Table view to sum these values or create charts in the “Insights” tab.
Question: What is a “Draft Task”?
A lightweight item that exists only within the Project. It’s useful for quick ideas that aren’t ready to be full Issues yet. They can be converted to Issues with one click.
Question: How do “Iterations” differ from “Milestones”?
Milestones are repo-specific and have a fixed due date (often used for releases). Iterations are Project-specific, repeat automatically (e.g., every 2 weeks), and are designed for Sprints.
Question: How can you ensure a PR is linked to a Project card?
By using “Linked Issues” in the PR sidebar or using closing keywords in the PR description. The Project card for the issue will then track the PR status.
Question: What are “Views” and why are they important?
Views are saved filters and layouts. You might have a “Bugs” view (filtered by label), a “Sprint Board” (filtered by iteration), and a “High Level Roadmap” (Layout: Roadmap).
Question: How do you handle “Blocked” tasks?
Usually by creating a custom “Select” field for “Status” that includes “Blocked,” or by using a “Dependencies” field to link to the blocking issue.
Question: What is the “Insights” tab in GitHub Projects?
It provides burn-up/burn-down charts and cumulative flow diagrams based on your Project’s fields and item history.

Interview Tips & Golden Nuggets

Golden Nugget: In an interview, mention GraphQL. GitHub Projects v2 is heavily reliant on the GraphQL API. Knowing this shows you understand the underlying architecture.
Trade-off: When asked “GitHub Projects vs Jira,” answer like a senior: “Jira offers deeper compliance and reporting for non-engineers, but GitHub Projects offers higher developer velocity by keeping the workflow inside the git ecosystem.”
The “Secret” Feature: Mention Cross-Org Projects. You can actually add items from different organizations if you have the right permissions.
Trick Question: If asked if you can use Projects offline—the answer is no. Unlike Git, Projects is a GitHub-hosted service layer.

Comparison Table

Feature	GitHub Projects (v2)	Jira Software	Trello
Integration	Native (Deep PR/Issue link)	Plugin-based	API/Power-Up only
Customization	High (Custom Fields/Views)	Extremely High (Workflows)	Low (Simple Kanban)
Learning Curve	Low for developers	High (Steep)	Very Low
Automation	Built-in + GH Actions	Automation Engine	Butler Automation

The Automated Project Lifecycle

Repository Ecosystem

Sync: Status updates when branches are deleted.
Visibility: See PR status (Draft/Open/Merged) directly on the card.
Labels: Use labels to trigger Project filters.

Collaboration

Assignees: Syncs between Issue and Project card.
Comments: Discuss work directly on the item without leaving the context.
Permissions: Inherited from Org or Repo levels.

Automation

Workflows: Auto-archive completed items after X days.
Action Triggers: Move items based on specific CI label additions.
API: Programmatic updates via GraphQL.

Decision Guidance: When to use what?

Use a Project Board when: You need to track progress across multiple repos or need custom metadata (Points, Sprints).
Use simple Issues when: You are working on a small, single-repo task list with no complex dependencies.
Use Roadmaps when: Communicating timelines to stakeholders or non-technical leadership.

Production Use Case: The “No-Ops” Project

A DevOps team manages their infrastructure-as-code (IaC) changes using a GitHub Project. When a terraform plan is generated in a PR, a GitHub Action updates a custom “Impact” field on the Project card. This allows the Lead Engineer to look at the Board and instantly see which pending merges are “High Risk” vs “Low Risk” without opening a single PR.

Keyfacts: GitHub Projects v2 • Built-in Automation • GraphQL Enabled • Cross-Repo Visibility