Having recently started work at AgencyND, I have stepped into working on a Content Management System (CMS) that was built in house. I have jumped right in and started enhancing our CMS, largely due to the fact that the CMS is built using Rails, a framework that I’ve been working with for 3 1/2 years. Another tremendous boon for our CMS is the wonderful community at Github. Rails is built on Ruby and has a tremendous community of libraries in the form of gems). Some gems are better than others; Some gems work for their given use case, but need some attention to work for our case. Thankfully, in an open-source community, I am able to make the changes that I need; Enter the fork.
Forking a git-based repository that is hosted on Github is ridiculously easy. In essence I make a copy of the other person’s repository and make the changes that I need. If needs be, I can leave it at that; however, that sells my update short. Via Github, I can notify the original owner that I have some changes that they can pull from me. They can choose to ignore me, or review my changes and see if they are worth incorporating into their code-base.
There are lots of decisions that go into whether or not to accept and incorporate my changes. First, does the change dramatically affect the API of the code. This is a deal breaker. If the original gem only accepts squares, then I better not change the API to only accept circles. Second, does the change come with a test suite? This is also a deal breaker. Being a huge proponent of automated testing, if I were to see a patch that didn’t include a test (or multiple tests), I’d say “no thank you”. Third, and this is perhaps the biggest one, does the change make sense? Do I personally know what these changes are doing? If I’m accepting the change, it’d be a good idea to know what is coming in.
— Jeremy
