## TL;DR: - [We've distributed all of the dependencies for the Work Items initiative to various teams](https://gitlab.com/groups/gitlab-org/-/epics/6033#critical-path) - [There's a lot that has to be built in order to achieve the `Feature` critical path](https://docs.google.com/spreadsheets/d/1AEYcOGhcF7v8ygCpnXEQWqPxBwRfuwTRsjUlvNyvjHY/edit#gid=0) - We can deliver substantial customer value earlier in the initiative by allowing users to create one or more Task work items within existing issues (PM Assumption | [Legacy Proposal](https://gitlab.com/gitlab-org/gitlab/-/issues/2036)). - We can more iteratively deliver on the dependencies for `Feature` and eventual parity with the legacy issue UI by allowing the task work item (new work item detail UI) to be viewed via a modal or side panel within the legacy issue UI (PM Assumption). - This allows us to iteratively deliver each widget within a relatively sandboxed environment while requiring very minimal work on the legacy issue UI (PM Assumption). ## Problem to solve 1. When cross-functional areas collaborate on a single issue, they each add weights and manually update the single Issue Weight field, so there is no clarity around which functional areas has how much weight per issue, making capacity planning difficult and inaccurate. 1. There is currently no way, other than manually creating issues and relating them, to manage cross-functional requirements and tasks on a single issues. Adding tasks or a similar solution to Issues is a precursor for solving these follow on problems: 1. If a single issue has multiple contributors responsible for implementation, its impossible to get an understanding of where an issue is and who it's waiting on without opening the issue and digging through the comments. This makes it hard for both the Engineering Manager and assigned Engineer to quickly understand where they need to focus their efforts when they down in the morning to work. **Job Stories:** > When I'm trying to understand my team's capacity vs. allocation, I want to see an accurate total allocated weight/count per engineer, so that I can make sure they aren't over or under allocated. > When managing my assigned work, I want to easily see what I'm responsible for on each issue, so that i can prioritize my time most effectively and perform ongoing triage efficiently as I context switch between Issues. > When planning an issue, we need a way for each functional part of the team to contribute to the overall issue weight while maintaining the individual weight parts, so that we account for the total work that needs to be done and have an accurate representation of the total complexity of a given issue. > When planning an issue, we need a way to quickly capture and break down technical requirements / steps necessary to complete a given issue, so that we derisk the issue and provide a more accurate issue weight in light of a given issue's completion criteria. ## Iteration Path Example UX: https://gitlab.com/gitlab-org/gitlab/-/issues/345169#note_736212696 This path would let us: 1. Iterate on the create/view process one widget at a time. 1. Iterate on the `workItem` GraphQL API while still maintaining compatibility with other APIs powering things like List and Board views. 1. Not involve disabling a bunch of stuff that we'll have to go re-enable later. 1. Solves the oprhan problem. 1. Doesn't break other things. 1. Allow a better user experience for viewing and updating `Task` within the context of an issue. Fringe cases: * What happens when you bulk edit on an issue list and `Task` does not yet have the widget you are bulk updating? * What happens when you drag `Task` from `Open` Board list to a list with an attribute that is not yet integrated into `Task`? ## Implementation Steps Anyone can update this at an point in time. <details> <summary>Expand breakdown:</summary> 1. Create Task w/ Title ~backend: - Add `Task` type to `work_items_types` table + migration - Hide `Task` as an option in the current issue creation flow. - Integrate `createWorkItem` mutation for https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73275/diffs - Add support for making the "related" link during the creation process. ~frontend: - Add button to `Convert to Task` - Make button open modal/sidebar with new work item detail view (create mode) - Prefill title with text from markdown taskable and auto-focus keyboard/cursor on the title input - Clicking out of the modal/sidebar before creation cancels the process - Click cancel in the modal/sidebar cancels the process - Click create uses the `createWorkItem` mutation - Handle mobile and desktop styling needs - After creation, replace the markdown taskable text in the description with a GFM issue reference to the newly created Task. - Provide a way for the user to understand any errors if they happen when clicking create. 2. View Task ~backend: - If backend is needed, When clicking through to Task detail view from anywhere other than issue detail, load the Task at the `/issue/123/ route.` - Provide GraphQL query for getting task information + widgets - Enable Title to be updated real-time via Subscriptions ~frontend: - When clicking on task (referenced from issue detail view), load task detail view in modal/sidebar. - When clicking through to Task detail view from anywhere other than issue detail, load the Task at the `/issue/123/ route.` - Enable Title to be updated real-time via Subscriptions - Optional: When clicking on task on Board, open Task detail view in modal instead of loading an empty sidebar (This can be optional but might be a nice way to slowly roll out interacting with the full issue from within a Board) - Optional: When clicking on task from List, open Task detail view in modal instead of redirecting to detail view (This can be optional but might be a nice way to slowly roll out interacting with the full issue from within a List and mimics the current behavior of Requirements) 3. Update Task ~backend: - Generic update mutation for `workItem` ~frontend: - When updating the title, use the `workItem` update mutation. 4. Fringe cases ~backend: - Prevent attributes from being updated on Task that don't "exist" yet (via Bulk Edit, Drag N Drop on issue board) -- more or less attributes that haven't been "widgetized" Next: Add support for the description widget </details> ## User Need Statement Parker, a busy Product Manager needs to quickly and confidently understand the capacity for each team member in order to know how to allocate resources and ensure the team is not overloaded or underutilized. ### Release Notes When planning an issue, there are often multiple different steps necessary to complete an issue such as front-end development, back-end engineering, documentation, and testing. You can now break down an issue into discrete tasks to track the steps needed for an issue to be completed. Up to this point, an issue only supported the ability to outline tasks via GitLab Flavored Markdown checklists from within the description. With this change, markdown checklist items can be seamlessly converted to tasks. When a task is created, it is automatically related to the issue from which it was created and you can also provide more context on the task by adding a description. Tasks are the next MVC toward our evolution to [work items](https://docs.gitlab.com/ee/development/work_items.html) and are not yet visible within Boards, but will be as soon as we add support for weight, assignees, labels, milestones, and iterations on Tasks. You can view the [roadmap](https://gitlab.com/groups/gitlab-org/-/epics/7103) to learn where we are heading or [share feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/363613) on specific areas that you'd like see improved. https://docs.gitlab.com/ee/user/tasks.html