TECH **GitHub Issues, Project Boards & Milestones: Zero-Fluff Study Guide**

GitHub Issues, Project Boards & Milestones: Zero-Fluff Study Guide

For engineers who need to ship, not just study.

1. What This Is & Why It Matters

GitHub isn’t just a place to store code—it’s a collaboration hub where teams track work, prioritize features, and ship software. If you ignore Issues, Project Boards, and Milestones, you’re flying blind:

• Issues = Your team’s to-do list, bug tracker, and discussion forum.
• Project Boards = A Kanban-style workflow (like Trello, but built into GitHub).
• Milestones = Deadlines that group Issues into sprints or releases.

Real-world scenario:
You inherit a legacy codebase with 50+ open bugs, no labels, and no way to tell what’s blocking the next release. Without these tools, you’ll waste hours in Slack/email trying to figure out: - What’s actually important? - Who’s working on what? - When is this supposed to ship?

Superpower you gain:
- Visibility – Everyone sees the same priorities.
- Automation – Move Issues between "To Do" and "Done" without manual updates.
- Accountability – No more "I thought you were fixing that bug."

2. Core Concepts & Components

? GitHub Issues

• Definition: A single task, bug, or discussion thread tied to a repo.
• Production insight: If you don’t use labels, assignees, or templates, Issues become a chaotic dumping ground. Teams waste time triaging instead of shipping.

? Labels

• Definition: Color-coded tags (e.g., bug, enhancement, p1) to categorize Issues.
• Production insight: Without labels, you can’t filter or prioritize. Example: A p0 label means "drop everything and fix this."

? Assignees

• Definition: The person responsible for an Issue.
• Production insight: If an Issue has no assignee, it’s nobody’s problem—and it won’t get fixed.

? Issue Templates

• Definition: Predefined forms (e.g., "Bug Report," "Feature Request") to standardize submissions.
• Production insight: Without templates, you’ll get vague reports like "The app is broken" with no steps to reproduce.

? GitHub Project Boards

• Definition: A Kanban board (columns like "To Do," "In Progress," "Done") to track Issue status.
• Production insight: If you don’t use automation rules, Issues get stuck in "In Progress" forever.

? Milestones

• Definition: A container for Issues tied to a deadline (e.g., "v1.2 Release").
• Production insight: Without milestones, releases become a guessing game. Example: "Is this bug fixed in the next release?" → "No idea."

? Automation (GitHub Actions + Project Boards)

• Definition: Rules that move Issues automatically (e.g., "When an Issue is closed, move it to 'Done'").
• Production insight: Manual updates waste time. Automation keeps the board real-time.

3. Step-by-Step Hands-On

Prerequisites

• A GitHub account (free tier works).
• A repo (create one if you don’t have one: gh repo create my-project --public).

Task: Set Up a Production-Ready Issue Workflow

Goal: Create a repo with: 1. Issue templates for bugs and features.
2. A Project Board with automation.
3. A milestone for the next release.

Step 1: Create Issue Templates

1. In your repo, create a .github/ISSUE_TEMPLATE directory:
   bash
mkdir -p .github/ISSUE_TEMPLATE
cd .github/ISSUE_TEMPLATE
2. Create bug_report.md:
   ```markdown

name: Bug Report
about: Create a report to help us improve
title: "[BUG] "
labels: bug
assignees: ""

Describe the bug
A clear and concise description of what the bug is.

Steps to Reproduce
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.
3. Create `feature_request.md`:markdown

name: Feature Request
about: Suggest an idea for this project
title: "[FEATURE] "
labels: enhancement
assignees: ""

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
4. Commit and push:bash
git add .
git commit -m "Add issue templates"
git push
```

Verify:
- Go to your repo → Issues → New Issue.
- You should see Bug Report and Feature Request as options.

Step 2: Set Up a Project Board

1. Go to your repo → Projects → New Project.
2. Select Board (Kanban-style).
3. Name it Product Backlog.
4. Add columns:
5. To Do (default)
6. In Progress
7. Review
8. Done
9. Click ... → Workflow → Add automation:
10. When an issue is closed → Move to Done.
11. When an issue is reopened → Move to To Do.

Verify:
- Create a test Issue.
- Close it → It should auto-move to Done.

Step 3: Create a Milestone

1. Go to Issues → Milestones → New Milestone.
2. Name it v1.0 Release.
3. Set a due date (e.g., 2 weeks from now).
4. Add a description: First stable release. All P0/P1 bugs must be fixed.

Verify:
- Create an Issue → Assign it to the v1.0 Release milestone.
- Go to Milestones → You should see progress (e.g., "2 open / 5 total").

4. ? Production-Ready Best Practices

? Security

• Restrict who can create Issues (Settings → Moderation → Issue creation).
• Use CODEOWNERS to auto-assign Issues to the right team (e.g., @frontend-team for UI bugs).

? Cost Optimization

• Archive old Projects (they count toward GitHub’s private repo limits).
• Use GitHub’s free tier for public repos (no cost for Issues/Projects).

? Reliability & Maintainability

• Standardize labels (e.g., p0, p1, p2 for priority).
• Use emoji in Issue titles (e.g., ? Bug: Login fails on mobile).
• Link Issues to PRs (type Fixes #123 in a PR description to auto-close Issue #123).

?️ Observability

• Pin important Issues (e.g., "Known Issues in v1.0").
• Use GitHub Insights (Repo → Insights → Pulse) to track Issue trends.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "How do you auto-close an Issue when a PR is merged?"
2. Answer: Write Fixes #123 in the PR description.

3. Trap: Closes #123 also works, but Fixes is more explicit.

4. "What’s the difference between a Milestone and a Project Board?"

5. Answer:

   
   
   • Milestone = Deadline + group of Issues (e.g., "v1.0 Release").
   • Project Board = Workflow (e.g., "To Do → In Progress → Done").

6. "How do you restrict who can create Issues?"

7. Answer: Repo Settings → Moderation → Issue creation → Restrict to collaborators.

7. ? Hands-On Challenge

Challenge:
Create a Project Board with automation that: 1. Moves Issues to In Progress when assigned.
2. Moves Issues to Review when a PR is linked.

Solution:
1. Go to Projects → Workflow → Add automation:
- When an issue is assigned → Move to In Progress.
- When a pull request references an issue → Move to Review.

Why it works:
- GitHub’s automation rules trigger on events (assignment, PR links).

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. GitHub Docs – Issues
2. GitHub Docs – Project Boards
3. GitHub Docs – Milestones
4. GitHub CLI (gh) Docs (for automation)