Open-Source Contribution

My Contributions

This week, we continued developing our command line tool. I wrote an extensive post about it last week. Instead of developing our own code, we were tasked with making contributions to another open-source repository from our class. I chose a project in JavaScript because I have more experience with it, and I felt like it would be easier to make contributions. So, Tiller is the app I chose.

Adding Features to Tiller

The first step was to create an issue for the developer and provide a preliminary list of changes I planned to make. I also reached out to them on Slack to inform them about it. After receiving their approval, I forked their repository and cloned the fork locally on my machine. Next, I created a new branch corresponding to the issue number I had just created.

My plan was to add markdown support for their tool as well as italics syntax in markdown files. The first step was to modify the app to accept .md files in addition to .txt files. Then, I introduced a new function to handle markdown processing:

const convertMarkdownFile = async (input) => {
    const fileContents = fs.readFileSync(input, 'utf8');
    const paragraphs = fileContents.split(/\n{2,}/).map(p => p.trim());
    return paragraphs;
}

This function would later be removed at the request of the author, but since I had mentioned this in the list of changes in the created issue and received their approval, I proceeded with committing these changes and creating the Pull Request.

Creating a Pull Request

After creating the PR, I reached out to them once again on Slack to notify them. I received a few comments on my code after their review. The most important one was not to create a separate function for markdown file processing but to incorporate the logic into the existing code. I made the necessary changes to the code, committed and pushed them for their review. At this point, they still requested a few minor changes to be made to the code before giving their full approval and merging the changes into their main branch.

Challenges

The main challenge in contributing to another project was maintaining consistency with their coding style and making minimal changes to the existing code. However, this challenge was easily mitigated by communicating with the author. In the future, I will make a better effort to gain a better understanding of the author's expectations to avoid redoing or undoing some of the work.

Contributions to Learn2Blog

This week, one of my peers also made some contributions to my own project. The process was similar to the one I described above. They created their issue first, made their changes, and finally created a PR. It was an interesting experience reviewing their code and seeing the different approaches they came up with. However, I did leave them feedback to change their code. They had proposed creating a new class to handle Markdown files. This resulted in some code being copied and not reused. Additionally, their code logic had some redundancies, which I pointed out in the PR. After a few back-and-forth conversations, we were able to merge the changes with my approval into the main branch.

This developer also found two other issues in my code that were not part of their contributions, but they pointed them out to me. So, I asked them to create issues on the repository for me to address later.

Summary

The most valuable lesson I learned this week is that an open-source project is never truly finished. Software will always have bugs and issues that need to be addressed continuously.

Additionally, I practiced staying focused on a single task instead of jumping around the code trying to fix everything all at once. This is definitely a bad habit that I have developed over time. Perhaps, it would help me to keep track of issues as I discover them, but practice not losing focus on the task at hand so I can come back to other issues at a later time.