Alex: Welcome back. Challenge 1 is called Find Your Way Around, and it is exactly what it sounds like: a guided scavenger hunt through your Learning Room repository.

Jamie: I like starting there. Before anyone edits a file or opens a pull request, they need to know where they are and what they are touching.

Alex: Yes. Your Learning Room is your own private GitHub repository for Day 1. It is created from a template when you accept the GitHub Classroom assignment, but you do not work in the template itself.

Jamie: So my repo is not the class shared notebook. It is my copy, with my issues, my branches, my pull requests, and my practice space.

Alex: Exactly. You accept the Classroom link, wait while GitHub creates the repo, open the new repository link, and bookmark it. The repo name usually looks like learning-room-your-username inside the workshop organization.

Jamie: And Challenge 1 shows up as an issue in that repo, right? The Student Progression Bot opens the next challenge after you close the current one.

---

Alex: A little GitHub map helps before we click around. GitHub has account pages, organization or user spaces, and repositories. Most workshop work happens inside a repository, because that is where files, issues, pull requests, checks, and project history live.

Jamie: So when someone says, go to the repo, I should expect a page whose main heading is something like owner slash repo-name.

Alex: Right. Every GitHub page also has a global navigation area near the top. Inside a repository, there is a second navigation area for that repo, with tabs such as Code, Issues, Pull requests, Actions, Projects, Wiki, Security, Insights, and sometimes Settings.

Jamie: And if I am using a screen reader, I do not have to rely on where things appear visually. I can use landmarks, headings, links, and tab names.

Alex: Three signals tell you where you are: the URL, the browser tab title, and the first H1 heading. For example, owner slash repo is usually the Code tab, owner slash repo slash issues is the Issues list, and owner slash repo slash pull slash 7 is a specific pull request.

Jamie: My quick check would be: press 1 to hear the main heading, press D to move through landmarks, and open the headings list if I want a fast scan of the page.

Alex: That works well. Also remember that GitHub's layout can change with zoom level, window width, account settings, and product updates. So use visual position as a hint, but trust stable things like the URL, heading, landmark name, tab label, button text, and file name.

---

Jamie: Okay, I have the Challenge 1 issue open. What is the first thing I am actually asked to find?

Alex: Start on the Code tab. The challenge asks you to look at the file and folder list in the root of the repository and count how many items are showing before the first folder.

Jamie: Before the first folder is a funny detail. Why not just count everything?

Alex: Because this is a navigation practice task, not a math test. Repositories change over time, and the exact count may vary. If you can find the Code tab, reach the file list, and write a reasonable count, you are doing the skill.

Jamie: So the evidence can be simple, like, I found 3 files in the root before the first folder, even if someone else's number is different.

Alex: Yes. Then move to the Issues tab. Look for an issue marked Open, activate one, read it, and write down its title.

Jamie: What if there are no open issues when I look?

Alex: Then say that. Noting that the Issues tab exists and that you checked it is acceptable for this scavenger hunt. The goal is to learn the page type: Issues list, then issue detail.

Alex: Back on the Code tab, open the docs folder and then open docs/welcome.md. Read the first paragraph or opening sentence and write down what it says.

Jamie: And if I notice TODO comments in that file, I should not panic. Those are intentionally left there for a later challenge.

---

Alex: The next few findings are about understanding the project from its surrounding text. On the Code tab, find the repository description, then find the README, and then check the About area.

Jamie: The challenge says top-right for the description and right sidebar for About, but GitHub may move those pieces around at high zoom or on a narrow screen.

Alex: Exactly. Listen or look for the repository description near the repo name or in the About information. It is short text that tells you what this repository is for.

Jamie: And the README is the longer rendered document that GitHub shows below the file list, if the repo has one.

Alex: Right. For this challenge, open README.md and find the part about who the workshop is for. Then write a sentence about what you found. For the About area, write down the repo information you can identify, such as the description or other visible repo details.

---

Jamie: Let's slow down on the file list, because that is where a lot of people lose their place.

Alex: On the Code tab, the file list behaves like a table. It usually has a name column, a recent commit message column, and an age column that says how long ago the item changed.

Jamie: For screen reader table navigation, I might jump to the table and move row by row. On Windows screen readers, that is often Ctrl+Alt with arrow keys inside the table.

