My First Open Source Contribution - A Complete Guide to Open Source Contribution

January 14, 2024

Greetings, fellow code enthusiasts!

My First Open Source Adventure - Let's Dive In! 🚀

Hey tech pals! Happy new year! Wishing you all a fantastic coding journey ahead.

I've been buzzing around the Angular community, fascinated by this framework that's become my programming crush. This winter break, I made a few resolutions, and one of them was to try my hand at open-source contribution in the Angular world. I rolled up my sleeves, took a deep breath, and embarked on my open-source journey. Drumroll, please! 🥁

Here's a quick guide to my open source contribution:

Step 1: Pick Your Adventure

Choosing what to do in open source. You've got options, and each one leads to a different kind of excitement. Here are a few adventure paths:

1.1 Bug Hunter 🐞 Dive into the project's issues, find those sneaky bugs, and fix them.
1.2 Feature Explorer ✨ Maybe you have a cool idea or want to add something new to the project. Being a feature explorer allows you to bring fresh concepts to the project.
1.3 Doc Wizard 📚 For those who love clarity and helping others, becoming a doc wizard might be your path. Improve documentation, fix typos, and make it easier for everyone to understand the project.
1.4 All of the Above! 🌐 Can't decide? No worries! Many open-source contributors wear multiple hats. You can switch between bug hunting, exploring features, and improving docs based on your mood and the project's needs.

Step 2: Hunt for a Project 🕵️‍♂️

Finding the right project is like going on a blind date. You're excited, a bit nervous, and you hope it's worth your time. Check out your past projects dependency list or use GitHub to find projects that match your skills. Look for projects with friendly communities and a good balance of activity.

Step 3: Explore the Project 🔍

Scan the repo very well. Every single file in the repo has a meaning to it. These files are usually listed in the top level of a repository.

LICENSE By definition, every open source project must have an open source license. If the project does not have a license, it is not open source.
README The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
CONTRIBUTING Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
CODE_OF_CONDUCT The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
Other documentation There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like Astro Docs.

Step 4: Fork, Set Up, and Go! 🔄

Fork the repository and then clone the forked version (essentially replicating the repository into your GitHub account to make changes there).

By this point, you should have already determined how you want to contribute. Let me share my specific contribution as an example. While exploring the repository's issues tab, I stumbled upon an intriguing bug:

Issue: Accordian: TextArea Shortcuts Not Working in Accordian Panels

Description: When TextArea components are utilized within accordion panels, and the focus is within the text area content, traditional keyboard shortcuts like Shift+Home, Shift+End for highlighting text, and Home, End for moving within the text area, do not function as expected. Instead, the focus moves to the next accordion panel. When the focus is within the text area, text-area shortcuts should take precedence. Interestingly, these shortcuts work seamlessly when the text area is outside of the accordion.

Upon analyzing this issue, it struck me because the conventional behavior of HTML components should inherently handle this scenario. Intrigued, I decided to take on this challenge, ensuring no one else was already addressing it.

Step 5: Understand the Code 💻

Understanding the codebase is key, and how deep you dive depends on what you're fixing. In my case, dealing with a bug, I quickly looked through how the project is organized and got a feel for how the code flows. Once I got the hang of it, finding where the bug was hiding became a breeze.

Here's a breakdown:

5.1 Check Out the Code Structure 📊 Take a good look at how the code is organized. Find the important bits like components, modules, and how they all fit together.
5.2 See the Code Flow 🔄 Picture how the code moves around, how data and control travel. Drawing diagrams or flowcharts might sound nerdy but can be really helpful.
5.3 Play with Debugging Tools 🛠️ Use debugging tools to step through the code.
5.4 Time Travel with Version Control 📜 Take a trip back in time through the version control history.
5.5 Read Any Documentation 📚 Check if there's any project documentation. Understanding why certain choices were made can really light up the path.

After this walkthrough, finding the bug's hiding spot wasn't rocket science. This step isn't just about fixing the bug; it's about making friends with the code, figuring out its secrets, and setting yourself up to make a solid contribution.

Step 6: Get the Project Running Locally 🛠️

Setting up the project on your computer is a must-do. Fixing a bug without testing it locally is like baking a cake without tasting the batter – it might not turn out well. While some projects make this step sound like climbing Mount Everest, you can find guidance in files like README.md, CONTRIBUTING.md, or DEVELOPER.md. These files are your compass, pointing you in the right direction to run the project on your own machine.

Don't be the lazy coder; follow the steps in the given order.

Step 7: Connect Your Code Spaces 🌐

Now that you have the project running locally and identified the areas to fix, the next crucial step is connecting your code spaces. This involves setting the upstream repository and creating a new branch.

Here's what you need to do:

Establish Upstream Connection The upstream repository should always point to the original project's GitHub repository. This ensures that your code aligns with the latest updates and changes in the project.

git remote add upstream <link-to-original-repository>

Define Your Origin and create a new branch On the other hand, your origin should point to the forked repository on your GitHub account. This is where you'll create a new branch and make and save changes before pushing them back to the project.

Ensure your upstream is synchronized with the original project, while your origin anchors your changes in your GitHub space. Now you're ready to share your coding contributions.

Dive into the code and make the necessary changes, whether it's fixing a bug or introducing a cool feature. Ensure your modifications align with the project's guidelines.

Pay close attention to the commit message instructions. Bots are strict about commit message formatting, so craft a well-structured message. It increases the chances of your Pull Request (PR) being accepted.

Once you've pushed the changes to your branch, head to GitHub. Navigate to the forked repository in your profile. Now, switch to the newly created branch where you've pushed your changes. Here, you'll spot a 'Contribute' button; give it a click and then hit the 'Open Pull Request' button.

This magical moment opens your Pull Request (PR), and all that's left to do is wait and watch, fingers crossed, hoping for that coveted merge. If the PR reviewers request changes, no sweat. Simply complete those tweaks, follow the steps mentioned above, and you're back in the game.

Consider this step as the climax of your coding saga – you've made your move, and now it's time for the community to weigh in on your coding masterpiece. Best of luck! 🌟

Reference: Open Source Guide

first open-source