How I Learned From Rejection

Reviews, rejections, and learning not to take it personally

This isn't a highlight reel. It's the part of open source that actually taught me the most: reviews, rejections, and learning to not take it personally.

The First PR That Got Shut Down

I spent an entire weekend hacking on a feature in the Kubeflow ecosystem. I was proud of it.

Then I opened the PR and got a public list of changes requested—more than I expected.

My first reaction was to want to disappear. After I cooled down, I realized:

  • The reviewer cared enough to be specific.
  • The feedback wasn't about me; it was about the code and the project.
  • The fastest way forward was to treat it like a free lesson.
1

Read CONTRIBUTING Before You Start

A lot of early failures are avoidable. Every project has guidelines. Read them.

2

Small PRs Land Faster

Big PRs are hard to review and easier to reject. Small PRs get merged. Focus on scope.

3

Docs Can Be High Impact

A good documentation PR can unblock many users, and it usually gets reviewed faster than code.

4

Ask Early When Scope Is Unclear

If your plan doesn't match repo direction, you'll waste time. Ask in an issue first.

5

Rejection Isn't the End

Most "no" answers are actually "not like this" or "not right now." They're redirects, not doors closing.

6

Validate Before Building

Don't assume maintainers want what you're building. Talk to them first. It saves weeks of wasted effort.

What Helped Me Get Over It

Stop Refreshing GitHub Waiting for Approval

Set it aside for a few hours. Your mental health is more important than refresh rate.

Make the Changes, Respond Calmly, and Keep Moving

Don't get defensive. Treat feedback as free consulting. Implement it professionally.

If the PR Isn't Going Anywhere, Learn From It and Pivot

Not every PR gets merged. That's okay. Extract the lessons and move to the next one.

Remember: This Is About the Code, Not About You

"Your code needs changes" ≠ "You're not good enough." Separate the work from your identity.

What I'd Tell a New Contributor

Getting pushback is normal. If you can learn to handle it well, you'll be ahead of most people.

Take the feedback, improve the work, and try again.

The reviewers who ask for changes are invested enough to care about quality. They're not trying to hurt you. They're trying to make the project better.

That's actually a privilege.

Real Example: CCExtractor PR #2246

I spent time creating a Linux throughput benchmarking guide and helper script. I thought it was useful.

The maintainer closed it saying the project had different priorities.

What I learned:

  • I didn't ask first
  • I assumed a problem existed based on my own need
  • I didn't validate problem-solution fit with maintainers

Now I:

  1. Look for open issues first before creating new work
  2. Ask in issues before starting significant contributions
  3. Focus on actively reported problems rather than assumed needs
  4. Validate alignment with maintainers before investing time

That closed PR taught me more than many merged ones would have.

Read Full Story