My first open source contribution: Talk about your pull request

I finally heard back from the project and my code was merged.
72 readers like this.
Why make a new open source software license?  MPL 2.0 (part 3)

Previously, I wrote about keeping your code relevant when making a contribution to an open source project. Now, you finally click Create pull request. You're elated, you're done.

At first, I didn’t even care whether my code would get merged or not. I had done my part. I knew I could do it. The future lit up with the many future pull requests that I would make to open source projects.

But of course, I did want my code to become a part of my chosen project, and soon I found myself googling, "How long does it take for an open source pull request to get merged?" The results weren’t especially conclusive. Due to the nature of open source (the fact that anyone can participate in it), processes for maintaining projects vary widely. But I found a tweet somewhere that confidently said: "If you don’t hear back in two months, you should reach out to the maintainers."

Well, two months came and went, and I heard nothing. I also did not reach out to the maintainers, since talking to people and asking them to critique your work is scary. But I wasn’t overly concerned. I told myself that two months was probably an average, so I put it in the back of my mind.

At four months, there was still no response. I opted for the passive approach again. I decided not to try to get in touch with the maintainers, but my reasoning this time was more negative. I started to wonder if some of my earlier assumptions about how actively maintained the project was were wrong—maybe no one was keeping up with incoming pull requests. Or maybe they didn’t look at pull requests from random people. I put the issue in the back of my mind again, this time with less hope of ever seeing a result.

I had nearly given up hope entirely and forgotten about the whole thing when, six months after I made my original pull request, I finally heard back. After making a few small changes that they requested, my code was approved and merged. My fifth mistake was giving up on my contribution when I did not hear back and failing to be communicative about my work.

Don’t be afraid to communicate about your pull request. Doing so could mean something as simple as adding a comment to your issue that says, “Hey, I’m working on this!" And don’t give up hope just because you don’t get a response for a while. The amount of time that it takes will vary based on who is maintaining the project and how much time they have to devote to maintaining it.

This story has a happy ending. My code was merged. I hope that by sharing some parts of the experience that tripped me up on my first open source journey, I can smooth the path for some of you who want to explore open source for the first time.

What to read next
User profile image.
Galen is a Senior Software Engineer at Simple Health in NYC. She loves writing (for computers and humans), lifting, and cats. @galenemco

1 Comment

Awesome job! Keep this up. Do not be afraid to contribute and possibly even receive bad feedback. Bad feedback is better than no feedback at all. And often the bad feedback means you might learn something from the experience. I enjoy getting pull requests for even the things I put on GitHub. Will I question things? But I will always attempt to do it in a way that will not turn someone away. Sometimes however, someone who submits a pull request and is asked to explain something further will take offense. Possibly even just close the pull request. Do not do this! If you took the time to put the effort into the pull request, it meant something to you. If I ask a question, then your work is still valued but I need more context. But even sometimes it might be an attempt to get the other person to look at things different hoping to learn.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.