Alex: Welcome back. Bonus C is called Group Challenge, and it asks you to design a collaborative challenge for future workshop cohorts.

Jamie: So the assignment is not just, work in a group. It is, design something that would make a group work well.

Alex: Exactly. You are creating the exercise, not merely completing one. The goal is to practice collaborative contribution, division of work, and communication across a small team.

Jamie: And this is part of the bonus path that opens after Challenge 15, right?

Alex: Right. Completing Challenge 15 unlocks Challenge 16, called Capstone Project, plus Bonus Challenges A through E. The capstone can involve the Accessibility Agents living catalog, GLOW, or another meaningful repository, and a review-ready draft or contribution plan can count there. Bonus C is one option inside that unlocked path.

---

Jamie: What is the learner actually making for Bonus C?

Alex: A written challenge design that 3 to 5 students could complete together. It should teach teamwork, not just split a task into unrelated pieces.

Jamie: So the output is a file, not a finished app or a finished accessibility fix.

Alex: Yes. You are documenting a reusable exercise in your Learning Room repository. That repository is provisioned for each learner, and it is also where the Day 1 issue, branch, commit, pull request, and merge practice happens.

Jamie: That helps. The Learning Room is the safe place to leave the design and show your work.

Alex: Exactly. Future cohorts should be able to open your file, understand the challenge, and know how the team would prove they finished.

---

Jamie: I think the hardest part is choosing a collaboration problem. What makes a good one?

Alex: Start with a task that one person could not easily do alone, or at least should not do alone if you want a better result. The work should create a reason for people to coordinate, compare findings, review each other, or depend on shared decisions.

Jamie: What is the difference between real collaboration and parallel solo work?

Alex: Parallel solo work is five people each editing a separate paragraph and never needing to talk. Real collaboration has shared judgment. Maybe the team has to prioritize issues, agree on standards, review fixes, or hand off work from one role to another.

Jamie: So five separate tasks can still be collaborative if the pieces affect each other.

Alex: Yes. If one person's finding changes what another person fixes, or the team has to agree on success criteria, the design starts to feel like a group challenge.

Jamie: And the accessibility note needs to be real, not just a sentence that says, this is accessible.

---

Alex: The file path is specific: create `docs/group-challenges/YOUR-USERNAME-challenge.md` in your Learning Room repository.

Jamie: That path matters because it gives everyone the same place to look.

Alex: Exactly. At the top of the file, add a clear title and a short summary. Then include the required parts: title, goal, team size, time estimate, instructions, success criteria, and an accessibility note.

Jamie: Success criteria is the part that answers, how do teams know they are done?

Alex: Yes. For example, done might mean each person filed one issue, each person opened one pull request, the group reviewed all pull requests, and the final README explains what changed.

Jamie: And the accessibility note explains how people using different tools can participate.

Alex: Right. It might mention keyboard access, screen reader-friendly instructions, clear file names, text alternatives for visual evidence, or allowing people to use GitHub.com, VS Code, or another accessible workflow.

Jamie: Then the GitHub part is still the usual contribution path.

Alex: Yes. Commit your file, push your branch, and open a pull request. In the challenge issue, the evidence field asks you to describe your group challenge and link to the file.

---

Jamie: The reference solution gives an example called Accessibility Audit Relay, which is a nice name because you can hear the handoff in it.

Alex: It is designed for 3 to 5 students auditing a sample web page for accessibility issues. Each person has a focus area, so no one has to inspect everything.

Jamie: Walk me through the roles.

Alex: One student checks images for meaningful alt text. Another reviews heading order, like H1, H2, and H3. Another tests whether link text is descriptive instead of vague text like "click here." A fourth checks color contrast, and a fifth, if present, reviews keyboard navigation order.

Jamie: Where does the relay part show up?

Alex: The group starts from a sample repository with a deliberately imperfect HTML page. Each student creates a branch for their focus area, files issues for the problems they find, discusses priorities with the team, submits a pull request fixing at least one issue, and reviews someone else's pull request.

Jamie: So the evidence is not just, I was present.

Alex: Right. Each student can post the issues they filed, the pull request they opened, and one review they gave.

Jamie: That works because everyone has a role, the roles connect, and the final page is genuinely better.

Alex: Exactly. The strongest designs have clear roles, concrete deliverables, and a reason for people to work together instead of merely working nearby.

