Create issue from group by picking the project for you automatically

Problem

• Many teams are using GitLab to do issue management that is not directly related to source code development.
• Or maybe the team creating the issue doesn't know which project/repo it belongs in. But they are working in a common organization / team defined by a group or a subgroup.
• How can we make it super easy to create an issue at the group level?
• We do not want the concept of group issues at this point. That does not fit our current design architecture and product strategy.
• But we do want it easy for a user to create an issue at the group level.
• Currently, if you try to create an issue at the group level, it forces you to pick a project. We want to abstract that out.

Common use cases

• An organization is structured in different business functions, such as engineering, operations, business development, sales, marketing. Each area has groups and subgroups. A person in the operations department does not know what particular project to start an issue, but we want to allow that person to quickly an issue that pertains to the operations department. It is a process issue and unrelated to developing software.
• An organization is structured in different product areas. There is a consumer hardware product. There is a web product. There is a mobile product. A marketing person sees a defect in the mobile product and wants to quickly log an issue related to a problem in the latest iPhone version of the app. The person doesn't understand or care that there are multiple repos and subgroups that are associated wth that iPhone app. That person just wants to log that defect and get on with their day without caring.

Potential solutions

• When creating a group/subgroup, you can define a default issue project.
• When you create an issue from the group/subgroup UI, in that UI flow (i.e. probably the web form), it belongs to that project.
• During that issue creation flow, you still have a chance to choose another project, but at a minimum, you are not forced to choose, because the system has chosen the default for you.
• In the group settings, you can change the default issue project. But there is a default chosen for you already, namely it is the first project that is added to the group.
• Another solution is building service desk out further in an internal setting. But that's probably too risky to iterate on it to solve this type of internal user problem.

@sarrahvesselov @smcgivern @mydigitalself @markpundsack : This is a problem that is oft-requested by the customers I talk to. They want to use groups for issues because groups is the right abstraction for them in terms of teams and business areas. Projects are not the right abstraction because it is code/repo-specific. But I think making native group issues is not something we're going to move toward anytime soon.

To me, what I've described here is the smallest iteration we can move in this direction. But based on our earlier discussions about giving UX more room to explore, I think UX should consider the bigger problem, broader designs, and then we can carve out something small.

@markpundsack : I think you had created at least one issue about creating default / pre-populated groups/projects for on boarding flows? I can take a few of these issues and we can maybe either make a meta issue (ugh) and then let UX have at it.

@mydigitalself : CC-ing you because many of the customers I talk to have heard of groups, but are not aware of subgroups just yet, and really do like the idea once I've mentioned them.

changed milestone to %Backlog in gitlab-foss

added UX in GitLab FOSS label

based on our earlier discussions about giving UX more room to explore, I think UX should consider the bigger problem, broader designs, and then we can carve out something small.

I appreciate that @victorwu. Do you have any insight into how they are using issues in a group setting? Understanding what kind of issues live at this level would help with context.

changed the description

@sarrahvesselov : I highlighted a few common use cases in the description? Does that help?

Yes, it does. Both of these use cases sound as though it is a quick way for someone to log an issue to the group without having to know where it should go. I could assume that these issues would then get triaged and moved into the appropriate area, or labeled in a way that would signal the appropriate people. Kind of a catch-all issue board.

We do not want the concept of group issues at this point. That does not fit our current design architecture and product strategy.

If this is not a concept we want, then do we limit in some way how long issues live in this catch-all list? If we don't, I can see the catch-all issue board being appropriated as a group issue board, used to track the management/progress of issues within multiple projects.

Kind of a catch-all issue board

I'm not sure how that would be different to group issues, either from a user's perspective or an implementation perspective?

@sarrahvesselov : Sorry I wasn't trying to be restrictive/limiting in our design when I say "we don't want group issues". I certainly think it does make sense overall as a design. But it would be a radical change in how we do GitLab, and we would have to re-invent and do a lot of clean up work in GitLab just to accommodate that. So I see it as an unfortunate constraint that we are stuck with because of the history of GitLab product evolution. (I.e. it started out with one project with one repo and it being developer focused.)

That's why I've considered crazy concepts like a hidden "shadow project" that functions to house group level things. But that still sounds really messy.

I do like the concept of a "catch-all" bucket. I can see that maybe as a group-level issue filter where we grab all the issues that have not yet been assigned a group filter.

Or maybe in some UI we de-emphasize the project concept. So even though there is a project A issue and a project B issue. Because both issues belong to Group C, we just emphasize that they are Group C issues, and have dedicated UI just for that.

I'm not sure how that would be different to group issues, either from a user's perspective or an implementation perspective?

If we simply go the route of adding a 'default project' for issues to be added to rather than making them choose, it really isn't any different at all. Users can do this now by simply creating a dummy project that they can assign their 'group level' issues to.

Sorry I wasn't trying to be restrictive/limiting in our design when I say "we don't want group issues".

Don't be sorry, I am trying to work within the given parameters. It just sounds like we are trying to dance around something users might really need or want.

So even though there is a project A issue and a project B issue. Because both issues belong to Group C, we just emphasize that they are Group C issues, and have dedicated UI just for that.

It sound to me that this is what some of our users may be trying to do. Use a group issue board to manage issues that belong to multiple projects. Others just want a quick way to add an issue that someone else will have to get to the right project later.

Thanks @sarrahvesselov . I've put this into the Backlog milestone. So I anticipate we'd really want to move this forward once we starting have group boards and a really good group issue list. Let me know if that makes sense. And then I can let the UX team do more exploration on this as a lower priority for now.

Makes sense to me @victorwu, thank you!

changed milestone to %Next 3-6 months in gitlab-foss

mentioned in issue gitlab-foss#34411 (closed)

moved from gitlab-foss#33432 (moved)