## Context Migrating issues to work items should feel much less disruptive compared to migrating epics to work items. With that said, it is still important to get as much feedback as possible prior to defaulting the new work item view to on for issues. ## Proposed staged rollout - **Stage 1 (NOW)**: Provide a toggle to switch between the legacy issue view and the new work item view. This is controlled with a FF based on a user actor. - **Stage 2**: Pilot feedback group. Enable the FF for the participants. Post in `#whats-happening-at-gitlab`. Create pilot feedback issue and slack channel. Blockers: - Development widget is more functional. - Design widget is polished. - Most frequently used quick actions are supported. - _TODO_: Figure out if we can find some GitLab.com customer users who want to participate to get a broader perspective of use cases. An external cohort would be extremely helpful. - _TODO_: Make sure to invite SA SMEs to the test group. - UX Research Issue: https://gitlab.com/gitlab-org/ux-research/-/issues/3303+ - **Stage 3**: Default the toggle to the work item detail view. Internal team members can still switch back to the legacy version. - Optional: Find customers on GitLab.com that want to participate. - **Stage 4**: Remove the toggle. - **Stage 5**: GA - GitLab.com incremental rollout. - Self-managed default to ON - Prior to rollout: Collaborate with engineers to identify charts/graphs/metrics we want to monitor closely during the phased rollout. ## Dates The following dates are subject to change based on what we learn from each subsequent stage. <table> <tr> <th>Date</th> <th>Activity</th> <th>Status</th> </tr> <tr> <td>2025-01-20</td> <td>Kick-off internal limited pilot (Stage 2a)</td> <td> Tasks: * [ ] Ensure contextual view is enabled and connected to the "new issue look" toggle. * [x] Create feedback issue: https://gitlab.com/gitlab-org/gitlab/-/issues/512715 * [ ] Recruit in `#whats-happening-at-gitlab` * [ ] Enable FF for participating users * [ ] Monitor feedback issue </td> </tr> <tr> <td>2025-01-20</td> <td>Kick-off external limited pilot (Stage 2b)</td> <td> :warning: Pending verification of no critical defects in Stage 2a. Tasks: * [ ] Recruit participants * [ ] Create external feedback issue * [ ] Resolve the following items https://gitlab.com/gitlab-org/gitlab/-/issues/461855#note_2294801631 * [ ] Enable FF * [ ] Monitor feedback issue </td> </tr> <tr> <td>2025-01-20</td> <td> Enable toggle for `gitlab-org` and `gitlab-com`. Dependency: Enable an FF with namespace actors. (Stage 3) </td> <td> :warning: Pending verification of no critical defects in Stage 2a. Tasks: * [ ] Switch FF actor * [ ] Default toggle to ON * [ ] Post in `#whats-happening-at-gitlab` * [ ] Verify adequate product documentation coverage and create issues for any necessary changes and/or improvements </td> </tr> <tr> <td>2025-02-03</td> <td>Remove toggle and default to ON for GitLab.com (Stage 4, 5)</td> <td> :warning: Pending verification of no critical defects in Stages 2b and 3. Tasks: * [ ] Collaborate with Amanda on release post item(s) * [ ] Communicate ahead of time with Customer Support to give them a heads-up * [x] Remove toggle & default FF to ON for GitLab.com </td> </tr> </table> ## UX > From our sync we discussed needing design for how we'd show users which mode they're using and change modes, and to identify potential value add features we can either promote or easily add within the work item mode to encourage use and testing. ## FF and tasks to bundle rollout items with the legacy vs. new toggle - [ ] `:work_items_view_preference` feature flag adds the toggle, using the user actor - [ ] Move everything that is in `work_items_beta` out, ensuring that those changes are ready for GA on the task, okr, and epic work item types. - [ ] Any new work for the issue work item type ready for dogfooding should skip `work_items_beta`, so go `work_items_alpha` to no feature flag (since it will be behind the toggle). ## Release Post Planning | New Thing | Tier | Description | |-----------|------|-------------| | Start date | Free | Set a start date on an issue. | | Link any work item type to another. | Free | Tasks, Issues, Epics, and other work item types can now be linked. | | Parent widget | Premium | Epic selector in the issue sidebar has been renamed to the "Parent" | | Real-time | Free | The issue detail view now updates in real-time when any data is updated. | | Ancestors | Free | View the complete lineage of parent work items at the top of the detail view. | | Secondary actions menu included in the sticky header | Free | Easily edit issues or take actions on an issue without having to scroll to the top. | | Change type | Free | Change an issue to another available work item type from the secondary actions menu or with the `/type` quick action. | | Move and Confidentiality | Free | Moving an issue and toggling issue confidentiality has been moved to the secondary actions menu. | | Drag and Drop Linked Items | Free | Drag and drop linked items to change relationship type or order. | | Development widget | Free | Merge requests, branches, and feature flags related to an issue or task are now consolidated in a single list. Easily copy references or branch names for each item in the list. | | UI/UX Polish | Free | Easily bulk remove labels and assignees when editing, simplified sidebar layout, ... | | Linked Items List Actions | Free | Show or hide linked item labels and closed work items. | | Parent/child quick actions | Free | The `/parent_epic` `/remove_epic` quick action has been deprecated in favor of `/set_parent`, `/remove_parent`, `/set_child`, and `/remove_child` |