Why Your Pull Request Got Ignored (And How to Get It Merged) 🔀✨

Real talk: I once submitted a PR that added a feature I spent TWO WEEKS building. Clean code. Tests passing. Documentation updated. I was so proud! And then... nothing. Weeks went by. No comments. No review. Just silence. 😭

Plot twist: The maintainer merged someone else's simpler PR that solved the same problem in 3 days. Mine got closed with "duplicate."

As a full-time developer who contributes to open source AND maintains Laravel/security projects, I've been on BOTH sides. I've ghosted PRs. I've HAD my PRs ghosted. And let me tell you - there's a SECRET FORMULA to getting PRs merged, and most contributors don't know it! 🎯

Let me show you why your PR is sitting there collecting dust - and how to fix it! 💪

The Uncomfortable Truth About Pull Requests 💣

What you think happens when you open a PR:

You: *opens amazing PR*
Maintainer: "This is brilliant! Let me merge immediately!"
*PR merged in 10 minutes*
*Champagne and celebration!* 🍾

What actually happens:

You: *opens PR*
Maintainer: *has 47 other PRs to review*
Maintainer: *has full-time job*
Maintainer: *has family, life, burnout*
Maintainer: *glances at your PR*
Maintainer: "This needs work... I'll come back to it"
Maintainer: *never comes back*
Your PR: *dies alone in page 3* 💀

The stats that hurt:

68% of PRs to popular open source projects never get merged
54% get closed without any feedback
83% of contributors give up after first PR is ignored
The average PR review time is 2-4 weeks (if it gets reviewed at all!)
ONE well-crafted PR has an 85% merge rate vs. 15% for rushed PRs!

Translation: Most PRs die in the queue. Yours is probably one of them! 😬

But hey! You're reading this, which means you're about to become part of the 15% whose PRs actually GET MERGED! 🎉

The PR Spectrum (Where Does Yours Fall?) 🎯

The "Ignored Forever" PR ❌

The classic:

Title: "Update"

Changes:
- 47 files changed
- No description
- No tests
- Breaking changes
- Fixes issue that doesn't exist

Comment: "I fixed some stuff. Pls merge."

Why maintainers ghost it:

What does this PR do? Who knows!
Does it break anything? Probably!
Is it tested? Nope!
Is there an issue discussing this? Nope!
Do I have time to figure this out? NOPE!

Maintainer's reaction: closes tab and hopes someone else deals with it

Your PR gets: Ignored until auto-closed after 90 days! 💀

The "Almost There" PR 📦

The frustrating one:

Title: "Add dark mode toggle"

Changes:
- Actual feature that works!
- Some tests
- Basic docs
- But... conflicts with main
- And... doesn't follow code style
- And... modifies 15 files that didn't need changes

Why it sits there:

Maintainer thinks: "This is good but needs work"
Maintainer comments: "Please rebase and fix conflicts"
You: never respond
Or you: force push and break everything
Maintainer: too tired to keep following up

Maintainer's reaction: "I'll wait for them to fix it... waits forever"

The "INSTANT MERGE" PR ✨ (BE THIS ONE!)

The gold standard:

Title: "feat: Add dark mode toggle (fixes #234)"

Description:
Implements dark mode toggle as discussed in issue #234.

**Changes:**
- Added toggle component in Settings
- Persists preference to localStorage
- Updates 3 theme-dependent components
- Added tests (coverage: 95%)
- Updated docs with screenshots

**Testing:**
- ✅ Tested on Chrome, Firefox, Safari
- ✅ Tested with light/dark OS preferences
- ✅ All existing tests passing
- ✅ No breaking changes

**Screenshots:**
[Before/After images]

**Checklist:**
- ✅ Rebased on latest main
- ✅ Follows code style guide
- ✅ Documentation updated
- ✅ Tests added and passing
- ✅ No merge conflicts

Why this is PERFECT:

