| This is a great point. We have ~10 repos as part of our product, so we faced the same issue. After toying with different solutions, we settled on using two dedicated issues-only repositories. One of them handles software development (all bugs, feature requests, the engineering stuff) and the other handles operational stuff like client installs and so on. This has worked well for us. Here are some advantages: 0. We get the big picture you mentioned, which is the crucial point. Planning, grouping issues for releases, etc., becomes much easier. 1. When it comes to access security, we can give people access to the issues repositories (via GH teams) without giving them access to the full source code. 2. Splitting operations and engineering increases focus. Engineers don't need to look at client installs, etc. 3. We can still reference repo issues in commits to other repositories. See [0] and [1] So all in all, I agree the fragmentation is a real problem, and I think centralized issues-only repos are the way to go. Hope this helps. 0: https://github.com/blog/1439-closing-issues-across-repositor... 1: https://github.com/blog/967-github-secrets |