Alex: Welcome back. Today we're opening the door that turns a branch change into a contribution: Challenge 6, Open Your First Pull Request.

Jamie: This is the one where the work stops being just, I changed a file, and becomes, I am asking the project to accept this change.

Alex: Exactly. A pull request, or PR, is a proposed change from one branch into another branch. It gives everyone a place to compare the branches, read the reason for the change, run checks, and talk before anything lands in `main`.

Jamie: So the PR is not just a submit button. It's the conversation around the change.

Alex: Yes. And in this challenge, the conversation is small on purpose: one branch, one issue, one clear description, and one PR link as evidence.

---

Jamie: Where are learners working for this one?

Alex: In the Day 1 Learning Room repository. That's the private repository provisioned for each learner, and it's where the Day 1 path happens: issue, branch, commit, pull request, and eventually merge.

Jamie: And the challenge issue itself is titled Challenge 6: Open Your First PR with the learner's username in it, right?

Alex: Right. The public challenge title is Open Your First Pull Request, and the assigned issue may say Open Your First PR with your username. The important part is that you're opening a PR from your working branch back into `main`.

Jamie: This also connects back to the issue from Challenge 2.

Alex: Yes. You filed an issue to describe a need or a problem. Now your PR connects the change to that reason, so the project history tells a complete story.

---

Alex: Before the PR exists, you need one small branch change. In the chapter practice path, the Learning Room has files like `docs/welcome.md`, `docs/keyboard-shortcuts.md`, and `docs/setup-guide.md`, each with a small problem to fix.

Jamie: So this is not the time to rewrite the whole repository.

Alex: Please don't. If the issue asks you to replace a TODO, fix one broken link, or correct one keyboard shortcut, do that one thing. A focused PR is easier to review, easier to explain, and easier to fix if a check fails.

Jamie: How does the web editor path work?

Alex: Open the file named in your issue, activate the pencil icon or Edit this file button, make the requested change, and then choose Commit changes. In the commit dialog, create a new branch for the commit and start a pull request. The chapter recommends a short-lived branch like `fix/yourname-issueXX`, while some challenge instructions may name `learn/YOUR-USERNAME`; follow the branch name your assigned issue or facilitator gives you.

Jamie: That branch name is a small thing, but it helps you hear what the branch is for.

Alex: Exactly. And if you're using NVDA, JAWS, or VoiceOver, stay in reading mode while you're moving around the page, then switch into the editor or form fields only when you're ready to type. That reduces the feeling of getting trapped in controls.

---

Jamie: Now we're on the Open a pull request page. What has to be right before creating it?

Alex: First, check the branch comparison. The base branch should be `main`, and the compare branch should be the branch with your change. That comparison is GitHub asking, what is different between these two branches?

Jamie: And then the title.

Alex: The title should tell the story quickly. Something like, Complete the Who Can Contribute section in welcome.md, Fix broken accessibility settings link in setup-guide.md, or Correct NVDA modifier key in keyboard-shortcuts.md.

Jamie: Then the body is where the issue link goes.

Alex: Yes. For this challenge, use a simple structure: `What this PR does`, one sentence about the change; `Why`, one sentence about the reason; and then `Closes #XX`, replacing XX with the issue number. For larger PRs, you may see sections like Summary, Changes Made, Related Issues, Testing, Screenshots or recordings, and a Checklist.

Jamie: What does `Closes #XX` actually do?

Alex: It creates a two-way link between the PR and the issue. The issue shows that it is referenced by the PR, the PR shows that it closes the issue, and when the PR is merged, GitHub closes that issue automatically. `Fixes #XX` and `Resolves #XX` work the same way.

Jamie: That's a surprisingly powerful line of text.

Alex: It is. It connects the change to the reason for the change, which is one of the habits that makes open source collaboration understandable later.

---

Jamie: After I activate Create pull request, am I done?

Alex: You're done opening it, but not done checking it. In this Learning Room path, the validation bot usually starts within about 30 seconds and posts feedback on the PR Conversation tab.

Jamie: What is the bot looking for?

Alex: It checks whether the PR references an issue with a closing keyword, whether the description is detailed enough, whether the changed files are in the expected Learning Room area, and whether basic accessibility rules pass. That can include heading order, descriptive link text, and valid alt text.

Jamie: If the bot says something failed, that doesn't mean the learner broke everything.

Alex: Not at all. Read the bot comment, fix the specific problem, and update the PR. If the problem is in the description, edit the description. If the problem is in the file, use the Files changed tab or the file editor, commit the fix to the same branch, and let the checks run again.

Jamie: And passing checks show up as green status, when the repository has them configured.

Alex: Right. A complete challenge submission has a clear PR title, a useful description, a linked issue, and passing checks when checks are present. Then you paste the PR URL into the challenge evidence field.

---

Alex: Let's make the PR page less mysterious. You can arrive there from a notification, from the Pull requests tab in the repository, or from a Compare and pull request prompt after pushing a branch.

Jamie: And if someone is using the terminal?

