What Happens After Your First Merged PR?

There are few moments in open source that feel as rewarding as seeing your first pull request merged.

For many contributors, it marks the end of days, weeks, or even months spent navigating an unfamiliar codebase, responding to review comments, revising changes, and wondering if their contribution will eventually be accepted. When the merge notification finally appears, it brings a sense of accomplishment. The effort has paid off, the contribution has been accepted, and your work has become part of a project that thousands of people rely on.

It is a milestone almost every contributor remembers. What happens afterwards, however, receives far less attention.

Some contributors submit another pull request almost immediately. Others become active members of the communities surrounding the projects they contribute to. Some eventually become reviewers, maintainers, and mentors. Others quietly stop contributing after their first merge.

What separates those paths?

To explore that question, we spoke with Kelvin Isievwore, Head of Engineering at Btrust, alongside Btrust Developer Grantees Abubakar Sadiq and Enigbe Ochekliye. Their experiences suggest that while your first merged PR is worth celebrating, it is rarely the moment that defines your journey. What matters most is what you do afterwards.

The First Merge Changes the Work

Kelvin still remembers his first merged pull request. In 2023, he found a bug that had been unresolved for more than a year. It had gradually become a bottleneck for new contributors. Before writing code, Kelvin spoke with the project maintainer to understand what others had tried and why those attempts had failed.

Those conversations shaped nearly two months of investigation before he eventually found a solution.

Looking back, the experience meant much more than fixing one bug.

That was the moment I realized this would become my routine, solving hard problems. It was also the moment I knew I wasn't going to stop contributing anytime soon.

Today, Kelvin reviews contributions and mentors developers across the Bitcoin ecosystem. He has noticed that many new contributors misunderstand what their first merge really means.

Many people think it gets easier after the first merged PR, but it's actually the opposite. Now you're expected to keep learning, improve your technical skills, communicate more effectively, help other contributors, and become better at receiving and acting on feedback. In many ways, the real work begins after that first merge.

A merged pull request does more than add code to a repository. It begins to build trust. Maintainers have seen you respond to feedback, collaborate during review, and carry an idea through to completion. That trust can lead to more opportunities and responsibility. But it also comes with an expectation: keep learning.

The Work Continues

Abubakar Sadiq experienced this almost immediately. His first contribution improved a functional test he found while reading through a project’s codebase. Once it was merged, reviewers suggested a follow-up fix that would apply the same improvement in other places.

After the PR was merged, reviewers suggested a follow-up fix to use the new improvement in other places.

For Abubakar, the merge was not the end of the task. It opened the door to the next contribution.

Sometimes, that next step can come even earlier. While the first PR is still under review, you may notice a related issue, find another small improvement, or receive feedback that points to a separate piece of work. Starting a second PR before the first one merges is completely normal, as long as the changes are independent and you can manage the review process.

The review process itself also challenged Abubakar’s expectations.

I was surprised by how thorough and lengthy the review process was, even for a test PR.

For someone contributing to a mature open-source project for the first time, that level of scrutiny can feel intimidating. But it reflects the care these projects require. Reviews are not just about finding mistakes; they are part of the collaborative process that helps contributors improve.

Abubakar’s advice to new contributors is simple:

If there are suggested follow-up review comments, see them through by opening a new PR that addresses them.

It is straightforward advice, but it reflects an important mindset. Open-source progress is rarely about one contribution. It is about returning, improving, and building on what you have already learned.

Curiosity Is What Keeps Contributors Growing

For Enigbe, the biggest lesson from her first merged pull request was discovering how much more she had to learn.

Her contribution involved Rust, a language she already felt comfortable using. The challenge came after she made her changes: the full build refused to compile because she had gaps in her understanding of the Foreign Function Interface, or FFI.

The experience was frustrating, but it became one of the most valuable lessons of her early open-source journey.

It was a deeply humbling experience. It showed me the importance of understanding the broader system rather than focusing only on the part you're directly modifying.

That lesson continues to shape the way she approaches open source today.

Rather than viewing a merged pull request as proof that she had mastered a project, she left with a deeper appreciation for the context required to contribute meaningfully to mature codebases. High-quality contributions, she says, demand patience, attention to detail, and an understanding of how different parts of a system fit together.

Those expectations have only strengthened her curiosity.

Every contribution answered one question, uncovering several more, and that curiosity has kept me engaged.

That curiosity has taken her beyond writing code alone. Wanting to better understand Bitcoin and distributed systems, Enigbe started a small book club with fellow Bitcoin enthusiasts and software developers. Together, they study Bitcoin and computer science fundamentals to build a stronger understanding of the systems they contribute to.

Her experience reflects something that came up throughout these conversations: contributors who stay engaged are rarely motivated only by a growing list of merged PRs. They stay because every contribution teaches them something new, raises new questions, and gives them another reason to learn.

The Contributors Who Keep Showing Up

After years of reviewing contributions and mentoring developers, Kelvin has noticed that a first merged PR is not always a good predictor of who will become a long-term contributor.

The difference, he says, is rarely technical skill alone.

Consistency, the ability to learn quickly from mistakes, and persistence make all the difference.

He has seen contributors whose PRs were closed because the work was no longer a project priority. Others waited weeks for a review or had to rethink their approach after extensive feedback.

The people who kept going were often the ones who learned to ask better questions, understand what the project actually needed, and focus their energy there.

Contributing consistently is also about more than writing code. Kelvin encourages people to become active in the communities around the projects they care about. Join Slack or Discord conversations, attend project meetings, read open pull requests, review code when you can, and engage with maintainers.

These small actions help you understand the project better while building trust within its community.

Enigbe shares a similar view. She believes one of the best ways to keep growing is by reviewing pull requests.

Code review lets contributors explore unfamiliar parts of a codebase, see different engineering choices, and offer thoughtful feedback that helps move the project forward. It is a reminder that meaningful contribution is not only about the PRs you merge yourself.

More Than a Milestone

Your first merged pull request is easy to celebrate because it is visible. It appears on GitHub, earns congratulations from peers, and gives you proof that your work has become part of a real project.

But the more important changes often happen quietly. They show up in the confidence to ask better questions, the patience to work through several rounds of review, the curiosity to understand parts of a codebase beyond the task in front of you, and the willingness to keep showing up after the excitement of that first merge fades.

These qualities cannot be measured by a GitHub profile or a list of merged PRs. They grow over time through consistent participation, thoughtful feedback, and a genuine desire to keep learning.

That was the strongest thread running through every conversation for this article.

Kelvin found himself returning to harder problems after his first merge. Abubakar learned that one contribution can naturally lead to another, sometimes even before the first one is fully merged. Enigbe gained a deeper appreciation for the systems she was working in and developed a curiosity that still shapes how she learns today.

None of them described their first merged PR as the moment they had finally “made it”. They described it as the moment they realised there was still so much more to learn. Perhaps that is what really happens after your first merged PR.

You stop thinking only about making your first contribution and start thinking about how you can make the next one.

As Kelvin puts it:

Congratulations! Your Bitcoin open-source journey officially begins.