OpenSource Together

Command Palette

Search for a command to run...

Chapter 9: When a Pull Request Is Not Accepted

Not every pull request gets merged.

This is a normal and expected part of open source collaboration.

This guide focuses on understanding rejection and responding constructively.

Rejection Is Not Failure

A pull request being closed or rejected does not mean:

  • Your work was useless
  • Your skills are insufficient
  • Your contribution was unwelcome

It usually reflects project constraints, priorities, or direction.

Common Reasons Pull Requests Are Not Accepted

Pull requests may be declined due to:

  • Scope mismatch
  • Project roadmap decisions
  • Maintenance burden
  • Alternative solutions preferred
  • Timing issues
  • Architectural concerns

These factors are often independent of code quality.

Reading the Response Carefully

When a pull request is not accepted:

  • Read the explanation fully
  • Identify the main concern
  • Separate feedback from outcome

Understanding the reason is more important than the result.

Responding Respectfully

A respectful response includes:

  • Acknowledging the decision
  • Thanking maintainers for their time
  • Avoiding defensive language

Professionalism leaves a positive impression.

Asking for Clarification

If the reason is unclear:

  • Ask politely for clarification
  • Avoid challenging the decision
  • Focus on learning

Clarification can provide valuable insight.

Learning From Rejection

Rejections often teach:

  • Project priorities
  • Hidden constraints
  • Design philosophy
  • Contribution boundaries

This knowledge improves future contributions.

Deciding What to Do Next

After a rejection, you can:

  • Adjust the proposal
  • Contribute in another area
  • Apply lessons to another project
  • Take a break if needed

Walking away is sometimes the healthiest option.

Avoiding Emotional Burnout

Rejection can be discouraging.

To protect yourself:

  • Avoid over-identifying with outcomes
  • Take breaks when needed
  • Remember that open source is collaborative, not competitive

Sustainability matters.

Maintaining Long-Term Perspective

Open source collaboration is cumulative.

One rejected pull request does not define your trajectory.

Consistency and learning compound over time.

Leaving the Door Open

Even after rejection:

  • Maintain a positive tone
  • Stay engaged if appropriate
  • Follow project updates

Future opportunities may arise.

What You Should Be Able to Do Now

You should now be able to:

  • Interpret pull request rejection calmly
  • Respond professionally
  • Extract learning from the experience
  • Continue contributing with confidence

Resilience is a key open source skill.

Reflection

Ask yourself:

  • What did I learn from this outcome?
  • How can I apply this insight?
  • What kind of contribution would feel better next?

Growth often follows discomfort.

Next Up

Chapter 10: Contributing Without Writing Code

0 / 13 completed
Previous