11.2 Configuring Projects, Labels, Milestones, and Workflows

Why configuration is its own GH-900 skill

Domain 5's second bullet is explain how to configure projects, labels, milestones, and workflows. D5.1 asked what Projects is. D5.2 asks how you make a blank table useful: custom fields, built-in automations, and the repository metadata (labels and milestones) that still sit on issues and pull requests. GitHub's About Projects page lists those pieces in one paragraph; the exam splits them because candidates mix project fields with issue labels, and mix project workflows with GitHub Actions.

A project starts with built-in metadata you already know from issues: title, assignees, labels, milestone, linked pull requests, and a default Status single-select. Configuration is how you add the metadata your process needs—target ship date, story points, priority, sprint—and how you stop doing that by hand.

Custom fields (and the 50-field cap)

You are not limited to built-in issue metadata. Custom fields attach extra attributes to issues, pull requests, and draft issues in this project. GitHub's documented examples match the exam wording:

You can use up to 50 fields in a project, including built-in metadata and custom fields. That cap is a favorite numeric fact. “Unlimited custom columns” is wrong. Single-select fields themselves support up to 50 options, each with optional color and description, and you can set a default option so new items arrive pre-filled (removing the default does not rewrite existing items).

Iteration fields deserve extra attention because they are not dates with a nicer name. An iteration is a repeating block of time with a duration (days or weeks), a start date, editable names, and optional breaks for holidays. Creating the field auto-creates three iterations. Filter with the iteration name or with @current, @previous, and @next, plus operators such as iteration:<@current. Group a view by iteration to balance upcoming work; use Move items to... on a group to roll unfinished work into the next sprint. Roadmaps use iteration fields (and date fields) as the timeline. Breaks communicate “we are not scheduling work here”; they are not deleted sprints.

Issue fields, parent/sub-issue progress, pull request reviewers, and issue type can also appear as columns. For GH-900, memorize the five custom types in the official About Projects list and the 50-field total. Do not spend the domain memorizing every newer issue-type column.

Custom fields are project metadata. They do not replace repository labels. A Priority single-select on the project is not visible as a label in another repository's Issues tab. Labels remain the cross-cutting tags on the issue itself; custom fields remain the planning attributes for this project (or for org-level issue fields, which GH-900 does not center).

Built-in workflows (not GitHub Actions)

Projects include built-in workflows. You open the project menu, click Workflows, edit a workflow, then Save and turn on workflow. These are not YAML files in .github/workflows. If a question shows on: issues in a YAML file, that is Domain 4 Actions, even if the job adds the issue to a project via the API.

When a project initializes, two workflows are enabled by default: when issues or pull requests in the project are closed, Status is set to Done; when pull requests in the project are merged, Status is set to Done. You can also set fields when items are added (for example Status → Todo on add) and close issues when project Status changes.

Three automation families show up on the exam:

Auto-add. Add new issues and pull requests from a chosen repository when they match a filter. Filters include is (open, closed, merged, draft, issue, pr), label, reason, assignee, and no (label, assignee, reason). Negation works (-label:bug). Existing items that already match are not added when you enable the workflow—only items created or updated afterward. You can duplicate auto-add workflows; each targets a repository (or the same repository with a unique filter). Plan limits apply: 1 auto-add workflow on GitHub Free, 5 on Pro and Team, 20 on Enterprise Cloud and Enterprise Server.

Auto-archive. Remove matching items from active views while keeping custom field data on the archive page, where you can restore them. Auto-archive filters are only is, reason, and updated (for example last 14 days, 3 weeks, or 1 month). GitHub marks an item updated when it is created, reopened, edited, commented, labeled, reassigned, milestoned, transferred, or when project field values change. Enabling auto-archive also archives items that already match, unlike auto-add. Archive is not delete: the 50,000-item cap still counts archived items; you delete only to free space.

Set fields. Item added → Status Todo; item closed → Status Done; pull request merged → Status Done. These keep the board honest without a person dragging cards.

You can go further with the GraphQL API and Actions, but GH-900 wants the built-in trio. Activity from built-in workflows shows as @github-project-automation on the issue timeline.

Labels still live on issues and pull requests

Labels classify issues, pull requests, and discussions in the repository where the label was created. Adding, editing, or deleting a label in one repository does not change labels in another. GitHub ships default labels (bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question, wontfix, plus accessibility). Organization owners can customize default labels for new org repositories. Issues labeled good first issue populate the repository contribute page.

Permissions are a standard GH-900 trap:

• Write access is required to create, edit, or delete a label.
• Triage access is enough to apply or dismiss existing labels.

Deleting a label removes it from issues and pull requests. In a project, labels are built-in metadata you can show as a column, filter (label:bug), group, or slice. They are still repository objects. A project custom field named “Type” is not a label. Auto-add can key off labels (label:"good first issue") so labeled work flows into the project without a person pasting URLs.

Milestones still live on issues and pull requests

A milestone groups issues and pull requests in a repository toward a date. The milestone page shows a description, due date, completion percentage, counts of open and closed items, and the item list. You can create new issues already associated with the milestone and drag to prioritize (prioritization stops if a milestone has more than 500 open issues).

Milestones are not iteration fields. An iteration is a project field with repeating length and @current filters. A milestone is a named repository bucket with a due date and a percent complete based on closed issues and pull requests. Roadmaps can draw vertical markers for milestones so the timeline shows both project iterations and repository due dates. You can group or filter a project view by milestone because that metadata syncs from the issue. You cannot attach a milestone to a draft issue until you convert the draft into a repository issue.

If a question says “show how much of version 2.1 is closed,” the answer is a milestone. If it says “plan the next two-week sprint across repos,” the answer is an iteration field (often plus a board grouped by iteration).

Organization project templates

You can create a project template for an organization, or set an existing project as a template, so members start from a known layout. GitHub copies views, custom fields, draft issues and their field values, configured workflows (except any auto-add workflows), and insights. Auto-add is excluded on purpose: it is bound to specific repositories and would surprise the next team. You cannot add status updates to a project that is set as a template.

Org owners can recommend up to six templates; those appear first in the create-project dialog. Admins can toggle Make template in project settings. Write or admin permission lets you Copy as template, which duplicates the current project and marks the copy as a template. Templates can also be added to teams and repositories for discovery.

Exam scenarios and traps

• “Track story points and a ship date that issues do not have natively” → number and date custom fields, not a new label named 5-points.
• “Every new bug issue in web should appear on the org board” → built-in auto-add workflow with label:bug, not an Actions workflow unless the question shows YAML.
• “Closed items clutter the board but we might reopen them” → auto-archive, which keeps field data; not delete.
• Enabling auto-add does not import the existing backlog; enabling auto-archive does archive items that already match.
• Templates do not copy auto-add workflows. If the cloned project is empty, that is expected until someone turns auto-add on again.
• 50 fields includes built-in plus custom. 50 options is the single-select option cap—do not swap those numbers.
• Labels: triage applies, write creates. Milestones: repository due-date buckets, not iteration sprints.
• Project workflows ≠ Actions. .github/workflows is Domain 4.

Configure fields and automations first; communication features in the next section (saved replies and assignees) sit on the issues and pull requests those workflows pull in.