## Release notes You can now [configure project-level custom work item types](https://docs.gitlab.com/user/work_items/configurable_work_item_types/) to match the way your team actually plans and tracks work. Instead of everything being labeled as an "Issue," you can create types like **User Story**, **Bug**, or **Maintenance** — each with its own name and icon. New types support custom fields and status lifecycles, and appear in saved views and issue boards. Type configuration cascades from the top-level group to all projects. You can also control which types are available per project. Enable or disable a type across all projects at once, or let individual projects manage their own type visibility. When a type is disabled in a project, existing work items are not affected. https://docs.gitlab.com/user/work_items/configurable_work_item_types/ ## Problem - There is no way to define or control work item types. - There is no way to define or control which widgets should be available for each type. ## Proposal - Within a top-level group, support the ability to display all current types. - An individual with the appropriate permissions can edit the existing type names. - A new type can be created with a custom name. - Work item type names can be edited at any time. - Widgets can be enabled/disabled on a per-type basis. ## UX WIP (canonical home will be https://gitlab.com/gitlab-org/gitlab/-/issues/517746) ## Iteration Path 1. :white_check_mark: [**Phase 1 (Beta)**](https://gitlab.com/groups/gitlab-org/-/work_items/7897#release-strategy)**: Enable customers to configure custom work item types at the project level (team planning use cases)**. Instead of using scoped labels to denote type (ex: `type::feature`), customers will be able to create native custom types such as `User Story`, `Bug`, `Maintenance`, or `Feature`. Customers will also be able to define different status lifecycles specific to each type of custom work item. This addresses long-standing complaints about the lack of flexibility in naming conventions, dissatisfaction with the fact that everything is labeled as an `Issue`, and the inability to have different workflows for different types of work that are executed. * _Internal dogfooding milestone_: Migrate from scoped labels to `Feature`, `Bug`, `Maintenance`, and `Security` work item types for R&D (`gitlab-org`). 2. :white_check_mark: [**Phase 2 (GA)**](https://gitlab.com/groups/gitlab-org/-/work_items/7897#release-strategy)**: Enable customers to enable/disable work item types within subgroups and projects.** Not every department and program within a customer's organization follows the same workflows. Some teams will require different work item types than others. This improvement enables work item configuration to be extended to all Groups and Projects, supporting all different project-level types of planning work within a larger enterprise while maintaining intuitive and straightforward configuration governance. * _Internal dogfooding milestone_: Start introducing new custom work item types to better model associated business processes (ex, `Access Request` enabled only for the Access Request project) without having a bunch of types that don't apply to team members' respective project(s). 3. **Phase 3 (Maturity milestone): Customers can configure what metadata they want associated with a given custom work item type.** Today, there is no control over which fields show up on an Epic or Issue. With this change, customers can map specific custom fields to one or more work item types, enabling them to capture the necessary data that aligns with their business processes, while also simplifying the user experience by disabling fields that are not necessary or in use. * _Internal dogfooding milestone_: Begin to replace over-reliance on labeling with structured metadata via custom fields for corresponding work item types. 4. **Phase 4 (Maturity milestone): Customers can configure custom types within Groups (portfolio planning use cases).** They will also be able to specify the allowed parent/child relationships among their work item types. Instead of being forced to use `Epic` \> `Epic` \> `Epic` \> `Issue` \> `Task`, customers will be able to model their planning hierarchy exactly as they refer to it internally (ex: `Theme` \> `Capability` \> `Feature` \> `User Story` \> `Task`). This will be a massive improvement in enabling customers to accurately represent their mental model of planning objects and reduce friction in adoption at both the buyer and end-user level. * _Internal dogfooding milestone_: Fully realize our new "operating model" natively within GitLab's planning capabilities without unintuitive workarounds and excessive labeling. 5. **Phase 5 (Maturity milestone):** Enhanced configuration options for Groups and Projects. With this improvement, Groups and Projects can further tailor work item configuration (types, statuses, custom fields) to extend the Organization's base configuration to optionally provide different programs and teams with the full autonomy to model work items for their unique needs, processes, and planning/work management use cases (custom fields, field level visibility, ...). . * _Internal dogfooding milestone_: All planning use cases where teams are working across `gitlab-org` or `gitlab-com` can be configured to their unique needs within their specific contexts without introducing conflicting configuration for other teams. The field can maintain a different set of statuses, workflows, and work items for customer collaboration projects. Customer support could maintain work item types for connecting ZenDesk flows to R&D backlog items. 75% or more of marketing use cases from Asana could be replicated in GitLab (dependent on planning view improvements). A comprehensive list of company-wide process improvement opportunities is too extensive for this comment. ### What is the type of buyer? - Customizable issue types will be in gitlab~2278657 - Complementary compliance and configuration controls will be in ~"GitLab Ultimate". These will come in some flavor in MVC3 or 4 (or later). _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._