✅ Links to existing issue (shows it's wanted!)
✅ Clear description of what/why
✅ Lists all changes explicitly
✅ Has tests and docs
✅ Provides proof it works
✅ Follows checklist
✅ Ready to merge RIGHT NOW

Maintainer's reaction: "This is BEAUTIFUL! clicks merge button immediately" 😍

Your PR gets: Merged same day! Then featured in release notes! 🎉

The 7 Deadly Sins of Pull Requests 💀

Sin #1: The "No Issue" PR

The crime:

You: *spends week building feature*
You: *opens PR*
Maintainer: "We don't need this feature"
You: "But I already built it!" 😭
Maintainer: *closes PR*

The fix:

You: "Hey! Would you accept a PR that adds feature X?"
Maintainer: "No, that's out of scope for this project"
You: "Thanks for saving me a week!" ✅

OR

You: "Hey! Would you accept a PR that adds feature X?"
Maintainer: "Yes! Please open an issue first to discuss approach"
You: *opens issue*
You: *discusses design*
You: *gets approval*
You: *builds it*
You: *PR gets merged!* 🎉

The rule: NEVER code before discussing! Always open an issue first! 🎯

In the security community, we ALWAYS discuss vulnerabilities before submitting patches. Same principle applies to features - get buy-in FIRST! 🔒

Sin #2: The "Everything and the Kitchen Sink" PR

The crime:

Changes:
- Added feature X
- Refactored unrelated code Y
- Updated dependencies
- Reformatted 50 files
- Changed code style
- Fixed typos in README
- And... 47 other things

Why maintainers hate it:

Can't review 47 changes at once!
Which change broke tests?
Can't merge feature X without accepting all other changes!
Risk of bugs increases exponentially!

The fix:

PR #1: Add feature X (5 files)
PR #2: Update dependencies (1 file)
PR #3: Fix README typos (1 file)

Each PR: Small, focused, easy to review!
Merge rate: 📈📈📈

The rule: ONE PR = ONE change! Multiple changes = Multiple PRs! 🎯

Balancing work and open source taught me this: I have 30 minutes for reviews. A focused 5-file PR? I can review it. A 50-file chaos PR? That's next month's problem! ⏰

Sin #3: The "Style Guide? What Style Guide?" PR

The crime:

// Project uses semicolons
const user = getUser();

// Your PR:
const user = getUser()  // No semicolon!

// Project uses 2 spaces
function foo() {
  return bar
}

// Your PR:
function foo() {
    return bar  // 4 spaces!
}

Why it matters:

Linter fails! ❌
CI fails! ❌
Maintainer has to manually fix! 😤
OR reject your PR! 💀

The fix:

# BEFORE coding, run:
npm run lint  # Fix any issues!
npm run format  # Auto-format code!
npm test  # Ensure tests pass!

# Many projects have .editorconfig
# Let your IDE use it!

# Check for CONTRIBUTING.md
# It has the rules!

The rule: Match the existing code style! Use the project's linter! Run tests BEFORE pushing! 🎯

Sin #4: The "Trust Me Bro" PR (No Tests)

The crime:

Title: "Fix critical bug in authentication"

Changes:
- Modified core auth logic
- No tests added
- "Trust me, it works!"

Maintainer's thought process:

"Does this actually fix the bug?" - Don't know
"Does this break anything else?" - Don't know
"How do I verify this works?" - Don't know
"Should I merge this?" - NOPE!

The fix:

Title: "Fix critical bug in authentication (fixes #123)"

Changes:
- Modified auth logic (src/auth.js)
- Added regression test (tests/auth.test.js)
- Verified fix works with test
- All existing tests still passing

Test output:
✓ should reject invalid tokens (NEW TEST!)
✓ should accept valid tokens (existing)
✓ should handle expired tokens (existing)

The rule: If you fix a bug, add a test that would have caught it! If you add a feature, test that feature! No tests = No merge! 🎯

In my Laravel work, I learned this the hard way: "Works on my machine" means nothing. Tests prove it works everywhere! 🧪

Sin #5: The "Good Luck Merging This" PR (Conflicts!)

The crime:

Your PR: *based on main from 3 weeks ago*
Main branch: *has 47 commits since then*
Your PR: *conflicts in 12 files*

Maintainer: "Please rebase and resolve conflicts"
You: *never responds*
Or worse: You: "Can you merge it for me?" 😬

The fix:

# Keep your PR up to date!

# Every few days:
git checkout main
git pull upstream main
git checkout your-feature-branch
git rebase main

# Resolve conflicts as you go
# Not all at once at the end!

# Force push (YOUR branch only!)
git push --force-with-lease

# Now your PR is clean! ✅

The rule: YOU own your PR! YOU keep it up to date! YOU resolve conflicts! Maintainers don't have time to fix your merge conflicts! 🎯

Sin #6: The "Drive-By" PR (Then Ghost)

The crime:

Day 1: You open PR
Day 2: Maintainer comments: "Can you add tests?"
Day 3-365: *crickets* 🦗

OR

Day 1: You open PR
Day 2: Maintainer comments: "Looks good! Just fix the linting"
Day 3: You force-push completely different code
Day 4: Maintainer: "Wait, what? This broke everything!" 😱

The fix:

Be responsive!
✅ Check GitHub notifications daily
✅ Respond to comments within 48 hours
✅ If you need time, say so: "Working on it, will update by Friday!"
✅ If you can't finish, say so: "I don't have time anymore, feel free to take over"
✅ When you make changes, comment what you changed

Be considerate!
✅ Don't force-push without explaining
✅ Don't disappear mid-review
✅ Don't make major changes without discussion
✅ Communication is KEY!

The rule: Maintain your PR like you maintain your code! Stay engaged until it's merged! 🎯

Sin #7: The "Reinvent Everything" PR

The crime:

Issue: "The login button is 2px too small"

Your PR:
- Rewrote entire authentication system
- Switched from JWT to sessions
- Refactored the whole frontend
- Added 47 new dependencies
- Changed database schema
- "Also fixed the button size!" 🎉

Why maintainers cry:

Asked for 2px change, got 2000 lines!
Now they have to review a MASSIVE rewrite!
Risk of bugs EVERYWHERE!
Probably won't merge ANY of it!

The fix:

Issue: "The login button is 2px too small"

Your PR:
- Changed button CSS from 18px to 20px
- That's it!
- 1 file, 1 line, 1 change! ✅

Maintainer: "Perfect!" *merges immediately*

The rule: Solve the ACTUAL problem! Don't over-engineer! Simplicity wins! 🎯

The "How to Get Your PR Merged" Checklist ✅

BEFORE you start coding:

□ Is there an existing issue? If not, open one!
□ Did maintainer confirm they want this? Get approval first!
□ Did you discuss the approach? Get agreement on design!
□ Did you check for duplicate PRs? Don't waste time!
□ Did you read CONTRIBUTING.md? Follow the rules!
□ Did you check the style guide? Match the style!

WHILE you're coding:

□ Are you making ONE focused change? Not 47 changes!
□ Are you following code style? Linter should pass!
□ Are you writing tests? Code + tests = mergeable!
□ Are you updating docs? Docs = helps users!
□ Are you keeping commits clean? Meaningful commit messages!
□ Are you rebasing regularly? Stay up to date!

BEFORE you open the PR:

□ Does the linter pass? npm run lint
□ Do all tests pass? npm test
□ Did you test manually? Does it actually work?
□ Is your branch up to date? Rebase on latest main!
□ Are there merge conflicts? Resolve them first!
□ Did you write a good description? Explain what/why!

AFTER you open the PR:

□ Did you link to the issue? "Fixes #123"
□ Did you add screenshots/demos? Show it works!
□ Did you request review? Tag maintainers if appropriate!
□ Are you responsive? Check notifications daily!
□ Did CI pass? Fix any failing checks!
□ Did you address feedback? Respond to comments!

The Perfect PR Template 📋

Use this for your next PR:

## Description
[Brief description of what this PR does]

Fixes #[issue number]

## Changes
- [Specific change 1]
- [Specific change 2]
- [Specific change 3]

## Type of Change
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that would break existing functionality)
- [ ] Documentation update

