Hacker News Reader

Comment by danial | Hacker News Reader

Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more.

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.

View on HN

"Since Gitlab projects are repo-centric"

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).

Hi, we are moving more and more into the direction of going multi repo/multi project. Subgroups is the most significant step forwards for this. Expect to see cross project pipelines, management feature, monitoring etc

Like Job mentioned, we've been ramping up issue boards and groups (subgroups now) rapidly in the past few releases. Group-level issue boards are definitely on our radar. Feel free to leave any comments on the issue itself that Job linked: https://gitlab.com/gitlab-org/gitlab-ee/issues/928.

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!

When you say team-based, do you mean as in organizations? That would be a huge killer feature. I've only been part of an org on GH, but org wide issues/boards/communication is a huge missing piece.

Yes, I think teams/organizations/groups are used interchangeably.

Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business unit can reasonably control a codebase, and you have access to it, it should be in the same repo as your other codebases, full-stop.

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.

Yup, I think Google & Facebook have this one right, a mono-repo is the way to go.

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 originally built GitLab with that use case of a single repo in mind. Create a GitLab project, and you have a single repository for code. We know this is an important use case for many teams, because of it's straightforward, simple scenario. It's something that's important to us, even as we expand to other use cases of multi-repo teams (groups/subgroups housing of projects). Thanks for the comment.

Thanks!

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

Reply on news.ycombinator.com