Compared to all other ticketing tools, GitHub Issues is the only platform giving entire freedom to define whatever types of labels you want. All other tools have an opinion on label types, such as priority, severity, component, epic, etc. Now if you consider that the number of GitHub public active repositories amounts now to 25 million at the end of 2017, and that, well, most of these public (understand open-source) projects are managed through GitHub, then you could be wondering if any best practices have emerged. Is there any unique best practices that cannot be applied to other tools? Should we all switch to GitHub to manage our projects there?
First, we will analyze the 20 most popular open-source projects, how they are structured, and which labels they use.
Then, we will try to find common patterns, to help us understand when and how those best practices can be applied to your project.
Finally, we will compare with other existing project management tools, so you can decide whether GitHub is worth using as your project management tool.
The full article is available on here on Linux.com.
Just a note after you read the article. What if I told you there was a tool that would integrate GitHub and let you use your label categories as if they were part of GitHub initially (with pickers)? You could also monitor the issues for each of those labels and get the visibility you were missing. That’s actually what the first version of our iPhone app, Anaxi, does. And a lot more is coming. We will soon integrate Jira, so if you are using GitHub for some projects and Jira for others, you will be able to have one single interface for your reporting and get the visibility you need.