My first Open Source contribution.
Last week I made my first open source contribution. Today I am working on my second one.
I wanted to tell you guys about my experience, the problems I ran into, and what I learned from contributing to Open Source software. The goal with this blog/post is to inspire others to do the same.
My Background
I started my FCC journey in March 2016 and acquired my front-end certificate recently. I hold a BSc in Industrial Engineering, so I had some prior programming experience with Matlab/R/LaTeX, but none with Javascript. This gave me advantage in solving the numerical algorithms in FCC curriculum. Anything unrelated to that, I was just as wet behind the ears as the average Joe.
How I got started to contributing
Couple of months ago, I read an article on how to land your first open source contribution, from your browser, in 15 minutes. I surfed the web for something I could contribute to.
I found nothing.
Everything I found was out of my league. From FCC I have learned that when facing a problem which is way over your head, you take a step back, gather more knowledge, then come back to that same problem.
Months passed and I gained more coding knowledge. I felt confident enough to go back to the aforementioned problem. I came across an open source audio player, Zen Audio Player, where you can listen to YouTube videos, without the distracting visuals. They had this issue
It looked simple enough. The presenting player only had one demo song, so I all had to do was to implement a code that would play a random demo from a chosen list. Easy job.
It was not so simple.
The procedure
Writing the code was straightforward, but the whole procedure was not.
Before I started, I had lots of questions on my mind (and still do), i.e. should I ask them to assign me to that issue before I wrote down any code? If so, what would happen if I couldn’t solve it?
I chose to solve the issue without getting assigned to it, that way it would save me the embarrassment of having to tell them I couldn’t do it. I felt that time was not on my side. By chance, someone else could submit their solutions before me.
I started by git clone their repo. Their code was quite easy to understand. The codebase had a very descriptive naming conventions for variables and functions. By putting console.log(foo) here and there I learned how things worked, this made me feel anxious though. What if I forget to remove those console.log commands and accidentally git push it ?
Solving the issue was not a problem, it took me around 1 hour. After that, I started running into problems.
First problem
Before I started, I had no experience with Github other than pushing my own files into my own repos. The flora of commands I used were, git clone, git init, git add ., git commit -m "first commit and git push -u origin master.
I was filled with confidence after solving the issue, I went on to push my changes into the repo.
git add .
git commit -m "Closes 202 Update the demo logic to use a random video every time"
git push -u origin master
ERROR: Permission to zen.audio denied to master. fatal: The remote end hung up unexpectedly
Wait what? I can’t push my files into their repo? What is going on here…
It took my 2 hours of research to figure out how to actually push my changes into their repo. And I’m still confused about the whole process. Basically, I had to create my own fork of the original repo, make changes to my fork, then make a pull request to the original fork. The process looks like this
- Fork the original repo.
-
git cloneyour fork. -
git add <files you changed>,git commit -m "your commit here",git push -u origin masterinto your forked repo. - From the original repo Github page, click New pull request.
- Click compare across forks
- Make it so the original repo is the base fork, and your repo is the head fork.
- Make a nice comment on your changes, preferably why you chose to solve it like this. It should not be necessary to explain your code, the code itself should explain itself.
- Submit and wollah ! You just presented your solution to the issue.
After submitting my changes, I had mixed feelings about this. Joining in on other’s people’s code and contributing to their work felt extremely good. However, I kept on thinking that my code was not good enough and I might get bad a response.
Second problem
While anxiously waiting for a feedback, I noticed something strange on the pull request I made on github website. My code was failing one test out of two.
How could this have happened? It worked perfectly when I tried it out on my browser.
First test - Codeclimate
Turns out that the code was inspected for errors with Codeclimate. By running the command npm test I could see the results of these tests. It showed errors in almost every single line I wrote. By reading the details, I learned that I was not following the projects coding style, instead I followed my own coding style, which wasa total mess. This was easily fixed tough.
Second test - Travis CI
The issue had a bonus criteria, writing a unit test for the new demo functionality. I was determined to skip this part. This was way out of my league. I have had no experience with unit testing before.
I decided open that scary test.js file and see if I could comprehend anything there. What I saw was a enormous amount of functions and commands I’ve never seen before.
I did some research on unit testing, Mocha in particular. The test.js file began to make more and more sense to me. Finally, I wrote my own test on that new demo functionality, but still not quite sure if it made any sense…
First feedback
Couple of hours after doing my first pull request, I got a feedback from the owner. A positive feedback. He started by thanking me for contributing and commented on parts of my code what could be better. The functionality was fine, but the names of variables and functions were not.
I adapted my code more to their code style and pushed it along with the unit test I just made. Shockingly, my unit test code was accepted !
After couple of more pushes with minor fixes I got this feedback
I did it ! My first open source contribution. It didn't take long for them to merge my changes into their repo and update their website with the feature I made.
They were happy with my contribution and invited me to their orginization on Github. Now I’m working on my seconds contribution with them, a little more complicated than the first one.
Conclusions
Overall, this was an amazing experience. The whole process took about 5 hours, not 15 mintes. Coding my solution didn’t take that long. Most of the time I spent doing research on Github’s workflow and Unit testing. But that is the part where I learned the most.
Persistency is the key to success
Many times I was about to give up. Github just seemed so unintuitive to me at first, I must have spent 2 hours figuring out how to make a proper pull request.
Before I even started working on that issue I gave up on the bonus criteria, the unit test part. Luckily, I decided to give it a try. This was way out of my comfort zone. But they say that it’s the best place to grow.
What I learned
-
A decent code style. It is extremely important for the codebase to have a consistent coding style with informative naming. If everyone would contribute with their own style (like I intended), the whole codebase will be messy. The code should be understandable without help from large chunks of comments. Before contributing, I used to name my variables such as
var lol = stuffandfunction doStuff(lol1,lol2). This led to difficulties with writing larger applications, such as the Calculator or Tic-Tac-Toe. I had to write down the logic and flow with a pen and paper to understand my code.
What you gain
Amongst other things, this is what you gain by contributing to open source software.
- Reputation. By contributing to Open Source I gain reputation. This can come in handy when applying for jobs.
- Rewarding. The feeling of someone else using your work is magnificent.
Thank you for reading my post. Now go find yourself some issues to solve ! And if you have any pro tips for me, they would be much appreciated.