Customizable Issue Types

Problem to solve

The only way to classify an issue type is by label. This makes it difficult to do analytics and other meaningful type-specific workflow customizations difficult.

As a Product Manager, I need to be able to classify work items by specific, pre-defined types so that I can easily report on their progress.

Examples:

  • If an issue is an incident, default the discussion order to newest first to better accommodate firefighting mode.
  • If an issue is a defect, apply a specific issue template.
  • See a breakdown of types of issues delivered in a given milestone.
  • More effectively allocate capacity of a given milestone to specific types of issues - 60% feature, 20% defects, 20% technical debt.
  • Surface issue type on issue cards within boards and hide other labels.
  • Define workflow A for defects and workflow B for features.

Proposal

Release Post

features:
  secondary:
    - name: "Customizable issue types"
      available_in: [starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/'
      reporter: gweaver
      stage: plan
      categories:
        - 'Issue Tracking'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/118666'
      description: |
        Instead of relying solely on generic labels to classify issues, you can now customize the types of issues 
        within your group. Using issue types enables more robust analytics into the health of your value stream and is 
        the first step we're taking towards supporting more extensible workflows within GitLab.

Defaults:

  • Feature: newly proposed characteristic of a product
  • Bug: problem resulting in an interruption to a user's flow or productivity
  • Enhancement: improvement to a feature
  • Tech Debt Maintenance: not a bug, but an area in need of review for improvement in design or code (or both)
  • Incident (Existing): critical, high level problem needing immediate attention and impacting many users
  • Test Case (Existing): documented specifics surrounding the attempt to determine if something is working properly in the product
  • Issue (existing): any general idea, update or change
  • Requirements: an artifact which describes the specific behavior of your product. Requirements are long-lived and don’t disappear unless manually cleared.

Behavior:

  • Within a group (the top most parent group), CRUD types within an "issue types" list.
  • Each type has a field for the name of the type (required), a description (required), and an emoji/icon (required) representative of the type.
  • If a user tries to delete a type, require double confirmation and clearly communicate the number of issues with that will lose the current type.

What does success look like, and how can we measure that?

Success Metrics

  • % of issues using issue types

Acceptance

  • Documentation
  • GraphQL first
  • Pajamas First
  • APIs implemented
  • Defaults set
  • Gist of the proposal is implemented

What is the type of buyer?

Icons

The issues for getting the icons for each of the default issue types is being tracking here -- &5418 (closed)

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.

Edited by 🤖 GitLab Bot 🤖