5 ms·

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 int

by danial 10y ago

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.

microcolonel 10y ago
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.
- bryanlarsen 10y ago
  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 https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
- victorwu 10y ago
  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.
jobvandervoort 10y ago
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 https://gitlab.com/gitlab-org/gitlab-ee/issues/928
victorwu 10y ago
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 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!
- prh8 10y ago
  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.
  - sytse 10y ago
    Yes, I think teams/organizations/groups are used interchangeably.
chetanahuja 10y ago
"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).
- dimitrieh 10y ago
  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

by danial 10y ago

microcolonel 10y ago

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.

bryanlarsen 10y ago
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 https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.
victorwu 10y ago
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.

jobvandervoort 10y ago

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 https://gitlab.com/gitlab-org/gitlab-ee/issues/928

victorwu 10y ago

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 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!

prh8 10y ago
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.
- sytse 10y ago
  Yes, I think teams/organizations/groups are used interchangeably.

chetanahuja 10y ago

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

dimitrieh 10y ago
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