3 Things I Learned From Contributing to Open Source
Tags: opensource
Published: 2021-09-24 14:00:43

This week, I've been contributing to another [static site generator](https://github.com/ycechungAI/cmd-ssg) (SSG). I've picked up a few things that may be useful to first time open source contributors:
- Communication is your best ally
- Be cautious about the changes
- Respect the author's coding style

## Communication is your best ally
![Photo by krakenimages on Unsplash](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ed00bbt9nkw6wxs10il9.png)
 
I wouldn't have been able to get started without help from [Eugene](https://github.com/ycechungAI), the owner of the SSG repo. I couldn't install or run the SSG on my machine, so I decided to file an [issue](https://github.com/ycechungAI/cmd-ssg/issues/20) for that. Luckily, Eugene responded to me and pointed out the root of the issue: my Node.js version didn't meet the requirement. Luckily, the documentation for the prerequisites was updated after the incident. After updating Node and checking if the SSG worked as expected, I was ready to start diving into the codebase.

## Be cautious about the changes
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ek14azs1fxb7auz59pfl.png)
 
When building on the existing codebase, what I found most challenging was to make just enough changes to it. Without familiarity with its bizarre implementation logic and code architecture, building on it was honestly like walking on thin ice. I wanted to [add Markdown support](https://github.com/ycechungAI/cmd-ssg/issues/18) to the SSG, but I literally broke it just by accidentally replaced a logical OR assignment operator (`||=`) with an assignment operator (`=`). In this situation, the hero on which you can depend is nobody else but Mr. Version Control (like Git).

## Respect the author's coding style
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dj1jxxaf6zm3nuel89z5.png)
 
While reviewing my code before making a pull request, I realized I'd written everything according to my coding style. Although it's not a major issue, I believed it would mess up the consistency of the codebase and make it less straightforward. For instance, I'd prefer naming constant variables in uppercase. However, most of them are already named in camel case, so I try to stick to Eugene's naming convention. I know it may not be the best practice, but I think it's better to respect others' practice than arguing about it just to prove that I'm right.

## A Happy Ending
Thankfully, my pull request got accepted on my first attempt. My code was not 100% clean, so Eugene may haven't had time to review it thoroughly yet. However, I still take it as another successful contribution to an open source project.

As for Eugene, he also [contributed the same feature](https://github.com/oliver-pham/silkie/issues/10) to [Silkie](https://github.com/oliver-pham/silkie), my SSG. I noticed his code might need to be fixed and refactored, so we worked together on both Slack and GitHub to resolve those issues. Given our time constraint and Eugene's lack of experience with Python, it was a success that we managed to add a new feature without breaking the existing ones.