Skip to content

CHALLENGES

Jump to bottom
github-actions[bot] edited this page May 8, 2026 · 2 revisions

Challenge Hub

Welcome to the Challenge Hub - your guide to all 16 core challenges and 5 bonus challenges.

The challenges are the practice path for the course. Each one asks you to do a small piece of real GitHub work, leave evidence of what you did, and then close the issue so the next challenge can open. The goal is not speed. The goal is to build a contributor rhythm you can trust: orient yourself, make the move, verify the result, and ask for help with clear facts when something feels off.

How Challenges Work

Start in your private Learning Room repository, not in the public curriculum repository. Open the Issues tab, find the challenge issue assigned to you, and read the issue body before acting. Each issue explains the task, the evidence prompt, and any buddy check or automated check that applies.

When a challenge asks for evidence, post it as a comment on that challenge issue. Evidence can be a link, a short reflection, the name of a branch, a pull request number, or a note about what you tried and what happened. After you post the evidence, close the challenge issue. The Student Progression Bot uses that closed issue as the signal to open the next challenge.

Every challenge below includes a reference solution. Treat those files as worked examples, not answer keys. Your exact branch name, issue number, wording, or file count may differ. What matters is whether you practiced the skill and can explain the result.

Day 1: You Belong Here (Challenges 1-9)

Challenge 1: Find Your Way Around

Chapters: Ch02-04 | Evidence: Comment

This first challenge is about orientation. Before you edit anything, you learn how a repository is organized: where the Code tab lives, where Issues live, how the file tree behaves, and how the README gives a project its front door.

What to do:

  • Find the Code tab and count the files or folders in the repository root
  • Open the Issues tab and identify at least one issue or confirm the tab exists
  • Navigate to docs/welcome.md and read the opening paragraph
  • Find the repository description and the rendered README

Evidence to post: Describe what you found and name one navigation shortcut or screen reader technique that helped.

Compare your result with the Challenge 1 solution reference when you want a second view of the same exploration path.

Challenge 2: File Your First Issue

Chapter: Ch05 | Evidence: Comment

Issues are how maintainers turn observations into trackable work. In this challenge, you find a small TODO in the Learning Room and write an issue that another person could understand without being in the room with you.

What to do:

  • Open docs/welcome.md and search for TODO
  • Create a new issue with a specific title
  • Explain what needs to change, where it is, and why the change would help

Evidence to post: Link to the issue you created and include one sentence about why your title is clear.

If you want to compare tone and structure, read the Challenge 2 solution reference.

Challenge 3: Join the Conversation

Chapter: Ch05 | Evidence: Comment

Open source is conversation as much as code. This challenge teaches you how to participate in an issue thread with an @mention, a reaction, and a comment that moves the work forward.

What to do:

  • Find your buddy's Challenge 2 issue or a facilitator-provided peer simulation issue
  • Leave a meaningful comment with an @mention
  • Add a reaction to the original issue or a helpful comment

Evidence to post: Link to your comment and describe what made it useful, kind, or specific.

The Challenge 3 solution reference shows one way to make a short comment feel genuinely collaborative.

Challenge 4: Branch Out

Chapter: Ch06 | Evidence: Comment

A branch is a safe workspace. It lets you try a change without rewriting the main version of the project. In this challenge, you create your own branch and confirm that you know where your work will happen.

What to do:

  • Find the branch selector on the Code tab
  • Create a branch named learn/YOUR-USERNAME from main
  • Confirm the branch selector now names your branch

Evidence to post: Write the branch name you created and how you confirmed you were on it.

Use the Challenge 4 solution reference if you want to check your branch mental model.

Challenge 5: Make Your Mark

Chapter: Ch06 | Evidence: Comment

This is your first small content change. You edit a file, replace a TODO with real text, and commit the change with a message that explains what happened.

What to do:

  • Switch to your learn/YOUR-USERNAME branch
  • Edit docs/welcome.md to replace the TODO with useful content
  • Write a commit message that explains the change in plain language

Evidence to post: Share your commit message and the file you edited.

For a worked example of a focused commit, compare with the Challenge 5 solution reference.

Challenge 6: Open Your First Pull Request

Chapter: Ch06 | Evidence: Comment

A pull request is the conversation around a proposed change. It lets others review your branch before it becomes part of main. This challenge connects your branch, your issue, and your explanation into one contribution.

