How I Started Contributing to Open Source

It’s almost time for Hacktorberfest 2022 and I thought I’d share my experience of how I started contributing to open source as an early career Front-End developer.

Just a little HTML

My very first contribution was actually in a small open source project where I saw an issue to add OG meta tags. I thought this was a great way to test forking, cloning and running someone else’s project locally, making the changes, doing a pull request and seeing what happens. I figured it was an easy first pull request. My PR was accepted and merged. I was thanked for my contribution and that little “win” made me want to hunt for something more. But none of the other open issues interested me.

Looking for a team

I remembered that a while back, before I learned how to code in React, I had come across another open source project that I’d saved for later. Web Dev Path is an initiative that allows a new dev to work in a structured project under guidance, following the industry’s best practices, using git version control. I had already joined their Slack channel and had told them I’d be back to contribute when I was ready. Well, I still didn’t feel anywhere near ready but I was really curious and needed a challenge where a team counted on me.

Scary at first

To contribute, I would have to understand the codebase. I read through their README and wiki and followed the instructions to get started locally. But it was hard to read code I didn't write. I saw a new issue had been open for a few days and I thought I should assign it to myself but I was too nervous. I thought that if I made the changes locally and I figured it out on my own, I could then pick up the issue. I started to read through the codebase and the issue instructions but before I could even make any changes, another developer claimed the issue.

Fair enough, the issue was un-assigned. It was probably for the best because while waiting for another interesting issue to open up, I started familiarizing myself with the project by understanding their tech stack (React.js, Next.js, Sass) and started participating in their Slack channels to communicate with the team.

Starting with documentation

Chatting in Slack, the team needed someone to update their wiki by adding the UX/UI Design process documentation. I thought this would be a great first issue while I got to know everyone.

The project team lead added me as a collaborator and she encouraged me to use git version control to update the page. Another dev on the team was also very supportive when I had questions. I saw that it was pretty comfortable working with the team.

The first significant contribution

A couple days later I saw a new issue opened to make the site a Progressive Web App (PWA) and I had 10 days to do it. This was something new for me to learn and I didn’t have to be very comfortable with the codebase to be able to implement it. Still, I ended up becoming a little bit more familiar with the folder structure, site manifest and env keys. First I tried to figure things out on my own and when I was stuck I asked specific questions.

I tested it locally using Lighthouse in Chrome dev tools, then created a PR. I learned how to communicate in a PR and in Slack and started to use more dev talk like “in development” and “in production”.

Community matters

The team was respectful and supportive. It felt like the right spot for me and once the PR was merged, I was on cloud nine!

It was so fun to contribute and collaborate that I wanted more! I moved on to diving deep into the codebase, updating the footer, the about us page, and now working on the contact form, all from Figma designs created by designers on the team who were also learning to work with developers. From the beginning I made sure I kept the consistency by writing my code similar to the code already there.

I’m a regular contributor and through this project I have been improving my communication skills as a frontend developer by building relationships, communicating on issues, pull requests and on Slack, receiving feedback on my code, participating in code reviews, practicing git version control and determining when and how to ask for help.

Conclusion

Some discomfort or fear of messing up is normal but I’m glad I looked past it and saw how fun collaborating can be in a respectful and supportive team. I became more open to working with other teams, participating in more projects and building relationships with other devs remotely.