Alex: Welcome to Git Going with GitHub. This episode is the front porch for the workshop: what you are building, where the pieces live, and why the path is designed the way it is.

Jamie: I like that phrase, front porch. Because if someone is brand new to GitHub, open source, VS Code, or the command line, the first question is probably, am I already supposed to know all of this?

Alex: No. Open source means people collaborate on projects where the work is visible, reviewable, and shared under rules that allow others to use or improve it. In this workshop, that collaboration is not pretend. You will practice the same GitHub workflow that real projects use.

Jamie: So open source is not just code sitting somewhere public. It is people proposing changes, discussing them, reviewing them, and deciding what should become part of the project.

Alex: Exactly. And accessibility work belongs in that conversation because small improvements can remove real barriers. The workshop gives you a supported place to learn the mechanics before you carry those skills into larger community projects.

---

Jamie: The materials also say this course is actively maintained. That feels important, because GitHub pages and VS Code screens do change.

Alex: They do. The course guide is your table of contents, and the Learning Room is your personal workshop space. The materials are being refined for the May 2026 cohort, so you should expect updates before and during the course.

Jamie: What happens if a button name or page order does not match what the chapter says?

Alex: Do not treat that as failure. Check the URL, the browser tab title, the page heading, landmarks, tab names, button labels, keyboard help, and in VS Code, the Command Palette. Then ask a facilitator or report the mismatch with the page link, the step that differed, and what your screen reader announced or what you observed.

---

Alex: The workshop has a two-day shape. Day 1 is GitHub foundations in the browser: navigating repositories, using issues, making branches and commits, opening a pull request, reviewing, and merging.

Jamie: Can we preview those words quickly? Because repository, issue, pull request, and merge can sound like a wall of vocabulary.

Alex: A repository is the project space. It holds files, history, issues, and pull requests. An issue is a tracked conversation about work to do, a bug, a question, or an improvement. A pull request, often shortened to PR, is a proposed change that other people can review before it becomes part of the project.

Jamie: And merge is the moment the approved change is brought into the main project history.

Alex: Right. A branch is a safe working line for your change, and a commit is a saved snapshot with a message. In Day 1, those contributions happen in your own provisioned Learning Room repository, so you can practice issue, branch, commit, pull request, and merge without risking a public project.

---

Jamie: Then Day 2 moves out of the browser-only world.

Alex: Yes. Day 2 is VS Code, Git, GitHub Copilot, and the Accessibility Agents ecosystem. Some workshop materials may describe a snapshot, for example 55 accessibility agents organized across 3 teams. The safest way to remember it is that Accessibility Agents is a living catalog: agents can be added, revised, or reorganized as the course grows.

Jamie: And the course is not saying, let the agents do magic before you know what is happening.

Alex: Right. You learn the manual workflow first, then you see how automation can support it. There is also a bridge between the two days: on many GitHub repository pages, pressing the period key opens github.dev, which gives you a VS Code-style editor in the browser. It is useful, but it has limits: no local terminal or debugger, web-compatible extensions only, and not the full desktop agent workflow.

---

Jamie: Before someone gets to all that, what should they do first?

Alex: Start with the pre-workshop setup. It helps you create or verify your GitHub account, choose a browser, install Git, install VS Code for Day 2, and configure your screen reader for GitHub. Plan about 30 minutes, and if setup is not finished before the workshop, tell a facilitator early.

Jamie: Then comes the GitHub Classroom assignment link, right?

Alex: Yes. The facilitator gives you a link that usually starts with https://classroom.github.com/a/. Open it in the browser where you are signed in to GitHub, authorize GitHub Classroom if asked, choose your name from the roster if prompted, accept the assignment, wait for the repository to be created, refresh until the repository link appears, and bookmark it.

Jamie: That repository name usually looks like learning-room-your-username.

Alex: Exactly. It is private to you unless the facilitator intentionally pairs you with someone. Everyone starts from the same template, but your issues, branches, commits, pull requests, mistakes, fixes, and bot feedback belong to your learning process.

---

Jamie: Once the Learning Room exists, how does a learner know what to do first?

