## [Iteration 1: Introduce Status](https://gitlab.com/groups/gitlab-org/-/epics/11975#iteration-1-introduce-status) _Outcome: Users can set a view and set status on Tasks from a predefined list of statuses, beyond open/closed._ _Start with Tasks: Issue workflows are deeply entrenched in user workflows and without a fully customizable solution, we won't be able to replace status labels resulting in an interim state where users could have to update both status and label status. While this can still be true of tasks, Tasks are in many cases used for smaller items of work that may require fewer discrete statuses — just knowing todo, doing, done will provide value in most cases and often may not require further status labeling. Tasks will allow us to build the component in the work item framework, without impacting issues or epics but with easy reuse in those items in later iterations._ ### Designs * [Item detail](https://gitlab.com/gitlab-org/gitlab/-/issues/383125/designs/Detail_page__Set_view_status.png "Detail_page__Set_view_status.png") * [List items (tasks)](https://gitlab.com/gitlab-org/gitlab/-/issues/383125/designs/List.png "List.png") * We could consider adding a "Task status" filter, but this may be more confusing than valuable at this point * [Child and linked items (tasks)](https://gitlab.com/gitlab-org/gitlab/-/issues/383125/designs/Child_items.png "Child_items.png") ### Additional reference * See the requirements SSOT parent epic, https://gitlab.com/groups/gitlab-org/-/epics/5099, for more information * A deep dive into UX concerns can be found in https://gitlab.com/groups/gitlab-org/-/epics/11975 * [UX video walkthrough](https://www.youtube.com/watch?v=SRM_EiW0YPM) (19:06, chapters by background, iteration plan, status categories, and initial design)