Introduction
Let's face it. It's already challenging enough to work on your own. I mean, if you cannot even satisfy yourself with what you wrote, how can you expect people to accept your code?
However, I can guarantee you that it is not that difficult. Through this post, I hoped to give everyone a little insight into my journey of getting my first pull request accepted.
Background
This week, our professor asked us to find a classmate and submit a pull request to a project that each of us was building. While others are messaging on Slack, I was lucky to be reached out by Vivian, who was also looking for a partner. Since we have both know each other for a while, I decided to contribute to her project.
Filing the issue
First, I decided to check the repo and noting down everything I could. Carefully examined how Vivian wrote the project allowed me to avoid unnecessary changes and ensure that the new code I wrote would not break the existing ones. Once satisfied, I decided to file an issue describing in detail what I wanted to do. The plan was:
- Make adjustments to the file handling to support markdown file(s).
- Implementing the ability to parse some of the Markdown's syntax into their corresponding HTML elements.
- Provide documentation for the newly added feature.
I had to pay close attention to my partner's response and trying my best to answer any question she might have. Finally, when Vivian went through with my issue, I wasted no time cloning the project down and began coding.
Making the changes
Writing the implementation was not as difficult as I expected. I soon discovered that I could reuse a lot of the existing logic and only made minor adjustments where necessary. To support markdown files alongside text files, I added extra conditional statements to check for the .md extension and utilized Array.filter to get the list of markdown files if the input was a folder. For parsing the markdown syntax, both Vivian and I decided on using a combination of regular expressions and String.replace. Once the newly written code passed a series of tests, I moved on to fill in the documentation for the new feature, providing instructions and examples explaining how it should work.
Getting the pull request reviewed
When I was finally satisfied with everything, I reached out to Vivian to review my pull request. Both of us spent quite a while discussing the new code, with myself filling in any question that my partner had, and in the end, she decided that no additional changes were needed.
Accepting pull requests
Similar to what I did, Vivian also reached me through Slack and asked to review her pull request. While going through the changes that my partner made, I noticed some minor issues. I decided to leave some comments at where they were, explaining how I wanted to change them and included some links for further reading/reference. With the feedback, Vivian quickly fixed the issues and asked me to looked at the code again. Additionally, I asked her to send me on Slack some screenshots of her tests and outputs. After verifying that everything was working as intended, I decided to merge the pull request and not forget to leave her a small token of appreciation.
Conclusion
It is easy to get discouraged because you may think you are not good enough to make a pull request. However, by standing up to that belief and just simply do it, you are creating an opportunity to not only improve your skills by receiving feedback from others but also expand your connection. Additionally, contributing to someone else project allows you to "steal" from their knowledge and make it your own, giving you more options to choose from next time facing similar problems. So, what are you waiting for? Find any projects that interest you and start contributing!
Cheers! 🍻
Cover photo by Scott Graham on Unsplash
Top comments (0)