Alex: Welcome back. Today we're working on Bonus B: Document Your Journey.

Jamie: I like this one already. It sounds less like fixing a file and more like making sense of what just happened.

Alex: That's exactly the spirit. You write a reflection document about your workshop experience, what you learned, what surprised you, and what you want to do with these skills next.

Jamie: And this is a bonus challenge, so when does it appear for learners?

Alex: Bonus challenges unlock after Challenge 15, Discover Accessibility Agents. That challenge is browse-first, because the Accessibility Agents collection is a living catalog that grows over time. After Challenge 15, Bonus B can happen before, during, or after Challenge 16, which is the Capstone Project.

---

Jamie: So what does completion actually look like here? Are we writing a private journal entry, or something that belongs in GitHub?

Alex: You're writing a Markdown file in a repository, usually on your own branch. The target file path is reflections/YOUR-USERNAME.md, with your actual GitHub username in the file name.

Jamie: That path is useful. It tells me this is documentation, not just a comment I might lose later.

Alex: Right. The challenge asks for a 300 to 500 word reflection with headings and lists. It should include what you learned, how the experience felt, your biggest win, what comes next, and one piece of advice for the next cohort.

Jamie: What if somebody hears that and freezes because they don't know what their biggest insight is yet?

Alex: Start with the easiest prompt: what would you tell someone starting tomorrow? One honest sentence is enough to get the file moving, and you can build from there.

---

Alex: A strong reflection usually has a simple arc. Before the workshop, what did GitHub feel like? During Day 1, what became less mysterious? During Day 2, what clicked because you built or reviewed something yourself?

Jamie: So not, "I learned GitHub," full stop. More like, "I learned that an issue is a conversation about an improvement," or, "I learned that a branch lets me work without disturbing main."

Alex: Yes. Day 1 happened in your Learning Room repository, which was provisioned for you. That's where you practiced the core contribution path: issue, branch, commit, pull request, and merge.

Jamie: And those moments are worth writing down because they can feel tiny while you're doing them. Filing a first issue or resolving a merge conflict can be a real confidence shift.

Alex: For Day 2, you might mention going local in VS Code, using the terminal, reviewing a pull request, or exploring the living catalog of Accessibility Agents in Challenge 15. If you connect this to the Capstone Project, remember that Challenge 16 accepts contributions to Accessibility Agents, GLOW, or any other meaningful repository.

Jamie: And the capstone evidence does not have to be a perfect, fully merged masterpiece.

Alex: Exactly. A review-ready draft or a clear contribution plan can be valid evidence. In your reflection, describe what you attempted, why you chose that repository or topic, and what you learned from preparing the work.

---

Jamie: Let's talk about tone, because "portfolio language" can sound intimidating. How polished should this be?

Alex: Polished enough that another person can follow it, but still in your own voice. Instead of saying, "I am now an expert developer," say what you can actually do: "I can open a focused pull request, write a clear description, and respond to review comments."

Jamie: That's more believable, and honestly more useful if someone reads it later.

Alex: Specific beats grand. Name your top three GitHub skills, explain one challenge that felt hard, and describe one win you are proud of. Then add what you'll do next, such as contribute to an accessibility project, set up Git on your personal laptop, or keep practicing with GitHub learning materials.

Jamie: And the one sentence summary at the end can be simple.

Alex: Very simple. Something like, "I came in thinking Git was only for programmers and left understanding it as a collaboration tool." If your document has headings, paragraphs, and honest reflection, you have met the main learning goal.

---

Alex: Markdown is the format that makes this reflection readable on GitHub. It's plain text with lightweight symbols for structure, like number signs for headings, hyphens for lists, and brackets for links.

Jamie: And GitHub turns that plain text into rendered HTML, so headings become real headings and lists become real lists.

Alex: Yes. You can practice Markdown in a GitHub issue, in any .md file in VS Code with preview, or in a GitHub Gist. In VS Code, Markdown preview is commonly opened with Ctrl+Shift+V.

Jamie: For this reflection, what are the easy accessibility wins?

Alex: Use one top-level title, then use heading levels in order. Put a space after the number signs, leave blank lines between paragraphs, and use real lists instead of long comma-heavy sentences.

Jamie: And links and images?

Alex: Use descriptive link text, not "click here." If you include an image, write alt text that explains the purpose of the image. Inline code is useful for file names like reflections/YOUR-USERNAME.md, and fenced code blocks should include a language identifier when you use them.

---

Jamie: GitHub Markdown has extra features too, right? Do learners need all of them for this bonus?

Alex: They don't need all of them, but it's useful to recognize them. Task lists can show next steps, alert blocks can highlight notes or warnings, and details sections can make optional material collapsible.

Jamie: I always wonder about tables. They look neat visually, but they can get noisy with assistive technology.

Alex: Use tables only when the information truly has rows and columns. Introduce the table before it appears, keep it simple, and avoid using a table just to make layout look tidy.

Jamie: What about the fancy stuff, like diagrams and math?

Alex: Mermaid diagrams need a text equivalent because the diagram alone may not communicate well to everyone. Math expressions and footnotes can be useful, but they are not needed for this reflection. Heading anchors, issue references, pull request references, commit hashes, and user mentions can help connect your story to real GitHub work.

Jamie: And HTML inside Markdown?