---

Jamie: This challenge leans on GitHub Flow, even though the learner is designing an exercise.

Alex: It does. GitHub Flow is the lightweight branch-and-pull-request workflow used throughout the workshop: branch from main, make a focused change, commit it, open a pull request, discuss and review, pass checks, and merge.

Jamie: Can you say why one branch per task keeps coming up?

Alex: A small branch makes the pull request easier to understand and review. If the branch changes one thing, reviewers can tell what happened, authors can respond faster, and the team can merge with more confidence.

Jamie: And Git Flow is a different model with more branch types.

Alex: Yes. Git Flow often uses long-lived main and develop branches, plus feature, release, and hotfix branches. It can make sense for scheduled releases, mobile apps, firmware, or enterprise products. This workshop uses GitHub Flow because open source learning work benefits from a simpler path.

Jamie: So for Bonus C, keep the designed workflow small, reviewable, and easy to explain.

Alex: Exactly. If your challenge needs a branching diagram that takes ten minutes to explain, it is probably too complex for this purpose.

---

Jamie: What about keeping work current? Some group designs might use forks or a shared sample repository.

Alex: If a fork is part of the exercise, sync before creating a new branch, before opening a pull request, and whenever the upstream main branch has changed. In the GitHub web interface, the easiest route is often the "Sync fork" button when GitHub shows one.

Jamie: And the command line version?

Alex: Add the upstream remote once, switch to your main branch, fetch upstream changes, merge `upstream/main` into your main branch, and push the updated main to your fork. GitHub Desktop can also fetch, pull from the upstream default branch, and push the result.

Jamie: Commit messages are part of group communication too.

Alex: They are. Use a concise first line that says what changed, add an optional body if the why needs explanation, and use a footer if you need to reference an issue. Atomic commits help here, because each commit represents one coherent change.

Jamie: Common mistake: one giant commit that says updates.

Alex: Exactly. A better message is specific, like `fix missing alt text on product images` or `docs add keyboard testing instructions`.

---

Jamie: Group work also brings us back to open source culture.

Alex: Yes. Open source communication is mostly written, asynchronous, and public. That means your comment may be read hours later, by someone in another time zone, using a different language, or catching up through a screen reader.

Jamie: Chapter 8 had learners write a reflection before doing heavier review work.

Alex: Right. That reflection asked for one respectful review habit, one clear way to ask for help, and one constructive way to respond to feedback. If writing is hard, drafting in a text editor first is completely reasonable.

Jamie: So write for the person who arrives later and needs context.

Alex: Exactly. Include the exact step where you got stuck, what you already tried, and what you expected to happen. That makes it easier for someone to help without guessing.

Jamie: What does helpful feedback sound like in a group challenge?

Alex: Start by acknowledging what is working. Then identify the specific concern, explain why it affects the project, suggest a path forward when you can, and make clear whether the concern is blocking or just a suggestion.

Jamie: Tone matters a lot when comments are public.

Alex: Use "we" language or describe the code instead of judging the person. If you are uncertain, say so. If a comment sounds sharp, rewrite it into something specific and useful before posting.

Jamie: Accessibility issues can feel personal because they affect real people.

Alex: Yes. Describe the barrier, the context, and any assistive technology involved when relevant. Avoid blaming the author, and focus on how the experience can be improved.

Jamie: The repo's README and community health files help too.

Alex: They do. A README should explain the project, installation, usage, contributing, license, and any accessibility notes. CONTRIBUTING, code of conduct, security, and license files set expectations for participation, safety, and reuse.

Jamie: Channel choice matters too.

Alex: Use issues for tracked tasks, pull request comments for a specific change, discussions or chat for broader questions, and urgency markers only when something is truly urgent. A good first issue is also a social promise: the task should be scoped, welcoming, and supported.

---

Jamie: Commenting etiquette is where groups can get messy.

Alex: Keep comments focused, do not pile on when someone already raised the point, and resolve conversations when the concern has been addressed. Reactions are useful for simple agreement, so not every agreement needs another full comment.

Jamie: Saved replies can help, especially if typing the same accessible review phrasing over and over is tiring.

Alex: Yes. A saved reply can hold a polite review template, an accessibility testing reminder, or a standard request for reproduction steps. You can create one in GitHub settings and insert it from the comment editor when needed.

