Alex: Welcome back. Today we're looking at the part of GitHub that keeps work from turning into a pile of mystery tabs: labels, milestones, projects, and cross-references.

Jamie: I love this topic because it sounds small at first. A label is just a tag, right? But then suddenly it's how a team decides what needs attention, what belongs in a release, and who can help.

Alex: Exactly. Labels, milestones, and projects are the organizing layer on top of issues and pull requests. They help a team sort work by type, status, priority, goal, and timeline. Cross-references connect related conversations so people do not have to hunt through the repository to understand the story.

Jamie: And for learners using a screen reader, that organization is not just nice. If the issue list announces labels and status clearly, you can scan with more confidence instead of opening every issue one by one.

Alex: Yes. The goal is not to decorate issues. The goal is to make the work understandable enough that another person, or even an automated workflow later, can act on it.

Jamie: So where does this show up in the course workflow?

Alex: Chapter 9 is a guided triage chapter. You're working in your Learning Room repository, which is the per-learner repository used for the Day 1 contribution flow. The challenge asks you to inspect an open issue, decide what labels, milestone, and project placement would make sense, and then post a recommendation in your assigned Chapter 9 challenge issue.

Jamie: So learners might not be changing the real labels themselves?

Alex: Right. If you have write access, you can apply the labels and milestone directly. But the required evidence is a structured issue comment that a maintainer could use immediately. That matters because triage is a contribution even when you do not have permission to click every control.

Jamie: What does that comment need to include?

Alex: It starts with the issue number you reviewed. Then you suggest one to three labels, such as documentation, bug, accessibility, enhancement, or good first issue. You recommend a milestone, or you write none with a reason. You choose a project board column such as To Do, In Progress, or Needs Triage. Then you add one sentence explaining why those choices fit the issue.

Jamie: I can imagine getting stuck on the milestone piece. What if I honestly cannot tell where it belongs?

Alex: Then say none, and explain why. That is valid triage. If the project placement is unknown, Needs Triage is the safe default. If the issue itself is unclear, your recommendation can say that the description needs more detail. The learning pattern here is inspect the issue, classify it with shared vocabulary, and explain your reasoning in writing.

Jamie: That also connects nicely to Challenge 08, the Day 1 stretch around the culture layer. Labels and triage are technical, but the way you communicate your recommendation is part of respectful collaboration.

Alex: Exactly. A good triage note does not scold the reporter. It helps the maintainer understand the work faster.

Alex: Let's start with labels. A label is a colored tag applied to an issue or pull request. It communicates a category, status, priority, or audience at a glance.

Jamie: And screen readers announce them with the issue, right? Something like, "Label: bug," or "Labels: accessibility, good first issue."

Alex: That's right. Most repositories begin with a familiar set. Bug means something is not working as expected. Enhancement means a new feature or improvement. Documentation is for docs-only work. Good first issue signals that a task may be suitable for a new contributor. Help wanted means maintainers are inviting community help.

Jamie: And then there are labels that say more about the decision state, like question, invalid, wontfix, duplicate, and needs triage.

Alex: Yes. Question means more information is needed. Invalid means the issue does not fit the project's criteria. Wontfix means the project will not address it, usually because it is out of scope or intentional behavior. Duplicate points to another issue that already covers the same topic. Accessibility is often added as a custom or project-specific label for accessibility-related work.

Jamie: If accessibility is not already there, that does not mean the project cannot track accessibility work. It may mean the team needs to create the label.

Alex: Exactly. A custom label should have a clear name, a useful description, and a color. The color helps visual scanning, but the name and description are what make the label understandable across tools.

Jamie: How do learners find the full label list without guessing from the issue page?

Alex: Open the repository on GitHub.com, go to the Issues tab, and find the Labels link near Milestones in the issue toolbar. In Windows screen readers like NVDA or JAWS, you can move through links with K until you hear Labels, then press Enter. With VoiceOver on macOS, Quick Nav K can find the link, and VO+Space activates it. The Labels page shows each label name, description, and color.

Jamie: And the command line version is pretty direct too.

Alex: Yes. In the repository folder, gh label list shows the labels. If you want names and descriptions in a structured format, you can run gh label list --json name,description. That can be useful if you want your screen reader to read a clean list from the terminal.

Jamie: Once I know which label I want, how do I apply it to an issue or pull request?

Alex: On GitHub.com, open the issue or pull request and move to the right sidebar. Find the Labels heading, activate the edit or gear button, choose labels from the dropdown, and close the dropdown with Escape when you're done. Selections save automatically. You can type part of a label name, like access, to filter the list.

Jamie: What about the other tools people use in this series?

Alex: github.dev, the web editor, is for editing files, so it does not manage issue labels. In VS Code Desktop, the GitHub Pull Requests extension can show issues and let you add or remove labels from the GitHub side panel. GitHub Desktop does not directly manage labels, so use Repository, then View on GitHub, and do the label work in the browser.

Jamie: And with the GitHub CLI, it is gh issue edit or gh pr edit?

Alex: Exactly. For example, gh issue edit 42 --add-label "accessibility,good first issue" adds two labels to issue 42. gh issue edit 42 --remove-label "needs triage" removes one. For a pull request, gh pr edit 15 --add-label "documentation" applies the documentation label to PR 15.

Alex: Filtering is where labels become really useful. If you want only accessibility issues, you do not need to scan the full issue list. You filter by label.

Jamie: In the browser, that can happen from the issue search field or by activating a label link, depending on where you are.

Alex: Right. In the GitHub CLI, gh issue list --label "accessibility" lists issues with that label. To combine labels, you can use more than one label filter, such as gh issue list --label "accessibility" --label "good first issue". Add --state open if you only want open issues. You can also search text across labeled issues with gh issue list --label "bug" --search "keyboard".