Alex: Use it sparingly. GitHub allows some HTML, like keyboard key styling, but blocks unsafe elements. Preview your file and listen to how the structure reads, because rendered Markdown is what most people will encounter.

---

Alex: The open source culture chapter gives this reflection some depth. It reminds us that technical skill gets work into a project, but communication helps people keep working together.

Jamie: So if I'm reflecting on the workshop, I can include communication habits too, not just commands I memorized.

Alex: Definitely. GitHub Flow is the core workflow: create a branch, make changes and commit, open a pull request, discuss and review, pass checks, and merge. The pull request is where the explanation, tradeoffs, review, and decision all live.

Jamie: And Git Flow is different, right? Some learners may see that term later.

Alex: Git Flow is a more complex release model with branches like develop, feature, release, and hotfix. You may see it in older or release-heavy projects, but this workshop uses GitHub Flow because it is simpler for open source contributions.

Jamie: What about forks staying current?

Alex: If you work from a fork, sync it before starting new work, after upstream changes, or before opening a pull request. The GitHub web interface is usually the easiest method, but the command line version is: add an upstream remote once, switch to main, fetch upstream, merge upstream main into your main, then push your updated main to your fork. GitHub Desktop can also handle this through its interface.

---

Jamie: A lot of the culture chapter is about feedback. How does that belong in a journey reflection?

Alex: You can write about the kind of collaborator you are practicing becoming. Helpful feedback usually starts by acknowledging what works, then names a specific concern, explains why it matters, suggests a path forward when possible, and makes clear whether the concern is required or optional.

Jamie: That sounds very different from just saying, "This is wrong."

Alex: Exactly. Prefer "we" language or describe the code instead of the person. Use tentative language when you're unsure, respect cultural and language differences, and avoid urgency words unless something is truly urgent.

Jamie: Comment etiquette matters too. Public threads can feel high stakes.

Alex: Keep comments focused, don't pile onto a point someone else has already made, and resolve conversations when the work is actually addressed. Reactions can acknowledge without adding noise. Saved replies can also help you reuse kind, clear language for common situations, including accessibility review notes.

Jamie: And both sides of code review have responsibilities.

Alex: Reviewers should review the work, not the person, ask questions instead of making demands, avoid gatekeeping knowledge, and approve explicitly when the work is ready. Authors can say thank you, explain choices, avoid taking feedback personally, and surface blockers early.

---

Alex: There are a few more open source habits that can shape the reflection. A good README explains what the project is, how to install or use it, how to contribute, and what license applies.

Jamie: And accessibility belongs there too, not hidden away.

Alex: Right. A README can mention keyboard support, screen reader notes, known accessibility limits, or how to report an accessibility issue. Community health files also matter: CONTRIBUTING.md, CODEOFCONDUCT.md, SECURITY.md, and LICENSE help people understand how the project works.

Jamie: For first-time contributors, what makes a good starting point?

Alex: Small, clear, and scoped. Read the issue before starting, check whether someone is already assigned, ask a focused question if needed, make one coherent change, and write a pull request description that explains what changed and how to review it.

Jamie: And when things get uncomfortable?

Alex: If feedback feels harsh, pause before replying and look for the actionable part. If you disagree, explain your reasoning respectfully. If someone is rude, use the project's code of conduct or ask a maintainer for help. If you caused offense, acknowledge it, apologize briefly, and adjust your behavior.

---

Jamie: Walk me through the actual Bonus B workflow like I'm doing it right now.

Alex: Start on your branch. Create a file at reflections/YOUR-USERNAME.md. Add a title such as "My Git Going with GitHub Journey."

Jamie: Then I add sections for before the workshop, Day 1, Day 2, what I built, and what I would tell future students.

Alex: Yes. You can also use headings like "What I learned," "My biggest win," and "What I will do next." Keep it around 300 to 500 words, use lists where they make the writing easier to scan, and keep paragraphs short.

Jamie: What should the commit message sound like?

Alex: Make it meaningful and specific, such as "Add workshop journey reflection." Then push your branch to GitHub and open a pull request. In the challenge issue, the required evidence is a link to your reflection file or pull request, plus a brief takeaway if you want to include one.

Jamie: The challenge also says sharing in wins or discussions is optional.

Alex: Yes. Share if it feels useful or encouraging, but the required part is the reflection file or PR link.

---

Jamie: Before someone submits, what should they check?

Alex: Preview the rendered Markdown. Make sure the heading levels make sense, paragraphs have blank lines, links have meaningful text, any images have alt text, and the file is not far outside the word count.

Jamie: And if the formatting looks wrong?

Alex: Check the common Markdown mistakes first: missing space after the number signs in a heading, no blank line between paragraphs, skipped heading levels, generic link text, missing alt text, a table with no introduction, or a code block with no language label.

Jamie: Where should learners look when they want the official answer instead of guessing from memory?

Alex: Use GitHub's official writing and formatting documentation for Markdown behavior, GitHub's open source contribution guidance for workflow, Open Source Guides for community expectations, and W3C WAI resources for accessibility patterns.

Jamie: So Bonus B is not busywork. It's a chance to turn two days of practice into something you can reread, share, and build on.

Alex: Exactly. Document the journey in your own words, format it accessibly, and leave a clear trail of what you learned and what you plan to do next.