Open Source. Part I

How I work with GitHub


Nowadays, in my day-to-day work I extensively use such open source tools as Docker, Kubernetes, Ansible created and supported by the communities of enthusiasts and professionals working on these projects commercially.

From each according to his ability, to each according to his needs

This socialist motto clearly describes labor as the main need which takes place in such communities. Actually, Open Source Software movement has been existing for quite long. Around this movement there appear different non-commercial organizations, (for example, Open Source Initiative), funds (among which there are Free Software Foundation and Apache Software Foundation) and projects of common interest (like SourceForge and Google Code). In my opinion, though, a brisk growth of this movement is related to appearing such a player as GitHub that succeed thanks to seamless UX, simplicity and social mechanic.

So what is my motivation? What makes me spend my spare time on publishing own best practice in open source? Hard to answer this question uniquely. It is all about three things: fulfilling myself in the expertise, being a part of very much enthusiasts community and the wish to be useful to this society. I definitely get inspired by such people as Fabien Potencier and Mitchell Hashimoto. They’ve become leaders of opinions thanks to their talent and hard work.

In these articles series, I want to share my experience of how I organize my working process with open source. Under severe time constraints, I have found the appropriate tools and chosen best practices that let me use this limited resources effectively.

Starting work

Basic Options


GitHub labels: let split tasks up visually and prioritize them.

GitHub labels


GitHub milestones: combine tasks in sets according to description and ETA (estimated time of arrival).

Hub milestones

Kanban Boards

GitHub projects: define workflow of issues having the set of statuses specified individually according to the particular project.

GitHub projects

Wiki or Knowledge base

GitHub wiki: gives an opportunity to keep the records, write specs and glossary with your own history of changes.

GitHub wiki

Work on tasks

I usually start my work using the application named Notes that is always at hand.


Here I keep notes about coming tasks and everything related: required functionality, underlaid ideas and useful links.

The problem to solve: noting the concept to use it later.

The next step is filtering and formalization of the notes written down before. Thus we create fully-featured tasks to be implemented later.

For this purpose, I use a really nice app named Ship that replaced more simple Gitscout.


When formalizing tasks, I should answer some important for me questions:

  • What type of issue is it (a bug, feature, refactoring or documentation)? (GitHub labels)
  • Which stage should it be accomplished on? (GitHub milestones)
  • What project should it belong to? (GitHub projects)
  • What priority should it have? (ZenHub estimate)

The problem to solve: quick access to the tasks of all the projects in one window.

When the list of tasks is created, you should plan the work on it. More exactly, you can use the time management tools to realize when it is better to start the task and it is needed to finish it.

Here I have tried several tools:


There are lots of books and techniques talking about time management. There is, even more, software for that. However, it is worthless if there is no discipline.

The problem to solve: time management.

I want especially mark one service that I don’t use much, but I’m pretty sure it carries some potential. I am talking about ZenHub that would start its way as an extension for Chrome browser, but today it has become a comprehensive all-in-one app.


Interesting possibilities ZenHub suggests to me:

  • weight of tasks
  • epics
  • releases
  • reports

The problem to solve: the tool for full control of the projects.


Communication via email and/or GitHub bug tracker can not always be convenient. Such means of interaction don’t involve fast feedback to users.

Gitter can be used for a quick follow up. Initially, it appeared to integrate with GitHub.


I usually create the channel for discussions only on some particular stage when the project is proved to be valuable and became a working prototype.

The problem to solve: first line technical support.

It is quite important to have a single access point for all the events happening in the repository: new tasks, builds statuses, new comments.

I personally prefer Slack for this purpose.


Gitter can also be used, but as for me, it is not an option for in-company communication. HipChat is another good alternative.

The problem to solve: checking all the project events in a centrally-controlled way.

Continuous integration

The quality tracking (lint) of the code published in open source is very important for professional status. Nowadays, using services like Scrutinizer is virtually considered to be good style.


The list of such services can vary depending on the technology stack that is used in projects. I personally use Exago and Go Report Card for Go projects.

The problem to solve: collect of quality metrics, spotting code defects as early as possible.

Before I had used Jenkins (as automation server) that required much time and effort to maintain it. Now using Travis CI, I can forget about this pain in the neck having saved both money on VPS and time (the most valuable resource).

Travis CI

On the market there is a plenty of similar services, for example:

However, I first recommend to check the apps on the official platform:

The problem to solve: automation of testing process and builds.

Providing reliability

As an engineer you should avoid single point failure. Multiple times in my experience I have faced the situation when deploying a release in some company is blocked by the inaccessibility of GitHub.

For that reason, I’ve chosen Bitbucket to backup my projects. If needed, I can switch to it quickly.


Also, you can always set Git directly on your servers and additionally hook one of the following web apps:

The problem to solve: high availability of source code.


I only passingly mentioned first line technical support (knowledge base: FAQ, record-keeping, glossary) and third line technical support (bug tracker) as I am planning to talk about it in detail in one of the next articles related to backward communication.

Adding up I’d like to state some important points:

  1. Draft should always be at hand to write down your idea.
  2. Organise your work with ideas sifting them out and sorting out priorities.
  3. Manage your time working with issues.
  4. Automate some part of work process getting rid of beaten track .
  5. Think up negative scenario to narrow down risk of point failure.


You can check other useful tools in my collections: