Many fast-moving companies store their issues in GitHub: Gumroad, Vercel, Sanity, Superhuman, Framer, and WeFunder, to name a few (as of this writing).
Here are some reasons teams use GitHub issues:
💼 Your code and issues are closely integrated. At Instantish, we believe issue tracking is a key part of the engineering process. You can easily identify bottlenecks in this process when you can trace pull requests back to issues, and issues back to conversations.
🤖 You can use built-in automation linking issues, code, and deploys. There are 7500+ Actions and 400+ Apps in the GitHub Marketplace. Actions are like open source mini-apps that you can use to automate your engineering processes as your team scales.
💗 GitHub Issues are getting even better. GitHub has been making a lot of improvements to their issues offering lately. And, with GitHub Issues + Instantish, you'll have a scalable issue tracking process that's approachable enough for your whole team to use.
Here are some helpful things to remember about GitHub repositories:
📦 You can have a repository that is for code only and has issues disabled.
🎫 You can have a repository for issues only and have code disabled.
🔗 You can reference issues and PRs across repositories if you need to. The syntax is just a little bit less intuitive for your team (you have to do myorg/myrepo#123 instead of #123, and there is currently no auto-correct)
📍 GitHub milestones are at the repository level only. They are pretty simple, are often used for sprints, and can have due dates.
🗺 You can use GitHub projects to plan efforts across repositories. Projects can be at the organization level or at the repository level. They are more robust than GitHub milestones because you can create column lanes with light automation, and order issues within those columns.
We've talked to a lot of teams that use GitHub issues, and here's what we'd recommend.
❌ 🥝 Try not to store your issues in both frontend and backend repositories. You'll find that many features or bugs span both frontend and backend. If you already have two code repositories for frontend and backend, you can either choose one repo to store your issues (we suggest backend), or create a separate issue repository.
❌ 🔖 Try not to store "general tasks" alongside engineering issues. Some teams love to use GitHub for general tasks too. At Instantish, we use issues for customer success tasks (like writing this article!), marketing design, and recording feedback, so we use separate repositories for that. It's important for engineering sprint planning that you don't have unrelated tasks adding noise.
✅ 🏠 When in doubt, start with one repository. You can always move issues later on, and Instantish is built for both single repository and multiple repository use cases. A good rule of thumb is asking yourself "where are the pull requests that close these issues going to be?". We know multiple teams with popular products that have scaled to 20k+ issues in a single repository.