Introduction

Contributing to open source can seem intimidating, especially to those who've never done open source before. I know I felt intimidated, thinking that open source is only for talented and senior developers.

While that may be true for those who've made packages and tooling used by thousands (or even millions) of devs, it's not true if you want to contribute to an existing open source project. I've realized that and I'm here to share how I made my first open source contribution.

If that sounds interesting, then let's continue!

Finding an Open Source Project to Contribute to

There are a lot of open source projects out there, but where do you start?

I narrowed it down using these three helpful prompts:

• What specific area of tech am I interested in?
• What are my current skills, or skills I want to improve?
• What's the tech stack of the open source project?

What specific area of tech am I interested in?

Looking for projects that fit your interests would help you get started. Your interests can be anywhere from frontend templates, developer tools, AI, smart contracts, cybersecurity, etc.

I'm passionate in Web3, so I tried to find Web3 projects that are open source. Web3 also encourages open source so it wasn't hard looking for one.

What are my current skills, or skills I want to improve?

As for skills, what are you currently good at? or want to gain more experience at?

For me, I'm a backend developer that specializes in Node.js and TypeScript. I've integrated Web3 libraries to Node.js apps, and I've also written technical documentations for previous projects.

With that, I'd look for Node.js and TypeScript projects, where I'm already good at. I won't look for a Go or Rust project where I don't have the necessary skills to contribute.

What's the tech stack of the open source project?

Combining my interests and skills, I've looked at a few open source projects and their tech stacks.

Ethereum scaling solutions and zero knowledge (ZK) are two areas I'm interested in Web3. I've read Vitalik's article on the different types of ZK-EVMs. I saw Taiko as one of the current Type 1 ZK-EVMs in development.

Reviewing Taiko's monorepo tech stack, I saw that they use TypeScript. Their documentations use MDX, which is an improved version of markdown. I've used markdown before so contributing to their docs in MDX is doable.

With that, I started preparing to make my first open source contribution with Taiko.

Contributing to Taiko

Reviewing contributing guidelines

Before anything else, I first looked at Taiko's CONTRIBUTING.md file to orient myself on their contributing guidelines:

• how to contribute
• coding standards
• documentation standards
• helpful tips

Then I saw two ways to contribute in the Make a contribution section:

• Opening a new issue
• Working on an existing issue

I've chosen to work on an existing issue.

For coding standards, I looked at the standards and conventions used in the project. I saw that they are using conventional commits for pull request titles and commits.

Then for branch naming, I saw that there was no particular convention, so a short branch name describing what it is for should be enough.

Finding an existing issue to work on

I've tried to look at some good first issues, since these are usually not difficult issues, and are meant to help onboard first time contributors.

I ended up choosing the issue to improve their "Node running guide for setting RPC endpoints".

Then I reviewed the issue, and looked at the description and comments. I also reviewed the website where the docs are located.

I made sure I understood what was needed.

Forking, cloning, and working on the changes

After reviewing the issue, I forked and cloned Taiko's monorepo. Then I started working on a proof of concept.

Locating the code that needs improvement was pretty straight-forward, since the project is structured as a monorepo. The website package contains Taiko's guides, so I worked on that.

After I was able to run my local setup and test the changes, I made some comments on the issue and asked for a review to verify if the changes would solve the issue.

After getting approval from Dave (d1onys1us), I proceeded to open a pull request.

Going through the pull request review process

The review process was interesting. While waiting for reviews, I've noticed that there were changes on the main branch that was merged to my feature branch.

Then I reviewed the changes, and it affected my changes, which didn't make sense when combined with the changes from the main branch. So I decided to take the initiative to improve the section and propose the changes on my ongoing pull request review.

The team liked the change, so I proceeded to commit the changes.

Then another reviewer commented that I had API keys exposed on the guide images, so I quickly fixed these to resolve the review comment.

After all of that, my pull request was finally approved and merged!

Finally, I can say that I've contributed to open source! Got a cool GitPOAP to prove it too! 🙂

My Takeaways (Conclusion)

Making my first open source contribution helped me realize what open source meant. The value of open source is in its contributors and their contributions, no matter how big or how small.

Being an open source contributor can also be compared to a boy or girl scout, where the scouts leave the campsite cleaner than when they've found it. When a contributor encounters a bug in a feature or a typo in the documentation of an open source project, they can create an issue along with the fix, leaving the code cleaner than when they've first encountered it.

I also want to thank the team at Taiko for being welcoming, supportive, and making my first open source contribution a fun experience. Do check out the project if you're interested!

If you've missed it, here's the issue that I've worked on at Taiko and the pull request that solves the issue.

And here's a summary of what I did:

1. Found an open source project:
   • What specific area of tech am I interested in?
   • What are my current skills, or skills I want to improve?
   • What's the tech stack of the open source project?
2. Reviewed contributing guidelines (CONTRIBUTING.md)
3. Looked at good first issues
4. Chose an existing issue, then reviewed the description and comments (if any)
5. Forked and cloned the repo
6. Set up my local environment
7. Worked on and tested the changes
8. Opened a pull request
9. Went through the review process and resolved comments (if any)
10. Pull request got merged!

I won't stop there. I'm excited on the journey ahead and looking forward to be a more consistent open source contributor. One contribution at a time.

Thank you for reading and as always, I'm open to suggestions, feedback, and comments. Also feel free to contact me at my email (jasper.d.gabriel@gmail.com), and I'm available on Twitter, LinkedIn, and GitHub.