We’re huge fans of Github at Wiredcraft. We started using it in 2009 and haven’t looked back. While it initially mostly replaced our code tracking tool (I believe we were then using Redmine), it now is the single most important platform for our team to collaborate, on all levels, from code to HR.
We went through using a few tools over the years; Basecamp, Open Atrium or more recently Trello for threaded discussions, Redmine for issue tracking, IRC or Campfire for chats, Wikis, Hackpad and files, in Dropbox or Git, for documentation…
It became painfully obvious over time that we were spreading ourselves thin. I wrote about the increasing surface of friction that the adoption of the SaaS model has introduced. Our needs changed over the years and we faced a few key junctions when we had to adopt a new tool.
This meant convincing the entire team to adopt a new workflow; not something particularly easy to do with a team of technologists mostly focused on shipping stuff.
First, let me illustrate how our current approach is actually impacting our communication.
Juha joined our team two months ago. He’s been involved in some of the most passionately debated issues we’re working on, getting his hands dirty with Vagrant, Docker, Python, Ansible and some of the more esoteric things we’re doing on devo.ps. In these 2 months, he received a total of 15 emails.
What we’re effectively doing is driving most of our collaboration through Github:
Our internal wiki, associated to the code of our company site (a Github page by the way) is filled with awesomeness. From the “Getting started” page that walks new employees through our tools and processes, to the tutorials on “Writing issues, comments and milestones”, we’ve captured most of the valuable lessons we’ve learnt along the way.
Our recruitment process is entirely done through the issue queue. Whenever we receive a new application by email, we create an issue on Github and let one of our managers grab it.
Day-to-day operations, from buying new snacks for the office to dealing with HR or logistical issues. Need a new SSD for your Macbook? Create an issue on Github. Want to get sponsored to attend a conference in Beijing? Same deal.
Marketing efforts are discussed and led through the Github issue. This very post was discussed, planned and wrote on Github.
And a lot more…
This actually had a couple interesting effects on the team:
By the way, Wikis on Github are full-blown Git repositories.
There are still a couple things that we’re not tracking in there obviously. We use a 3rd party solution for our CRM and are sharing a lot of administrative and legal documents through Dropbox. We’ve also started using Huboard in some cases, bringing a more Kanban-like (some may say Trello-like) approach to managing our tasks, and, as we’ve written before, we heavily automate things through Hubot.
But Github is where we go for everything we produce (content, design, code), discuss (issues, announcements) and document (guides, processes, documentation).