In my organization we use issues to track work that doesn’t change source code (e.g. devops configuration, data science experiments). Since GitLab doesn’t let you assign an issue to an epic, we end up creating dummy projects with names like “Issues”. This feels like a hack.
What is the recommended GitLab orthodoxy on this? Is there a convention for creating projectless issues, or is the omission from GitLab a deliberate design choice to discourage you from doing this?
Hi,
Issues can be assigned to projects and they can also be assigned to groups. They have to be assigned and located somewhere. So you could create a group called “Issues” and put them in there. It’s not possible to create issues that don’t belong to a group or project.
Gitlab is a product for code and projects. If you want issues with projects that have nothing to do with git or coding, then perhaps you need to be using an alternative product for that. This is not what Gitlab is.
Assigning an issue to a group sounds like what we want. (And, yes, it’s important to have a sense for what GitLab doesn’t do. I have to keep insisting that it’s not a time card where you keep track of every minute of your day.)
However, I don’t see how to assign issues to groups. In my UI (version 15.8.1-ee) I only see how to create an issue associated with a project, and that’s what the documentation says too. Is there something I’m overlooking?
Ah yeah my mistake. I just checked on mine, if at group level I try to create, it will ask me to select a project. Sorry about that.
It seems the group issues is for showing all issues across all projects within the group in one location.
Creating issues in groups that get grouped by an epic is not yet available. Work items should help solve this feature request when available.
Tasks for issues is the first iteration with work items. It won’t help your question, only mentioning for context. For now, I’d suggest using the project issue tracker, and watch the direction for work items to migrate later.