Alex: Welcome back. This is the closing conversation for the workshop, but it is not an ending. It is the moment where the live structure fades, and your own developer rhythm starts to matter.

Jamie: I like that, because after a workshop there can be this quiet drop-off. You had issues assigned, people nearby, and a schedule. Then suddenly it is just you and GitHub.

Alex: Exactly. So we are going to make the after-workshop path feel practical: what you built, what skills you can now claim, how to show the work, and how to keep learning without waiting for another event.

Jamie: And maybe how to avoid the classic trap of thinking, I finished the workshop, but I am not a real developer yet.

Alex: Start with what happened on Day 1. In your Learning Room repository, which was provisioned for you, you created real GitHub activity. You configured your account, adjusted accessibility settings, moved through repositories and files, filed issues, created branches, edited files, opened pull requests, responded to automated feedback, and merged work.

Jamie: That is a lot more than watching a demo. You also dealt with the things people usually meet later, like merge conflicts, reviews, labels, milestones, project boards, and notifications.

Alex: Right. Day 1 was the proof that you can navigate this environment and participate in a collaborative workflow. Not perfectly, not magically, but with enough orientation to keep going.

Jamie: And Day 2 moved from GitHub in the browser into building locally.

Alex: Yes. You installed and configured VS Code, cloned a repository, worked with Git on your computer, and practiced the mental model of working directory, staging area, and repository. You created branches, staged changes, committed, and pushed. You also explored Copilot, issue templates, fork-based contribution, the Accessibility Agents living catalog, and the capstone path.

Jamie: And the capstone part is broader than one project, right?

Alex: Yes. Challenge 16 is the Capstone Project, and it accepts meaningful work for Accessibility Agents, GLOW, or another repository where your contribution makes sense. A review-ready draft or a clear contribution plan can count as valid evidence. The important thing is that your GitHub profile now shows real traces: issues, pull requests, reviews, commits, and capstone evidence.

Alex: There is also a skills inventory hiding inside all of that work. Repository navigation applies to almost any GitHub project. Issue tracking applies to bug reports, feature requests, and project planning. Pull requests, code review, merge conflicts, and Git fundamentals show up in companies, open source projects, and school teams.

Jamie: And VS Code is not just a workshop tool. It is where a lot of daily development happens, no matter what language someone learns next.

Alex: Exactly. You also practiced accessibility awareness across the whole workshop, which means you were not only learning tools. You were learning to notice whether software includes people or creates barriers.

Jamie: There are a few skills learners may not recognize as skills, too. Reading documentation, for example, can feel like the thing you do because you are stuck.

Alex: And it is one of the strongest developer skills there is. You followed written guides, compared instructions with what was on screen, looked up references, and adjusted when something did not match. You also practiced asking for help with context: what you tried, what error you got, and what you expected to happen.

Jamie: So the hidden skill is not knowing every command by memory. It is being able to recover, communicate, and keep learning while the tools change.

Jamie: How does someone turn all of that into a portfolio without making it feel fake or inflated?

Alex: Start with your GitHub profile, because it is already connected to the evidence. Go to github.com/settings/profile and find the pinned repositories area. Pin repositories that show your best work, such as a project you created, a contribution repository you actually used, or a personal project you build after the workshop.

Jamie: So not every repository needs to be pinned. Choose the ones that help a visitor understand what you can do.

Alex: Exactly. Then create a profile README. That means making a repository with the same name as your GitHub username, with matching capitalization, and adding a README.md file. A simple version can say: Hi, I am your name, I am focused on these interests, here is recent work, and here is what I am learning.

Jamie: Recent work could include preparing a capstone contribution for Accessibility Agents, GLOW, or another meaningful repository, plus completing this workshop. What I am learning could name topics like Git, accessibility, JavaScript, Python, or AI-assisted development.

Alex: Yes. Keep it honest and current. Your contribution graph can also support the story, because issues, pull requests, commits, and reviews can all create activity. Consistency matters more than trying to produce a huge burst once in a while.

Jamie: There are some accessibility details worth naming here. In profile settings, pinned repositories are checkboxes, so a screen reader user can Tab through them and press Space to pin or unpin. The contribution graph may be announced as a table or grid, with day cells that include dates and counts.

Alex: For low-vision users, pinned repositories appear as cards, and at high zoom they may reflow into a single column, which can be easier to scan. Test your profile README in light and dark themes, especially if you use images. For sighted visitors, pinned repositories and the README are highly visible, so concise headings and a few clear bullets go a long way.

Jamie: What about practice after the workshop? Without live prompts, it is easy to either do nothing or pick something way too big.

Alex: A sustainable habit can be small. Once a week, open GitHub, review notifications, read one issue, make one small improvement, or write down one thing you learned. The goal is to keep your hands on the workflow so it stays familiar.

Jamie: Finding approachable issues is the part that can feel intimidating. Labels like good first issue are helpful, but they do not always mean easy.

