Make Your First Open Source Contribution, Step by Step

Proof required

Submit the repository URL. It needs 100+ stars and a commit in the last three months. Add a codebase map of at least 300 words. Give the project's purpose in one sentence, and the main directories. Say which area you'll change and why. Add one lesson from merged PRs that isn't in the README.

What gets checked

• 100+ stars and a commit in the last three months. The contribution needs a real community.
• The map names specific folders and files, like 'src/components/Button/', not 'a components folder'.
• The PR lesson cites a PR number and teaches something about conventions or review.

Common mistakes

• Picking a huge project like React. Reviews can take months; 200–2,000 stars is better.
• Skipping merged PRs. That's how you learn style, and PRs get closed for ignoring it.
• Not running it locally first. You can't test a change you can't run.

Resources

What a verifier looks for

• Open the repository. Check 100+ stars and a commit in the last three months.
• The map must name specific folders and files, not only the project's purpose.
• The PR lesson must cite a PR number. Ask for the link if it's missing.

You'll sign in first, then come straight back here.

Proof required

Submit the issue URL and your open pull request URL. Add the full PR description with Problem, Solution and How to test sections.

What gets checked

• The PR is open or in review. One closed at once as spam or a duplicate doesn't count.
• All three sections are in your own words, not the issue title repeated.
• It fixes a filed issue, not an unrequested feature or a stray typo.

Common mistakes

• A README typo as your first PR. Many projects auto-close these; fix a labelled bug.
• Opening it without running the tests. PRs that break CI rarely merge.
• A description of just 'fixes #123'. Those wait months or get closed.

Resources

What a verifier looks for

• Open the PR. It should be open or reviewed, not closed at once as a duplicate.
• Check it has real Problem, Solution and How to test sections.
• Check CI status. Failing tests with no mention means they didn't run them.

You'll sign in first, then come straight back here.

Proof required

Submit the merged PR URL, showing the purple 'Merged' badge. Add the GitHub handle of the maintainer who merged it. Add 100 words on the feedback you got and how you handled it. If there was none, write 'no change requested'.

What gets checked

• The PR shows 'Merged', and someone other than you merged it.
• The repository has 100+ stars. Your own project doesn't count.
• The reflection names specific feedback, like 'rename the variable and add a null check'.

Common mistakes

• Giving up after the first change request. One round of changes is normal.
• Going quiet. PRs silent for two weeks get closed; check every 3–5 days.
• Merging it yourself before approval. Then no maintainer merged it.

Resources

What a verifier looks for

• Open the live URL and look for the purple 'Merged' badge. A screenshot isn't enough.
• Check who merged it at the bottom of the PR. It must be someone else.
• Ask what the code did before and after. If they can't say it themselves, treat it as unverified.
• If 'no change requested', check the timeline for review comments. Flag silent merges.

You'll sign in first, then come straight back here.