How Contributions Are Evaluated
The Maintainer's Perspective
Understanding how maintainers evaluate contributions helps you craft PRs that get merged—not ignored.
The Evaluation Framework
┌─────────────────────────────────────────────────────────────────────────────┐
│ CONTRIBUTION EVALUATION MATRIX │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ RELEVANCE │
│ Does this belong in the project? │
│ │
│ ▲ │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ │ │ │ │
│ │ REJECTED │ IDEAL │ │
│ QUALITY ◄──┼──────────────────┼──────────────────┼──► HIGH │
│ │ │ │ │
│ │ IGNORED │ MAYBE LATER │ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ │ │
│ ▼ │
│ LOW │
│ │
│ Additional factors: MAINTENANCE BURDEN + CONTRIBUTOR TRUST │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Dimension 1: Relevance
Questions Maintainers Ask
- Is there an issue tracking this?
- Does this align with project roadmap?
- Is this something users actually need?
- Does this fit the project's scope?
Instant Rejection Triggers
❌ Unsolicited feature additions
❌ Scope creep / kitchen sink PRs
❌ Features maintainers rejected before
❌ Duplicates of existing PRs/issues
How to Score High
✅ Link to an existing issue
✅ Pick up "help wanted" issues
✅ Discuss approach before coding
✅ Keep PRs focused and small
Dimension 2: Quality
Quality Checklist
- Tests pass locally and in CI
- New code is tested
- Follows existing code style
- Clear, descriptive commit messages
- PR description explains the "why"
- No unrelated changes included
- Documentation updated if needed
The Ideal PR Description
## Summary
[One paragraph: WHAT this PR does]
## Motivation
[One paragraph: WHY this change is needed]
Fixes #123
## Changes
- [Bullet point 1]
- [Bullet point 2]
- [Bullet point 3]
## Testing
- [How you tested this]
- [Steps to verify]
## Screenshots (if UI changes)
[Before/after screenshots]Dimension 3: Maintenance Burden
The Hidden Factor
This is what most new contributors don't consider. Maintainers think long-term: "Will this cause problems for the next 5 years?"
┌─────────────────────────────────────────────────────────────────┐
│ MAINTENANCE BURDEN SCALE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ LOW BURDEN (Welcome!) │
│ ══════════════════════ │
│ ✓ Bug fixes │
│ ✓ Documentation improvements │
│ ✓ Test additions │
│ ✓ Performance improvements (no API changes) │
│ ✓ Small refactors │
│ │
│ MEDIUM BURDEN (Discuss First) │
│ ══════════════════════════════ │
│ ○ New configuration options │
│ ○ Small features │
│ ○ Dependency updates │
│ ○ Larger refactors │
│ │
│ HIGH BURDEN (Rarely Accepted) │
│ ══════════════════════════════ │
│ ✗ New dependencies │
│ ✗ Breaking changes │
│ ✗ New public APIs │
│ ✗ Major new features │
│ ✗ Architecture changes │
│ │
└─────────────────────────────────────────────────────────────────┘The Boring Solution Wins
When in doubt, choose the boring solution. Maintainers will thank you.
Dimension 4: Contributor Trust
┌─────────────────────────────────────────────────────────────────┐
│ TRUST SIGNALS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ HIGH TRUST LOW TRUST │
│ ────────── ───────── │
│ │
│ Previous merged PRs Brand new account │
│ Quick response to reviews Slow or no responses │
│ Follows contribution guidelines Ignores guidelines │
│ Polite, professional Demanding or rude │
│ Accepts feedback gracefully Argues every point │
│ Complete, thorough PR Sloppy, incomplete work │
│ Engaged in discussions Only submits PRs │
│ │
└─────────────────────────────────────────────────────────────────┘Start Small
Your first contributions should be small and obviously correct. Build credibility.
Be Responsive
When maintainers review your PR, respond within 24-48 hours. Every time.
Accept Feedback
Even if you disagree, thank them for the review. Discuss respectfully.
Be Consistent
One-time contributors are forgettable. Regular contributors build relationships.
The Review Process Flow
┌─────────────────────────────────────────────────────────────────────────────┐
│ PR REVIEW PIPELINE │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [PR Submitted] │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Automated Checks │ ──── FAIL ────► [Fix and re-push] │
│ └────────┬────────┘ │
│ │ PASS │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Quick Screening │ ──── REJECT ──► [Closed with explanation] │
│ │ (Is it relevant?)│ │
│ └────────┬────────┘ │
│ │ PASS │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Enters Queue │ │
│ │ (Days to weeks) │ │
│ └────────┬────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Deep Review │ ──── Changes Requested ──► [You respond] │
│ └────────┬────────┘ ▲ │
│ │ │ │
│ │ APPROVED │ │
│ ▼ │ │
│ ┌─────────────────┐ │ │
│ │ Secondary Review │ ─────────────────────────────┘ │
│ │ (Maybe) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ [MERGED! 🎉] │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Common Rejection Reasons
No Issue Linked
"Please open an issue first to discuss this change."
Scope Too Large
"This PR does too many things. Please break it into smaller PRs."
Doesn't Fit Roadmap
"We don't plan to add this feature. See issue #X for context."
CI Failing
"Please fix the failing tests before we review."
Missing Tests
"Please add tests for this new functionality."
Stale / Abandoned
"Closing due to inactivity. Feel free to reopen if you're still working on this."
The Ideal Contribution
✨ Gold Standard Contribution
- Fixes an existing issue (linked in PR)
- Discussed approach in issue before coding
- Small, focused PR (under 200 lines)
- Tests included and passing
- Follows all contribution guidelines
- Clear PR description with context
- Clean commit history
- Documentation updated
- Responds to reviews within 48 hours
- Accepts feedback gracefully