Alex: The Student Progression Bot creates Challenge 1: Find Your Way Around. Open your Learning Room, go to the Issues tab, or use GitHub's keyboard shortcut G then I, find that challenge issue, and read it from top to bottom before activating controls.

Jamie: The issue itself tells you what to do and what evidence to post.

Alex: Yes. Evidence might be a comment, a field, or another requested trace of the work. When the instructions tell you to close the challenge issue, closing it triggers the next challenge. You are not expected to search the whole curriculum to guess the next task.

---

Jamie: There are a lot of tools named in the guide: browser, github.dev, VS Code, GitHub Desktop, GitHub CLI. How should someone choose without feeling behind?

Alex: Use the tool that fits the moment. The browser is best for Day 1, issues, repository navigation, pull requests, and reviews. github.dev is helpful when you want a VS Code-like editor without installing anything. VS Code desktop is best for Day 2 work with local Git, Copilot, extensions, and deeper editing.

Jamie: And GitHub Desktop or the command line are options, not secret requirements.

Alex: Exactly. GitHub Desktop gives you a visual desktop Git workflow. GitHub CLI is useful if you like terminal workflows or want automation later. If the command line is new to you, you still belong here; the course keeps returning to the contribution workflow itself: issue, branch, change, commit, pull request, review, and merge.

---

Alex: When you feel lost with a screen reader, listen for structure before you act. Useful signals include the page title, repository name heading, landmarks like main content or repository navigation, tab names such as Code, Issues, and Pull requests, issue or pull request titles, branch names, button names, field labels, bot comments, and check results.

Jamie: So the move is not to press keys faster. It is to pause, find where you are, and then decide.

Alex: Yes. And the course has built-in support. Every challenge has instructions and evidence prompts, chapters include stuck points, reference solutions are available after you try, Gandalf posts educational feedback on pull requests, and facilitators and peers are part of the learning system. If you are still stuck, open a support issue and include what you tried, what happened, what you expected, plus your screen reader and operating system.

---

Jamie: How do the chapters, appendices, podcasts, and exercises fit together?

Alex: The live agenda is intentionally smaller than the full curriculum. Live sessions focus on the core contribution path, while the full chapter set is there for preparation, catch-up, remote participation, and follow-up. Day 1 runs from setup and tool choice through GitHub navigation, the Learning Room, issues, pull requests, merge conflicts, open source culture, labels, notifications, and the Day 1 close.

Jamie: And Day 2 maps those browser skills into VS Code and a more complete contribution process.

Alex: Right. Day 2 covers VS Code setup, accessibility features, how Git works, Git in practice, code review, Copilot, issue templates, fork-based contribution, Accessibility Agents, the Capstone Project, and what comes next. Challenge 15 is browse-first discovery of Accessibility Agents, not a requirement to fork that repository. Completing Challenge 15 opens Challenge 16, titled Capstone Project, plus Bonus Challenges A through E; the capstone can be a contribution to Accessibility Agents, GLOW, or another meaningful repository, and review-ready drafts or contribution plans can be valid evidence.

Jamie: The appendices sound like the place to go when you need a quick answer rather than a full lesson.

Alex: Yes. Keep the glossary and screen reader cheat sheet handy. Other reference material covers core workshop help, deeper Git topics, VS Code and Copilot, GitHub platform features, community practice, troubleshooting, quick reference, and resources for continued learning. The course also points to official GitHub docs and the changelog when you need the current source of truth.

Jamie: And the exercises have a pattern: Try It, You are done when, and What success feels like.

Alex: That pattern matters because it makes practice checkable. Try It gives you the action, You are done when tells you the finish line, and What success feels like helps you recognize the result, especially when you are navigating by sound, keyboard focus, and page structure.

---

Jamie: What is the first success check for someone who just accepted the assignment?

Alex: You are ready to continue when you can say four things: I can open my Learning Room repository, I can find the Issues tab, I can open Challenge 1, and I know where to post evidence and how to ask for help.

Jamie: That is refreshingly small. Not, I understand all of Git. Not, I can solve every merge conflict.

Alex: Exactly. If you want the gentlest path, go from pre-workshop setup to choosing your tools, understanding GitHub, navigating repositories, learning the Learning Room, and then your Challenge 1 issue. You belong here, and the course will keep making the next step explicit.