GitHub Issues & Projects

• One issue per repo, numbered sequentially. Reference cross-repo with org/repo#123; same-repo with just #123.
• Markdown body with task lists, code, mentions, image drops, and reactions. Comments are threaded.
• Labels categorize freely (bug, good first issue, area: api). Milestones bundle issues toward a release.
• Sub-issues (recent addition) give a real parent/child hierarchy without faking it via task lists.
• Issue templates in .github/ISSUE_TEMPLATE/ standardize bug reports and feature requests.
• Auto-close from PRs. "Closes #123" in a PR description closes the issue when the PR merges.

The classic Projects boards were per-repo and limited. Projects v2 (just "Projects" now) is a spreadsheet-meets-board that pulls issues and PRs from anywhere into one view.

• Custom fields — text, number, single-select, iteration, date.
• Multiple views — table, board, roadmap timeline — over the same items.
• Workflows auto-add issues, set status on PR merge, archive when done.
• Insights charts the field data — burnup-style velocity, status distribution.

Issues are for actionable work; Discussions are for Q&A, ideas, and announcements. Open-source projects use them as a community forum, marking helpful answers and converting issue-shaped requests into Issues only when ready.

• Reporting is light. Insights cover the basics. Cross-org dashboards, capacity planning, and rollups across many initiatives are weak.
• Workflow customization is shallow. No custom states per repo, no required field validation, no transition guards.
• Non-engineers don't always thrive in a markdown/PR-shaped tracker.
• Best fit: open source, small-to-medium teams whose work lives in code. Pair with Linear or Jira for org-wide planning if needed; sync IDs both ways.