Before your first open-source PR.
The skills that actually get a fix merged are debugging skills: navigating a big repo, reproducing a failure, tracing a root cause, and explaining a minimal patch. Here’s how to build them honestly.
What OSS Labs are
OSS Labs replay real public bug-fix history as guided debugging challenges. We pick a merged fix commit, revert the repo to its buggy parent, add a visible regression test, and let you reproduce, trace, and patch the bug inside a real repo snapshot — with hidden validation to confirm you fixed the cause, not just the symptom.
A lab completion is not a contribution. You did not open the upstream PR and you did not merge anything into the project. You practiced the exact debugging loop a contributor uses — which is the point.
The playbook
How to read unfamiliar repos
Start from the failing test, not the README. Follow imports outward from the symptom. Build a mental map of the few files that matter instead of trying to understand everything.
How to reproduce failing tests
Run the exact test command first. Read the assertion that fails — expected vs received — before touching any source. A reproduction you can re-run is the foundation of every real fix.
How to trace a fix commit
A merged fix usually changes a small set of runtime files plus a test. Use the changed-file list as a suspect map, not a recipe. Trace from the test into the runtime path and form your own hypothesis.
How to write a PR-style explanation
Problem → root cause → fix summary → files inspected → tests run → validation result. Keep it minimal and honest. Maintainers trust a clear repro and a small diff over a long narrative.
How to avoid claiming fake contributions
Completing a lab is practice, not a merged PR. Say what actually happened: you reproduced and fixed a reverted regression in a lab. Never imply you contributed upstream.
Resume-safe wording
Use language that’s true and still impressive.
- “Completed an OSS-backed debugging lab based on public Fastify bug-fix history.”
- “Reproduced a failing regression test, traced the root cause, and shipped a minimal patch.”
- “Passed visible and hidden validation in a real repo snapshot.”
- “Contributed to Fastify.”
- “Merged a PR into an open-source project.”
- “Official Fastify challenge / equivalent to a real PR.”
From a Buglyst lab to a real PR
Once the lab loop feels natural, take it upstream: find a real issue with a clear reproduction, write the failing test yourself, propose a minimal fix, and open a PR with the same Problem → Root cause → Fix summary structure. The labs are reps; the real PR is the match.
Explore OSS Labs →