I’ve mentioned in previous posts about my involvement in a blog aggregator project, Telescope. In our most recent sprint, our goal was to have a minimal viable product, or as others like to call it, dog food. It didn’t have to be pretty, it just had to work.
There were a few components that needed to be completed in order for this to happen, including setting up a reverse proxy using nginx ( thanks @manekenpix), adding SSL certificates with Let’s Encrypt, and connecting the front-end to the back-end. I was fortunate to have had a hand in all of these all of these parts of the code base as I feel I have learned a lot from both the front-end and back-end tasks that I completed. But there is a bigger lesson that I took home from this sprint, and that is collaboration.
In the past, my involvement in open source projects has been to get an issue assigned to me, then go off on my own and try to solve the bug. Because of the amount of work that needed to be done as well as the complexity of it, this approach to collaboration would have been highly ineffective. As a result, I was working with multiple people on the same issues. This was ideal because everyone brought some knowledge that only they had which helped keep the project moving forward.
One tool that is especially useful for this type of scenario is git. Although this is not how we collaborated on this project, in hindsight it would have been useful to create a branch in one of the forks of the contributors and have everyone involved contribute to that branch. In this way when a pull request is made, everyone will get credit for what they contributed.
But what about if only one person committed the changes but many others contributed?
Well, fortunately GitHub allows you to co-author commits.
Overall, I really enjoyed this kind of collaboration and hope to do it more often.