What are GitHub Issues and how do teams use them for project management?

Think of GitHub Issues like sticky notes on a team kanban board in a physical office. Each sticky note describes a task or bug, gets color-coded labels (bug, feature, urgent), is assigned to a team member, and moves across columns (To Do, In Progress, Done). GitHub Issues are the digital equivalent, tightly integrated with the code they reference.

GitHub Issues live within a repository and each gets a unique number (like #42). An issue contains a title, a Markdown-formatted description, and a conversation thread where team members discuss the problem and propose solutions. You can attach labels (strings like 'bug', 'enhancement', 'good first issue', 'priority-high') to categorize and filter issues. Milestones group related issues into a release target with a due date and completion percentage. Assignees indicate who is responsible for resolving the issue. Templates let repository maintainers define structured forms for bug reports and feature requests, ensuring reporters provide the necessary information like reproduction steps or expected behavior.

Internally, GitHub Issues are deeply linked to the rest of the platform through cross-referencing. When a developer mentions issue #42 in a commit message or pull request description, GitHub automatically creates a bidirectional reference. Using keywords like 'fixes #42' or 'closes #42' in a pull request description will automatically close the issue when the PR is merged into the default branch. This creates an auditable trail from problem identification through code change to resolution. The GitHub API exposes issues as REST and GraphQL resources, enabling automation: teams build bots that auto-label issues based on content, assign them based on file paths changed, or escalate issues that remain open past an SLA threshold.

In production teams, issues serve as the central nervous system of project management. A platform engineering team running checkout-worker might use labels like 'P0-outage', 'P1-degraded', 'P2-improvement' for priority, combined with 'area/payments', 'area/shipping', 'area/auth' for component ownership. GitHub Projects (the board feature) organizes these issues into views: a sprint board for the current iteration, a roadmap view for quarterly planning, and a triage view for incoming bugs. Issue forms with required fields ensure that bug reports include the environment, steps to reproduce, and actual versus expected behavior, dramatically reducing back-and-forth.

A common gotcha is that closing an issue via a keyword like 'fixes #42' only works when the pull request is merged into the default branch (usually main). If you merge into a feature branch, the issue stays open. Also, issues are repository-scoped, so cross-repository tracking requires GitHub Projects at the organization level. Beginners often create issues without labels or milestones, making them impossible to find later. Always label and categorize issues from the start.