Alex: Welcome back. Challenge 5 is called Make Your Mark, and this is where your Learning Room starts to feel like a real repository instead of a place you are only reading.

Jamie: Because now we are changing an actual file, not just opening issues or looking around.

Alex: Exactly. You will edit `docs/welcome.md`, replace a TODO with real content, and save that change with a commit message that says what changed and why. A commit is a saved snapshot in Git, so this is your first clear record of contribution.

Jamie: And this happens in the private Learning Room repository that GitHub Classroom created for each learner, right? Not in the original template repository.

Alex: Right. Your Learning Room is your own private copy from the classroom assignment, named something like `learning-room-your-username`. Everyone practices the same issue, branch, commit, pull request, review, and merge flow, but your work stays in your own repo unless facilitators intentionally arrange peer review. Day 1 prioritizes Challenges 1 through 6, so this one is part of the core path.

---

Jamie: Before I touch the pencil icon, where should I be? I can imagine someone accidentally editing in the wrong place.

Alex: Start in your Learning Room repository, then check the branch dropdown. For Challenge 5, you should be on your `learn/YOUR-USERNAME` branch, which is the practice branch you created earlier so your work is separate from `main`.

Jamie: So the branch is a safety rail. I can make the change there first, and main stays stable.

Alex: Yes. The Learning Room was designed for that kind of practice: safe enough to experiment, realistic enough to build real habits, and paced so you are not blocking anyone else.

Jamie: What if someone is listening and thinking, I do not even see my Learning Room yet?

Alex: Then go back to the GitHub Classroom assignment link, make sure you accepted the assignment, and open the repository link when GitHub finishes creating it. If Challenge 1 was missing earlier, the usual check was the Issues tab and then the Actions tab, where the progression workflow and Gandalf PR validation workflow live. By Challenge 5, you should already have that repo bookmarked and your challenge issue open.

---

Jamie: Okay, what file are we editing?

Alex: Open `docs/welcome.md`. The `docs` folder also contains practice files like `keyboard-shortcuts.md`, `setup-guide.md`, and `CHALLENGES.md`, but Challenge 5 is focused on the TODO you found earlier in the welcome file.

Jamie: The issue says to replace the TODO with real content. Does that mean there is one correct sentence everyone has to use?

Alex: No. The reference solution gives an example, not a required answer. For instance, it replaces a comment like `TODO: add link to workshop schedule` with a sentence that links to the workshop schedule file.

Jamie: So if my TODO is about who can contribute, I write a clear sentence or two that actually belongs in that section.

Alex: Exactly. Keep it small, useful, and related to the TODO. This is not a redesign of the whole page. It is one focused improvement.

---

Jamie: Walk me through the browser version, because that is the path a lot of people will use first.

Alex: In your Learning Room, confirm the branch dropdown says `learn/YOUR-USERNAME`. Then navigate to `docs/welcome.md`, open the file, and activate the pencil icon labeled `Edit this file`.

Jamie: Then I find the TODO in the editor and replace it with my actual text.

Alex: Yes. After the edit, move to the commit area. Write your commit message, and for this challenge commit directly to your `learn/YOUR-USERNAME` branch.

Jamie: If I use a screen reader, is the pencil icon findable as a button?

Alex: It should be. With NVDA or JAWS, many learners use button navigation to find `Edit this file`. With VoiceOver, the Buttons rotor can help. The important part is to verify the file name and branch before you start typing.

Jamie: What if GitHub offers to create a new branch?

Alex: For Challenge 5, stay with the challenge instruction and commit to your learning branch. In the next pull request work, you will see short-lived feature branches like `fix/yourname-issueXX`, but this challenge is about making one meaningful branch commit.

---

Jamie: The commit message feels small, but it is doing a lot of work here.

Alex: It is. A message like `Update welcome.md` tells us the file changed, but not what happened. A stronger message is `Add workshop description to welcome.md` or `Replace placeholder text with actual welcome message`.

Jamie: So I should be able to read the message later and know the purpose of the change without reopening the file.

Alex: That is the goal. A good commit message answers two plain questions: what changed, and why it changed.

Jamie: The solution shows a more formal version too, right? Something like `docs: replace TODO with workshop schedule link`, then a short body underneath.

Alex: Yes, and that format is useful. The first line is a short summary, often around 50 characters if you can manage it. Then a blank line can separate an optional body that explains the reason in more detail.

Jamie: But I do not have to use the fancy prefix to pass the challenge.

Alex: Correct. `Fix TODO in welcome.md` and `Add schedule link to welcome page` are both acceptable because they are clear. The convention is helpful, not mandatory.

---

Jamie: After I commit, what evidence do I need to give back in the challenge issue?

Alex: Paste the commit URL, share the exact commit message you used, and briefly say what you changed the TODO to say. The issue template asks for all three so a facilitator, bot, or future-you can follow the trail.

Jamie: How do I find the commit URL if I have never copied one before?

