2020 was crazy, from UFO videos to missing stars, a possible World War in the first week (Trolls) to a Worldwide pandemic, 2020 told everyone to hold its beer. And subsequently, we had the Worldwide Lockdown, no Colleges (Yippee), Work from Home (Sign me up for that), no Football (Well, that's bad), no Adventures, Trips, Movies, get together (Why 2020, why?) but still I enjoyed it a lot, cause during the early Lockdown I decided to get back into Open Source after a break of nearly two years. It was my first ever 2-month long Hackathon, and I was going crazy. I enjoyed working on a fantastic project under a smart and experienced mentor, the Semester Long Projects SLoP 2020, organized by the Developers Club of Dhirubhai Ambani Institute of Information and Communication Technology, was a memorable experience, with a nail-biting finish I was eventually able to secure the first position. It was a fantastic event, and more than winning, I was more excited to make connections that are still strong. I worked and got to know many people whose names still keep popping up here and there. After that one event, I never looked back, participated in various events, hackathons, and competitions, performing well in some, and even underperformed at times. Open Source made Lockdown a whole lot memorable for me.

Recently GirlScript Summer of Code came along, a vastly popular event organized by a well-respected EdTech organization, The GirlScript foundation. It is a 3-month long event dedicated to Open Source and provides a well-rounded opportunity to beginners who are just taking their first step into Open Source along with the seasonal professionals who are looking to contribute to a well-structured project. Numerous internship opportunities, fantastic prizes, and acclamation are just the tip of the iceberg as GirlScript Summer of Code (usually called GSSoC) guarantees the participants with an expanded network and a rigorous 3-month program full of coding (wow), documentation (hell yeah) and debugging (oh no!). A big shoutout to Harsh Mishra for recommending GSSoC to me and helping me throughout the process as I applied for the Mentor role in GSSoC. After waiting for days full of anticipation, I finally received the e-mail; for the next three months, I was going to be a mentor in GSSoC'21.

But this post is not about my role as a mentor, nor it's about GSSoC as a competition; there are more suitable blogs than this about the event and personals with a better story. This blog is meant for those who are taking their first step in Open Source via GSSoC; I will try my level best to guide you throughout the competition, help you open your first issue and your first Pull Request (I prefer to call it PR) and provide you some easy cheats which won't guarantee you a podium but will undoubtedly help you in enjoying the event to its fullest. The event is yet to pick up its pace (the coding period started on the 8th of March), but with approximately 6000 participants, the hype is definitely real. But don't get me wrong, GSSoC is solely meant to promote Open Source, and OSS means that it is open for everyone, so it doesn't matter if you are a GSSoC participant or not; it doesn't matter whether you have mastered your Tech Stack or not, all that matters is that you have decided to step into Open Source and trust me you are in for a treat. With these words, buckle up everybody, and let's talk about contributing to GSSoC or Open Source in general.

First step in GSSoC'21?

Well, first of all, you need to register in GSSoC, ensure that you perform all the formalities the organizers ask you to fulfill, join the official communication channels, and you are good to go!

How GSSoC works?

How does GSSoC work, you ask? It's quite simple. In layman's terms, multiple people apply to register their project under the banner of GSSoC, the owners (called Project Admins) of the projects that are accepted than are assigned a bunch of mentors (usually 2-3) who are tasked to help the Admins throughout the three months. Participants can contribute to these projects and earn points, and now you know where I am going with this, prizes are distributed based on points earned yadda yadda yadda.

How to choose a project?

Before choosing a project, we need to ask ourselves a few questions:

What languages, tech stack, framework. Am I proficient in? None is also acceptable, to be honest.
What languages, tech stack, framework. I want to learn/master or at least get the hang of it after these three months?

The best part about GSSoC is the number of projects that one can choose from; with nearly 100 projects using various tech stacks to select from, GSSoC has something for everyone. Fond of Web development, multiple projects are using MERN, MEAN, MEVN, ROR stack. Love Machine learning and Deep Learning, there are projects which specifically focus on classification and prediction. Love Python? Do take a look at multiple Flask and Django projects. Willing to master DS and Algo, GSSoC has got you covered. From beginners to advanced, you will for sure find something. You don't the coding and debugging part? How about Documentation? Nearly every project needs that.

So now we know our preferred tech stacks, let's look for projects on the GSSoC official website. As for now, you are allowed to contribute to any project, make a list of all the projects you find interesting, star them (to show your appreciation), and then we can start hunting for issues to solve.

Every Project on GitHub has an Issues section; go to the issues section and go through all the issues which have GSSOC21 label and are not assigned to anybody (it's crucial), while most of the projects prefer to have one person working or assigned to an issue, some projects might not follow this workflow; hence it is always recommended to ask the mentors and admins of the project before working on an issue. After you have found the issue you think you can solve, leave a comment like _ "Hey there, I think I can solve this issue, I will use this scheme, and will probably take this much time, "_ and then wait till the issue is assigned to you, this is important as this is not a race instead of a collaborative event. But wait, I can't find any issue to work on; what should I do now? No problem at all, go through the codebase once, try to find a bug (something that doesn't look right) which can be anything from a Typo to a Glitch fest, or try finding a missing feature (Something that is missing), open an issue for the same, and you are good to go, but remember to wait for the Admins and mentors to go through your issue once.

So finally, the issue has been assigned; the mentor has labeled it as GSSOC21 or similar and also assigned the difficulty level; ask the mentor to put them if the labels are missing. Now what?
Here is where the Best Part start. It's time to get your hands dirty. Now in the subsequent steps, I will tell you how you should make your PR.

The Dirty Work

Forking Projects

Let's start by Forking the Project.

This will create a Local Copy of the Repository on your GitHub Profile.

Cloning

Now we can start with cloning the Repo in our local system. Moreover, it is recommended to keep the reference to the Original Project in upstream.

git clone https://github.com/<your-username>/<repo-name>  
cd <repo-name>  
git remote add upstream https://github.com/<upstream-owner>/<repo-name>

Updating Copy

You might need to update our copy (if you forked earlier and the project had gone through changes); for that, we can use two methods.

Merge (Not preferred)
Rebase (Preferable)

git remote update
git checkout <branch-name>
git rebase upstream/<branch-name>

Branching

Our fork and the local copy are up to date; now it's time to work on the issue assigned to you.
There is a general non-breaking rule, you should never make a PR from the master, although this won't break anything, but it is a general practice and is very helpful if you mess up the commit history, so first of all, let's checkout to a new branch.

# It will create a new branch with the name Branch_Name and switch to that branch 
git checkout -b branch_name

Notice that you checkout to the new branch from the initial branch only.

So, suppose if you were in branch master and checked out to foo and then again used the command to checkout to bar. The branch is made from foo, not master. (Confusing? Never mind, as a general rule of thumb, always ensure to checkout to master using command whenever you are going to work on a new issue).

Working Remotely

Now get your hands dirty, code, edit and debug.

All set? You proofread, right? Do it once more.

Now, let's tell git to track the new files.
Let's start with a git status to check what has changed.

git status

Commit

After you've made changes or made your contribution to the project, add changes to the branch you've just created by:

# To add only a few files to Branch_Name
git add <some files>

# To add all new files to branch Branch_Name  
git add .

To commit, give a descriptive message for the convenience of the reviewer by:

git commit -m "message"

Always write a sensible commit message; it's a good practice and more comfortable for a 3rd person to comprehend.

Push the Commits and Pull Request

You have completed the most challenging part; now, all you need to do is, Push the commits, make a PR sit back, take a deep breath and wait for your mentors to review the PR.

# To push your work to your remote repository
git push -u origin Branch_Name

After pushing the commits, this message will pop up:

Finally, time to make a Pull Request; the process is simple, give a proper title, and explain the changes you have made. This is what your PR should look like.

Remember Fixes #issue_num is very important.

But while you wait, why not start working on a new issue. Follow the same steps for any project, Fork Clone Branch Add Commit Push.

[Note: If you are going to work on a different issue in the same project, do checkout to master before making a new branch].

But what if your mentor is not satisfied? No pressure you have got this, usually, they also tell you some vital information, like what is lacking, what to change.

Checkout to the branch, make those changes, Add, Commit, Push.

Viola, you updated your PR with another commit. Way to go.

This is the general workflow of any GitHub contribution and applies to every project, so while you are at it, look for other organizations and repositories to contribute to, search for good-first-issues they are usually easy and one excellent place to start.

Soon I will make a blog about all programs like GSSoC, which will help you to take part in programs like GSSoC; who knows, you might grab a good result in that event, you can follow me so that you don't miss it.

But before we conclude, we need to discuss something essential. Some essential rules of Open Source which you must abide by because, after all, we are in the same boat and must help each other. Kindly keep these things in mind:

Be Nice, Be Respectful (BNBR)
Check if the issue you created exists or not.
Make good commit messages and document your PR well.
Always add Comments in your code and explain it at points.
Dynamic Input is always preferred over static Driver Code.
Always create a Pull Request from a Branch; Never from the master.
Follow proper Code conventions. Using i',j` in Loops shows a poor understanding of Code Quality. Use appropriate Variable, Function Names.
Code would be reviewed by Mentors before they are merged. Every good PR requires Reviews.

That's all, folks.

Thank you so much for sticking with me till here. All the images used are of the Project Rotten-Scripts. I am one of the mentors of the project and would love to have you over there as well. Feel free to hang around, open an issue, maybe. There are many such awesome projects in GSSoC. Like I have said already, start contributing ASAP.

Liked what you read? I have restarted blogging after a long time; I talk about multiple stuff (Football, Anime, IoT, Music, Human Emotions, to name a few). You can follow me on my socials if you want.

Let connect; I love to get in touch with people who have a similar mindset, my LinkedIn.
For exclusive Tech Posts, check my Dev Profile.
Go through my GitHub, you might find something interesting.

All the images have been taken from Rotten-Scripts.

Vybhav Chaturvedi, Over and Out.