Contributions are fun, but not easy!
Tags: opensource, collaboration, coding, discuss
Published: 2023-09-23 05:51:38

If you're thinking about making contributions to other people's projects, get ready for the grind 🐱‍💻.
This week, I had one of my very first experiences contributing to someone else's repository as part of my school's open source course curriculum. Its not like I haven't opened a PR before in life. I have worked on both personal and hackathon projects (for example -> [UI](https://github.com/Amnish04/SugaryPills.UI), [API](https://github.com/Amnish04/SugaryPills.Backend)) with my friends and we had to contribute to each other's repos to work as a team.

But this time, it was a little different as I had to go through a procedure that is similar to how it is done in the real world. This lab was built on top of [release 0.1](https://github.com/Amnish04/til-page-builder) of the project we finished last week. The purpose was to find a classmate's repository to work on, and contribute a brand new feature to the existing project. The whole experience from finding a partner to successfully making the contribution was a series of steps, that had to be taken one at a time.

## Finding a project 📂

I know you are expecting this to be the easiest part, and that's a rational thought. Why wouldn't I find a project if everyone in the class has one, right? 
**No Sir!**

### The crisis

This thought almost got me in trouble. Sure, I found someone who agreed to let me contribute to their project the first day of week. But when I actually sat down to coding a couple of days later, I saw that someone else had already merged a pull request for the feature I was planning to contribute, yayy 🥳.
Alright, on a serious note, I couldn't believe what I saw. All that time, I was under the false impression that if someone agreed to let me contribute, they'll keep waiting for me.
But the **good part** is it gave me a pretty valuable lesson early on in my open source journey. 

Let me quote:

> If you're not doing it now, someone else will do it b’for you.

### Recovery

Open source is like a race. Everyone wants to get that PR merged, and I can imagine how crazy this competition would be in the real world. Lucky I get these lessons at the right time 😌.

Fortunately, I was able to find another repo to work on within **18** hours, when it was time to move to the next step!

## Forking and Setting up the project 🍴

After I opened the [markdown support issue](https://github.com/avelynhc/til_tracker/issues/8) for the new project, I quicky [forked](https://github.com/Amnish04/til_tracker) the repo and started reading the documentation to set it up.

Within the first 15 minutes of reviewing the project, I found several other issues other than what I was originally planning to fix:
1. [Missing tsconfig.json](https://github.com/avelynhc/til_tracker/issues/12)
2. [Issue with installation instructions](https://github.com/avelynhc/til_tracker/issues/9)
3. [Bug with stylesheet](https://github.com/avelynhc/til_tracker/issues/10)

I was able to open pull requests for 2 of these, 1 got [merged](https://github.com/avelynhc/til_tracker/pull/14)), the other is still under [discussion](https://github.com/avelynhc/til_tracker/pull/11).

Anyhow, before I started working on the last issue, I had to first work on adding the **markdown support**, which was the actual **meat of the matter**.

## Coding Time 🚀

The exisiting tool was able to process a `text` file and generate an `html` file out of it with not much features. The objective was to extend its functionality by adding support for markdown files with `.md` extenstion, and add at least one markdown parsing feature.

### Examining

I started by examining the architecture of the program, and studying the coding style of the author. It took me a while, but I quickly came up with the structure I would follow to add the new functionality.
I chose a feature that would parse the lines starting with `# ` like tokens as headings in `html`.

### Implementation 
The following enum helped me define the tokens:

```ts
// Markdown Tokens
enum MarkdownTokens {
    H1 = '# ',
    H2 = '## ',
    H3 = '### ',
    H4 = '#### ',
    H5 = '##### ',
    H6 = '###### ',
}
```

I tried my best to keep the code as modularized and elegant as possible.
All the changes eventually led to the following file structure:

![New file structure](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y1lr4g9i3xhdb76pch4v.png)

For more details, feel free to visit my [repo](https://github.com/Amnish04/til_tracker/tree/issue-8).


## The big moment 🥁

After I finished testing my code locally with all kinds of inputs possible, it was time to finally create the [pull request](https://github.com/avelynhc/til_tracker/pull/19). There were some **merge conflics**, but I fixed them quickly as I have a lot of experience with those from my coop.

Again, I thought this was going to be a smooth merge. But when working with someone else, conflicts are bound to happen.
The author wanted some things to be done in a different way and we had a long converstion, which is still ongoing. I am hoping to come to a consensus soon. Once that is done, the code should be merged to the repository.

### PR Conversation (Update)

After a long conversation on the [pull request](https://github.com/avelynhc/til_tracker/pull/19) I opened, we decided to switch back to the old directory structure as the author preferred a more simplistic approach to files were organized.

![Reverted file structure](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dzzfa6oxx5mfp69pbxkv.png)


I was also urged to use regular expressions instead of using the enum, as the `regexp` approach was more dynamic.

In order to align with author's preferences, I had to push another [commit](https://github.com/avelynhc/til_tracker/pull/19/commits/2784b07d56689fa074bea9d42112837f6d271c6d) on my [branch](https://github.com/Amnish04/til_tracker/tree/issue-8).

It took a little more convincing after that, before my PR was finally merged into the author's [repository](https://github.com/avelynhc/til_tracker/tree/main) 😮‍💨.

And that my friends, is the story of my very first formal open source contribution (although not real real 😉).

## Contribution to my repo 🤩

A couple of days after I finished working on my own pull request, someone opened an [issue](https://github.com/Amnish04/til-page-builder/issues/6) on my project asking if they could contribute to it in a similar way. I immediately agreed to the request and posted some general guidelines to follow while coding the feature.


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

There wasn't much for me to do in this process, except reviewing the [Pull Request](https://github.com/Amnish04/til-page-builder/pull/7) my friend opened on my repo, and adding comments for some issues I found in his changes.

The best part was that the contributor sent me a private message on Slack thanking me to allow his contribution:

![Private message from contributor](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g2c52qbuw20kfo1ieaur.png)

I was glad my project helped someone learn new things 🙃 

## Learnings 📚

Here comes the most important section as the whole point of doing any kind of  activity is  learning something from it.
I certainly did learn lots of stuff.

Contributing to projects you don't own is a **time-consuming** process. Apart from coding your implementation/fix, you have to go back and forth with the owner to make sure they like whatever you did. You have to respect others' time and efficiently manage yours, so slacking is never an option.

Let me quote again:

> Open source is a drag race where everyone wants to win. **Start early** and be the first one, or **never finish**.