I haven't used bitbucket for larger projects yet, any insights there also appreciated.
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...
The UI and milestones, though, I think are good. JIRA is to me the king of clunky. I've used it in 3 projects over the years and evaluated it last year, and I've been pretty disappointed with it.
To borrow from another comment here, it has a bit of a Bugzilla feel, like it just grew and grew, and you have tons of fields and features, but they're poorly designed and put together. A bit of a mess, to put it bluntly. FogBugz has a similar feel to me.
I encourage you to check out JetBrains' YouTrack. I never used it in a project, but a couple days evaluating gave me a good impression. Good luck with your search.
btw, I don't think that there is necessarily anything wrong Milestones, but there are always too many clicks involved in the GH interface and the buttons are often not where I expect them to be -- even when you have something that works well (i.e. dynamic adding of tags that automatically updates the DB), there is frequently no indication of actual success, which ends up puzzling the user.
Thanks a lot for the suggestion for YouTrack, will definitely check it out.
I use GH for about 12 hours a day almost every day, between open source and client projects. I face slow downs in the issue tracker, the git repos themselves (I only use command line), and the web interface to browse a project (code, history, pull requests). I notice a slow down about once a day. Some features, like the contributors graph, are always dead slow. About 10-20% of PR merge attempts fail, and I have to click the button again, sometimes multiple times. I see the Unicorn fail page or some Octocat fail page often enough.
It makes me think exactly of what you describe, a combination of Rails perf / scalability and perhaps a lack of strong backend engineering, I'm not sure.
Right now the problems are in the level of a mild annoyance / surprise that a company like GH has these issues. If it gets worse, I would consider moving away. But because I truly love the UI and overall functionality, it's a positive tradeoff for us at the moment.
You're very welcome regarding the YouTrack suggestion.