Alex: True. Look for signals around the label. Is the issue clearly described? Does the repository have a README, contribution guide, or code of conduct? Are maintainers responding respectfully? A smaller documentation fix, typo correction, accessibility note, or reproduction step can be a very real contribution.

Jamie: And if you are not ready to claim an issue, you can ask a careful question.

Alex: Yes. You can say what you understand, what you are considering, and what you want to confirm before starting. That is professional. It is much better than silently struggling for hours or sending a huge pull request that does not match the project.

Alex: For deeper learning, give yourself lanes. For Git and version control, the Pro Git book is free and thorough, and chapters 2 and 3 are a useful starting point. Later, the advanced Git appendix can help with rebasing, cherry-picking, stashing, and other tools you do not need every day at first.

Jamie: For GitHub itself, the official documentation is worth bookmarking, and GitHub Skills gives you interactive practice. The GitHub Blog is useful when you want to keep up with feature changes and common practices.

Alex: For VS Code, the VS Code documentation covers settings, keybindings, and extensions, and the accessibility documentation goes deeper on screen reader support, high contrast, and keyboard navigation. For accessibility, keep WCAG 2.2 close, especially the quick reference, and use resources like WebAIM, Deque University, and the workshop appendix on accessibility standards.

Jamie: And AI-assisted development keeps changing, so it helps to return to official Copilot documentation, plus the workshop references for Copilot and agents. Use those tools as support, not as a replacement for understanding what you are changing.

Alex: For programming languages, choose based on what you want to build. Web interfaces often point toward HTML, CSS, and JavaScript. Data work might point toward Python. Automation and scripting can also begin with Python or shell basics. Interest is a strong filter, because you will stay with practice longer when the work connects to something you care about.

Jamie: GitHub Skills feels like a good bridge after this workshop because it still teaches by doing. Which courses would you suggest trying next?

Alex: Start with courses that reinforce the workflow you just learned: Introduction to GitHub, Communicate using Markdown, Review pull requests, Resolve merge conflicts, and GitHub Pages if you want to publish a simple site. If you are moving toward automation, look for courses on GitHub Actions. If you want more collaboration practice, choose pull request and project management courses.

Jamie: How does someone start one without getting lost?

Alex: Go to skills.github.com, choose a course, and select the start button. Most courses create a practice repository in your account, then guide you through issues, comments, and pull requests. Treat it like a safe lab. Read the instructions, make the smallest required change, wait for the bot feedback, and continue when the course updates.

Alex: Staying connected matters, too. Community Access resources can help you find support after the workshop, especially if you want spaces that understand accessibility, learning pace, and assistive technology.

Jamie: Open source can feel huge, though. How do you pick communities that are healthy?

Alex: Look for projects where maintainers communicate clearly, issues are organized, contribution guidance exists, and people are treated respectfully. You can also start by observing: read discussions, watch how reviews happen, and notice whether newcomers get useful responses.

Jamie: The accessibility community is also a place to keep learning. It includes developers, testers, designers, assistive technology users, educators, and advocates.

Alex: Yes, and that mix is valuable. Accessibility work improves when lived experience and technical skill meet. You can contribute by reporting barriers clearly, testing with assistive technology, improving documentation, reviewing designs, or helping code meet accessibility standards.

Jamie: What if someone wants to contribute back to this workshop itself?

Alex: That is welcome. Useful contributions include fixing typos, clarifying instructions, reporting confusing steps, improving alt text, suggesting accessibility notes, updating links, testing with a screen reader or magnification, or proposing new examples. Small fixes are not lesser contributions. They make the path easier for the next learner.

Jamie: And the workflow is the familiar one.

Alex: Yes. Open or find an issue, discuss the change if needed, create a branch, make the edit, commit it with a clear message, open a pull request, and respond to review. If the project asks for a different process, follow the contribution guide. That habit of reading the local instructions before acting will serve you everywhere.

Jamie: So contributing back is also practice. You are improving the material and rehearsing the same collaboration pattern in a real context.

Alex: If you get stuck after the workshop, slow the problem down. Write down where you are, what command or action you tried, what happened, and what you expected. Then check the README, the issue thread, the official documentation, and recent project activity.

Jamie: And if you ask for help, include the text of the error when you can, not just it did not work.

Alex: Exactly. Share your environment, the step you were on, what changed recently, and what you already tried. That gives another person something to work with. It also helps you notice the answer yourself sometimes.

Jamie: That is reassuring. Getting stuck is not evidence that you do not belong. It is part of the work.

Alex: Here is the final thought. You did not leave this workshop with only a certificate-shaped memory. You left with repositories, pull requests, commits, reviews, issues, settings, tools, and a better sense of how collaboration happens.

Jamie: And you do not have to keep the same pace as a workshop. You just need a pace you can return to.

Alex: Exactly. Keep one small habit alive. Read, try, commit, ask, review, and reflect. Over time, those small actions become a developer story you can point to with confidence.

Jamie: Congratulations on finishing the workshop. More importantly, congratulations on having a real next step.