Jamie: That is a nice way to answer practical questions. What accessibility bugs are still open? Which documentation issues are good for a first contribution? What is still marked needs triage?

Alex: Yes, and that is why consistent labels matter. If every maintainer labels differently, filtering becomes unreliable. If the vocabulary is shared, the issue list becomes a useful map.

Alex: Milestones organize issues and pull requests around a release, deadline, sprint, or shared goal. A label tells you what kind of work something is. A milestone tells you what goal or time period it belongs to.

Jamie: So a bug label might tell me the type of issue, while a milestone like Version 1.2 or Workshop launch tells me when the team wants it finished.

Alex: Exactly. To find milestones, open the Issues tab and activate Milestones near the Labels link. A milestone usually has a title, description, due date if one is set, and progress information. GitHub shows how many linked issues or pull requests are open or closed, so the milestone becomes a progress tracker.

Jamie: What should I listen for when reading one?

Alex: Listen for the milestone title first, then the due date, then the open and closed counts. The description often tells you the goal. If the due date is close and several blocking issues are still open, that changes the triage conversation.

Jamie: How do you create one?

Alex: In the browser, go to Issues, then Milestones, then New milestone. Give it a short title, add a description, and set a due date if the team has one. From the command line, GitHub CLI can create a milestone through the GitHub API, for example: gh api repos/OWNER/REPO/milestones -f title="Workshop launch" -f due_on="2026-06-30T00:00:00Z". Replace OWNER and REPO with the repository owner and name.

Jamie: And adding an issue to a milestone is similar to labels?

Alex: Very similar. On the issue page, use the Milestone control in the right sidebar and choose the milestone. With the CLI, gh issue edit 42 --milestone "Workshop launch" assigns issue 42. gh issue edit 42 --remove-milestone removes it. To list issues in a milestone, use gh issue list --milestone "Workshop launch".

Jamie: Cross-references feel related, but they are not labels or milestones. What are they doing?

Alex: A cross-reference is a link between GitHub items, usually created when you mention another issue, pull request, or commit. If you type #42 in the same repository, GitHub links to issue or PR 42. If the item is in another repository, you can use OWNER/REPO#42.

Jamie: So if an issue report mentions that it is related to another bug, I can type the number instead of copying the whole URL.

Alex: Yes. You can cross-reference from an issue comment, a pull request description, a commit message, or another discussion area where GitHub supports it. The linked item may also show a timeline event, so people can follow the relationship in both places.

Jamie: Then there are the magic words: closes, fixes, and resolves. I always worry about using those accidentally.

Alex: Good instinct. Closing keywords are powerful. If a pull request description says Closes #42, GitHub will close issue 42 when that pull request is merged into the default branch. A normal comment saying Closes #42 does not close it by itself. Use closing keywords when the work truly completes the issue; otherwise, say related to #42 or see #42.

Alex: GitHub Projects are the planning boards for organizing issues, pull requests, and notes across a team. The current GitHub Projects experience is flexible: you can view the same work as a table, a board, or a roadmap.

Jamie: So the project is not replacing labels or milestones. It is another layer that helps people see status and coordination.

Alex: Exactly. In table view, items are rows, and fields like status, assignee, labels, milestone, repository, or priority appear as columns. Screen readers may announce the row information as you move cell by cell, so column names matter. In board view, work is grouped into columns such as To Do, In Progress, and Done. Roadmap view is timeline-oriented, useful when date fields are part of the project.

Jamie: Where do learners find a project?

Alex: A repository may have a Projects tab, and organizations or user profiles can have projects too. If a project is linked from an issue, you may also find it in the issue sidebar. Permissions matter here: some learners can recommend project placement even if they cannot add the issue directly.

Jamie: And if they can add it?

Alex: Open the issue, find the Projects area in the sidebar, and choose the project. After the issue is in the project, fields like Status can place it in a board column. For the Chapter 9 recommendation, naming a column like Needs Triage, To Do, or In Progress is enough when you do not have direct access.

Jamie: Let's put the pieces together. If I am helping organize work during a hackathon, what would a practical setup look like?

Alex: Start with a small label set people can actually use. Documentation, bug, accessibility, enhancement, good first issue, help wanted, and needs triage are a solid base. If the team has agentic workflows later, labels like needs-review or accessibility-check can also be useful because an automation or agent can watch for them and respond.

Jamie: Then create a milestone for the shared goal, not for every tiny task.

Alex: Right. A milestone such as Hackathon MVP, Workshop launch, or Day 1 cleanup gives the team a target. Issues in that milestone should all support that target. The project board then shows movement: Needs Triage for unclear work, To Do for accepted work, In Progress for active work, and Done when it is complete.

Jamie: That gives maintainers a quick read. The label says what it is, the milestone says where it belongs, and the project says what is happening with it.

Alex: Yes. A simple practice exercise is to open an issue, add or recommend one label, link a related issue with #number if there is one, and write a short triage comment. If you can change the issue, make the update. If you cannot, leave a clear recommendation.

Jamie: And the evidence for Chapter 9 is still the comment in the assigned challenge issue.

Alex: Correct. Close your Chapter 9 challenge issue when the recommendation is posted, and mention whether you also applied labels or a milestone directly. By the end, you should be able to read an issue, classify it thoughtfully, explain your reasoning, and leave a note a maintainer can act on.

Jamie: I like that this chapter makes organization feel like contribution, not admin busywork.

Alex: It really is contribution. Open source depends on people making work easier to understand. If you want more practice after this, GitHub's official documentation covers labels, milestones, and Projects in detail, and the GitHub Skills course on repository management gives an interactive path through related settings. But the core habit starts here: read carefully, choose clear categories, and explain your reasoning kindly.