Ten pull requests, in order, from one we review ourselves to one a real project keeps. You are not aiming for ten checkmarks. You are aiming for one contribution you can talk about for fifteen minutes, and nine that made it possible.
Roughly one milestone every two weeks — about a semester. Milestones 7, 9 and 10 will overlap, and should.
Open a pull request against this workbook adding your own entry. Your first PR is to us, not to a stranger.
Committing to main on your fork, then wondering why the PR contains everyone else's work. If your diff has files you did not touch, close it and start the branch again.
Also answer: Which part of fork → branch → commit → PR did you have to look up? Be honest — everyone looks something up here.
A real code change in a DevForge repo — the portal, a club project, a script. Real review, forgiving maintainer.
Picking something too big because it sounded more impressive. If your diff passes 100 lines at milestone 2, you chose wrong — split it or pick again.
Also answer: How long between understanding the bug and having a fix? Where did that time actually go — reading, setup, or typing?
A reproducible issue on a real outside project. No code in this milestone at all.
"It doesn't work." Also: filing before searching. Being a duplicate is fine if you say what you searched for; being unreproducible is not.
Also answer: Paste the maintainer's first reply verbatim. What did it assume you already knew?
Cover existing untested behaviour. No behaviour change. This is the highest-acceptance PR a beginner can open.
Writing a test that passes even when the feature is broken. If you did not watch it fail, you did not write a test — you wrote a comment that takes 40ms to run.
Also answer: What did reading the test suite tell you about this codebase that reading the source did not?
Fix the issue you filed at milestone 3, or a good-first-issue that a maintainer assigned to you.
Opening the PR before commenting on the issue. Two people silently fixing the same bug is how contributors burn out and how maintainers stop labelling issues for beginners.
Also answer: What was the actual root cause, and what did you believe it was during the first hour?
Document the exact thing that confused you at milestone 4 or 5. Now you have earned this PR.
This is the milestone that looks easy and is not. If you cannot point at the hour you were stuck, you have not earned it yet — go back and finish 4.
Also answer: What did the existing docs assume about the reader that turned out to be untrue for you?
A change the maintainers agreed to before you built it. The conversation is the milestone; the code is the receipt.
Building first and asking after. Second trap: the unsolicited refactor. If your PR title starts with 'refactor' and nobody asked for it, expect it closed. Refactor when a reviewer asks, inside the PR they asked in.
Also answer: What did the maintainer change about your proposal before agreeing to it?
Two reviews: one on a club member's PR, one on a stranger's. Sit on the other side of the table.
Rubber-stamping, and its mirror image — nitpicking whitespace and naming that a linter already handles. Both tell the author you did not read it.
Also answer: What did you fail to understand in their code, and did you say so out loud in the review?
A PR that took three or more rounds, or one that got closed. This is the only milestone you cannot complete by getting it right first time.
Arguing, or ghosting. They end the same way, and maintainers remember both.
Also answer: Quote the harshest piece of feedback you received. Was it right? What would you tell yourself the day before you opened that PR?
A contribution the project actually keeps, and that you can talk about for fifteen minutes without notes.
Choosing the largest diff instead of the one you understand best. Nobody in an interview counts your lines.
Also answer: This is your interview answer. Write it as one, out loud, and time yourself.
Five fields, hard caps, filed within 48 hours of the review. The caps are enforced on submit, not suggested — a reflection nobody can read in thirty seconds is one nobody reads at all, including you, three months later, in an interview.
The approach you took — including the one you abandoned before it.
The error, the wrong assumption, or the dead end. "Nothing" is not an answer; if nothing broke, the task was too small.
Paste the actual comment. Do not paraphrase — paraphrasing sands the lesson off.
One concrete change to how you'd approach the next one.
Hours spent · rounds of review · status (merged / open / closed).
This is not a course, and finishing it is not a certificate. Nothing here is completed by watching a video.
