Make Your First Open Source Contribution

Proof required

Submit: (1) the GitHub URL of the repository you chose (must have 100+ stars and a commit within 3 months), (2) a one-page codebase map (minimum 300 words) naming: the project's purpose in one sentence, the main directories and what each contains, the area you plan to change and why, and one observation formed by reading merged PRs that is not in the README.

What gets checked

• Repository has 100+ stars and a commit within the last 3 months — a dormant project with 5 stars does not pass; the contribution needs a real community that will review it
• Codebase map names specific directories and files — 'there is a components folder' does not pass; 'src/components/Button/ contains the accessible button primitive, which I found by reading PR #847 which added ARIA label support' does
• The PR observation names a specific PR number and describes something learned about code conventions, review standards, or project philosophy — not something in the README

Common mistakes

• Choosing the largest possible project (React, Linux kernel) — maintainers of very large projects have extremely high review standards and response times can be months; a project with 200–2,000 stars and active issue discussion is a much better first contribution target
• Skipping the PR reading step — the PR history is how you learn what maintainers value and what style they will reject; submitting without reading merged PRs produces PRs closed as 'not matching project style'
• Not running the project locally before choosing what to contribute — if you cannot build and run it, you cannot test that your change works

Resources

What a verifier looks for

• Check the GitHub URL — verify the star count is ≥100 and the last commit is within 3 months; if not, the project does not meet this milestone's standard
• The codebase map must name specific directories and files, not just describe the project's purpose — 'src/features/auth/LoginForm.tsx handles the login flow and calls /api/auth as found in PR #847' passes; 'they use React for the frontend' does not
• The PR observation must name a specific PR number — ask for the PR link if not included; an observation without a named PR cannot be verified

Own a milestone like this? Submit proof and invite verifiers — sign in to get started.

Proof required

Submit: (1) the URL of the GitHub issue you are resolving, (2) the URL of your open pull request, (3) the full PR description text — it must include Problem, Solution, and How to test sections.

What gets checked

• Pull request URL resolves to an open or pending-review PR — a PR closed immediately as spam or a duplicate without substantive review does not pass
• PR description includes all three required sections (Problem, Solution, How to test) in the contributor's own words — copying the issue title as the problem statement without expansion does not pass
• The contribution addresses a filed issue — a PR adding a feature no one asked for, or a spelling fix in a file with 100 other errors, does not demonstrate understanding of the project's real needs

Common mistakes

• Fixing a typo in the README as the first contribution — maintainers of active projects receive dozens of README typo PRs and many auto-close them; a code change that fixes a labeled bug demonstrates understanding in a way documentation fixes do not
• Opening the PR without checking for existing tests — a PR that breaks CI tests is almost never merged on a first contribution; run the test suite locally and fix failures before opening
• Writing a PR description that says only 'fixes #123' — maintainers need context; a PR with no description or a one-liner routinely waits months for review or gets closed for insufficient context

Resources

What a verifier looks for

• Open the PR URL and verify it is open or has received review — a PR closed within minutes as 'duplicate' without any substantive review does not satisfy this milestone
• Read the PR description — it must have genuine Problem, Solution, and How to test sections; 'closes #123' as the entire description does not pass
• Check CI/test status on the PR — if tests are failing and the description does not acknowledge this, the contributor did not run tests locally before submitting

Own a milestone like this? Submit proof and invite verifiers — sign in to get started.

Proof required

Submit: (1) the URL of the merged pull request (GitHub URL showing 'Merged' status, purple badge), (2) the GitHub handle of the maintainer who merged it, and (3) a 100-word reflection on what reviewer feedback you received and how you addressed it — or 'no change requested' if merged on the first review.

What gets checked

• PR URL shows 'Merged' status (purple badge on GitHub) and the merge was performed by someone other than the author — a self-merge on your own fork does not count
• The repository has 100+ stars — a PR merged into a project you created yourself or a project with no other contributors does not demonstrate external validation
• Reflection names specific feedback if any was given — 'they said it looked good' is not a reflection; 'the reviewer asked me to rename the variable and add a null check — I did both and the next review approved immediately' is

Common mistakes

• Giving up after the first round of requested changes — reviewer feedback is the proof that you are being reviewed by someone who cares about code quality; one round of changes is normal, not a rejection
• Not responding to reviewer comments within a reasonable timeframe — PRs that go silent for 2+ weeks are often closed as abandoned; check for new comments every 3–5 days
• Trying to merge the PR yourself before it is approved — this closes the PR without review and means you cannot submit a merged URL from a real maintainer

Resources

What a verifier looks for

• Open the PR URL and confirm the purple 'Merged' badge is visible — do not approve based on a 'Closed' PR (which shows red) or a screenshot; the URL must be live and publicly accessible
• The merging account must be different from the contributor's account — check the merge event at the bottom of the PR page to see who clicked the merge button
• AI-fakeability note: ask one follow-up question — 'What did the code do before your change, and what does it do now?' If the contributor cannot answer in their own words without looking it up, treat the PR as unverified
• If the reflection says 'no change requested': check the PR timeline for whether any review comments were left — a PR merged silently on a repo with <500 stars may not have been genuinely reviewed; flag this if evident

Own a milestone like this? Submit proof and invite verifiers — sign in to get started.