## Testing
- [ ] Tested locally
- [ ] All existing tests passing
- [ ] New tests added for new functionality
- [ ] Tested in multiple browsers/environments (if applicable)

## Screenshots (if applicable)
[Add screenshots showing the change]

## Checklist
- [ ] Code follows the style guide
- [ ] Self-reviewed my own code
- [ ] Commented code where needed
- [ ] Updated documentation
- [ ] No new warnings
- [ ] Added tests that prove fix/feature works
- [ ] New and existing tests pass locally
- [ ] Rebased on latest main
- [ ] No merge conflicts

## Additional Context
[Any additional information reviewers should know]

Copy this! Use it! Watch your merge rate 📈!

Real Examples: Good vs. Bad PRs 🎓

Example #1: Bug Fix

❌ Bad PR:

Title: "Fix"

Description:
Fixed a bug

Files changed: 15
Commits: "fix", "fix2", "fix3", "actually fixed", "real fix"
Tests: None

✅ Good PR:

Title: "fix: Prevent null pointer exception in user profile (fixes #456)"

Description:
The user profile page crashes when a user has no avatar set.
This PR adds null checks and a default avatar fallback.

**Changes:**
- Added null check in UserProfile.tsx (line 45)
- Added default avatar constant (src/constants.ts)
- Added regression test (tests/UserProfile.test.tsx)

