This Epic blocks https://gitlab.com/gitlab-org/gitlab/-/issues/2059 ## Design document The ["Configurable Work Item Statuses" design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/work_items_custom_status/) contains all architecture and implementation decisions. It functions as our SSOT: ``` https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/work_items_custom_status/ ``` ## Current Status * The MVC1 (Iteration [1](https://gitlab.com/groups/gitlab-org/-/epics/14793) and [2](https://gitlab.com/groups/gitlab-org/-/epics/14794)) of configurable statuses was released in `18.2`. * The MVC2 (Iteration [3](https://gitlab.com/groups/gitlab-org/-/epics/17798) and [4](https://gitlab.com/groups/gitlab-org/-/epics/14795)) of configurable statuses was released in `18.5`. ## Problems To Solve For a detailed problem overview, view the [:bulb: Solution Validation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/368290#problem) - How can we better support configuring "workflows" (https://gitlab.com/gitlab-org/gitlab/-/issues/2059) - How can we provide more context on the status of an issue outside of relying on labels? - How can we report on issues that were closed (completed) as opposed to closed (moved, duplicate, promoted, not doing)? - How can we improve the process of calculating lead/cycle time for issues including determining active vs. time spent waiting? ### Customer Perspective We currently rely on labels for statuses, maintain a few system-generated statuses -- `duplicate`, `promoted`, `moved`, `merged` -- and have two formal states for work items -- `open` and `closed`. The overuse of labels to solve every custom meta-data need is not scalable. Some recent feedback from a customer: > Elevating important issue/epic metadata from labels to fields, specifically: issue type, priority, and status as well as the ability to customize those fields would remove the feeling of label overuse As we work towards a holistic solution for custom workflows (https://gitlab.com/gitlab-org/gitlab/-/issues/2059), it makes sense to create the proper foundation and small primitives (https://gitlab.com/gitlab-org/gitlab/-/issues/271171#benefits) that will allow us to compose workflows for different types of issues. ## Iteration plan - https://gitlab.com/groups/gitlab-org/-/epics/14793+ - https://gitlab.com/groups/gitlab-org/-/epics/14794+ - https://gitlab.com/groups/gitlab-org/-/epics/17798+ - https://gitlab.com/groups/gitlab-org/-/epics/14795+ - https://gitlab.com/groups/gitlab-org/-/epics/19641+ - https://gitlab.com/groups/gitlab-org/-/epics/16448+ ## Tier Configurable statuses will be the foundation for [workflows](https://gitlab.com/groups/gitlab-org/-/epics/364), an important team capability. [Directors will care the most about workflows from a purchasing perspective](https://about.gitlab.com/company/pricing/#three-tiers), so this feature will be available in ~"GitLab Premium" with future enhancements focused on providing a compelling upgrade path to ~"GitLab Ultimate". --- <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->