Jamie: Reviewers have responsibilities too.

Alex: Review the change, not the person. Ask questions instead of making demands, distinguish opinion from requirement, avoid gatekeeping knowledge, and approve explicitly when the work is ready.

Jamie: Authors have responsibilities on the other side.

Alex: Say thank you, do not take feedback as a personal attack, explain your choices, and surface blockers early. If you disagree with a decision, respond with evidence and ask what tradeoff the maintainer is prioritizing.

Jamie: And if the feedback is harsh or someone is rude?

Alex: Pause before replying, answer the specific technical points, and ask a facilitator or maintainer for help if the conversation stops being respectful. If you accidentally cause offense, acknowledge it, clarify your intent, and adjust your wording.

---

Jamie: Code review tooling helps with Bonus C because the exercise you design may ask teams to review each other's work.

Alex: In VS Code, the GitHub Pull Requests and Issues extension lets you view pull requests, check out a PR branch, read changed files, create pull requests, and comment without constantly switching to the browser.

Jamie: The setup is Extensions sidebar, search for GitHub Pull Requests, install, and sign in with GitHub.

Alex: Yes. After sign-in, verify that the GitHub section appears in the Explorer sidebar. The Pull Requests panel can show open pull requests, PR details, checks, file changes, and filters such as items waiting for your review.

Jamie: Diffs can be rough when you are listening to them.

Alex: Use the Accessible Diff Viewer in VS Code. Press F7 for the next change and Shift+F7 for the previous change; it announces added and removed lines in a structured way.

Jamie: And if inline commenting in VS Code is awkward?

Alex: Use GitHub.com as the fallback. Open the pull request, go to the Files changed tab, read the diff, and leave the comment there. It is also useful to compare which environment made review easier for you.

Jamie: Formal review verdicts matter too.

Alex: Yes. Approve means the work is ready from your perspective. Request changes means something must be addressed before merge. Comment-only means you have feedback or questions but are not giving a final verdict.

Jamie: What about Copilot during review?

Alex: It can help summarize unfamiliar changes or explain code you do not understand, but verify everything against the actual diff and the project rules. It should support your judgment, not replace it.

---

Jamie: If learners create the Bonus C pull request from VS Code, what should they watch for?

Alex: Use the Command Palette to create the pull request, then fill in a clear title and description. Confirm the base branch target and compare branch source, and add reviewers, labels, milestone, or draft status if the workflow asks for them.

Jamie: Templates may appear in the PR form too.

Alex: Yes. A pull request template might ask for description, related issue, type of change, testing, checklist items, and screenshots if applicable. Fill it out with enough detail that a reviewer can understand the purpose without opening every file first.

Jamie: And merging belongs after review and checks, not before.

Alex: Right. A maintainer can merge with the project's chosen strategy, such as a default merge or squash and merge, and then delete the feature branch if appropriate. After merging, switch back to main and pull the latest changes.

Jamie: Troubleshooting is part of the skill too.

Alex: If the extension says "No pull requests found," check the filter. If creation fails, confirm your branch is pushed and you have permission. If authentication fails, sign in through the browser, reload VS Code, and try again.

---

Jamie: What counts as completing Bonus C?

Alex: Your challenge issue has a required evidence field. Fill it with the challenge name, a short description of what teams would do, and a link to your file.

Jamie: And the pull request should contain `docs/group-challenges/YOUR-USERNAME-challenge.md`.

Alex: Yes. The file should be understandable enough for review, even if reviewers suggest improvements. Bonus C is about designing the group challenge clearly.

Jamie: What should a facilitator or reviewer look for?

Alex: Clear roles, concrete deliverables, a team size around 3 to 5, a realistic time estimate, step-by-step instructions, success criteria, and an accessibility note that makes participation possible for people using different tools.

Jamie: If someone cannot think of a challenge, where should they start?

Alex: Look at the other bonus challenges for inspiration and think about a real problem a small team could solve together. For accessibility-specific designs, use reliable references such as official GitHub documentation, the GitHub changelog, WCAG guidance, WAI tutorials, and the ARIA Authoring Practices Guide.

Jamie: So the finished design should feel like an invitation to collaborate.

Alex: Exactly. Give every participant meaningful work, make the handoffs clear, and leave future learners with a challenge they can actually complete together.