Alex: Yes. In the name column, folders and files are links. Folders may be announced with a trailing slash, and opening a folder reloads the page to show that folder's contents. Breadcrumb links and the browser Back command can take you back up.

Jamie: There is also a file finder shortcut, right?

Alex: Yes. GitHub has a Go to file control, and the repository shortcut T can open it when GitHub receives the key command. If your screen reader is using T for table navigation in Browse Mode, choose the method that is working in your current setup.

Jamie: When I open a Markdown file like README.md or welcome.md, I should expect headings, paragraphs, links, and maybe code-style text. A code file will feel different because the content is line-oriented.

Alex: And single file pages have action buttons too, such as controls to view raw content, copy, download, or edit when you have permission. Later you will edit files, but in Challenge 1 you are mainly reading and recognizing the page.

Jamie: What about blame and commit history? Those sound ominous.

Alex: They are just history views. Commit history shows a list of saved changes. Blame shows which commit last changed each line of a file. You do not need them to finish this challenge, but knowing they exist helps when you want to understand who changed what and when.

---

Jamie: Challenge 1 mostly uses Code and Issues, but the repo has more tabs than that.

Alex: It does. Pull requests are where proposed changes are discussed before merging. Actions show automation runs. Projects, Wiki, Discussions, Security, Insights, and Settings may appear depending on the repository and your permissions.

Jamie: The branch selector is on the Code tab too. Do I need to use it right away?

Alex: Not for this scavenger hunt, but you should recognize it. A branch is a safe line of work inside the same repo. Later, you will create a practice branch so your changes do not go straight onto main.

Jamie: And tags?

Alex: Tags are named points in history, often used for releases. The same selector may let you switch between branches and tags.

Jamie: I always mix up clone, fork, and branch.

Alex: A clone is a local copy on your computer. A fork is your own server-side copy of someone else's repository. A branch is a separate line of work inside a repository. For Challenge 1, you do not need to fork anything.

Jamie: And watching, starring, and forking are different social or workflow actions.

Alex: Right. Watching subscribes you to notifications. Starring bookmarks or signals interest. Forking creates a copy under your account or organization. Useful tools, but not required for completing Find Your Way Around.

Jamie: If the website is hard for me on a given day, do I have alternate ways to browse?

Alex: Yes. You can use github.com in the browser, press period on a repo page to open github.dev, browse with VS Code and the GitHub Repositories extension, or use GitHub CLI. For example, gh repo view owner/repo --web opens a repo page in your browser, and standard git clone works when you are ready to work locally.

---

Alex: When you have your findings, paste them into the evidence box in the Challenge 1 issue. Short sentences are enough: the root count, an open issue title, the opening of welcome.md, the repository description, who the README says the workshop is for, and what the About area shows.

Jamie: I appreciate that the evidence is not trying to trick anyone. If I explored the right places and described what I found, that counts.

Alex: After you submit your evidence, the challenge asks you to open the Peer Simulation: Welcome Link Needs Context issue and leave an encouraging comment or reaction. If your facilitator gives you access to a real buddy repository, you can use your buddy's issue instead.

Jamie: So even in the first challenge, I am practicing repository navigation and community behavior. Find the place, read the context, respond kindly.

Alex: Exactly. Then follow the issue instructions for completion. In this Day 1 flow, closing a challenge issue is what lets the Student Progression Bot open the next challenge.

---

Jamie: What are the common places people get stuck in this one?

Alex: If you cannot find the tabs, move to the Repository navigation landmark or search the links for Code and Issues. If you cannot find docs/welcome.md, return to the Code tab, open docs, then choose welcome.md. If you are unsure what to write as evidence, describe what you found in your own words.

Jamie: And if Challenge 1 itself is missing after I accepted the assignment?

Alex: Refresh the Issues tab once or twice. If it still does not appear after a couple of minutes, check the Actions tab for the Student Progression Bot workflow, then ask a facilitator with your repo link. While you are in Actions, you may also see the PR validation workflow for Gandalf; you do not need to run it yet.

Jamie: So the win condition is not memorizing GitHub's current layout or having the same file count as everyone else.

Alex: Right. The win is confidence. You can identify the repo, move between Code and Issues, open a folder, read a Markdown file, find the README and About information, leave a first community-style response, and recover when the page does not look exactly like the screenshot in your head.