GitHub Foundations #7 Domain 5: Project Management — Projects, Automation, and Insights
Where Domain 4 covered development tools like Actions, Codespaces, and Copilot, Domain 5 asks about the tools that plan and track that development. Its share of the exam is not large, but what it asks is well defined, so preparation converts directly into points. There are two threads: GitHub Projects, which groups issues and PRs into a plan, and Insights, which reads a repository’s activity.
GitHub Projects — grouping issues and PRs into a plan #
An issue holds one task, and a PR holds one change. Real work, however, moves in larger units, such as “in what order do we finish these features this quarter?” GitHub Projects collects issues and PRs scattered across multiple repositories into a single planning surface where you assign status and priority and track progress.
The first distinction the exam expects is generational. Today’s Projects lives under an Organization or a personal account, can gather items across repositories, and supports flexible, spreadsheet-like fields. The older Projects (classic) was a simple kanban board tied to a single repository and has been on its way out, so exam answers are always based on the current Projects.
Three views — table, board, and roadmap #
The same set of items can be displayed in three forms. Matching each view to its use case is a staple question.
| View | Shape | The question it answers |
|---|---|---|
| Table | Spreadsheet-style list | How do I sort and bulk-edit all items by field? |
| Board | Kanban with status columns | What is in progress right now, and what is blocked? |
| Roadmap | Date-based timeline | When does each piece of work start and end? |
A view is just a saved screen configuration, so one project can hold several views side by side. A Board view for team meetings and a Roadmap view for quarterly planning can show the same data from different angles.
Custom fields — status, priority, and iteration #
Beyond the basics, you can freely add fields to project items.
- Single select — a field that picks one of a fixed set of values, such as Status (Todo, In Progress, Done) or priority (P0, P1, P2).
- Iteration — a field that defines repeating time windows, like two-week sprints, and assigns items to them. When the exam asks which field is used for sprint-based assignment, the answer is iteration.
- Text, number, date — free-input fields for things like time estimates or due dates.
Filters and grouping operate on these fields. Filter syntax like status:"In Progress" narrows a view, and grouping by assignee or priority organizes it.
Connecting issues and PRs — the link between plan and execution #
The items that flow into Projects originate as issues and PRs. The linking rules carry over directly from Domain 3.
- Writing a keyword like
Closes #12in a PR body closes the referenced issue automatically at merge time. - A milestone groups issues and PRs at the repository level around a release, while Projects is the planning layer above it that crosses repositories.
If a question asks you to separate the two levels, answer that a milestone is a release bundle inside a repository, and Projects is a planning tool at the account or organization level.
Adding items and project permissions #
There are three paths for putting an item into a project. Search with #repository-name in the input row at the bottom of the project screen, assign it from the Projects section in the sidebar of an issue or PR page, or let the auto-add workflow described below collect it automatically. You can also jot down notes that are not issues yet as draft items and convert them to issues later. A typical pattern is stacking planning-stage ideas as drafts and promoting them to repository issues once they are confirmed.
A project’s visibility and permissions are managed separately from repositories. A private project is visible only to invited people, and even a public project does not expose the contents of private repositories its items link to. The fact that write access to a project and write access to a repository are independent of each other can appear as a boundary question.
Built-in automation workflows #
Projects ships with automation that removes the manual work of moving statuses around. You turn it on and off under Workflows in the project settings.
- Auto-add — automatically adds issues and PRs from specified repositories when they match a condition.
- Item added to project — sets initial values, such as setting Status to Todo when an item is added.
- Item closed / PR merged — moves Status to Done when an issue is closed or a PR is merged.
- Auto-archive — automatically archives items that have been done for a while.
Conditions that the built-in workflows cannot express can be extended with GitHub Actions. At the exam level, it is enough to keep the division of roles: basic automation is the built-in Projects workflows, and complex automation is an Actions integration.
Charts — a project’s Insights #
Insights inside a project draws charts from item data. You can build charts of the current distribution of statuses and charts of change over time (burn-down style), which teams use in sprint retrospectives. The name collides with the repository’s Insights tab, so keep them apart: project Insights charts planning items, repository Insights shows repository activity statistics.
The repository Insights tab #
The repository’s Insights tab is a collection of statistics that shows how the repository is moving. You should be able to match each item to its purpose in one line.
| Item | What it shows |
|---|---|
| Pulse | Recent activity summary (merged PRs, open issues, active people) |
| Contributors | Per-contributor graphs of commits, additions, and deletions |
| Traffic | Visitors, views, clone counts, and referral sources |
| Community Standards | Checklist of community files such as README, LICENSE, and CONTRIBUTING |
| Forks / Network | Fork list and branch divergence graph |
Two details are worth pairing with the table: Traffic is visible only to people with push access, and Community Standards connects to the community files covered in Domain 7.
Wrapping up #
Three takeaways from this post.
- GitHub Projects gathers issues and PRs from multiple repositories into a plan, and Table, Board, and Roadmap are three angles on the same data.
- Repetitive chores like initializing status and marking items done belong to the built-in automation workflows, and anything beyond that extends through Actions.
- Repository Insights is the statistics bundle — Pulse, Contributors, Traffic, and Community Standards — for reading a repository’s activity and health.
The next post, “GitHub Foundations #8 Domain 6: Privacy, Security, and Administration — Permissions, 2FA, and Dependabot”, covers the area where the exam asks the most boundary questions: the map of the permission model and the security features.