**Root Cause:**
The component assumed avatar URL always exists, but new users
don't have avatars yet.

**Testing:**
- ✅ Tested with user with avatar (works)
- ✅ Tested with user without avatar (shows default)
- ✅ All existing tests passing
- ✅ Added test to prevent regression

**Before:**
[Screenshot showing crash]

**After:**
[Screenshot showing default avatar]

Fixes #456

Why the good one gets merged:

✅ Clear problem statement
✅ Explains root cause
✅ Shows testing was done
✅ Has screenshots
✅ Links to issue
✅ Includes regression test
✅ Ready to merge NOW

Example #2: New Feature

❌ Bad PR:

Title: "New feature"

Description:
Added dark mode

Files changed: 73
Lines: +2847, -1923
Tests: None
Conflicts: Yes
Style issues: Yes

✅ Good PR:

Title: "feat: Add dark mode toggle in settings (fixes #123)"

Description:
Implements dark mode as discussed in issue #123 and design doc.

**Changes:**
- Added ThemeProvider wrapper (src/contexts/ThemeContext.tsx)
- Added toggle in Settings page (src/pages/Settings.tsx)
- Updated 8 components to use theme colors
- Persists preference to localStorage
- Detects OS theme preference on first load
- Added tests (coverage: 93%)
- Updated README with new feature

**Design Decisions:**
- Used CSS variables for easy theming
- Toggle in Settings (not navbar) per feedback in #123
- Persists to localStorage for consistency across sessions
- Falls back to OS preference if user hasn't chosen

**Testing:**
- ✅ Tested on Chrome, Firefox, Safari
- ✅ Tested with light/dark OS preferences
- ✅ Tested localStorage persistence
- ✅ All components render correctly in both themes
- ✅ No breaking changes
- ✅ All existing tests still pass

**Screenshots:**
Light mode: [screenshot]
Dark mode: [screenshot]
Toggle UI: [screenshot]

**Demo:**
[Loom video showing feature working]

Fixes #123

Why this gets merged fast:

