Monday, March 3, 2014

Bug Fix Assignment or: How I Learned to Stop Worrying and Contribute Back to the Community

The first time I contributed to an open source project on Github was during my co-op at Workinman. We needed a Haxe video player that can be compiled to both HTML and Flash. It was something new and I consulted the holy prophet of Google for guidance, who lead me to JarisPlayer. I encountered an issue, found a way around it, changed 5 lines of code, and made my first pull request! Initially I only posted the solution inside the issue, and the developer of JarisPlayer told me to do it correctly by providing a pull request. Thinking back, that was a highlight during my co-op. 

The bug fix this time probably took less time, but it felt a lot harder. 
Initially, I planned to find a bug by using the open-source Leap Motion Library for Processing for one of my data visualization project (NOTE TO SELF: Write a post about that later.) Be it fortunate or unfortunate, I did not encounter any problems. So I went to the Github Page for the library, and it does not have an issue tracker! With one hope squashed and eight left, I decided to work on fixing bugs for an image/video slider I'm using, called bxSlider. I use in the portfolio site for my designer friend Jack Wilson</selflessplug>, and even though bxSlider is the fourth most used sliders on the web, I encountered many problems with it. The project was well-maintained-not, the last commit made 6 months ago and the number of issues stacking to an alarming 266. I found out that I'm not the only one experiencing these bugs (whew), and there's people that already figured out a solution for some of them. Their solution however was only implemented in their branches, quoted in their issue discussions, without a pull request pointing back to the main repo. (46 pull requests) So I wrote two commits fixing one bug I found and implementing one of their solutions to a bug I'm encountering, and did it the right way - Pull Request and issue.

Links:
My pull request
Their discussion and fix

What I learned:

  • If the tool I'm using is open-source and I encountered problems, BE SURE to check out the discussions around it! This would've saved much time when I used it to build the site.
  • Fixing something that matters to me is so much better than just working on something irrelevant. In fact, I don't think I will ever do the latter. Bug squashing is often the most exhausting part in programming.
  • Github's collaborative coding environment is excellent. I put the URL of a developer's fix I'm implementing into my commit and my pull request, and these two activities showed up on that developer's issue! Similar things happened at my URL quote - Github replaced them with more descriptive hyperlinks.


Here's to hope these fixes get noticed by the maintainers!

No comments:

Post a Comment