DEV Community

Matthew Hou
Matthew Hou

Posted on • Edited on

I Got My First Open Source PR Merged After 7 Rejections. Here's What I Learned About Contributing.

#github #opensource #programming #beginners

My first 7 open source pull requests were all closed without merging. Two were ignored entirely. Three got "thanks, but we're not going in this direction." Two had 20+ review comments that I never addressed because I felt overwhelmed.

My 8th PR was merged into a project with 15K stars. Then my 9th, 10th, and 11th. Once I understood the unwritten rules, everything clicked.

Here's everything I wish I'd known.

Why Your First PRs Get Rejected

Reason 1: You're Solving a Problem Nobody Has

My first PR added "dark mode support" to a CLI tool. The maintainer's response: "We've discussed this before and decided against it — it adds maintenance burden for a feature few users want. See issue #234."

The fix: Before writing code, check:

  1. Is there an open issue for this? (If yes, comment "I'd like to work on this" before starting)
  2. Has this been proposed and rejected before? (Search closed issues)
  3. Does the maintainer want this? (Ask in an issue first for non-trivial changes)

The best first contributions aren't features. They're:

  • Bug fixes with a clear reproduction case
  • Documentation improvements (typos, unclear instructions, missing examples)
  • Test improvements (better coverage for existing features)
  • Good first issues (literally labeled for you)

Reason 2: Your PR Is Too Big

I once submitted a PR that refactored an entire module, fixed 3 bugs, updated dependencies, and added a feature. 1,200 lines changed. The maintainer looked at it, said "this is too much to review," and closed it.

The rule: One PR = one change. If your PR description needs bullet points, it's too big.

❌ "Refactored auth module, fixed login bug, updated bcrypt, 
    added password reset feature"

✅ "Fix: login fails when email contains uppercase letters"
    (12 lines changed, one test added)
Enter fullscreen mode Exit fullscreen mode

Small PRs get reviewed fast. Big PRs get ignored.

Reason 3: You Didn't Follow the Contributing Guide

Most projects have CONTRIBUTING.md. It tells you:

  • How to set up the dev environment
  • The coding style (tabs vs spaces, naming conventions)
  • The commit message format
  • The testing requirements
  • The PR template

If you skip any of these, your PR starts with negative goodwill. The maintainer sees "this person didn't read the docs" and they're already skeptical.

# Before your first PR, do ALL of these:
1. Read CONTRIBUTING.md (cover to cover)
2. Read CODE_OF_CONDUCT.md
3. Run the existing test suite locally
4. Check the commit message convention (Conventional Commits? Imperative mood?)
5. Look at recent merged PRs for style reference
Enter fullscreen mode Exit fullscreen mode

How to Find Your First Contribution

Strategy 1: Fix Something That Annoyed You

Use an open source tool. Hit a bug or confusing behavior. Instead of workarunding it, fix it.

This is the highest-quality contribution because you have genuine context — you understand the problem because you experienced it.

Strategy 2: Good First Issues 

GitHub search: label:"good first issue" language:typescript stars:>1000
Enter fullscreen mode Exit fullscreen mode

These are intentionally scoped for new contributors. Maintainers have already defined the problem and often describe the expected solution.

Tip: Comment on the issue before starting work. "I'd like to take this on. My approach would be [brief description]. Does this sound right?" This prevents duplicate work and gets early feedback on your approach.

Strategy 3: Documentation

Every project has documentation gaps. Find them by:

  1. Following the setup instructions as a new user — where did you get stuck?
  2. Reading the API docs — are there missing examples?
  3. Checking if the README is current — does it reference outdated versions?

Documentation PRs are almost always welcome and almost never rejected.

Strategy 4: Tests 

# Find untested code paths
npx jest --coverage
# Look at files with low coverage
# Write tests for the uncovered paths
Enter fullscreen mode Exit fullscreen mode

Test PRs are valued by maintainers because they make the project more reliable without adding features to maintain.

The Perfect First PR (Template) 

## Summary
Fix login failure when email contains uppercase letters.

Closes #456

## Problem
Users with uppercase email addresses (e.g., "John@Example.com") 
couldn't log in because the lookup was case-sensitive.

## Solution
Normalize email to lowercase before database lookup in the 
auth service. Added a test for case-insensitive login.

## Changes
- `src/auth/login.ts`: lowercase email before lookup (1 line)
- `tests/auth/login.test.ts`: added case-insensitive test (12 lines)

## Testing
- [x] Existing tests pass
- [x] New test covers the fix
- [x] Manually tested with mixed-case email
Enter fullscreen mode Exit fullscreen mode

Why this works:

  • Links to an existing issue (the maintainer already validated the problem)
  • Explains the problem clearly
  • The solution is small and focused
  • Tests are included
  • The maintainer can review in 2 minutes

After Your PR Is Submitted

Be Patient

Maintainers are often unpaid volunteers. A response might take days or weeks. Don't ping after 24 hours.

Reasonable timeline: wait 2 weeks, then add a polite comment: "Hi, just checking if you've had a chance to look at this. Happy to make any changes needed."

Respond to Every Comment

Review comments are a conversation, not a test. Respond to each one:

  • If you agree: make the change, reply "Good catch, fixed in [commit hash]"
  • If you disagree: explain your reasoning respectfully. "I considered that approach, but chose X because [reason]. What do you think?"
  • If you don't understand: ask. "Could you clarify what you mean? I want to make sure I address this correctly."

Don't Take Rejection Personally

A closed PR doesn't mean your code was bad. It means:

  • The project is going in a different direction
  • Someone else submitted a similar fix first
  • The maintainer doesn't have time to review right now
  • The approach needs a different solution

Say "Thanks for the feedback" and move on. Or ask: "Would a different approach be accepted? I'm happy to rework it."

The Career Impact Nobody Talks About

After contributing to 5+ projects:

  • My GitHub profile had activity that showed real collaboration skills
  • Two projects listed me in their CONTRIBUTORS file
  • A hiring manager specifically asked about my open source work in an interview
  • I got a DM from a maintainer asking if I wanted to do contract work on their project

Open source contributions are the most visible, verifiable proof of your skills. Any developer can claim "proficient in React" on their resume. Very few can point to a merged PR in a popular React library.

Getting Started This Weekend

  1. Pick a tool you use daily (VS Code extension, CLI tool, framework)
  2. Star the repo and read CONTRIBUTING.md
  3. Browse "good first issue" labels
  4. Comment on one issue offering to help
  5. Submit one small PR (documentation, test, or bug fix)

Your first contribution doesn't need to be impressive. It needs to be merged. Once you've done it once, the second time is 10x easier.

What was your first open source contribution? Or what's stopping you from making one? I'd love to help people get their first PR merged — drop your questions in the comments.

Top comments (0)