- My work experience during Release 0.1
- The issue filed
- The pull request created
- The pull request I reviewed
- The upgrades after my pull request got reviewed
- Discussion about community involvement
This blog post is about my work on first release of the DPS 909 course. It was a great learning experience as I learned many new things about Git, GitHub and Node.js. For this release I found a new issue in Filer, and came up with a working fix to it. First I had to create a new issue, fork and clone the Filer. Then I had to fix the code and push it to the branch, finally creating a pull request.
This task was a bit challenging for the first time and I got stuck at many different parts. But I also learned many things such as:
- installing and running Git on Mac.
- working with issues.
- forking and cloning a repository from GitHub.
- working with branches.
- testing Filer code.
- creating and working with pull requests.
- reviewing code written by other people.
Through this experience, I have realized that before working on my next GitHub issue, I will first revise through the steps. This will help me to avoid any confusions about what are the correct steps to follow in the procedure of contributing to any GitHub repository.
There were no test added for new fsPromises API.
I worked on adding a test for
fs.Promises.truncate(path[,len]) to test if the length is negative. This was issue #418.
It was fairly easy to find the issue rather than actually fixing it. Thanks to the open source community and my professor David Humphrey, that I got advised about the errors I was getting.
I added the working fix to my branch and created a pull request. But later while discussing the code with my classmates, I realized that my fix was not the best way to approach the problem. I will discuss that later in the blog.
The structure for Promises is different than other file system methods. I used a
.then() contained the working code that would run of the conditions are satisfied. The
.catch() contained the error handling code.
Review of another pull request
After creating the pull request for my work, I reviewed a pull request by another classmate. His fix added a test for
fs.promises.stat() to check when the path does not exist.
His code was in perfect working condition and passed the Travis CI build. However, he had similar issues as mine. When calling the
function(done) , we don’t use
done in Promises API.
Upgrades after my pull request review
I was waiting for this moment, but it did not happen. Yes! I did not get any review or feedback from anyone. So I took the initiative and asked my professor and couple of other classmates for the feedback. I came to know that my code is not as efficient as it can be. So I added second commit to GitHub with the changes. I had unnecessary code to catch the errors.
During this release, I quickly realized that community involvement is a blessing while working with open source projects. I was stuck with wrong approach towards
.catch(). But with the help of Slack , I was able to get good feedback about my errors in a very short span of time.
Moreover, as I was asking my questions on the group, another user named Huda Al Dallal (Huda_a), messaged me. She was having similar doubts as mine. I advised her to the best of my ability and cleared her confusion.
It feels great to be a part of this wonderful open source community where one moment I took help from someone, and later I was of help to someone else.