During years of work on projects of varying complexity, I tried a number of project management tools. Starting from simple TODOs to more serious tools like Asana, Trello or even Jira. Today I want to explain why I ended up using Github and show how we use it in our company.
GitHub is a code repository hosting platform first, and then it is all the other tools around it. Github project management and task management tools are very close to your code, which means that you can seamlessly add a reference to a commit or a particular line in a commit, or to a pull request in every comment or message you add on Github.
You can even paste a reference to a bunch of code from your codebase, and Github automatically transforms this reference into the widget with real highlighted code!
It also works in another direction. In your commit messages, Github parses into a link any reference to an issue/comment/PR.
Cross–referencing is what Github does well. For example, it tracks all the references to an issue/PR from comments to other issues/PRs. So, you can always find related tasks while observing a single issue.
When Github started, its goal was not project management but code hosting. Github Issues back then were the way to submit a bug or suggest a feature to a hosted software. It wasn't aimed to be a fully featured task management tool. However, it has evolved, and now it has enough features to provide to those who are looking to implement different project management approaches and techniques on top of Github.
Issues (or call it tasks) are at the core of Github project management. While creating an issue, you are allowed to use markdown syntax. You can assign an issue to multiple developers. It can also have multiple labels assigned to it. Moreover, you can filter issues by these labels.
When you find that you have too many issues that are related to the same feature or to a release you can group them into milestones. Grouping issues into milestones make the tracking of progress much simpler — fewer things in front of your eyes. Also milestones UI shows a nice progress bar.
Github even tracks editing history of issue description or comment. With diffs provided!
Milestones are an excellent way to group things, but there is another thing which is traditionally aimed to help in tracking a state of tasks. Github Projects allows one to represent issues in the form of kanban. It is not a replacement for milestones, but a perfect amendment. One of the approaches may be like this — use milestones to group things which belong to the same feature or same release, and use projects for presenting each of your scrum sprint (one project per sprint) with columns for each of the states of an issue — todo, in progress, done.
With Github you can manipulate a state of an issue in the following ways:
Automation doesn’t end up at the closing of an issue with a magic word. You can manipulate the position of an issue in a column of a project. E.g., you can pick a column where to put newly added issues. You can pick a column where to put closed or reopened issues. You can also create a column called Wrong and set the automation to put all reopened issues into this column.
In conclusion, I need to say what everyone who has been using Github already noticed. After Microsoft acquired it, it started to improve rapidly. There was some period when new features were coming every week! Usually far from major, but rather some small helpful improvements.
It seems like people from Microsoft see much potential in Github, and this is good news! Github as a platform is here for a long time, and it is definitely worth giving it a try.