GitHub Foundations #4 Domain 3-1: Collaboration — Issues, Labels, Milestones, and Templates

Starting with this part, we spend two posts on Domain 3, collaboration features. According to the official study guide, the collaboration domain carries the largest weight on the exam. Everything that turned GitHub from Git hosting into a collaboration platform lives here, and the question count is allocated accordingly. This first half covers work tracking centered on Issues; the second half, in the next post, covers code review centered on Pull Requests.

Issues — the basic unit of work tracking #

An Issue is GitHub’s unit for tracking bug reports, feature requests, and to-dos. Each repository has its own independent issue list, and numbers are assigned sequentially from 1 within the repository. One thing to remember: Issues and Pull Requests share the same numbering sequence. If you open a PR right after Issue #3, that PR becomes #4.

You can attach the following to an Issue.

• Assignees — the people responsible. A single Issue can have multiple assignees.
• Labels — classification tags. Covered separately below.
• Milestone — the goal bundle the Issue belongs to. Only one can be assigned.
• Projects — the link to project boards. Covered in Domain 5.

Mentions and references — telling @ and # apart #

Two symbols used in Issue and PR bodies and comments are a frequent distinction question on the exam.

• @username — a mention. It sends a notification to that person. It is for calling someone, as in @octocat could you take a look?. Team mentions (@org/team-name) work too.
• #number — a reference. It creates a link to an Issue or PR in the same repository. It is for pointing at a document, as in this was discussed in #12.

References are recorded in both directions. If Issue A’s body references #B, a cross-reference note that A mentioned this Issue also appears on B’s timeline. To point at an Issue in another repository, use the owner/repo#number form; pasting an Issue URL directly into the body also gets converted into a reference link automatically.

Closing keywords — closing Issues from commits and PRs #

Instead of closing an Issue by hand, you can have it close automatically when the fix is merged. The mechanism is writing a closing keyword plus the Issue number in the PR body or commit message.

fixes #12
closes #12
resolves #12

The three keywords have the same effect, and inflected forms (fixed, closed, resolved, and so on) are recognized as well. The condition is the exam point: the Issue closes when the change is merged into the default branch (main). Merging into any other branch does not close it. To close several Issues at once, repeat the keyword for each one, as in fixes #12, fixes #34.

Labels — classification and filtering #

Labels are colored tags that classify Issues and PRs. A new repository comes with a default label set: the nine labels bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question, and wontfix. Among these, good first issue and help wanted are the conventional labels for inviting contributors in open source, an exam point that also connects to Domain 7 (community).

Labels can be freely added and edited in the repository settings, and they work as search filters.

is:open label:bug                  open Issues with the bug label
is:issue assignee:@me              Issues assigned to me
is:open no:label                   open Issues with no label

Milestones — bundles with a deadline #

A milestone groups Issues and PRs under a goal with a deadline, such as a release or a sprint. The milestone page shows a progress bar based on the ratio of closed Issues it contains, and you can set a due date to track the remaining time. If labels are a horizontal classification by nature, milestones are a vertical grouping by schedule. Another point worth remembering: an Issue can carry multiple labels, but only one milestone.

Issue templates and forms #

A blank issue form tends to produce reports of uneven quality. Placing templates in the repository makes the new-issue screen start from a chosen form. Templates live in the .github/ISSUE_TEMPLATE/ directory.

• Markdown templates (bug_report.md) — a simple format that provides a pre-filled body.
• Issue forms (bug_report.yml) — structured input forms defined in YAML. They can enforce fields such as text inputs, dropdowns, and checkboxes, preventing required information from being omitted.

blank_issues_enabled: false
contact_links:
  - name: Usage questions
    url: https://github.com/example/repo/discussions
    about: Please use Discussions for questions

config.yml controls the template chooser screen itself. blank_issues_enabled: false prevents opening a blank Issue without a template, and contact_links adds external links to guide people to instead of an Issue.

Notifications — watch levels and management #

The Watch button at the top right of a repository selects the notification level.

Notifications are delivered to the web inbox and by email, and you can also Subscribe/Unsubscribe on individual Issues and PRs. If there is a comment you write repeatedly, you can store it as a saved reply and insert it from the comment box.

GitHub Flavored Markdown — structural syntax for collaboration screens #

Basic GFM syntax, mentions, and references were covered in #2. In the collaboration domain, the additional exam points are the constructs that give structure to Issue and PR bodies.

- [ ] open task             ← task list (renders as checkboxes in Issues)
- [x] completed task

| col1 | col2 |             ← table
| --- | --- |

```python                   ← code fence (language name enables highlighting)
print("hello")
```

<details>                   ← collapsible section
<summary>Title</summary>
Hidden content
</details>

Task lists are more than decoration: placed in an Issue body they are aggregated into a progress indicator, and in a PR body they serve as a checklist. Beyond these, strikethrough (~~text~~), footnotes, and emoji codes (:tada:) are also part of GFM.

Wrapping up #

This post covered the first half of the collaboration domain, the work-tracking features centered on Issues. The distinction between mentions and references, the conditions under which closing keywords act, the difference between templates and forms, and GFM syntax are the core of this area.

In the next post, “GitHub Foundations #5 Domain 3-2: Collaboration — Pull Requests, Code Review, and Discussions”, we cover the second half of the collaboration domain: the Pull Request lifecycle and code review, Discussions as frequently contrasted with Issues, and GitHub Pages.