Alex: The GitHub CLI can list open PRs with `gh pr list`, show a specific PR with `gh pr view`, check status with `gh pr checks`, and open the PR in the browser with `gh pr view --web`. The safest terminal habits are to check your branch first, keep the change small, include the closing keyword in plain text, and use documented help like `gh pr --help` when you're unsure.

Jamie: On the website, the Pull requests list has filters too, right?

Alex: Yes. You can filter by open or closed state, review status, assignee, author, and draft state. If GitHub keyboard shortcuts are enabled, shortcuts can help you move faster, but the reliable path is still the same: find the Pull requests tab, open the PR title, and verify where you landed.

Jamie: What should I listen for on the list page?

Alex: The PR number, title, author, status, and any check or review indicators. A short title is helpful here because it has to make sense when it's heard in a list with many other PRs.

---

Jamie: Once the PR is open, there are several tabs. I know people get lost here.

Alex: The main tabs are Conversation, Commits, Checks, and Files changed. Conversation is the overview: the PR description, bot comments, human review comments, and status summaries.

Jamie: So Conversation is where I confirm what the PR claims to do.

Alex: Yes. Read the description first, then the bot or reviewer comments. If a review conversation has been answered and fixed, GitHub may let the author or maintainer resolve that conversation, which marks that thread as handled.

Jamie: What about Commits and Checks?

Alex: Commits shows the sequence of commits included in the PR, which is useful when the author made follow-up fixes. Checks shows automated jobs and logs. If something fails, the Checks tab often gives more detail than the short status summary.

Jamie: And Files changed is where the actual diff lives.

Alex: Yes, and it's the tab people often fear at first. GitHub's newer Files changed experience includes better landmark structure for the file tree and diff area; if your account still shows it as a feature preview, you can check the User Menu and Feature preview area, but for many accounts it may already be standard.

---

Jamie: Let's slow down on the diff. What am I listening for?

Alex: A diff shows what changed in each file. Added lines are usually announced with a plus sign, removed lines with a minus sign, and unchanged nearby lines are context. The left file tree helps you move between changed files when a PR touches more than one file.

Jamie: Can I navigate that with headings and landmarks?

Alex: Yes. Use headings, landmarks, and the tab bar to move to Files changed, then scan the changed file headings. In the chapter's practice example, if the PR touched `docs/welcome.md`, you might hear added lines where TODO sections were filled in; if it touched `docs/keyboard-shortcuts.md`, you might hear changes inside a table.

Jamie: How do inline comments fit in?

Alex: Inline comments attach feedback to a specific diff line or range of lines. You can comment on one line, or select a range for a multi-line comment, then submit it as part of a review. Existing comments can also appear inside the diff, so it's worth reading both the Conversation tab and Files changed.

Jamie: Challenge 6 has a peer simulation check too.

Alex: Yes. Find the Peer Simulation: Improve contribution guidance PR and leave an encouraging comment. If you have access to a real buddy's PR, you may comment there as well, but the full review workflow comes later.

---

Jamie: The chapter also mentions draft PRs, reviewers, suggestions, and merge options. Do learners need to master all of that for Challenge 6?

Alex: Not all at once, but it's helpful to recognize the words. A draft PR is for work that should be visible but is not ready for final review. You can create a draft, convert an open PR to draft, or mark a draft ready for review when the work is ready.

Jamie: And requesting reviewers is the moment you ask another person to look.

Alex: Right. Reviewers can leave comments, approve, request changes, or submit a comment-only review. They can also use suggested changes, where a reviewer proposes an exact edit and the author can apply it, sometimes batching several suggestions into one commit.

Jamie: Then maintainers decide how to merge.

Alex: Yes. Depending on repository settings, a maintainer may use a merge commit, squash and merge, or rebase and merge. They may delete the branch after merging, or enable auto-merge so the PR merges when required checks pass.

Jamie: And after merge, the closing keyword does its job.

Alex: Exactly. The PR becomes part of `main`, and the linked issue closes automatically if the PR used `Closes #XX`, `Fixes #XX`, or `Resolves #XX` correctly.

---

Alex: A complete example might have the title, Fix TODO: add workshop schedule link to welcome.md. The body would say what changed, why it changed, and then `Closes #3`.

Jamie: So, not a novel. Just enough context for a reviewer to understand the change without hunting through the issue first.

Alex: Yes. Good PR descriptions avoid vague lines like fixed stuff, and they avoid leaving out testing or issue links. A before-and-after structure can help when the change is visual, behavioral, or accessibility-related.

Jamie: What are the most common stuck points in this challenge?

Alex: If you can't find New pull request, make sure you're on the Pull requests tab. If GitHub says there isn't anything to compare, check that your branch has a commit that differs from `main`, and that you committed to the intended branch. If you forgot `Closes #XX`, edit the PR description after creating the PR.

Jamie: And success is the PR URL, the issue link, and the checks passing when they apply.

Alex: That's it. You opened a PR, compared branches, connected the work to an issue, and practiced the same contribution pattern used by humans, teams, and AI-assisted workflows. AI can help draft changes later, but you now know how to inspect the PR yourself.

Jamie: That feels like a real milestone.

Alex: It is. The first pull request is where GitHub starts to feel less like a website full of buttons and more like a collaboration system you can move through with confidence.