11.1 GitHub Projects and Layout Options

Why GH-900 tests GitHub Projects

Domain 5 of GitHub Foundations (GH-900)—Manage projects with GitHub, 5–10% of the exam—opens with describe GitHub Projects and layout options. The January 2026 Microsoft Learn outline is product-surface knowledge: what Projects is, which objects it tracks, where it lives, and how table, board, and roadmap views differ. You are not scoring a Jira migration. You are expected to pick the current Projects product over retired classic project boards, repository Insights graphs, GitHub Discussions, and GitHub Actions YAML.

GitHub's About Projects page is the source. A project is an adaptable table, board, and roadmap that integrates with issues and pull requests so you can plan at the user or organization level. You create and customize multiple views by filtering, sorting, slicing, and grouping. You add custom fields, share status updates, visualize work with charts, create templates, and automate with built-in workflows. GitHub does not force Scrum, kanban, or a waterfall template; the same item list can look like a spreadsheet on Monday and a timeline on Friday.

That sentence is the first trap. GH-900 still uses the skill title “GitHub Projects,” but the product under test is not the old repository-only classic board (To do / In progress / Done columns glued to one repo). Classic projects were retired. If a question shows a per-repo board with no custom fields, no roadmap, and no organization-wide item list, that is the wrong generation. The current product lives on the Projects tab of a user profile or an organization, can pull issues and pull requests from many repositories, and stores extra metadata on the project itself.

Where a project lives

User projects belong to a personal account. They track issues and pull requests from repositories that account owns. You create one from your profile Projects tab: New project, then start from a blank Table, Board, or Roadmap, or from a built-in GitHub template.

Organization projects belong to the org. They track issues and pull requests from the organization's repositories. Org owners can mark projects as templates and recommend up to six templates so members start from the same fields and views. You can later add a project to a repository or to a team so people find it from those pages, but attaching a project to a repo does not turn it into a classic board: the project is still an org (or user) object that happens to be linked for discovery.

A project is therefore not “one repository’s issue list with extra columns.” One org project can mix bugs from web, pull requests from api, and draft ideas that are not in any repository yet. GH-900 likes scenarios where work spans two repos; the answer is an organization project, not two separate classic boards.

You can set a short description and a Markdown README on the project so newcomers know how Status, Priority, and Iteration are supposed to be used. Those sit in the side panel with status updates (covered in section 11.4). They are documentation for the project, not a substitute for a repository README.

Items: issues, pull requests, and draft issues

A project is a collection of items. GitHub documents three kinds:

You add issues and pull requests by pasting a URL, typing # to search, bulk-adding from a repository, using the issue or pull request Projects sidebar, or enabling an auto-add workflow (section 11.2). Adding or removing an item, and changing its project Status, writes a timeline event on the issue or pull request. People need at least read permission on the project to see those events. Built-in workflow changes are attributed to @github-project-automation.

Draft issues are the item type exam questions love to mislabel. Type a title on the bottom row of the table and press Enter: you now have a draft that exists only in the project. It can have assignees and custom fields, but it has no repository, no labels, and no milestone until you convert it to an issue. People assigned to or mentioned in a draft do not receive notifications until conversion. Drafts are for parking ideas during planning; they are not secret issues and they do not appear on the repository Issues tab.

A project can contain a maximum of 50,000 items across active views and the archive page. Archive to keep boards focused; delete only when you must free space after hitting the cap. Insights charts ignore archived and deleted items (section 11.4), so archival is a planning choice, not just housekeeping.

Two-way sync with issues and pull requests

Projects are not a disconnected spreadsheet. GitHub syncs automatically as you change issues and pull requests, so views and charts stay current. The integration works both ways: edit a pull request or issue in the project and the repository object updates. GitHub's own example is assignment: change an assignee in the project and the issue shows that assignee. Group the project by assignee and drag an issue into another person's group to reassign it. Status, iteration, and other fields you edit in the table are the live project record; repository-native fields such as labels, milestone, and assignees write back to the issue or pull request.

That is why GH-900 pairs Projects with issues and pull requests instead of treating them as a separate product family. The project is a lens over the same work. If a scenario says “update the assignee on the board without opening the issue,” dragging between assignee groups is the supported gesture. If it says “the issue list still shows the old assignee,” the candidate forgot two-way sync.

Views answer different questions from the same item list. You save a view so the team can return to “this sprint’s board” or “Q3 roadmap” without rebuilding filters. A view both scopes which items appear and chooses a layout. Layout is per view, not per project: one project commonly has a table named Backlog, a board named This sprint, and a roadmap named Launch.

Layout options: table, board, and roadmap

GitHub's Changing the layout of a view page names three layouts. You switch them from View next to the search bar. Each saved view stores its own layout.

Table layout is a high-density spreadsheet of issues, pull requests, and draft issues plus GitHub metadata and your custom fields. You group, sort, filter, and show or hide columns. This is the view you use to bulk-edit Priority, assign an iteration, or scan a backlog the way you would scan a sheet. Creating an issue inside a grouped table (for example grouped by Status) sets that field to the group's value automatically—open an issue under Todo and Status becomes Todo.

Board layout spreads the same items across customizable columns. A typical kanban uses the built-in Status single-select field as the column field (Todo, In progress, Done). You can instead set any other single-select or iteration field as the column field—Priority columns, or one column per sprint. Dragging one item or a multi-select of items into a column writes that column's value onto the items. That drag is not cosmetic; it is an edit. GH-900 will offer “the board is only a picture” as a wrong answer.

Roadmap layout is a timeline across a configurable timespan. It places items using your custom date fields and iteration fields. You drag items to change start and target dates or the selected iteration. Vertical markers can highlight iterations, milestones, and item dates so you see how work sits against a release. Roadmaps are how you answer “when does this ship?” without leaving GitHub. They are not Gantt charts exported from a desktop tool, and they are not the repository Network graph.

Filter, sort, slice, and group work in every layout. Slicing is a secondary grouping control so you can, for example, board by Status while slicing by assignee. None of those controls duplicate the item; they only change what the view shows.

Exam scenarios and traps

• “Plan work across two organization repositories with a kanban and a quarterly timeline” → one organization project with a board view and a roadmap view, not two classic boards.
• “Capture an idea that is not an issue yet” → draft issue in the project. Convert it when it needs labels or a milestone.
• “Change who owns the issue from the board” → group by assignee (or edit the Assignee field); two-way sync updates the issue. Do not invent a separate “project-only owner.”
• Layouts are table, board, roadmap. There is no “calendar layout” and no “classic layout” on the current product.
• Board columns are not hardcoded To do / Done. They come from a single-select or iteration field, commonly Status.
• Roadmaps need date or iteration fields. A project with only text fields cannot place items on a timeline.
• Draft issues do not show on the repository Issues tab and do not notify assignees until converted.
• 50,000 items is the combined active-plus-archive cap. Archiving hides items from views; it does not raise the cap forever.
• Projects is not GitHub Actions, not Discussions, and not the repository Insights tab. Those products appear in other domains.

If you can read a one-line story and answer “user or org project? which item type? which layout?” you have D5.1. The next section configures the fields, labels, milestones, and built-in workflows that make those views useful.