After developing several projects using different tech stacks, I was curious to know how the "real" world production-grade projects work.

How do tons of teams collaborate on a live project? Wondered how production grade code was written. How the projects were scaled to handle millions of users. Obviously the code I deployed wasn't written to be scalable or even structured in a way that followed production-grade standards.

So how do I improve my code? Know how huge projects in the real world function?

Yep. GitHub was side-eyeing me, noticed that.

Until then I had just used GitHub to take "backups" of my personal projects, not even as a versioning tool. Browsing some OSS repos, I noticed various sections like Issues, Discussions, Pull Requests, etc. I wanted to experience how all these things work.

Decided to try contributing.

💡 Don't hesitate to follow along!

The Prologue

I was searching for a repository where I could solve an issue relatively easily. Still getting to know the in and outs of GitHub, skimmed through various websites that show projects with good first issues.

• GoodFirstIssue.dev
• GSOCOrganisations.dev
• UpForGrabs

💡 Here's an awesome resource I found later, that dynamically curates open source projects in the tech stacks you are interested: OpenSauced

After a couple of days learning about these projects, It felt like I was peeping into an ocean with no clear depths. Humongous. The path that lead to the depths was visible but without the training & tools, the waters were still out of reach.

Soon after, I found out about this repo: FirstContributions

git clone "url you just copied"

I felt relieved.

It was exactly what I had been searching for. The first tool to get my feet wet.

Testing The Waters

The FirstContributions repo has a terrific README.md (generally where the details of the project are). It is written and illustrated very intricately with utmost beginner friendly instructions, as if helping a baby walk it's first steps.

I won't list all the instructions here to make the contribution. The repo has a terrific Readme, remember? ;)

I followed the instructions precisely. The task was straight to the point. Had to add my name to the list of contributors, which was a Markdown (.md) file. Easy, eh?

After opening the code, I chose the position where I wanted my name to appear and placed it there. Looking at other's entries they had hyperlinked their GitHub profile links to their names. Markdown file magic.

Did the same.

It felt too easy.

I needed something more. After all I'm contributing to open source, I need to make meaningful contributions to the repo. I decided to fix other people's entries that didn't have the correct syntax to be eligible as hyperlink for the Markdown file.

Little did I know, I wasn't just fixing issues but creating one for me.

I went overboard here. Do not make multiple changes on the FirstContributions repo.

The Pull Request

It was time.

Time to make a pull request (a request to the master repository to merge my code changes). Had made several changes (50+ changes), some deletions (spaces), some refactoring. Drafted a detailed message for the pull request's description by stating the fixes for the Markdown syntax.

and... it was submitted. My first PR. (even if it was just markdown).

The Github CI/CD actions had spun up (automated actions on your code/PR which involves checks). I opened the actions in a new tab and watched as it progressed.

If you just added your name and did everything correctly, your PR should get automatically merged. The last step of the CI/CD actions merges the PR.

Failed.

What? Failed? I went to the details of that step and noticed the function through which my PR had failed, was checking the number of changes made in the PR before auto-merging.

Great. Of course. It had to check.

A Ray of Hope

Making a single change, easy eh? Wondered if I should make another PR with a simple change or try fixing the current one.

Easy choice. The latter option.

I wrote a follow-up message on my PR thread among others in the sea of hundreds. Hoping to get noticed by the maintainers to accept my fixes manually.

No one answered. I hoped harder. As the sun shone it's bright rays the next day, I had found it.

A ray of hope.

I was fortunate enough to be replied by a fellow contributor @Esh07. You can view the thread here. The gist of it being, I should open another PR. He told me to re-fork the repo and do the process again, probably 'cuz I was a noob unable to sync with remote, rebase and merging with branches.

I had 2 options here. Either deleting the local setup, starting fresh ... or do things like syncing remote with local, merging and pushing it again.

Easy choice indeed. Latter option.

The Hunt

I scraped through blogs and forums for a quick guide on how to update my local repo with the latest changes from the remote repository.

💡 It is important to know that the local Git repository and the remote repository on GitHub are two different things. Committing locally on the project (git commit) does not update the remote repo on GitHub (before using git push) and other people pushing their changes on the remote doesn't get synced with our "local" version of the code automatically.

And the lesson learnt? A well written documentation is all you need.

GitHub has an excellent doc on Syncing a Fork.

First task down, one more to go. Creating a new PR.

The Pull Request: Second One.

I created another branch in my synced repo. This time I made sure that exactly 1 change was made: Adding my name and rushed to make a pull request for it.

In the new pull request, I documented everything that had been fixed since the issues encountered in the last PR, my appreciation towards @Esh07's help and the opportunity to have learnt all the amazing things Git and GitHub provide.

Here's the PR that got merged.

The Epilogue

And here I was. One step towards understanding how a usual project collaboration cycle is like.

fast_forward(today);

After pushing major features on OSS, I've learnt it's not about getting in a pull request or making contributions just for the sake of it but about learning from the process and to network/build with people globally.

May that be reading/understanding how the code works, getting to know how the SDLC works, how teams work together to solve issues, etc. just observing and actively being part of the community to genuinely improve the project can play wonders.

Thank you!
Here's a sunflower 🌻 for you having read this far!

Alright. Off I go.

Eager to know more, like creating your own open-source projects? Here's an ultimate-everything-guide: opensource.guide