[UX] View and manage status of a planning item
Problem to solve
With [UX] Configurable status field design (&11975 - closed) users will now be able to set different statuses on planning items, beyond the current open/closed states. This will provide users with easier visibility into the status of an item as well as simplifying future automation and reporting.
Understanding the status of an item is critical to reviewing work in progress, including running standup meetings, doing reporting, or ad hoc reviews.
- Users need to be able to open a planning item and understand the status of that item and adjust the status if needed.
- Users need to be able to easily understand the status of an item from a list or board
- Users need to be able to understand the status of any child or linked items on a planning item
Proposal
State vs. Status
Planning items currently have a state/status of open or closed. The terminology "state" and "status" is not used entirely consistently today — it's "state" in the API, "status" in global search, unnamed in most cases — but currently have the same meaning.
Retaining "state" as open/closed, at a level higher than status, will be helpful to preserve any integrations/automations reliant on this state, and makes sense overall as a way to classify and segment items with work to be done vs. those without.
Status can then be a separate, related attribute of an item. For instance an item could be "In progress" and Open, or "Done" and Closed.
In this context, status is more important than state as it provides more detail. Most items a user works with will be "Open", as we do in many places today we could indicate state only when an item is closed.
Why not just extend existing states?
Adding states was one approach that was considered. In this model, rather than having state/status as separate, related attributes, you'd have just one attribute, we'll call "State" to mirror the term used above.
This could look like: Open | In Progress | Done | Closed. This mirrors MRs somewhat, where "Closed" is the negative/incomplete state separate from a "Merged", or here "Done", positive complete state.
While this also achieves the goals of increasing visibility of an item's status, this would be a bigger and riskier change, potentially breaking integrations or automations using state today and fundamentally changing the meaning of "Closed" items. Lists and boards currently utilize open/closed to segment items, which would in turn have to be extended to additional states. Separating status from state minimizes these risks while providing the same benefits.
Status categories
Categories help support configurable statuses, ensuring that the general meaning each status can be understood by the system. This will allow:
- Category-based rules, e.g. any status in a category is automatically closed
- Category-based segmentation, e.g. filter to "active" items via an "In progress" category, rather than selecting all in progress statuses.
- Potential for simplification of visuals and iconography to the category, rather than individual statuses
- Alignment with reporting such as flow metrics (how long as an issue in one category vs. another, rather than one status vs. another)
Categories will not be configurable. Statuses within a category can be configured; all statuses belong to one category.
| Category | Description | Default status(es) | Example GitLab workflow statuses |
|---|---|---|---|
| Triage (not MVC1) | Items that are waiting on some action before formally moving into the active workstream. That could be items awaiting triage or initial review and acceptance, items needing more detail, or items that just haven't been planned yet. Items in a backlog status will not count in most productivity analytics. | Triage | workflowstart / unlabeled items / backlog milestone |
| To do | Items that are waiting on action to be taken. Aligns to "waiting" in flow metrics. | To do | workflowready for design workflowvalidation backlog workflowready for development workflowplanning breakdown workflowscheduling workflowrefinement |
| In progress | Items that are currently being worked on. Aligns to "active" in flow metrics. | In progress | workflowproblem validation workflowdesign workflowsolution validation workflowin dev workflowin review workflowverification |
| Done | Items that have been completed/delivered. | Done | workflowcomplete |
| Canceled | Items that are no longer relevant and will not be completed, either because they've been rejected, or because the item is a duplicate or otherwise no longer tracked. | Not doing, Duplicate | wontfix Duplicate / Closed (duplicate) |
Default statuses
Defaults allow users to get started with status without having to set anything up. In the first iteration only defaults will be available; once configuration is added users can change or remove most defaults.
Default statuses will be: To do, In progress, Done, Won't do, Duplicate
Duplicate
Today, marking an item as a duplicate causes it to be closed with a closed note "duplicate". With status, this same behavior can exist but instead close the item and change the status to a default, fixed "Duplicate" status.
Moved and Promoted currently utilize the same logic, but with work items this need will be phased out as moving/promoting items will no longer cause a new item to be created.
📦 Archived proposal
Problem to solve
Currently in GitLab we utilize 2 different icon sets for status on issues and work items — one that uses a generic "circle" shape (deprecated) and one that uses issue/epic shapes combined with status detail.The type-specific icons will not scale well with work item types, and may be more difficult to differentiate when >2 statuses are available. It would also be ideal to utilize consistent iconography so that in a view with mixed types, users can quickly scan statuses in a standard format.The deprecated circle icons appear similar to radio buttons and can provide an unintended affordance.
To best support work items, status visualization and color should be abstracted to a more general pattern that can represent at a minimum each status category. While the final categories are being determined, it's expected that at least the following will exist: not started, active/in progress, done, cancelled.
Proposal
Using iconography to denote status will continue to be effective so that we can differentiate status without necessitating a label, as would be the case if relying on color alone.
| Category | Icon description | Icon (draft) | Color |
|---|---|---|---|
| Not started | Dashed circle |  |
$gray-500 |
| Active/in progress | Partially complete circle; could be filled or just have border partly dashed/solid. Could have different variations for different statuses in this category, e.g. 25/50/75% complete. Matches status-running |
 |
$blue-700 |
| Done | Check, filled circle if active is filled. Icon is used elsewhere, so alternate shape could be ideal, but conceptually aligned to other uses like approvals (approval status is done). Matches status-complete |
 |
$green-700 |
| Cancelled | "\", "/", "-" or "x", "x" may look interactive as close. "-" is same as current Closed, unless filled. Unfilled to allow filled to mean "progress". Matches status-cancelled |
 |
$red-700 |
RISK: Inverting the Done/In progress colors will align the status with Pajamas, and components like pipeline status, but will take this into direct conflict with MR status. Since these items can appear very near one another, unlike pipeline status, this is problematic. Either both should move together, or the blue/green colors should remain as-is to maintain consistency.
Application
| Context | Image |
|---|---|
| Relationship widget | tbd |
| Work item detail |  |
| Board |  |
| List |  |