How I did my first opensource contribution and so can you?
Tags: javascript, opensource, frontend
Published: 2023-11-22 07:02:17

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
4. 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:-

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cff3nl6xt5li0mky111w.png)

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)](https://gitlab.com/gitlab-org/gitlab/-/issues/427429) 
  [(MR)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135386)
2. VSA table: Change the default sort by to 'Duration time' : [(Issue)](https://gitlab.com/gitlab-org/gitlab/-/issues/428200) 
  [(MR)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135694)
3. VSA table: Change the default sort by to 'Duration time' : [(Issue)](https://gitlab.com/gitlab-org/gitlab/-/issues/384964) 
  [(MR)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/136602)
4. VSA table: Change the default sort by to 'Duration time' : [(Issue)](https://gitlab.com/gitlab-org/gitlab/-/issues/429984) 
  [(MR)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/136625)
5. VSA table: Change the default sort by to 'Duration time' : [(Issue)](https://gitlab.com/gitlab-org/gitlab/-/issues/423753) 
  [(MR)](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135891)

## 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:-

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3y9owdoxsqmf0dqqpul4.png)_Focus on the last pipeline failed: Test coverage was insufficient_

4. 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.
5. 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."