## Why - Enabling work items at the group level is part of the critical path for epics to become work items. - Maintaining "issues only" projects causes management overhead that they want to avoid. Some companies like them have hundreds of teams, and having a project just for issues adds up. They need to maintain configuration and membership for each of those projects. It's also unintuitive and introduces friction during onboarding ## Proposal - Add issues natively to Groups. - The full proposal, including impacted areas in the UI, is outlined on the validation issue (https://gitlab.com/gitlab-org/gitlab/-/issues/396904+) ## Verbatims > Currently, our company mainly uses JIRA for issue management. However, our code is hosted in a gitlab instance, and we would like to move our issues to gitlab as well so we can have better integration. > > However, we have a product that consists of several services, which are all independent repositories, put together in one group. Often we have features in our tracker that touch several of our different services (for example, both the api and the websocket server). In JIRA we would just tag the issue to identify which services in the product would probably be touched by the feature. > > In gitlab, we can only create project-specific issues. So issues and features that touch different parts of our system currently have to be reported on each seperate repository, or we would have to create a separate project repository just to contain issues. https://gitlab.com/gitlab-org/gitlab-foss/-/issues/24536 > I have different projects in my group (let's say API and web client). When he encounter a bug, my clients never know from which project it came from. [interpretation: I do not want to be required to select a project in order to create an issue] https://gitlab.com/gitlab-org/gitlab-foss/-/issues/42408 > Most companies do not work in a single project, yet all of our functionality is optimized around the project. We need to recognize that companies have many teams, with many projects, and some projects are composed of many components (e.g. micro-services). While the relationship between these pieces is not always rigidly hierarchical, the addition of sub-groups gives us a chance to step in that direction. Imagine a company, with several departments, each with multiple apps composed of many services. e.g. `gitlab.com/company/dept/app/service/issues`. Now, the structure can already happen, but what about issues that span all the services in an app? Or issues that affect an entire department or even the whole company? We need to start supporting features at the group (and sub-group) level. https://gitlab.com/gitlab-org/gitlab/-/issues/17836 > It is not possible to create issues in a Group. But an issue, like bugs or feature-proposals from a User or Product Owner or even most of the time a Developer perspective, are product-related in the first place. Creating issues only under a project, that might be part of a product does not make any sense. It is also not the Reporters job to make the decision in which project an issue belongs. This becomes especially clear when a simple issue impacts 2 projects. Simple Example: Add Middle Name into User Database. That is a Frontend and a Database issue and I do not think that this should become an epic to manage it. https://gitlab.com/gitlab-org/gitlab/-/issues/207314 ## Iteration Path **Note:** Work items is inclusive of legacy issues. ### Step 1: Dogfooding | MVC | Outcome | | ------ | ------ | | 1 | [Create work items in a Group](https://gitlab.com/gitlab-org/gitlab/-/issues/392992) | | 2 | [Show Group work items in list](https://gitlab.com/gitlab-org/gitlab/-/issues/392812) and Board views | | 3 | [View work item detail within a Group](https://gitlab.com/gitlab-org/gitlab/-/issues/393240) | | 4 | Update & delete work item within a Group | | 5 | Clean up UX where the selection of a group or project is necessary (create MR from issue, create issue from group list/board, ...) | | 6 | Limit work items in a list to self (hide rollup) | | 7 | Limit work items in a board to self (hide rollup) | | 8 | Move & clone work as expected (legacy issues only) | | 9 | Relationships work as expected (legacy issues only) | | 10 | CSV Import/export has parity with project issues (import only imports to self, export is inclusive of all roll-up issues from children) | | 11 | Integrations have parity with project issues (jira integration, ...) | ### Step 2: General Availability - Identify and cleanup anything that feels "broken" from the current issue experience within Projects. ### Step 3: Enhancements - Settings parity - Bulk update parity - ...