Open Source Contribution - Release 0.1

Contributing to Filer (File System Interface for Node.js)

Over the last couple of weeks I've enhanced my ability of using Git and Github as well as learning the workflow of open source development. I achieved this through making my first open source contribution to Filer, an open source project located on Github.

Link to Filer: https://github.com/filerjs/filer

I started my contribution with filing an issue, in which I stated what I wanted to contribute to the project. Once the issue was reviewed by the moderator of the project, it was assigned to me. Once assigned, I started working on a solution that will add unit testing for a functionality of Filer. After finalizing the code, I was ready to do a pull request in order for moderators and the open source community to review my code and suggest improvements. Once my pull request was successfully submitted, I received encouragement that what I did was not useless and some constructive criticism to improve the readability of my code. The process that seemed hard to me at the first glance all of a sudden became manageable and extremely fun. It was exciting for me to see that I can actually contribute to real world problems without necessarily being hired by a company. Following this paragraph, I will describe the specifics of my contribution.

Getting Started

When thinking of contributing to an open source project, the first thing you should do is review the documentation and code that belongs to that project. Once you're familiar with the environment of the project and understand the functionality, you can now brainstorm on some functionalities that can be added to improve the product. At first, it might be hard to come up with sizeable functionalities, so you should start with something small, like creating unit testing for existing functionalities. Check what unit tests already exist in the project and come up with one that nobody created yet. This is the process that I followed when tackling how to get started on my contribution and it worked rather well for me, and I will use this process again and again when contributing to future projects. After you've figured out what you'll be working on, you need to file an issue.

Filing an Issue

When filing an issue there are a few things to consider and include in the description:

• Include a short description of the method or bug fix that you're going to write
• Keep the method you're planning to write short and focused on one problem
• Show a snippet of code to demonstrate the behaviour you are trying to test or the functionality you're trying to add
• Include a request statement, indicating that you'd like to work on this issue

An example of an issue that I created for Filer can be found here:

https://github.com/filerjs/filer/issues/398

Once a moderator reviews the issue, it will be assigned to you and you can start working on the code. I created tests for fs.promises.readFile() and fs.promises.writeFile(). There was existing testing to fs.readFile() and fs.writeFile(), however Filer did not include any testing for the support of promises, which was a recent feature added to Filer. I made sure that no issues were filed to create such tests and began my work to create my first open source contribution. 

Creating a Pull Request

After finishing the code and ensuring that the unit tests that I added passed and worked as expected, I created a pull request to request moderators of Filer to merge my code into Filer. In the pull request, I specified that I rewrote all test cases in the fs.writeFile-readFile.spec.js file to work with promises, testing that integration of promises into the readFile and writeFile methods works as expected. In addition, I also checked that fs.promises.readFile() and fs.promises.writeFile() methods return a promise as expected.

An example of a pull request I created for Filer can be found here:

https://github.com/filerjs/filer/pull/402

Checking Reviews on Your Pull Request

Since it was my first ever contribution to open source, I was eager to see how I did and what can be improved. So I asked my professor, who is also a moderator for the Filer project to review my code and tell me what can be improved. He left a comment on my pull request reassuring me that what I did was great, which was very encouraging and made me want to contribute more. Furthermore, my professor included some constructive criticism to improve the readability of my code. Right away I went into the code and fixed the readability because I know how important it is for code to be readable in open source, since so many people view it and need to understand it. Once the readability was fixed, I committed again, adding onto my pull request.

It is important to read the reviews on your issues and pull requests to ensure your success in an open source world. The open source community is always eager to help others in order to successfully create projects together as a community.

Review Other Pull Requests and Community Involvement

It is also important to contribute to the open source community. Once you receive help, you should also return the favour to others that need help and need constructive criticism on their pull requests. The community becomes strong when we help and encourage each other.

I reviewed JoshuaRM's pull request on GitHub because I noticed that he made the same mistake as me. Firstly, his code was nicely created and everything worked, which I commended in my review. However, there was one thing that needed to change. JoshuaRM included "error" object into the "then" statement, which will never get passed there. I pointed this out in my review and suggested to put the "error" object into the "catch" statement.

The link to JoshuaRM's pull request where my review can be found:

https://github.com/filerjs/filer/pull/401


Furthermore, over the last two weeks me and JoshuaRM worked together and helped each other to learn the principles of open source development. It is crucial to work with others when you first get into open source, because sometimes you can get lost and overwhelmed with big open source projects. Whenever Joshua needed help, I helped him, and whenever I needed help, he returned the favour. It was this community involvement approach that helped both of us learn the lessons we needed about open source. Furthermore, getting your code reviewed by the community will only improve your coding ability and workflow, so take advantage of this to get better and return the favour by making others better.

Conclusion

Don't be scared to start contributing to open source. Although many beginner software developers and students often think that they are not good enough to start contributing to open source, it is simply not true. For your first contribution start small, get used to the environment and move on to harder tasks once you're accustomed to principals of open source, and get to know some people from the community that can help you. I was worried that I would fail at first too, but once I started doing the work and believed in myself, I had no problem creating my first contribution to open source.