OS / How I made my first PR to DEV as a code newbie

In the past six months, my relationship with DEV was strictly limited to consumer and provider. I learned tons of new things and gave nothing back to the community. This is partially why I started blogging here. Another way I wanted to give back was contributing to the DEV code base itself, thereby incrementally improving the infrastructure that hosts this beautiful community. On May 19th, my PR was finally merged, and I decided to write a blog post about how a code newbie did it.

Step 1: Check open issues

I checked the main repo to see if there were any open issues. There were more than 700 of them. Great! "More chances for me", I thought to myself.

Step 2: Select an open issue

After I scanned all of the open issues, I picked a "manageable" one - something I could reasonably do in under 2 weeks. I imposed this restriction on myself because I was neither familiar with DEV's code base nor Ruby on Rails which is what DEV is built on.

Step 3: Raise your hand

On May 13th, I pulled the trigger and raised my hand, signalling to a core developer (@ridhwana ) that I wanted to work on issue 7835. I wrote to her, "If this is not taken already, I can take this!"

Step 4: Wait for approval

Typically a core developer will assign an issue to you, and that's when you can get started working. After all, you don't want to work on something that's already been claimed or worked on. Another core developer (@lightalloy ) promptly wrote to me, "You're welcome to work on this issue."

Step 5: Fork the repo, create a branch, and install locally

Complex projects typically have a dedicated README.md for contributing. Here is what DEV's contribution document looks like. The most complicated part was the installation process. I needed to install the development environment, so I followed the installation guide. Docker didn't work. Welp (😢)! So I installed DEV on Linux, which required PostgreSQL, Ruby, Rails, Redis, etc. All of of those dependencies are detailed in the installation guide.

Step 6: Work on it

Finally, I was ready to contribute. Thankfully, the issue had been linked to another issue which had been documented really well. It even had a PR to go with it. So I was pretty confident about making the right changes.

Step 7: Create PR and solicit feedback

2 days after I was assigned the issue, I made a PR to DEV. And it went pretty smoothly thanks to the core developers: @rhymes and @lightalloy . Both left me helpful tips on what to fix and I made two commits thereafter fixing my errors. I also made sure to add some comments on Github to document why those changes were made.

Step 8: PR gets merged and you celebrate

3 days later, the PR was finally approved by a majority and merged to master. PR #7895 will forever be mine... forever in the annals of DEV history (🎉🎉🎉).

Main Takeaway

Here is what I want you to takeaway from this post: you needn't be brave to make open source contributions because bravery is not the absence of fear. Bravery is about acknowledging that fear and deciding that the want to contribute is decidedly more significant than our competence, image, and self-importance. Remember, the worst thing that can happen is for your PR to get rejected because almost no one will criticize you for sharing the product of free labor. Here is one of a gazillion PR's I made that got rejected. More failures to come from me...

Warmly,
EK