What to do:

  • Go to Pull requests > New pull request
  • Set the base branch to main and the compare branch to learn/YOUR-USERNAME
  • Write a clear title and include Closes #XX in the description

Evidence to post: Link to the pull request and name the issue it closes.

The Challenge 6 solution reference shows how the title, body, and closing keyword work together.

Challenge 7: Survive a Merge Conflict

Chapter: Ch07 | Evidence: Comment | Autograded

Merge conflicts happen when Git cannot safely combine two edits by itself. The point of this challenge is to read the conflict markers calmly, choose the final wording, delete the marker lines, and prove the file is clean.

What to do:

  • Wait for the facilitator to trigger the conflict
  • Find the marker lines: <<<<<<<, =======, and >>>>>>>
  • Decide which content to keep, or combine both sides into one clear version
  • Delete all marker lines and commit the resolution

Evidence to post: Explain which content you kept and why. The autograder checks that no conflict markers remain.

The Challenge 7 solution reference is useful if the marker structure still feels unfamiliar.

Challenge 8: The Culture Layer

Chapter: Ch08 | Evidence: Comment

Technical work lands better when the communication is respectful and specific. This reflection challenge asks you to name the collaboration habits you want to practice before you move deeper into reviews and capstone work.

What to do:

  • Answer the reflection prompt in your challenge issue
  • Add or recommend a label for an open issue, if the issue asks for triage practice
  • Leave a comment explaining the reasoning behind your communication or triage choice

Evidence to post: Write three concrete collaboration behaviors you will use in the rest of the workshop.

The Challenge 8 solution reference gives examples of specific, actionable reflection language.

Challenge 9: Merge Day

Chapter: Ch10 | Evidence: Comment

Merge Day closes the Day 1 loop. You verify that your pull request is ready, merge it when approved, confirm the change landed on main, and notice how the linked issue closes.

What to do:

  • Verify your PR has no conflicts and a meaningful commit message
  • Merge your PR, or wait for a facilitator to approve and merge it
  • Confirm your changes appear on the main branch
  • Check that the linked issue closed automatically

Evidence to post: Share the merged PR link and the issue number that closed.

Before moving on, scan the Challenge 9 solution reference to make sure you caught both the merge and verification steps.

Day 2: You Can Build This (Challenges 10-16)

Challenge 10: Go Local

Chapters: Ch11-14 | Evidence: Comment | Autograded

Day 2 moves the same contribution workflow onto your computer. You clone your Learning Room repository, create a branch locally, edit a file, commit, and push the branch back to GitHub.

What to do:

  • Clone your Learning Room repository to your computer with VS Code, GitHub Desktop, or the command line
  • Create a branch named fix/YOUR-USERNAME
  • Edit a file in docs/
  • Commit and push the branch to GitHub

Evidence to post: Share your branch name and a short note about how you confirmed the push reached GitHub. The autograder verifies a commit on a non-default branch.

The Challenge 10 solution reference shows the local workflow as one complete loop.

Challenge 11: Open a Day 2 PR

Chapters: Ch14-15 | Evidence: Comment

This challenge proves that the pull request pattern is the same whether the edit started in the browser or on your computer. You push a local branch, open a PR, and explain the change for reviewers.

What to do:

  • Open a PR from fix/YOUR-USERNAME to main
  • Write a title and description that describe the change clearly
  • Notice the familiar shape: branch, compare, title, body, submit

Evidence to post: Link to the PR and identify what changed between the branch and main.

Use the Challenge 11 solution reference to compare the local-to-GitHub handoff.

Challenge 12: Review Like a Pro

Chapter: Ch15 | Evidence: Comment

Review is where a contribution becomes stronger. Your job is to read a classmate's pull request, leave comments that are specific and kind, and submit a review verdict that matches what you found.

What to do:

  • Open your buddy's PR or a facilitator-provided peer simulation PR
  • Go to Files changed and read the diff
  • Leave at least two inline comments: one naming something effective and one suggesting an improvement
  • Use Suggest changes for at least one comment, if the interface supports it
  • Submit your review with Approve, Request changes, or Comment

Evidence to post: Link to the review or describe where you left your comments.

The Challenge 12 solution reference models feedback that teaches without taking over the author's work.

