<!-- 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 --> Slack channel: `#f_work-items` ## Problem - Using labels to denote Issue types is cumbersome and makes every reporting view more complex (because you have to include all labels in picking which you want to show analytics for). - [Issue Types](https://app.periscopedata.com/app/gitlab/654183/Plan-stage-.com-events) are one of the top two use cases of labels. Given that, we should provide first class support for it. - Issues are starting to feel cluttered as we add more and more capabilities to them. There is no consistent pattern for how to surface relationships to other objects, there is not a coherent interaction model across Issuables, and the various implementations of [issue types](https://docs.gitlab.com/ee/development/issue_types.html) are feeling the pain of the lack of flexibility and extensibility. - Currently Epics, Issues, and Merge Requests all have similar but just [subtle enough differences in common interactions](https://www.loom.com/share/84510f5c54ad442e9e20f952aede8060) that it requires the user to hold a complicated mental model of how each behave. - Issuables are not extensible enough to support all of the emerging jobs they need to facilitate. Teams can create their own first-class object and use shared concerns from Issuables, but this leads to duplicated effort and ultimately little differences between common interactions that lead to a less than ideal UX (see previous point/video). ## Long Term Vision Issues have the potential to be a key catalyst to increase SPAN and [SpU](https://about.gitlab.com/handbook/product/metrics/#stages-per-user-spu) as they can serve as the centralized hub for collaboration. In addition, by improving To Dos / Notifications, we have the opportunity to provide a framework for any Stage to cleanly integrate data in a standardized way into Issuables and surface via ToDos / work streams to reduce context switching and fragmentation of the user experience. **Diagram:** <details>  </details> ## Step 1: Converting Issuables To Share A Universal, Extensible Interaction Model We need to accept the fact that different issuable types will require different fields and different context depending on what job they are being used to accomplish. A defect will need to list steps to reproduce. An incident will need references to stack traces and other contextual information relevant only to that incident. A merge request will need up to date context on pipelines, etc. Instead of each object type diverging, we can standardize on shared concerns and abstract different issuable sub-interactions into standalone, full stack components that can be easily plugged into different issuable types. ### All Issuables Already Contain A Series of Sub-Jobs/Interactions Our current Issuables include many different kinds of sub-interactions (mini-apps) experiences that enable end users to complete a sub-job within a given Issuable. **Examples:** <details> > **Add related issues and declare dependencies amongst issues**  > **See and organize all sub-epics and issues so one can quickly put together a top down plan**  > **Approve a Merge Request**  > **Quickly get an overview of an incident**  > **Manage versioned designs**  </details> While some of these interactions are unique to a given issuable type, others could be widely applied to many types of issuables. Examples include *related x*, *approvals*, *design manager*, etc. As we've continued to iterate on issuables, we've made decisions that are generally best for a given issuable type based on what we know at the time. The problem with this approach at scale is that we are missing an overarching framework for issuables that enables us to both globally optimize while solving the local problem at hand -- and end up with the very problems this issue is aimed at solving. We need to move from the assumption that each Issuable has a 1:1 relationship with the mini-jobs and interactions it supports to one where each interaction/sub-feature is abstracted into a re-usable "mini-app" that can included on any issuable. **Example diagram:** <details>  </details> ### Fields, Relationships, Apps, and Actions **Example illustration:** <details>  </details> Inspired by Apple's [Human Interface Guidelines for Widgets](https://developer.apple.com/design/human-interface-guidelines/components/system-experiences/widgets/) and [Complications](https://developer.apple.com/design/human-interface-guidelines/components/system-experiences/complications/), an Issuable can contain several different components: ## Fields Fields are simple primitives that store meta-data specific to the issue but are not tied to a shared data model that is necessary for other features in GitLab to work properly. Examples include: - Description - Title - User defined custom field (https://gitlab.com/groups/gitlab-org/-/epics/235) **Quick Action support:** Custom fields will support a singular quick action to update any custom field. Ex: `[field: <select field> <select /enter new value>]` ## Relationships **Work Item tracking this:** https://gitlab.com/gitlab-org/gitlab/-/issues/229731 Relationships define the issue's relationship to other GitLab objects in both a vertical and horizontal hierarchical network model. Relationships can be 1:1 or 1:many. Meta data about related objects can be surfaced in the relationship cards within an issue. Examples include: - Blocking issues - Related issues - Finishes / Completes / Satisfies (exact terminology TBD) a parent issue type - Child issue types - Vulnerabilities - Incidents - Alerts - Merge Requests - Feature Flags **Quick Action support:** :white_check_mark: ## Apps **Work item for refactoring existing sidebar items:** https://gitlab.com/groups/gitlab-org/-/epics/5302 Apps can be represented as a simple field within an issue but associate the issue to larger GitLab features that may or may not be enabled on the given project. They are the primary entry point for integrating more complex experiences -- beyond relationships -- Examples include: - Time Tracking - Iterations - Milestones - Discussions - Attachments / Design Manager - Estimation (weight) - Assignee - Due Date - Workflows (Status) Apps are represented in the main thread with a simple UX to highlight the most important information about the app within the context of the Issue. The app may link to a tab within the issue with more robust interactions or to another view outside of the issue. **Quick Action support:** :white_check_mark: ## Actions: Global Global actions are things that impact the state of the overall issue itself. Examples include: - Toggle confidentiality - Close Issue - Clone Issue - New Issue - Move issue - Lock issue **Quick Action support:** :white_check_mark: ## Actions: User Specific User specific actions: - Todos - Toggle Notifications **Quick Action support:** :white_check_mark: ## References - Participants - Reference URL - Issue email address ### Issuable Type Shared Concerns - Each Issuable type has a unique icon. (https://gitlab.com/groups/gitlab-org/-/epics/5418) - Each issuable type may define their own default statuses with the knowledge that future capabilities will include allowing end users to customize the workflows (status) that each type of issuable progresses through. - Every Issuable has a title, description, and discussion. Each type may define defaults for things like sorting comments by newest first, etc. but must allow the end user to select their preferable defaults. - TBD: What is the best location for award emojis such that there is a consistent user experience? - Each Issuable Type can define the default/required Fields, Relationships, and Apps that are packaged with that particular type with the knowledge that future capabilities will include allowing end users to customize/add additional Apps/Complications. ## Step 2: Customizable Issuable Types & Workflows/Status **Custom Issue Types work item:** https://gitlab.com/gitlab-org/gitlab/-/issues/118666 **Custom Statuses work item:** https://gitlab.com/groups/gitlab-org/-/epics/5099 **Custom Workflows work item:** https://gitlab.com/gitlab-org/gitlab/-/issues/2059 Users can create many unique workflow steps. Each is backed with a verb that can be used to transition Issuables into the given workflow state via quick actions, commits, or merge requests. **Illustration:** <details>  </details> Users can define their own issue types and define the order of workflow steps that a given issuable type goes through. **Illustration:** <details>  </details> ## Tiering & Business Model - Default Issue Types will be available in ~"GitLab Core" - Custom Issue Types will be available in ~"GitLab Premium" - The developer(s) of each Issuable App/Complication decide which tier to place it in based on [GitLab's buyer model](https://about.gitlab.com/handbook/ceo/pricing/#four-tiers). - Instead of making a binary tiering decision, it is highly recommended to design App/Complications that provide **some** value for each tier and a clear upsell path from one to the next. - Example: Epics were initially restricted to Ultimate/Gold. By rethinking the behavior of the feature in line with our buyer model, we were able to offer single-level Epics to Premium. Think critically about how you can design Issuable Apps in such a way. ## Discovery - [ ] Mural: Create initial problem statement & identify relevant job(s) - [ ] Mural: Capture individual brainstorming ideas for feature - [ ] Mural: Prioritize ideas in a matrix - [ ] Mural: Iterate on problem statement after exercise - [ ] Figma: Create task flow of screens based on ideas broken into [Sees and Dos ](https://medium.com/@tyrale/ux-triage-what-i-have-learned-performing-ux-audits-around-the-globe-250266ac95a5) - [ ] Figma: Using atomic design principles, flesh out the [See | Do](https://medium.com/@tyrale/ux-triage-what-i-have-learned-performing-ux-audits-around-the-globe-250266ac95a5) concept - [ ] Figma: Create low-fi wires of possible solutions based on See | Do - [ ] Figma: Outline key interactions such as on hover, on focus, etc. - [ ] Figma: Conduct min 5 usability tests on design once it’s refined enough /