How I did my first opensource contribution and so can you?

It was 3 months since I left my job as a frontend developer and during the process of job hunt, A new fear crept into my head : 

1. It's been a long time since I last had hands-on practice making changes in large company repositories, risking the loss of real industry experience.

2.Debugging code in a big repository with a substantial codebase and fixing it

The best option for overcoming this fear was either to get a job ASAP 😝 or opensource contribution till you get one (a job).
I started with the latter one. Went through many projects like Github, Apache, Gitlab, etc.

I decided to contribute to Gitlab as, it has very nice and detailed documentation and articles about the process of open source contribution, how to set up GDK (Gitlab Development Kit)in local, even about the commit messages, MR procedure, etc.

Areas where I faced issues:

I use Windows, but the local setup (cloning the repository and running the service in local) has to be done in Linux. So installed Linux OS as well, and cloned the repo but didn't work.

Solution 💡

GitLab has its own vscode. Hence every time I work on any issue assigned to me, I proceed with the following steps:
1.) login to Gitpod.
2.) Go to Developing GitLab with GDK on Gitpod (here). From here
you'll get the username and password (you can change it
later).
3.) Gitlab vscode will get open and in the terminal :

Some useful commands : 

1. gdk start (to start gitlab developement kit)
2. gdk doctor (run this command if the service is not up even after gdk start )

Then I used to get some suggestions like  :

1. bundle install (bundle file is a single, relocatable file that contains all the artifacts , needed to run your application)
2. bundle fund
3. Then we can access the service as https://local.host/3000/ Note: UI will not immediately reflect , It will take some time from 30 sec to 2 minutes and page will automatically refresh after every 5 seconds:-

After the local setup is done, I extensively focussed on searching, filtering, and grabbing the issues based on my tech stack.
Some of the tickets and their merge requests (MR) successfully deployed to production:-

1. VSA table: Change the default sort by to 'Duration time' : (Issue) (MR)
2. VSA table: Change the default sort by to 'Duration time' : (Issue) (MR)
3. VSA table: Change the default sort by to 'Duration time' : (Issue) (MR)
4. VSA table: Change the default sort by to 'Duration time' : (Issue) (MR)
5. VSA table: Change the default sort by to 'Duration time' : (Issue) (MR)

Some Learnings :

1. Gained confidence in my skills by actively making code changes in the company's codebase.
2. Experienced (SDE-2 / SDE-3) frontend developers as well as the UX folks were added as reviewers who used to review my code. Got to interact with them. All were very supportive and helpful, providing the implementation guidelines. And there used to be a thread of comments where we discussed till the assigned issue was crystal clear to me.
3. Faced the main challenge was with writing the test cases:-

Focus on the last pipeline failed: Test coverage was insufficient

1. Need to be very specific and stick to commit message guidelines as it is one of the reasons for the pipeline to fail apart from test cases.
2. Role of "prettier": Even if the code has no error (logical, syntactical or runtime). It will not allow to push the code. Reason being the formatting. Hence use npx prettier - - write fileName. It will do the required formatting in the respective file, the we can go ahead with the commit and push process.

Conclusion:

The question lingered: Is it worth it?

From setting up the service, reading articles, and navigating documents throughout the process, to handling my first ticket. Progressing not just in receiving the ticket, but also in debugging it in a large repository, identifying pages in the UI, solving the issue, and creating a Merge Request (MR) with recorded changes - comparing before and after. From writing test cases to ensuring a pipeline with all green ticks, to assigning a senior reviewer and interacting until the issue was crystal clear, leading to approval and merging of my MR into the master branch.
Moving from having one MR merged within 24 hours to having multiple MRs merged and achieving the status of a level 2 contributor in Gitlab. I must say, "Yes, it is worth it."