✅ Feature was pre-approved (issue #123)
✅ Clear implementation details
✅ Explains design decisions
✅ Comprehensive testing
✅ Visual proof it works
✅ No breaking changes
✅ Documentation updated
✅ Maintainer can merge with confidence

How Maintainers ACTUALLY Prioritize PRs 🎯

Secret formula from maintainer perspective:

High Priority (Merge Fast! ⚡):

✅ Small focused changes (< 100 lines)
✅ Fixes critical bugs
✅ Has tests
✅ No conflicts
✅ Responsive contributor
✅ Follows all guidelines
✅ Linked to approved issue

Merge time: Hours to days

Medium Priority (Review Eventually 📅):

⚠️ Larger changes (100-500 lines)
⚠️ New features (need more review)
⚠️ Missing some tests
⚠️ Contributor less active
⚠️ Needs minor changes

Merge time: Weeks

Low Priority (Dies in Queue 💀):

❌ Massive changes (> 500 lines)
❌ No linked issue
❌ No tests
❌ Merge conflicts
❌ Doesn't follow style
❌ Breaking changes
❌ Contributor ghosted
❌ Unclear what it does

Merge time: Never

Translation: Make your PR HIGH PRIORITY! It's not about quality of code - it's about EASY TO REVIEW! 🎯

Balancing work and open source taught me: I review PRs at night after work. A clean, small, well-documented PR? I'll merge it before bed. A messy, large, confusing PR? That's "someday" pile! 📚

The Contributor/Maintainer Relationship 🤝

Remember: Open source maintainers are:

✅ Volunteers (usually!)
✅ Busy with jobs/life
✅ Often burnt out
✅ Drowning in notifications
✅ Juggling 47 PRs
✅ Trying their best!

Your job as contributor:

✅ Make their life EASIER
✅ Submit mergeable PRs
✅ Be responsive and polite
✅ Take feedback gracefully
✅ Don't take silence personally
✅ Respect their time!

The golden rule:

Would YOU want to review this PR at 10pm after a long day?

If no → Improve it!
If yes → Ship it! 🚀

What To Do When Your PR Is Ignored 😔

Week 1: Be patient

Maintainers are busy! Give them time!
Don't ping immediately!

Week 2: Gentle nudge

"Hey! Just wanted to follow up on this PR.
Let me know if you need anything from my end! 😊"

Week 3: Check if stale

"Should I rebase this on latest main?
Happy to update if needed!"

Week 4: Offer to help

"I noticed there are a lot of PRs.
Can I help with reviews or anything?"

Month 2: Consider alternatives

- Fork and maintain yourself?
- Find different project?
- Become co-maintainer?
- Accept it might not get merged?

Reality check:

Sometimes PRs don't get merged (not personal!)
Sometimes projects are effectively unmaintained
Sometimes your feature isn't wanted
Sometimes maintainer quit but hasn't said so
That's open source! 🤷‍♂️

The Bottom Line 💡

Your PR gets ignored because you made it HARD to merge!

What you learned today:

Always open an issue BEFORE coding
One PR = One focused change
Follow the style guide religiously
Add tests (non-negotiable!)
Keep your branch up to date
Stay responsive to feedback
Use the perfect PR template
Make maintainer's job EASY
Small PRs merge faster than big ones
Your attitude matters as much as your code!

The truth:

PRs that get merged:

✅ Small and focused
✅ Pre-approved (linked issue)
✅ Follow all guidelines
✅ Have tests and docs
✅ No conflicts
✅ Responsive contributor
✅ Professional description
✅ Easy to review and merge! 🎉

PRs that die in the queue:

❌ Large and sprawling
❌ No prior discussion
❌ Ignore guidelines
❌ No tests
❌ Merge conflicts
❌ Ghost contributor
❌ "Trust me bro" description
❌ Nightmare to review! 💀

Which are YOU submitting? 🤔

Your Action Plan 🚀

Right now:

Review your open PRs
Are they following these rules?
Update descriptions to be clearer
Respond to any pending feedback
Rebase and fix conflicts

Next PR:

Open issue first (get approval!)
Make ONE focused change
Write tests
Follow style guide
Use the perfect PR template
Stay engaged until merged

Long term:

Build reputation as great contributor
Write PRs maintainers LOVE to merge
Eventually become trusted contributor
Maybe become maintainer yourself!
Pay it forward! 💚

Resources & Tips 📚

Before contributing:

Read CONTRIBUTING.md
Check CODE_OF_CONDUCT.md
Review existing PRs (learn patterns!)
Join project Discord/Slack
Introduce yourself!

Tools that help:

GitHub CLI (gh pr create)
Linters (follow the rules!)
Test runners (verify it works!)
Pre-commit hooks (catch issues early!)

Learning resources:

How to Contribute to Open Source
First Timers Only
Project-specific contribution guides

My experience: Check my GitHub for examples of PRs I've submitted (both merged and rejected - learn from both!).

Final Thoughts 💭

The uncomfortable truth:

Most contributors blame maintainers for ignoring PRs. But often, it's because the PR is HARD TO MERGE. Not bad code - just hard to review, hard to test, hard to trust!

The good news:

YOU control whether your PR gets merged! It's not about connections or luck. It's about making mergeable PRs!

5 minutes improving your PR can mean the difference between:

✅ Merged in a day
❌ Ignored forever

In the security community, we say: "Make it easy to say yes." Same with PRs - make it SO EASY to merge that maintainers can't resist! 🎯

Here's my challenge:

Right now, look at your last PR that didn't get merged. Be honest - did you follow the rules in this post? Would YOU want to review that PR?

Questions to ask yourself:

Did I discuss before coding? (Or surprise them?)
Is it focused? (Or kitchen sink?)
Does it have tests? (Or "trust me bro"?)
Is it up to date? (Or conflict city?)
Am I being responsive? (Or ghosting?)

Your move! ♟️

Want to improve your OSS contributions? Connect with me on LinkedIn - I'm always sharing tips!

Check out my PRs! See examples on my GitHub - learn from successes AND failures!

Now go write PRs that GET MERGED! 🔀✨

P.S. To maintainers: If you're drowning in PRs, it's okay to close stale ones! Better to close with explanation than leave contributors hanging forever! 💚

P.P.S. Remember: Every merged PR is a WIN for open source! You're making software better for everyone! Keep contributing! Don't get discouraged! The community needs YOU! 🌟