My adventures in social coding

At the beginning of 2014 I accepted to work on a project for a friend and since it was a simple presentation site I decided to build it with Jekyll1. (Throughout this post I will add explanations for non technical people as footnotes.) By the time I got started on this project I was kind of spoiled by Rails’ asset pipeline2 functionality which was missing from Jekyll, but I quickly found a plugin which promised to deliver this. Taking a closer look at its GitHub repository I noticed that the original author has not touched it for half a year or so and some of the pull requests3 were pretty straight forward so I decided to fork4 the repository and integrate those changes. Thanks to the magic of git and the Internet, I can “retrace” the timeline of what happened to my fork:

Which he did and from this point forward things sprang into motion: I got motivated to fix the outstanding Rubocop offenses, one of them being to write documentation for the classes and modules of the library. While doing this I actually understood the flow of the code - what it does and how it does it, after 3 years of pretending that I’m a maintainer… But better later than never, right? Another ambition got its resolution when I managed to bump the automated test coverage to 100%, which means that each and every line of the library is covered by tests, the risk of inadvertently breaking something without noticing while adding a new feature or fixing something being minimal. After releasing this version, I remember that I had an uplifting feeling while I was walking around town, looking at people and thinking “heh, you might not know, but I just released an opensource library doing some good for the community”. This was a high point of the euphoria roller coaster that followed.

I then researched a little bit and noticed that there at least two more libraries focused on providing the same thing (an asset pipeline for Jekyll) one of them being minimalist and the other, well, the “everything but the kitchen sink” type. This was a low point, but I soon realized that the library I’m maintaining sits somewhere in between them having a medium amount of features.

A few short days later I’m laying in bed one night and after unsuccessfully waiting for sleep to come I decide to open up my phone and I notice an email. Written by the original author of the library I forked, in which he tells me that he noticed that I continued maintaining it and as he doesn’t have the time, he wants to pass on the baton of the original library to a maintainer. I almost screamed a little. The highest point of the roller coaster - and it kind of stayed here from that point forward.

I got into my pre-Christmas mini vacation and after two or three afternoons of work I integrated the changes of my fork back into the original repository. And now I’m happily smiling as an author on the gem’s page. Another bucket list item checked off.

Footnotes

  1. Jekyll is a tool that generates a site based on a template and some post files which contain the actual content of the pages. It sits somewhere between writing your site by hand in HTML and using a full-blown CMS like WordPress. 

  2. The simple explanation for an asset pipeline is that it takes a bunch of CSS or JS files, pre-processes them, merges them together, minifies the result, etc. The obvious benefit is that instead of multiple requests there will be one request for CSS and one for JavaScript, easing the load on the server and making the page load faster. 

  3. A pull request is a way to propose your changes to a repository of code. Before making their way into the code base these changes have to be accepted by the owner of said repository. 

  4. A fork is a copy of a repository of code. 

Posted in: ruby, technical, work.

comments powered by Disqus

Navigate

Built from: _posts/2017/2017-12-27-my-adventures-in-social-coding.markdown.