3 ms·

I'm a Community Advocate at GitLab, what features are you missing from GitLab issues that prevented you from switching?

apocalyptic0n3 9y ago
I think this may have been addressed in a recent release, but projects involve far more than just the development team; Design, project management, video/photography, client, SEO, etc. will all need to be using the system as well. Beyond that, a project starts long before development is even thought about. Most of those teams will be doing work, that needs to be tracked, well before we're ready to create a code repo. With the way things are (or were), code is front and center and half the team doesn't care about that at all. There are also projects that have no development at all from the other teams (video/photo shoots, SEO for customers we didn't build sites for, etc.) You can only have one code base per repo, too. So our PM may go in and create a project for an app and then when we go to develop, realize we need two separate projects. Or maybe they will go create a new project for a new version of an existing site, but we will still be using the same codebase. It makes sense from their view point to track it separately and with a clean slate while from a code standpoint, it makes absolutely no sense. Beyond that, I personally have 74 tickets assigned to me across a dozen or so projects. PMs are tracking tickets in dozens of projects simultaneously. The last time I looked, there was no good way of seeing an overview of everything like that. Organizing by client while also ensuring that all users have access to all repos without allowing public access to the repo is also a pain. If we were only a development company, we'd use it for sure. But GitLab is too tied to the code to be a complete project management tool. There's also the issue that we want to have our CRM in the same place (it currently isn't) and there is no way GitLab will ever offer that.
- tyldum 9y ago
  +1 for the top level overview, although subgroups is a step in the right direction
- cmatija 9y ago
  * Issue visibility You can currently see an overview of issues and MRs assigned to you (as well as your GitLab TODOs). * Repo access You can narrow repo access to a certain group (i.e. make it internal) see [1] * Group-level issue boards We have an open issue for cross-project (group-level) issue boards, see [2] * Multiple repos per project We discussed opting for a non-repo-centric approach to projects in [3] Check out the discussion in there, to see our reasoning for sticking with one repo per project. * Non code projects You can disable the repository in a project, so you can focus on just the issues, or you can have a repository with only graphics. We use both internally. Our organization project doesn't have a repository [4], and our marketing repo has lots of design stuff [5] [1] - https://docs.gitlab.com/ee/user/permissions.html https://docs.gitlab.com/ee/user/permissions.html [2] - https://gitlab.com/gitlab-org/gitlab-ee/issues/928 https://gitlab.com/gitlab-org/gitlab-ee/issues/928 [3] - https://gitlab.com/gitlab-org/gitlab-ee/issues/1295 https://gitlab.com/gitlab-org/gitlab-ee/issues/1295 [4] - https://gitlab.com/gitlab-com/organization/issues https://gitlab.com/gitlab-com/organization/issues [5] - https://gitlab.com/gitlab-com/marketing/tree/master/design https://gitlab.com/gitlab-com/marketing/tree/master/design
- svesselov 9y ago
  “ projects involve far more than just the development team; Design, project management, video/photography, client, SEO, etc. ” This is an excellent point and something we are thinking a lot about. From a design point of you, we need a way to share and maintain multiple design files across a distributed team. This is something we are actively working to solve for ourselves within GitLab. From a project management point of view, we need to be able to see all the issue the team is working on along with what is in the pipeline. Multiple assignees is just one step in our process to giving users a holistic view to the entire project.

I think this may have been addressed in a recent release, but projects involve far more than just the development team; Design, project management, video/photography, client, SEO, etc. will all need to be using the system as well. Beyond that, a project starts long before development is even thought about. Most of those teams will be doing work, that needs to be tracked, well before we're ready to create a code repo. With the way things are (or were), code is front and center and half the team doesn't care about that at all. There are also projects that have no development at all from the other teams (video/photo shoots, SEO for customers we didn't build sites for, etc.) You can only have one code base per repo, too. So our PM may go in and create a project for an app and then when we go to develop, realize we need two separate projects. Or maybe they will go create a new project for a new version of an existing site, but we will still be using the same codebase. It makes sense from their view point to track it separately and with a clean slate while from a code standpoint, it makes absolutely no sense. Beyond that, I personally have 74 tickets assigned to me across a dozen or so projects. PMs are tracking tickets in dozens of projects simultaneously. The last time I looked, there was no good way of seeing an overview of everything like that. Organizing by client while also ensuring that all users have access to all repos without allowing public access to the repo is also a pain. If we were only a development company, we'd use it for sure. But GitLab is too tied to the code to be a complete project management tool. There's also the issue that we want to have our CRM in the same place (it currently isn't) and there is no way GitLab will ever offer that.

tyldum 9y ago
+1 for the top level overview, although subgroups is a step in the right direction
cmatija 9y ago
* Issue visibility You can currently see an overview of issues and MRs assigned to you (as well as your GitLab TODOs). * Repo access You can narrow repo access to a certain group (i.e. make it internal) see [1] * Group-level issue boards We have an open issue for cross-project (group-level) issue boards, see [2] * Multiple repos per project We discussed opting for a non-repo-centric approach to projects in [3] Check out the discussion in there, to see our reasoning for sticking with one repo per project. * Non code projects You can disable the repository in a project, so you can focus on just the issues, or you can have a repository with only graphics. We use both internally. Our organization project doesn't have a repository [4], and our marketing repo has lots of design stuff [5] [1] - https://docs.gitlab.com/ee/user/permissions.html https://docs.gitlab.com/ee/user/permissions.html [2] - https://gitlab.com/gitlab-org/gitlab-ee/issues/928 https://gitlab.com/gitlab-org/gitlab-ee/issues/928 [3] - https://gitlab.com/gitlab-org/gitlab-ee/issues/1295 https://gitlab.com/gitlab-org/gitlab-ee/issues/1295 [4] - https://gitlab.com/gitlab-com/organization/issues https://gitlab.com/gitlab-com/organization/issues [5] - https://gitlab.com/gitlab-com/marketing/tree/master/design https://gitlab.com/gitlab-com/marketing/tree/master/design
svesselov 9y ago
“ projects involve far more than just the development team; Design, project management, video/photography, client, SEO, etc. ” This is an excellent point and something we are thinking a lot about. From a design point of you, we need a way to share and maintain multiple design files across a distributed team. This is something we are actively working to solve for ourselves within GitLab. From a project management point of view, we need to be able to see all the issue the team is working on along with what is in the pipeline. Multiple assignees is just one step in our process to giving users a holistic view to the entire project.