Alex: After the commit, GitHub usually shows the latest commit near the file or repository view. Open the commit message link, and copy the URL from the address bar. You can also use the commit history for the file if you need to find it again.

Jamie: There is also a peer simulation check in the issue. What is that asking me to notice?

Alex: Compare your commit message with the peer-simulation PR title and commit message in your repo. Ask yourself whether you can tell what changed just by reading the title or message. If you have a real buddy in the workshop, comparing messages is a good way to practice clarity without judging anyone's writing style.

---

Jamie: What if the GitHub web editor is not the tool I want to use?

Alex: That is fine. On github.com, the pencil icon path is the most direct. In github.dev, you can press `.` from the repository to open the browser-based VS Code editor, edit the file, and commit from Source Control.

Jamie: And if I am working locally?

Alex: You can use VS Code with Git: edit the file, stage with `git add`, and commit with `git commit`. GitHub Desktop works too: edit in your preferred editor, return to Desktop, write the message, and click Commit.

Jamie: So the tool is flexible, but the outcome is not vague.

Alex: Right. The successful outcome is a real edit in `docs/welcome.md` and a descriptive commit message saved on the correct branch.

---

Jamie: Let us talk about the mistakes people are afraid of, because this is where anxiety can spike.

Alex: The most common one is editing on `main` instead of your practice branch. If you catch it before committing, switch to `learn/YOUR-USERNAME` with the branch dropdown and make the edit there.

Jamie: What if I cannot find the edit button at all?

Alex: Look near the top-right area of the file view for the pencil icon, or search the buttons for `Edit this file`. If the button is unavailable, check that you are in your own Learning Room repo and signed in with the right GitHub account.

Jamie: And the scary one: I accidentally committed to main.

Alex: Ask your facilitator for help. It is fixable, and this is exactly why the Learning Room exists. You are practicing real work in a place where recovery is part of the lesson.

Jamie: If I finished but I am not sure it is good enough, should I copy the solution exactly?

Alex: Use the solution as a comparison, not as a script. Your edit can be different. Check that it replaces the TODO with real content, that the commit message makes sense, and that your evidence points to the commit.

---

Jamie: How does this connect to pull requests? Challenge 5 is only a commit, but the chapter around it talks a lot about PRs.

Alex: A pull request, or PR, is how a saved change becomes a proposed contribution for review and merge. Challenge 5 gives you the commit habit first, because every PR is made of commits.

Jamie: So later, when I open a PR, the reviewer will see not only my description but also the commits behind it.

Alex: Exactly. A PR page has several important places: the Conversation tab for the description, comments, and bot feedback; the Commits tab for saved changes; the Checks tab for automated results; and the Files changed tab for the diff.

Jamie: Diff means the before-and-after view of the file, right?

Alex: Yes. Removed lines and added lines are shown so reviewers can understand the change. In later PR work, you will also include a line like `Closes #XX` in the PR description so the related issue closes automatically when the PR is merged.

Jamie: And Gandalf reads the PR too?

Alex: Gandalf posts validation feedback on the PR Conversation tab. It can check things like issue linkage, description detail, and accessibility-related file issues. If something fails, you update the branch and the checks run again.

Jamie: That makes the commit message part of a bigger communication chain.

Alex: Yes. A clear commit helps the PR make sense, a clear PR helps review move faster, and review prepares you for contributing beyond the Learning Room.

---

Jamie: There are a lot of moving pieces around the Learning Room: optional skills modules, peer review, bots, study groups. How much of that matters for this challenge?

Alex: For Challenge 5, keep your attention on the edit and commit. But it helps to know the larger map: GitHub Skills modules are optional self-paced practice in your account, while the Learning Room is the required workshop track for Day 1.

Jamie: And peers do not automatically see everything in my private repo.

Alex: Right. Facilitators may arrange peer review or sharing when it is useful, but your repo is private by default. The usual PR flow is: you open a PR, automation gives feedback, a reviewer may comment, you respond or update, and then the work is merged when it is ready.

Jamie: What if review takes a while, or I disagree with feedback?

Alex: Ask for facilitator help, respond kindly, and keep the conversation tied to the change. Study groups are fine when the workshop allows them, but your evidence and decisions should still be your own.

Jamie: It sounds like this tiny TODO edit is rehearsal for open source communication.

Alex: It is. And if GitHub's interface changes, use current official GitHub documentation, GitHub's accessibility guidance, or your facilitator as references. The labels may move, but the workflow remains: find the right repo, use the right branch, make the smallest useful change, describe it clearly, and leave evidence someone else can follow.

Jamie: So for Make Your Mark, I check my branch, edit `docs/welcome.md`, replace the TODO, commit with a meaningful message, paste the commit URL and message, and compare whether my message is understandable.

Alex: That is the challenge. Small change, clear record, confident next step.

Jamie: I like that. It is not about writing the perfect sentence. It is about making a real contribution that someone else can understand.