Challenge 13: AI as Your Copilot

Chapter: Ch16 | Evidence: Comment

Copilot can help draft and improve, but you remain responsible for the final result. This challenge asks you to use Copilot as a collaborator, then evaluate what it suggested before accepting anything.

What to do:

  • Ask Copilot to improve a documentation file
  • Apply the trust, verify, reject framework to each suggestion
  • Keep notes on what you accepted, modified, and rejected

Evidence to post: Share the prompt you used and one example of a suggestion you changed or rejected.

The Challenge 13 solution reference shows how to document human judgment around AI output.

Challenge 14: Template Remix

Chapter: Ch17 | Evidence: Comment | Autograded

Issue templates help contributors give maintainers the information they need on the first try. In this challenge, you create a small YAML issue form and verify that it has the required fields.

What to do:

  • Study docs/samples/challenge-14-registration-remix-example.yml
  • Create a new YAML template in .github/ISSUE_TEMPLATE/
  • Include name, description, title, and at least one form field
  • Commit and push the template

Evidence to post: Link to the template change or PR. The autograder verifies that the YAML template exists and includes required metadata.

The Challenge 14 solution reference can help you check both syntax and contributor usefulness.

Challenge 15: Meet the Agents

Chapter: Ch19 | Evidence: Comment

Accessibility agents are not magic helpers. They are structured instructions, responsibilities, and guardrails. This challenge asks you to inspect real agents before you build or improve one.

What to do:

Evidence to post: Name the agents you found and explain one guardrail that protects learners or users.

The Challenge 15 solution reference shows how to turn exploration into a useful agent note.

Challenge 16: Build Your Agent (Capstone)

Chapters: Ch18, Ch20 | Evidence: Comment | Autograded

The capstone is where you design a small agent of your own and prepare it as a contribution. The important part is not a flashy idea. The important part is a clear purpose, useful responsibilities, and boundaries that keep the agent safe and honest.

What to do:

  1. Fork the Community Access Accessibility Agents repository
  2. Clone your fork and create a branch named agent/YOUR-USERNAME
  3. Write an .agent.md file with YAML frontmatter, responsibilities, and guardrails
  4. Push and open a cross-fork PR to the original repository
  5. Review a classmate's capstone PR when one is available

Use the agent file template and fork workflow checklist for structure.

Evidence to post: Link to your capstone PR or summarize the agent file you created. The autograder verifies required agent structure when the file is represented in the Learning Room.

The Challenge 16 solution reference shows a complete agent example with responsibilities and guardrails.

Bonus Challenges

Bonus challenges are optional. Use them when you finish the core path early or want more practice with contribution habits that transfer beyond this workshop.

Bonus A: Improve an Existing Agent

Choose an existing agent, identify a focused improvement, and open a PR that explains why the change matters.

Compare your plan with the Bonus A solution reference.

Bonus B: Document Your Journey

Write a structured reflection about what you learned, what surprised you, and what you want to keep practicing. Use accessible Markdown so another person can read it comfortably.

The Bonus B solution reference offers a reflection structure if you need a starting shape.

Bonus C: Create a Group Challenge

Design a collaborative challenge for 3-5 students. A good group challenge names the shared goal, the separate roles, the evidence, and how the group knows it is finished.

Review the Bonus C solution reference for one way to describe group work clearly.

Bonus D: Notification Mastery

Configure GitHub notifications so you can find mentions, reviews, and assignments without drowning in every update.

The Bonus D solution reference shows how to describe a personal notification strategy.

Bonus E: Explore Git History Visually

Use GitHub Desktop or GitHub.com to explore repository history. The goal is to explain what changed over time, not merely to find a graph or timeline.

The Bonus E solution reference walks through one history-reading approach.

Skills-Inspired Optional Scenarios

For advanced students who finish early, use the curated optional scenarios in Learning Room skills bonus scenarios.

These scenarios adapt selected GitHub Skills exercises into this workshop environment without changing the official 21-challenge progression.

If You Get Stuck

Every challenge issue includes an "If you get stuck" section with common problems and recovery paths. Start there, then use these supports:

When you ask for help, include what you were trying to do, where you were in the repository, what happened, and what you expected. That gives your buddy, facilitator, or bot enough context to help you quickly.

Clone this wiki locally