This seems to be the huge blind spot on gitlab product design. Everything is tied to git repo's while in the real world installs, users want global views of things which go across git-repos. I suspect this comes from starting off as a github clone, which has it's own constraints as a product (and it's public face).
Currently we are considering bringing all the issues of all projects (that are in the same group) into one location, i.e the group-level board, exactly as you describe it.
Team-first/team-based collaboration is something we are now highly interested in, with subgroups being a big feature in 9.0 in this direction. Our next step will be to tie that with issue boards. Thanks for the feedback!
I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in its own company-specific repo. Then they put the whole thing in a "UI kit" which realistically they will never reuse.
But there are advantages to multi-repos, especially if you're trying to share with clients and/or open source. You can have your cake and eat it too: we use https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
We're working on it! We were holding off until subgroups shipped so we can make sure group-level boards work well with it. It's on the shortlist for one of the next releases. Our PM for this, Victor, might provide more detail here later.
Issue for this: https://gitlab.com/gitlab-org/gitlab-ee/issues/928
I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a single place. A board that is visible at a group-level would solve this problem.
I believe this is a feature that's coming soon, though. I am looking forward to it.